Campagne Gheist : vol massif de tokens GitHub pour extraire les secrets
Sommaire
En bref
- Depuis septembre 2026, Wiz Research a détecté une campagne Gheist exploitant plus de 13 500 tokens GitHub compromis provenant de 850+ comptes.
- L'attaque crée des branches avec des workflows qui encodent les secrets en base32 (contournant le masquage) et les exfiltrent via les logs GitHub.
- Le contrôle d'approbation de GitHub pour les repositories publiques a bloqué l'exploitation visible, mais les repositories privées et les environnements GitHub Enterprise restent vulnérables.
- De nombreux comptes compromis sont ensuite réutilisés par d'autres acteurs (malware, cryptomining, campagnes APNK liées à PolinRider).
Ce que dit la source
Wiz rapporte une campagne de masse exploitant des tokens GitHub volés pour implanter des workflows malveillants dans chaque repository accessible à chaque token. Le workflow sync-check encode les secrets du repository en base32 (technique contournant le masquage automatique de GitHub), les affiche dans les logs, puis supprime la trace via l'API. L'attaque a compris plus de 13 500 branches plantées sur 850+ comptes, des projets personnels aux repositories privées d'organisations enterprise. Depuis octobre, la campagne continue d'évoluer avec deux variantes parallèles (Tool A et Tool B) qui ont ajouté des raffinements : timeout, matrices d'environnement, recherche récursive de credentials multiples, et ciblage de runners self-hosted.
- Plus de 13 500 branches plantées dans 850+ comptes compromis, du personnel au niveau enterprise
- La clé de l'exploit : encoder les secrets en base32 évite leur masquage dans les logs GitHub, puisque le masquage ne fonctionne que sur les valeurs littérales
- permissions: {} du workflow restreint le GITHUB_TOKEN de l'attaquant mais pas le contexte secrets, laissant les credentials intacts
- L'utilisation de l'API GitHub pour télécharger les logs crée zéro trace de domaine ou connexion sortante à bloquer
- Tool B a évolué : ajout de timeout-minutes: 6 dans les heures suivant le premier déploiement, puis job sync-host cherchant 31 formats de tokens (Anthropic, Hugging Face, NVIDIA, clés privées, Terraform, Kubernetes), Docker socket, et credentials AWS/GCP/Azure
- Les workflows publiques ont été bloqués par le contrôle d'approbation GitHub (juillet 2026), mais cette protection ne s'applique pas aux repositories privées ni à GitHub Enterprise Server
- Les comptes compromis sont réutilisés par d'autres acteurs : malware lure, cryptomining (25 comptes créant des Windows RDP runners en 9 minutes), PolinRider (malware APNK), et Megalodon
Dans les commentaires
Débat très limité sur ce fil : un seul commentaire substantiel, qui souligne le risque des workflows sur pull_request_target et l'absence de review avant exécution selon la configuration.
- Le commentaire unique met l'accent sur le contexte : la dangerosité dépend fortement du type de trigger (pull_request_target particulièrement exposé) et de l'ordre de review mis en place, ce qui limite le scope du risque à des configurations spécifiques plutôt qu'une vulnérabilité universelle.
Notre lecture
Intéressant pour les DSI et tech leads de tout type d'organisation : à la fois un incident opérationnel immédiat (rotation des tokens GitHub exposés) et un problème de design que GitHub a partiellement adressé (l'approbation hold). Trois actions concrètes : 1) vérifier les tokens GitHub dans le Cloud Secret Manager (AWS Secrets Manager, GCP Secret Manager) et les renouveler si exposure possible ; 2) monitorer les repositories privées et GitHub Enterprise via CloudTrail (rechercher les ci-sync-* branches et les suppressions rapides) comme le montre Wiz ; 3) revoir les triggers des workflows critiques, surtout pull_request_target, et documenter qui approuve avant exécution. Le risque réel varie énormément selon qu'on est sur un repository public (contrôlé) ou privé/enterprise (peu protégé). La campagne elle-même continue : à surveiller et à documenter dans les audits de sécurité GitHub.