GhostAction Campaign engage des comptes de maintenance et insère des flux de travail pour exfilter des secrets

Les chercheurs en sécurité ont redétecté une vaste campagne de vol d'identités qui exploite les comptes de maintenance de projet open source pour insérer des flux de travail malveillants dans les dépôts GitHub. Selon plusieurs rapports techniques - dont ceux de StepSecurity, Socket et GitGuardian -, les agresseurs liés à la campagne connue sous le nom de Action fantôme ils ont engagé des comptes de maintenance de bonne réputation et poussé un fichier de flux de travail qui attire des secrets vers un serveur contrôlé par l'opérateur. Les faits confirmés comprennent des engagements documentés dans plusieurs fenêtres temporaires (p. ex. 27 dépôts à 13: 20 UTC sur le compte de Takashi Kitao et 318 dépôts en 16 minutes sur le compte d'Henry Wu) et la détection de centaines de comptes et de milliers de secrets exfiltrés pendant la période visée par le rapport.

La technique n'est pas une vulnérabilité dans GitHub elle-même, mais un abus des identifiants de maintenance (probablement des jetons d'accès personnels, PAT) pour modifier la branche par défaut des projets et ajouter un workflow qui fonctionne avec le dépôt permet. Le fichier malveillant est présenté avec des noms légitimes tels que "security-audit.yml" ou "github _ actions _ security.yml" et effectue quatre tâches clés pendant son étape "Audit" : il ajoute les secrets désignés du dépôt, recherche dans les profils d'identification de l'arbre de travail (13 modèles associés à AWS, fournisseurs d'IA, registres et services Cloud), scanne l'historique git entier pour les identifiants précédemment compromis et combine les ID d'accès AWS avec leurs clés d'accès secrètes. Les données collectées sont envoyées par HTTP à une IP dure (193.32.204 [.] 199), ce qui confirme l'exfiltration de secrets non chiffrés.

Ce qui est prouvé: Plusieurs entreprises de sécurité ont observé le même flux d'attaque; les flux de travail malveillants activent le flux de travail _ expédition et fonctionnent après des énigmes non filtrées, utilisent la profondeur de l'ajustement: 0 pour accéder à l'historique, et les jetons exfilter et les clés de service tels que PyPI, npm, DockerHub, AWS, OpenAI, Anthropic, OpenRouter et Tokens de GitHub / GitLab. Les rapports publics indiquent des chiffres précis: Socket a détecté plus de 500 comptes qui ont pris des engagements de workflow depuis le 7 octobre 2026 et, lors d'un balayage précédent, GitGuardian a signalé 772 dépôts publics touchés entre le 31 août et le 30 septembre 2026; un autre dénombrement cite 817 dépôts engagés et 3 325 secrets exfiltrés.

Ce qui est inféré mais pas entièrement prouvé: la source exacte des lettres d'identité utilisées pour prendre les comptes - les points d'analyse aux jetons filtrés dans des boucles d'information-voleurs ou des lettres d'identité -; bien que cette hypothèse corresponde aux modèles précédents de GhostAction, il n'y a pas de suivi public qui démontre la chaîne complète du vol initial de PAT au commit malveillant dans chaque compte affecté. Il n'y a pas non plus de preuves publiques, pour l'instant, de paquets malveillants publiés dans des dossiers avec des justificatifs volés - bien que la modification d'une image Docker ait été documentée pour inclure un mineur dans au moins un cas.

L'impact pratique pour les projets et les organisations est direct: tout secret présent dans le dépôt (soit dans les variables d'Actions, dans les fichiers d'arborescence de travail ou dans les anciens engagements) peut être lu et exfiltré, et donc les vecteurs sont ouverts pour compromettre les infrastructures CI / CD, les enregistrements, les services cloud et les comptes de développeurs. De plus, l'utilisation de la propre identité du responsable pour insérer la charge rend plus difficile de distinguer l'activité malveillante des changements légitimes dans les examens de surface, et la présence de flux de travail dans les fourches et les miroirs (y compris les fourches privées) amplifie la surface d'exposition. Socket a averti que de nombreuses fourchettes dans l'espace de noms d'un des comptes affectés continuaient à porter la définition malveillante, permettant une exécution supplémentaire si Actions est activé.

Pour les développeurs et les administrateurs de dépôt, la réponse doit être immédiate et pratique. Tout d'abord, vérifiez s'il y a un fichier sur une branche (y compris par défaut) appelé "security-audit.yml" ou "github _ actions _ security.yml" ou tout flux de travail suspect ajouté depuis le 31 août 2026; s'il apparaît, faites un engagement. L'élimination du fichier malveillant de toutes les branches n'est pas suffisante à elle seule : il est nécessaire de révoquer le titre compromis (PAT), de faire pivoter toute clé ou jeton qui aurait pu être dans le dépôt (PyPI, npm, DockerHub, AWS, services IA, GitHub / GitLab, etc.) et de régénérer l'accès. Il convient également d'inspecter les fourches et les myrors - les fourches publiques et privées peuvent hériter du flux de travail et exécuter les expéditions subséquentes - et de désactiver les actions GitHub dans les dépôts qui ne l'exigent pas.

Sur le plan opérationnel, l'examen de l'historique des actions permet d'identifier les exécutions inhabituelles (flux de travail _ envoi invoqués à l'extérieur, exécutions causées par des puzzles de comptes commis), ainsi que les dossiers du réseau d'audit et de l'IC pour détecter les connexions sortantes à des adresses suspectes (p. ex., la PI observée 193.32.204 [.] 199) aidera à réduire la portée. La recherche de motifs de références sur l'arbre et dans l'historique git est critique : puisque le workflow fait fsch-profondeur : 0, l'adversaire avait accès à l'historique complet. Pour rechercher des secrets involontaires, vous pouvez utiliser des outils de numérisation tels que ceux proposés par GitHub (scannage secret) et des produits tiers spécialisés dans la détection de secrets dans les dépôts; GitHub documente ses capacités de numérisation secrètes sur son site officiel.

Mesures spécifiques recommandées: 1) Revoir et faire tourner immédiatement les PAT, les clés de service et les jetons répertoriés; 2) supprimer le flux de travail malveillant dans toutes les branches et fourchettes, et désactiver les actions jusqu'à ce que vous confirmiez le nettoyage; 3) activer ou revoir les politiques d'approbation pour les flux de travail externes et bloquer l'exécution automatique des flux de travail non vérifiés; 4) permettre la numérisation secrète et les alertes de sécurité dans l'organisation; 5) examiner et vérifier les logos CI / CD et le trafic sortant vers des IP/hôtes non reconnus; 6) forcer 2FA et examiner les sessions et examiner les applications autorisées ainsi que tenir des réactifs privés et / ou traiter les fichiers associés;

Pour guider les incidents et les mesures d'atténuation, la documentation officielle sur les actions et la numérisation secrète se trouve dans les ressources de GitHub (https: / / docs.github.com / fr / actions et https: / / docs.github.com / fr / code-security / secret-scanning / about-secret-scanning). Il est également utile de suivre l'analyse de tiers tels que GitGuardian, qui centralisent les indicateurs publics et les détections (https: / / www.gitGuardian.com /). Le fait d'avoir ces procédures normalisées dans les dossiers d'intervention en cas d'incident réduit le temps d'exposition et facilite la révocation ordonnée des titres de compétence.

Le fait est que cet épisode met en évidence un principe récurrent de la sécurité de la chaîne d'approvisionnement: les comptes humains avec de grandes permissions sont des vecteurs à impact élevé. Tout en étudiant l'ampleur totale et la provenance des jetons utilisés, les gestionnaires de projet doivent supposer que la simple présence d'un flux de travail suspect implique une exfiltration possible et agir avec la rotation des pouvoirs et la révocation de l'accès. Les défenses efficaces combinent la prévention (limitation du permis, politiques d'examen du flux de travail), la détection (analyse secrète, surveillance de l'action) et la réponse rapide (rotation et nettoyage), et dans ce cas particulier sont les seules mesures qui réduisent l'accès de l'agresseur aux secrets déjà reproduits.