Gheist, token GitHub rubati per sottrarre i segreti dai repository

Logo di GitHub, la piattaforma i cui token rubati sono sfruttati dalla campagna Gheist
Immagine: GitHub/Wikimedia Commons (MIT).

Una campagna automatizzata battezzata Gheist sta usando token di GitHub rubati per inserire nei repository dei workflow che stampano i segreti nei log di GitHub Actions, da cui gli aggressori li scaricano prima di cancellare le esecuzioni. A descriverla sono i ricercatori di Wiz, che la seguono dal 15 settembre 2026 e hanno recuperato oltre 13.500 branch piantati da più di 850 account compromessi, dai progetti personali ai repository privati di organizzazioni enterprise.

Logo di GitHub, la piattaforma i cui token rubati sono sfruttati dalla campagna Gheist
Immagine: GitHub/Wikimedia Commons (MIT).

Come funziona la campagna Gheist

Il nome deriva dallo user agent gheist che lo strumento degli attaccanti invia nelle richieste alle API di GitHub. Una volta ottenuto un token, il tool scorre tutti i repository a cui quel token ha accesso. In ognuno crea un branch chiamato ci-sync- seguito da sei caratteri casuali e vi aggiunge il file .github/workflows/sync-check.yml, con il messaggio di commit «ci: sync config». Il commit non è firmato e risulta creato a nome del proprietario del token.

Il push del branch avvia il workflow, che stampa l’ambiente del job e tutti i segreti leggibili, codificati in base32. GitHub maschera i segreti nei log solo quando compaiono esattamente come sono stati salvati: una volta codificati, spiega Wiz, il mascheramento non li riconosce e finiscono nel log in chiaro. Lo strumento scarica il log tramite le API e cancella l’esecuzione pochi secondi dopo. Non c’è alcun server di comando e controllo: i dati escono attraverso le API di GitHub, quindi non esiste un dominio esterno da bloccare.

Repository privati e GitHub Enterprise i più esposti

Dal 28 luglio 2026 GitHub trattiene nei repository pubblici le esecuzioni di workflow potenzialmente malevole finché un collaboratore non le approva. Secondo Wiz, tutte le esecuzioni di Gheist controllate nei repository pubblici sono rimaste bloccate in attesa di approvazione. Questa protezione però non si applica ai repository privati né a GitHub Enterprise Server, dove i ricercatori hanno osservato workflow completati e poi cancellati, con credenziali cloud successivamente usate per esplorare AWS Secrets Manager.

Una delle varianti, dal 19 ottobre, include anche un secondo job rivolto ai runner self-hosted, che cerca token e chiavi sulla macchina e usa Docker per raggiungere i file dell’host. Al 24 ottobre la campagna era ancora attiva e in evoluzione. Wiz ha segnalato l’attività a GitHub e circa due terzi degli account coinvolti non risultano più disponibili, segno probabile di un intervento della piattaforma. Il rapporto non indica quante organizzazioni abbiano effettivamente subito l’esposizione dei segreti.

Un rischio per la supply chain del software

Il punto debole sfruttato non è una vulnerabilità di GitHub, ma il modo in cui funzionano i permessi: come ricorda la documentazione della piattaforma, chiunque abbia accesso in scrittura a un repository può leggere i segreti configurati. Un token rubato con quel livello di accesso basta. Gli account di sviluppatori e i sistemi di automazione restano così una porta d’ingresso verso gli ambienti cloud aziendali, come mostrano anche casi recenti quali la compromissione del pacchetto Axios su npm e l’attacco a Warp tramite un fornitore.

Cosa fare per proteggersi da Gheist

  • Cercare nei repository, soprattutto privati e su GitHub Enterprise Server, branch che iniziano con ci-sync- e il file .github/workflows/sync-check.yml, oltre a richieste API con user agent gheist nei log di audit.
  • Se si trova traccia della campagna, non basta cancellare il branch o l’esecuzione: vanno ruotati tutti i segreti che il repository poteva leggere e revocato il token che ha effettuato il push.
  • Controllare nei log del cloud, per esempio CloudTrail su AWS, l’uso di ruoli da parte di workflow avviati su branch insoliti.
  • Limitare durata e permessi dei token personali e degli account di automazione, applicando il principio del privilegio minimo.
  • Valutare protezioni sui branch e l’approvazione obbligatoria dei workflow anche negli ambienti privati, dove possibile.

Fonti: https://www.wiz.io/blog/gheist-attempted-scaled-abuse-of-stolen-github-tokens-stumbles, https://thehackernews.com/2026/10/gheist-uses-stolen-github-tokens-to.html, https://www.helpnetsecurity.com/2026/10/27/gheist-github-token-abuse/, https://www.darkreading.com/cyberattacks-data-breaches/gheist-stolen-github-tokens-cloud-secrets

"
Sicurezza Informatica
Lo staff di Sicurezza Informatica.