La campagne GhostAction utilise des comptes GitHub compromis pour injecter un workflow GitHub Actions malveillant qui exfiltre les secrets CI/CD des dépôts ; elle a fortement accéléré les 8 et 9 octobre 2026. Cette analyse s’adresse aux auditeurs, RSSI et responsables sécurité : mode opératoire, correspondance avec MITRE ATT&CK, détection, questions d’audit ISO 27001 et pistes de sensibilisation. Elle repose principalement sur les travaux publiés par GitGuardian : l’attaquant n’est pas identifié et le nombre de secrets réellement volés en octobre n’est pas publié.
Pour une lecture orientée dirigeant, voir notre décryptage « GhostAction : des comptes de développeurs piratés pour voler les clés des serveurs ».
Contexte
- Ampleur : environ 1 900 comptes GitHub compromis, plus de 30 000 dépôts visés appartenant à environ 3 000 utilisateurs et organisations, 3 174 secrets ciblés lors de la vague d’octobre (GitGuardian, mis à jour le 13 octobre 2026 ; The Hacker News, 15 octobre 2026). Pas de liste publique des organisations touchées.
- Chronologie : campagne découverte en septembre 2025 (817 dépôts, au moins 3 325 secrets exfiltrés) ; activité résiduelle entre octobre 2025 et avril 2026 ; nouvelle vague du 31 août au 30 septembre 2026 (772 dépôts publics, 2 577 secrets visés) ; accélération les 8 et 9 octobre 2026 ; nouvelles injections les 10 et 12 octobre, dont le workflow n’a pas pu s’exécuter, GitHub le bloquant depuis le 9 octobre.
- Secrets les plus visés (vague de septembre 2026) : clés SSH et accès aux serveurs de déploiement (446), accès Azure (218), registres de conteneurs (142), bases de données (112), clés AWS (106), FTP (92), Google Cloud et Firebase (80), jetons GitHub (66), puis jetons de bots, Cloudflare, npm, PyPI et clés d’API de fournisseurs d’IA.
- Taux de réussite : en septembre, GitHub a retenu la plupart des exécutions en attente d’approbation ; GitGuardian compte 26 secrets exfiltrés dans 13 dépôts. Début octobre, les workflows se sont exécutés et Socket confirme des exfiltrations réussies, sans total publié.
Mode opératoire : ce qui est documenté et ce qui ne l’est pas
| Étape | Ce qui est rapporté | Correspondance MITRE ATT&CK (notre lecture) |
|---|---|---|
| Accès initial | Utilisation d’identifiants de développeurs déjà compromis : jetons d’accès personnels (PAT) ou identifiants issus de journaux d’infostealers et de fuites. Chaque commit est créé sous l’identité de la victime. | T1078 Valid Accounts |
| Injection | Création, via l’API GitHub, d’un fichier de workflow au nom trompeur, présenté comme un audit ou un contrôle de sécurité, dans tous les dépôts accessibles en écriture. Dans 92 cas, un workflow injecté lors d’une vague antérieure et jamais supprimé a simplement été redirigé vers la nouvelle infrastructure. | T1195.001 Compromise Software Dependencies and Development Tools ; T1036 Masquerading |
| Exécution | Déclenchement à chaque push et à la demande, sur les runners hébergés par GitHub. | T1059.004 Unix Shell |
| Collecte | Les noms des secrets sont repris des workflows légitimes du dépôt, puis leurs valeurs sont lues. Depuis la vague d’octobre, le script recherche aussi des clés dans l’arborescence et dans tout l’historique git (expressions régulières couvrant clés cloud, jetons GitHub et GitLab, clés d’IA), et récupère le contexte autour des identifiants de clés AWS pour les associer aux clés secrètes. | T1552.001 Credentials In Files ; T1552.004 Private Keys |
| Exfiltration | Envoi des valeurs collectées par une requête HTTP non chiffrée vers un serveur contrôlé par l’attaquant. Les vagues sont étiquetées par un paramètre de la requête. | T1048.003 Exfiltration Over Unencrypted Non-C2 Protocol |
| Réutilisation | Une partie des victimes d’octobre avait déjà été touchée en 2025 : l’attaquant mise sur des secrets jamais renouvelés. Les mêmes comptes compromis ont aussi servi à au moins quatre campagnes de minage de cryptomonnaie distinctes. | Non documentée au-delà de ce constat |
La colonne MITRE est une lecture de notre part, à partir des éléments publiés.
Faits techniques connus sur l’évolution de la charge
- Trois versions successives du script ont été observées le 8 octobre, de plus en plus complètes (recherche dans l’historique, insensibilité à la casse, récupération du contexte autour des clés AWS). GitGuardian juge cette vague plus expérimentale et manuelle que les précédentes.
- La recherche dans l’arborescence n’apporte rien sur un dépôt public, dont le contenu est déjà lisible : selon GitGuardian, cela indique que l’attaquant visait aussi des dépôts privés.
Ce qu’on ne sait pas
L’identité de l’attaquant, la façon dont chaque compte a été compromis, le nombre de secrets réellement exfiltrés en octobre et leur usage ultérieur. GitGuardian ne relie pas avec certitude GhostAction aux campagnes de minage observées sur les mêmes comptes. Nous ne spéculons pas sur ces points.
Détection : ce qui a fonctionné, et pourquoi l’attaque passe sous les radars
- Ce qui a fonctionné : la surveillance de GitHub public par GitGuardian, le repérage indépendant des commits malveillants par des chercheurs de Cynative puis l’analyse de Socket ; le mécanisme d’approbation des exécutions de GitHub, qui a bloqué la plupart des exécutions en septembre ; enfin le blocage du workflow par GitHub à partir du 9 octobre.
- Pourquoi l’attaque passe sous les radars : commits signés par l’identité réelle du développeur ; nom de fichier rassurant ; exécution sur l’infrastructure de GitHub, hors du périmètre surveillé par l’entreprise ; secrets valides pendant des mois faute de rotation. Au 5 octobre, seuls 16 % des dépôts touchés en septembre avaient été effectivement nettoyés.
- Ce qui reste observable : création ou modification d’un fichier de workflow sans demande de fusion ni revue ; commits créés via l’API hors des habitudes du développeur ; connexions sortantes des runners vers une adresse IP brute en HTTP ; journal d’audit de l’organisation GitHub (création de workflows, usage de jetons, connexions depuis des origines inhabituelles).
- Point clé pour la remédiation : renouveler les secrets exfiltrés ne suffit pas. L’identifiant GitHub qui a permis l’injection doit aussi être retrouvé et révoqué, faute de quoi un autre acteur peut le réutiliser.
Questions d’audit ISO 27001:2022
- A.5.17 et A.8.24 (informations d’authentification, utilisation de la cryptographie) : « Disposez-vous d’un inventaire des secrets utilisés par vos chaînes CI/CD (clés cloud, accès SSH, FTP, bases de données, registres), avec propriétaire, durée de vie et date de dernier renouvellement ? Les secrets à longue durée de vie sont-ils remplacés par des mécanismes à durée courte quand c’est possible ? »
- A.8.4, A.8.25 et A.8.32 (accès au code source, cycle de développement sécurisé, gestion des changements) : « Les fichiers de workflow sont-ils protégés (branches protégées, propriétaires de code, revue obligatoire) ? Une création ou modification hors demande de fusion déclenche-t-elle une alerte ? L’historique git fait-il l’objet d’une recherche de secrets ? »
- A.8.2, A.8.5 et A.8.7 (droits d’accès privilégiés, authentification sécurisée, protection contre les logiciels malveillants) : « Les jetons d’accès personnels ont-ils une portée minimale et une expiration ? La MFA est-elle imposée au niveau de l’organisation ? Quelle procédure s’applique aux accès d’un développeur dont le poste a été infecté par un infostealer ? »
- A.5.19 à A.5.21 et A.8.30 (relations fournisseurs, chaîne d’approvisionnement TIC, développement externalisé) : « Les contrats avec les prestataires de développement précisent-ils le stockage et l’accès aux secrets, l’obligation de notification en cas de compromission et le renouvellement des secrets en fin de contrat ? »
- A.5.26 et A.8.16 (réponse aux incidents, activités de surveillance) : « En cas de fuite de secret, la procédure prévoit-elle le renouvellement de tous les secrets exposés et la révocation de l’identifiant d’accès initial ? Le journal d’audit de l’organisation GitHub est-il collecté et surveillé ? »
Pistes de sensibilisation
- Pour les développeurs et prestataires : atelier « Un secret supprimé du code reste dans l’historique ». Sur un dépôt de démonstration, retrouver les secrets présents dans l’historique git, puis dérouler leur renouvellement complet, jusqu’à la révocation du jeton qui y donnait accès.
- Pour les dirigeants et responsables d’application : « Qui a les clés de la maison ? ». Dresser la liste des prestataires qui détiennent des accès aux serveurs et au site, et vérifier qu’un renouvellement est prévu à chaque fin de contrat.
À lire aussi : notre décryptage pour les dirigeants, « GhostAction : des comptes de développeurs piratés pour voler les clés des serveurs », et le bulletin de veille du 16 octobre 2026.
Analyse préparée avec l’aide d’une intelligence artificielle à partir de sources publiques, sous la responsabilité de KyNeo. Malgré nos contrôles, des erreurs peuvent subsister : en cas de doute, référez-vous aux sources citées. Les informations non confirmées sont signalées comme telles.