GhostAction élargit l'attaque: phishing pour voler les lettres de créances et la persistance dans le code VS

Un groupe derrière la campagne GhostAction - déjà connu pour infiltrer les workflows GitHub Actions dans des projets open source - a élargi son arsenal: en plus d'installer des workflows malveillants dans des dépôts commis, il envoie maintenant des emails supplantantant pour capturer des identifiants et livre un chargeur d'information déguisé en source (.woff2) qui agit comme un infostealer avec persistance dans les équipes de développeurs. Cette évolution, rapportée par OpenSourceMalware et reproduite par des moyens de sécurité, montre une transition de l'exploitation pure de l'exécution automatique en CI à une combinaison d'ingénierie sociale, d'abus d'OAuth et de persistance dans l'environnement de développement.

Faits confirmés : OpenSourceMalware des chercheurs ont identifié un domaine enregistré comme my-github [.] COM that points to IP 193.32.204 [.] 199 - le même IP utilisé par la campagne pour exfilter des données - et a observé que le domaine a été utilisé dans un message d'hameçonnage qui imitait un avis de sécurité GitHub pour capturer des mots de passe et des codes 2FA. La page frauduleuse a agi comme un mandataire inverse : elle a volé des identifiants et a exécuté JavaScript qui a automatiquement autorisé une application OAuth et a complété le flux du périphérique GitHub pour obtenir un jeton avec repo, workflow et lire : permissions d'org. Ce jeton vous permet de modifier les fichiers sous .github / workflows / et de réinjecter des workflows malveillants. En outre, une deuxième étape a été détectée dans 94 dépôts : inclusion d'un .vscode / tasks.json avec déclenchementOn: folderOpen, un fichier public / polices / fa-solid-400.woff2 contenant la charge utile pour voler des identifiants (AWS, PyPI, npm, Kubernetes, SSH, jetons des fournisseurs IA) et un flux de travail de sauvegarde qui, si la première piste n'exécute pas le voleur, lance l'extraction et installe un conne qui exécute le code attaquant toutes les cinq minutes ; le même filtre se produit au HT80 / 80TP.

Comment fonctionne la chaîne d'attaque techniquement: la séquence combinée déclarée peut être résumée de cette manière. D'abord, l'acteur commet des dépôts et ajoute un flux de travail malveillant qui, si exécuté sur GitHub Actions, recueille des secrets accessibles (jetons GitHub, identifiants sur la repo) et les envoie à un serveur contrôlé. Pour supprimer les blocs dans les workflows, l'attaquant utilise le phishing dirigé : un domaine similaire à GitHub est enregistré et utilisé pour envoyer une fausse notice de connexion. La page proxy vole les identifiants et, à travers les scripts, automatise le flux du périphérique GitHub pour obtenir un jeton réutilisable sans interaction utilisateur consciente. Avec ce jeton, l'acteur peut écrire de nouveaux workflows ou fichiers dans des dépôts. Si le contrôle des performances d'Actions est limité par GitHub, l'adversaire ajoute des composants qui sont exécutés localement dans la machine du développeur (tâches VS Code et fichiers binaires déguisés en sources) pour persister et voler des secrets locaux, installant également un cron pour maintenir un accès régulier.

Qui est touché et pourquoi il est pertinent: la cible principale sont les responsables de projets open source et les développeurs ayant accès à des dépôts vulnérables ou abandonnés. OpenSource Les malwares représentaient 94 dépôts affectés appartenant à 66 propriétaires; de nombreux dépôts étaient inactifs (la plupart sans engagement en plus d'un an). La combinaison de dépôts non protégés et d'autorisations excessives dans les jetons GitHub facilite l'expansion latérale : avec un jeton de dépôt, l'attaquant peut affecter l'intégration, les paquets et les utilisateurs en aval qui font confiance à ces dépôts.

Les conséquences pratiques comprennent la perte de jetons réutilisables qui permettent de modifier le code et les flux d'IC, l'exposition des identifiants de cloud et les dossiers des fournisseurs (AWS, npm, PyPI), le vol de clés SSH et les secrets API IA - toutes les données qui permettent de l'abus d'infrastructure à la distribution de logiciels malveillants par des artefacts légitimes. En outre, la persistance locale à travers un fichier qui est activé lors de l'ouverture du projet dans VS Code augmente le risque: le développement avec un dépôt compromis peut transformer le poste de travail en porte arrière.

Confirmé contre incertain : est un fait vérifié, selon les rapports, que le domaine my-github [.] com a été utilisé pour le phishing et que la PI ci-dessus a servi de point d'exfiltration. La conception technique de l'automatisation du débit du dispositif pour les jetons est également confirmée. Il n'est pas clair - selon les chercheurs eux-mêmes - si d'autres domaines avec des noms similaires (par exemple mon-gitlab [.] com) appartiennent au même opérateur: les enregistrements, les régulateurs et les appareils CRYPTO / DNS ne montrent pas de connexion directe. L'attribution de l'acteur reste non confirmée et la motivation exacte (financière, espionnage, preuve conceptuelle) n'a pas été établie publiquement.

Interprétation et contexte : La tactique révèle deux tendances connues mais plus agressivement combinées : a) abus du mécanisme de flux OAuth/Device pour obtenir des références persistantes sans intervention explicite de l'utilisateur, et b) utilisation de vecteurs de persistance dans les outils de développement (code VS) qui ne sont pas toujours vérifiés par les contrôles de l'IC. La réponse de GitHub - bloquer l'exécution du workflow malveillant - a réduit l'efficacité de la première étape, mais l'acteur a répondu en quelques jours avec un design qui évite la dépendance du coureur. Cela illustre la dynamique offensive et défensive dans laquelle les attaquants adaptent leur infrastructure après chaque mesure d'atténuation.

Mesures spécifiques à prendre aujourd'hui par les développeurs et les administrateurs: révoquer tous les jetons et toutes les autorisations de GitHub à partir d'un appareil propre et faire pivoter tous les identifiants qui ont pu être accessibles aux workflows (clé de nuage, jetons de paquet, identifiants d'inscription). Revoir et supprimer les applications OAuth inconnues sur la page de configuration > Applications OAuth autorisées et dans la gestion des jetons de l'organisation. Audit des dépôts par des fichiers suspects (.github / workflows avec des noms d'IC communs, .vscode / tasks.json, des sources inhabituelles en public / polices) et par tout cron programmé ou tâche dans les postes de travail développeur. Rechercher les connexions sortantes vers 193.32.204 [.] 199 et domaines my-github [.] com et les bloquer au niveau du réseau. Activer des politiques qui limitent le flux de travail permet à ce qui est strictement nécessaire et nécessite des examens manuels pour les changements dans .github / workflows; utiliser des outils de protection tels que GitHub Actions de durcissement de sécurité et Exiger l'approbation pour l'accès de tiers dans les organisations. Pour les titres de créance de grande valeur (cloud, IA) envisager la rotation immédiate et l'utilisation des titres de créance à court terme et des services de gestion secrète. Enfin, pour renforcer la protection contre l'hameçonnage d'OAuth, promouvoir les mécanismes d'authentification résistant à l'hameçonnage (clés de sécurité de l'FIDO) et l'éducation spécifique au génie social à l'aide de pages proxy et de flux automatiques.

Pour plus d'informations techniques sur la façon dont le débit de l'appareil et les mesures préventives fonctionnent dans Actions, voir la documentation officielle de GitHub sur le débit de l'appareil et les recommandations de durcissement de l'action : https: / / docs.github.com / fr / applications / oauth-apps / building-oauth-apps / authoring-oauth-apps # devicu-flow et https: / / docs.github.com / fr / actions / guides de sécurité / actions de sécurité-durcissement-pour-github. Vous pouvez également suivre la recherche et les échantillons dans le dépôt d'analyse d'OpenSourceMalware: https: / / opensourcemalware.org /.

Bref, l'opération GhostAction a démontré la capacité d'adapter et de mélanger rapidement la chaîne d'approvisionnement, le phishing OAuth et les techniques de persistance locales. Les développeurs et les organismes de maintenance libres doivent supposer que tout dépôt ayant un historique d'engagements inactifs ou récemment non audités pourrait être un vecteur et agir en priorité dans la révocation, la rotation et le durcissement des permis.