Gheist: token GitHub rubati, segreti esfiltrati dai log di Actions

📌 Sviluppi successivi: Worm testmetest: payload da 13 MB in 42 repository GitHub (26 ottobre 2026)

Una campagna chiamata Gheist usa token di accesso GitHub rubati per far eseguire ai repository delle vittime un workflow di GitHub Actions che stampa i segreti nei log, da cui l’attaccante li scarica. La descrizione tecnica viene dall’analisi di Wiz Research, riportata da Help Net Security; ne hanno scritto anche The Hacker News, Dark Reading, che parla di un attacco alla catena di fornitura ancora in corso contro migliaia di repository di sviluppatori, e Infosecurity Magazine, che conferma l’ordine di grandezza: oltre 13.500 branch e repository presi di mira.

Cosa è successo

Secondo Wiz, i ricercatori hanno recuperato più di 13.500 branch creati dall’attaccante in repository appartenenti a oltre 850 account GitHub compromessi. Il nome della campagna viene dallo user agent che lo strumento invia con le sue richieste alle API di GitHub. Wiz non indica come siano stati rubati i token.

Il punto critico sono i repository privati. Dal 28 luglio GitHub trattiene nei repository pubblici le esecuzioni di workflow potenzialmente malevole finché un collaboratore non le approva, e lì l’attacco viene bloccato. Questo controllo però non vale per i repository privati né per GitHub Enterprise Server: secondo Wiz, nei registri di audit di GitHub si vedono esecuzioni sui branch dell’attaccante completate e poi cancellate dallo user agent di Gheist. Tra i segreti esposti ci sono quelli legati agli environment, che spesso sono credenziali di produzione.

Come funziona l’attacco

La catena descritta da Wiz è breve e tutta interna a GitHub:

1. lo strumento prende un token rubato ed elenca tutti i repository a cui quel token può accedere;
2. in ognuno crea un branch con il nome ci-sync- seguito da sei caratteri casuali e vi aggiunge un piccolo workflow chiamato sync-check;
3. il push del branch avvia il workflow da solo; il workflow ha un unico compito: scrivere i segreti del repository nel log dell’esecuzione;
4. per aggirare il mascheramento dei segreti di GitHub, che riconosce un segreto solo se compare identico a come è stato salvato, ogni valore viene codificato in base32 e finisce nel log per intero;
5. lo strumento scarica il log tramite le API di GitHub e cancella l’esecuzione pochi secondi dopo.

Non c’è un server dell’attaccante: i segreti escono attraverso le API di GitHub, quindi non esiste un dominio esterno o una connessione da bloccare. Cancellare l’esecuzione e il branch, però, non annulla l’esposizione.

Wiz ha osservato due varianti dello strumento. Dal 19 ottobre una delle due aggiunge un secondo job rivolto ai runner self-hosted: cerca token e chiavi sulla macchina e usa Docker per raggiungere i file dell’host.

Nelle organizzazioni enterprise lo strumento è passato in pochi minuti tra i token di più utenti e di account di automazione, e ha clonato i repository privati prima di inserire il workflow. Ore dopo, credenziali cloud della stessa organizzazione sono state usate per enumerare AWS Secrets Manager; Wiz non dice come siano state ottenute. Nei registri CloudTrail delle vittime compaiono i workflow delle organizzazioni stesse eseguiti sui branch ci-sync- mentre assumevano ruoli AWS: la prova che Actions ha girato senza alcuna approvazione.

Gli stessi account sono usati anche da altri gruppi: il 6 ottobre 391 account hanno rinominato circa 1.461 repository come esche di software craccato (166 di questi account non compaiono mai nell’attività di Gheist) e il 18 ottobre 25 account di Gheist hanno creato ciascuno un repository «Windows RDP Runner» nel giro di nove minuti.

Nella nostra lettura le tecniche MITRE ATT&CK pertinenti sono T1078 (Valid Accounts), T1213.003 (Code Repositories), T1027 (Obfuscated Files or Information) per la codifica in base32, T1567 (Exfiltration Over Web Service), T1070 (Indicator Removal) per la cancellazione delle esecuzioni e T1555.006 (Cloud Secrets Management Stores) per l’enumerazione di AWS Secrets Manager.

Impatto per le aziende europee e italiane

Molte aziende italiane tengono codice e pipeline di rilascio su GitHub, spesso in repository privati con segreti di environment che aprono l’accesso a cloud, registri di container e database di produzione. Un solo token di uno sviluppatore o di un account di automazione basta a esporre i segreti di tutti i repository che quel token raggiunge. Per i soggetti NIS2 la sicurezza dello sviluppo e della catena di fornitura è una delle misure richieste: l’uso di credenziali di produzione esfiltrate va valutato anche come possibile incidente da notificare.

Cosa fare subito

1. Cerca le tracce nei registri di audit di GitHub: lo user agent di Gheist, la creazione di branch ci-sync-*, workflow sync-check e cancellazioni di esecuzioni subito dopo la fine.
2. Controlla i registri del cloud: se i workflow si autenticano con OIDC, cerca le assunzioni di ruolo il cui subject contiene un branch ci-sync-. Secondo Wiz questa è la prova che Actions ha girato su un branch dell’attaccante, anche se non raccogli i registri di GitHub.
3. Ruota tutti i segreti a disposizione di un repository colpito: di repository, di organizzazione e di environment. Revoca i token che hanno fatto i push, come raccomanda Wiz.
4. Verifica i runner self-hosted: avvii di container con accesso al file system dell’host e credenziali presenti sulla macchina dal 19 ottobre in poi.
5. Riduci la superficie (indicazioni nostre): limita le policy di fiducia OIDC a branch o environment precisi, proteggi gli environment con regole sui branch di rilascio e revisori obbligatori, usa token con permessi minimi e scadenza breve, e valuta regole che impediscano di modificare i file dei workflow a chi non deve farlo.

Come aiuta ARXDOME

ARX Sentry raccoglie con il suo agent log, eventi e inventario di processi dei server Linux, Windows e macOS, compresi quelli usati come runner self-hosted: aiuta a notare avvii insoliti di container e processi sulla macchina. Con ARX Trace i nostri analisti possono avviare raccolte e ricerche su più macchine per verificare cosa è stato toccato, e ARX Shield permette di isolare dalla rete un runner sospetto in attesa della rotazione dei segreti.

Ultimo aggiornamento: 27 ottobre 2026