Des jetons GitHub volés ont permis une campagne automatisée d'extraction de secrets depuis des dépôts privés et des environnements GitHub Enterprise Server, selon la société de cybersécurité cloud Wiz. Baptisée Gheist, cette opération transforme les journaux GitHub Actions en canal de collecte : des workflows malveillants y écrivent des identifiants encodés, que les attaquants récupèrent avant de supprimer les exécutions.
Wiz a repéré plus de 13 500 branches créées par les attaquants, associées à plus de 850 comptes compromis, couvrant aussi bien des projets personnels que des dépôts d'entreprise. Ces chiffres mesurent des branches et des comptes ; les constats n'établissent pas combien d'organisations ont vu leurs secrets exposés.
Les chercheurs suivent Gheist depuis le 15 septembre. Il restait actif et continuait d'évoluer au 24 octobre, selon le rapport de The Hacker News sur l'analyse de Wiz. Le nom vient de gheist, le user agent que fournit son outillage dans les requêtes à l'API GitHub.
Où les workflows ont tourné
Les journaux d'audit GitHub attestent d'exécutions dans des dépôts privés et sur GitHub Enterprise Server : les exécutions sur les branches malveillantes se sont terminées, puis des requêtes utilisant le user agent gheist les ont supprimées. Les journaux AWS CloudTrail montrent aussi que des workflows légitimes des organisations ont été exécutés depuis ces branches et ont assumé des rôles AWS, ce qui indique que des tâches Actions ont tourné sans approbation.
Au sein des organisations, l'outillage a alterné, en quelques minutes, entre des jetons appartenant à des utilisateurs et à des comptes d'automatisation. Il a cloné des dépôts privés avant d'introduire le workflow malveillant. Des identifiants cloud de la même organisation ont ensuite été utilisés, quelques heures plus tard, pour énumérer AWS Secrets Manager. Wiz n'a pas établi l'origine de ces identifiants ni identifié la personne qui les a utilisés.
Les dépôts publics ont connu un sort différent. Chaque exécution publique de Gheist examinée par Wiz, sur toutes les versions d'outil observées, est restée en attente d'approbation et n'a donc pas exécuté sa charge utile.
GitHub a introduit cette retenue le 28 juillet pour les workflows qu'il identifie comme potentiellement malveillants. Un collaborateur disposant d'un accès en écriture doit approuver une exécution signalée. La protection ne couvre que les dépôts publics sur github.com ; les dépôts privés et GitHub Enterprise Server n'entrent pas dans son périmètre. Son efficacité dépend en outre du fait que GitHub signale l'exécution.
De l'accès au dépôt aux identifiants lisibles
Gheist part d'un jeton déjà volé qui accorde un accès en écriture au dépôt. Wiz a retracé certains jetons jusqu'à des journaux d'infostealers et à des compromissions de la chaîne d'approvisionnement antérieures, dont la compromission de mars touchant l'outil d'analyse de vulnérabilités Trivy.
Pour les dépôts accessibles avec un jeton, l'outil pousse un commit non signé au nom du propriétaire du jeton. Sa combinaison d'identification est une branche correspondant à ^ci-sync-[0-9a-z]{6}$, le message de commit ci: sync config et un seul fichier ajouté : .github/workflows/sync-check.yml.
Ce push déclenche un workflow qui écrit dans ses journaux l'environnement de la tâche et les secrets accessibles, encodés en base32. La documentation de GitHub avertit que le masquage des secrets peut échouer lorsque les valeurs ont été transformées. Selon Wiz, la représentation en base32 échappe au masquage parce qu'elle diffère du secret d'origine. Une chaîne de détection publiée est toJSON(secrets) }}' | base32 -w 120.
Bien que le workflow déclare un bloc permissions vide, cela restreint son GITHUB_TOKEN sans l'empêcher de lire les secrets. Les attaquants s'appuient sur leur jeton volé pour récupérer les journaux via l'API GitHub, puis effacent l'exécution quelques secondes plus tard. La collecte passe donc par GitHub lui-même, sans nécessiter de destination distincte contrôlée par les attaquants.
Une variante planifie aussi une tâche par environnement de déploiement afin d'atteindre les secrets propres à ces environnements, qui, selon Wiz, incluent souvent des identifiants de production. Des relecteurs obligatoires peuvent bloquer cet accès : selon la documentation de GitHub, les secrets d'un environnement restent inaccessibles à une tâche tant qu'un relecteur obligatoire ne l'a pas approuvée.
Vers le 19 octobre, une autre variante a ajouté une tâche visant les runners auto-hébergés, c'est-à-dire les machines que les organisations exploitent pour exécuter les tâches Actions. Elle cible apparemment les dépôts disposant d'un runner enregistré et tente de rechercher 31 types de jetons et d'identifiants, dont des clés privées, les environnements de processus, les identifiants de rôle d'instance AWS, les fichiers d'identifiants des runners et le jeton du compte de service Kubernetes. Wiz a qualifié la tâche de défectueuse et n'a signalé aucune exécution réussie.
Repérer et contenir l'exposition
Wiz recommande de vérifier dans les journaux d'audit GitHub la présence du user agent gheist et des exécutions sur des branches ci-sync-* supprimées moins d'une minute après leur fin. Sur les runners auto-hébergés, les indicateurs incluent .gdmp_pat, .gdmp_patg, .gdmp_sweep et le marqueur de journal de tâche ===== gdmp-pivot:.
Les journaux cloud offrent une autre piste de détection lorsque les workflows utilisent OIDC, qui fournit des identifiants à courte durée de vie au lieu de clés cloud stockées. Les assumptions de rôle ou échanges de jetons peuvent faire apparaître une branche ci-sync- dans leur sujet. Il existe une limite : le sujet OIDC par défaut de GitHub n'inclut le nom de branche que pour les tâches n'utilisant pas d'environnement de déploiement.
Supprimer une branche ou effacer une exécution ne peut pas annuler les identifiants déjà exposés. Wiz conseille aux dépôts concernés de renouveler tous les secrets accessibles au niveau du dépôt, de l'organisation et de l'environnement, de révoquer les jetons à l'origine des commits, et d'examiner les appareils de leurs propriétaires à la recherche d'infostealers. Les exécutions sync-check retenues doivent rester non approuvées, et le code des branches piégées ne doit pas être exécuté. Si l'une de ces branches a été exécutée sur un runner auto-hébergé, Wiz recommande de considérer comme compromis la machine et son rôle d'instance cloud.
Pour limiter les accès futurs, Wiz recommande des relecteurs obligatoires pour les environnements contenant des secrets de production, une confiance OIDC restreinte aux branches ou environnements protégés, et des GitHub Apps ou des jetons à granularité fine et à courte durée de vie à la place des jetons d'accès personnels. Il recommande également des runners auto-hébergés éphémères, sans accès au socket Docker ni accès illimité aux métadonnées cloud.
