La campagne GhostAction cible les secrets CI/CD de GitHub via des comptes compromis

Une nouvelle vague de l'attaque sur la chaîne d'approvisionnement GhostAction a compromis environ 1 900 comptes utilisateurs GitHub entre le 8 et le 9 octobre 2026. Les chercheurs en sécurité de GitGuardian ont observé que les acteurs de la menace ciblaient plus de 30 000 dépôts appartenant à 3 000 utilisateurs et organisations, dans le but d'extraire des identifiants sensibles depuis les environnements d'intégration continue.

Ce qui s'est passé

La campagne, identifiée pour la première fois en septembre 2025, repose sur l'obtention par les attaquants d'un accès en écriture aux dépôts légitimes des développeurs. Ils y parviennent en utilisant des jetons d'accès personnels (PAT) volés ou des identifiants extraits des journaux de logiciels espions (infostealers). Une fois à l'intérieur, les attaquants injectent des fichiers de workflow GitHub Actions malveillants dans les dépôts ciblés. Ces fichiers sont souvent déguisés sous des noms trompeurs tels que "security-audit.yml" ou "github_actions_security.yml" pour éviter tout soupçon immédiat lors des revues de code superficielles.

L'objectif principal est le vol à grande échelle de secrets stockés dans les pipelines CI/CD. Cela inclut les identifiants des fournisseurs cloud, les jetons de registres de paquets pour des services comme npm, PyPI et DockerHub, ainsi que les clés API des fournisseurs d'intelligence artificielle. Le récent pic d'activité représente une escalade significative, les attaquants ayant tenté d'extraire 3 174 secrets depuis des dépôts publics. Gaetan Ferry et Guillaume Valadon de GitGuardian ont noté que la compromission de 1 900 comptes était la cause directe de cette tentative généralisée.

Cette nouvelle phase de GhostAction semble plus expérimentale et manuelle que les itérations précédentes. La charge utile a évolué à travers plusieurs versions depuis le 31 août 2026. La première version introduisait une fonctionnalité permettant de scanner l'historique git à la recherche de secrets, en utilisant des expressions régulières pour identifier les ID de clés AWS, les jetons GitHub et GitLab, ainsi que d'autres clés API cloud. Les variantes ultérieures ont amélioré cette capacité en capturant le contexte autour des ID de clés AWS pour les associer à leurs clés d'accès secrètes correspondantes, augmentant ainsi la probabilité que les données volées soient utilisables.

Détails clés

• Échelle de l'impact : Le pic des 8-9 octobre a ciblé plus de 30 000 dépôts appartenant à 3 000 utilisateurs et organisations.
• Compromission des comptes : Environ 1 900 comptes GitHub ont été compromis à l'aide de PAT volés ou d'identifiants issus de journaux d'infostealers.
• Secrets ciblés : Les attaquants ont tenté d'extraire 3 174 secrets, y compris des identifiants cloud, des jetons de paquets et des clés API IA.
• Évolution de la charge utile : Le workflow malveillant a évolué pour inclure le scan de l'historique git, les versions ultérieures capturant le contexte autour des clés AWS pour faciliter le vol complet des identifiants.
• Méthode de déploiement : Les workflows malveillants ont été poussés sous des noms trompeurs comme "security-audit.yml" pour se fondre dans les tâches de maintenance légitimes.
• Chronologie de la mitigation : GitHub a commencé à empêcher l'exécution du workflow malveillant le 9 octobre, stoppant les vagues suivantes les 10 et 12 octobre avant qu'elles n'extraient de nouveaux secrets.

Contexte

GitHub Actions est une plateforme d'automatisation populaire qui permet aux développeurs de définir des workflows pour construire, tester et déployer du code directement au sein de leurs dépôts. Ces workflows nécessitent souvent un accès à des informations sensibles, telles que des mots de passe de base de données ou des clés de services cloud, qui sont stockées en tant que « secrets » dans les paramètres du dépôt. Bien que pratique, cette centralisation fait des pipelines CI/CD une cible de haute valeur pour les attaquants. Si un attaquant peut modifier la définition du workflow, il peut exécuter des scripts qui exfiltrent ces secrets vers des serveurs externes.

Les attaques sur la chaîne d'approvisionnement comme GhostAction exploitent la confiance inhérente aux écosystèmes de développement logiciel. En compromettant un seul compte développeur, les attaquants peuvent propager du code malveillant à tous les projets maintenus par cette personne. C'est particulièrement dangereux car le code malveillant provient d'une source fiable, ce qui rend sa détection plus difficile pour les outils de sécurité automatisés ou les pairs reviewers. L'utilisation de logiciels espions pour récolter les identifiants initiaux souligne l'importance de la sécurité des terminaux en complément des protections spécifiques à la plateforme.

Pourquoi c'est important

Pour les équipes qui gèrent leur propre infrastructure logicielle, cet incident souligne la fragilité de la gestion des identifiants dans les pipelines CI/CD. De nombreuses organisations comptent sur des secrets à longue durée de vie qui sont rarement renouvelés. Le fait qu'une partie des victimes de cette nouvelle vague ait déjà été compromise lors d'attaques précédentes suggère que les attaquants misent sur la validité persistante des secrets non renouvelés. Si votre équipe ne renouvelle pas régulièrement les clés API et les jetons, une seule brèche peut avoir des conséquences durables, permettant aux attaquants de maintenir leur accès même après que la vulnérabilité initiale a été corrigée.

De plus, l'évolution de la charge utile de GhostAction démontre que les attaquants s'adaptent activement aux mesures défensives. L'ajout du scan de l'historique git signifie que la simple suppression d'un secret du code actuel est insuffisante s'il existe dans l'historique des commits. Les équipes doivent considérer que tout secret jamais commité dans un dépôt est potentiellement exposé. Cela nécessite un changement de stratégie, passant d'un nettoyage réactif à une gestion proactive des secrets, incluant l'utilisation de jetons à courte durée de vie et des contrôles d'accès rigoureux pour les modifications de dépôts.

Que pouvez-vous faire

• Renouvelez immédiatement tous les secrets CI/CD : Considérez que tout secret stocké dans un dépôt GitHub a pu être exposé si votre compte faisait partie de la base d'utilisateurs affectée ou si vous utilisez des schémas similaires.
• Activez les règles de protection des branches : Exigez des revues de pull request et des vérifications de statut avant la fusion des modifications dans les branches principales pour empêcher les modifications non autorisées des workflows.
• Auditez l'historique git à la recherche de secrets : Utilisez des outils pour scanner l'intégralité de votre historique de commits à la recherche d'identifiants fuités, et non seulement la tête actuelle de la branche.
• Implémentez le principe du moindre privilège : Restreignez qui peut pousser des fichiers de workflow et gérer les secrets dans vos dépôts, réduisant ainsi la portée d'un compte compromis.
• Utilisez des identifiants à courte durée de vie : Lorsque c'est possible, remplacez les clés API à longue durée de vie par des jetons temporaires qui expirent automatiquement, limitant la fenêtre d'opportunité pour les attaquants.
• Surveillez les activités inhabituelles des workflows : Configurez des alertes pour les modifications apportées aux fichiers de workflow, surtout ceux dont les noms ressemblent à des audits de sécurité ou des tâches de maintenance.