Ricevi DeafLetter
Una selezione settimanale di segnali, vulnerabilità e guide. Gli avvisi critici restano facoltativi.
Puoi cancellarti in ogni momento. Privacy policy.
Dal 15 settembre 2026 Wiz Research traccia Gheist, una campagna di abuso su larga scala di token GitHub rubati. L'operazione ha piantato oltre 13.500 branch in più di 850 account, da progetti personali a repository privati di organizzazioni enterprise, con l'obiettivo di esfiltrare segreti tramite workflow Actions malevoli. Il dato che definisce il caso: il controllo di approvazione introdotto da GitHub il 28 luglio 2026 ha bloccato completamente l'esecuzione sui repository pubblici, ma non si applica ai repository privati e agli ambienti GitHub Enterprise Server, dove le esecuzioni hanno completato con successo.
- Oltre 13.500 branch con pattern "ci-sync-" sono stati piantati in più di 850 account GitHub compromessi, secondo Wiz Research.
- Il controllo di approvazione di GitHub, attivo dal 28 luglio 2026, ha bloccato tutte le esecuzioni verificate su repository pubblici in stato "action_required".
- Su repository privati e GitHub Enterprise Server il medesimo controllo non si applica: le esecuzioni completano e i log vengono cancellati tramite user agent "gheist".
- Il bypass del masking di GitHub avviene tramite codifica base32, che evita il filtro verbatim e stampa i segreti in chiaro nelle API stesse della piattaforma.
Come funziona il bypass che esfiltra attraverso le API di GitHub
Il workflow malevolo, denominato "sync-check" dalla fonte, non stabilisce connessioni esterne verso infrastrutture controllate dall'attaccante. Invece, sfrutta le API di GitHub stesse: stampa i segreti nel log di esecuzione, li scarica tramite API con user agent "gheist" e cancella l'esecuzione per cancellare le tracce. Secondo Wiz Research, "because the secrets leave through GitHub's own API, there is no attacker domain or outbound connection to block".
Il meccanismo di elusione del masking si basa sulla codifica base32. GitHub maschera i valori dei segreti solo quando compaiono verbatim nel log; trasformandoli in base32, il valore encoded non matcha il pattern di masking e viene stampato in chiaro. La variante Tool B amplia il raggio d'azione con una matrice di ambienti: cicla deployment environments diversi per estrarre segreti scoped per specifici contesti, spesso credenziali di produzione.
Il disallineamento tra difesa pubblica e superficie privata
Il 28 luglio 2026 GitHub ha implementato un controllo di approvazione che richiede esplicita autorizzazione prima dell'esecuzione di workflow su repository pubblici. Per Gheist, il controllo ha funzionato: "the malicious payloads never ran". Ma la stessa protezione non si estende ai repository privati né agli ambienti GitHub Enterprise Server, dove il workflow viene eseguito automaticamente.
I log di audit di GitHub mostrano esecuzioni su branch "ci-sync-*" che completano il ciclo e vengono poi cancellate dal medesimo user agent "gheist". Questo disallineamento crea una condizione di rischio concentrato: i repository privati enterprise ospitano tipicamente i segreti più sensibili — credenziali cloud, token di servizio, chiavi di deployment — proprio dove la difesa è più sottile.
La raccolta su runner self-hosted e i limiti del tool
Un job aggiuntivo, "sync-host", è progettato per eseguire su runner self-hosted e cercare 31 formati di token, inclusi provider AI come Anthropic, Hugging Face, Groq e NVIDIA, oltre a chiavi private, file .env e Terraform state. Tuttavia, il medesimo job presenta difetti di implementazione: cerca un file di runner con nome errato, utilizza una regex URL-credential non funzionante e non raccoglie token GCP né Azure. Questi difetti potrebbero aver limitato l'estensione della raccolta su ambienti self-hosted, anche se la fonte non quantifica l'impatto effettivo di tale limitazione.
Sovrapposizioni con altre campagne e movimento dei token nell'ecosistema
La fonte documenta sovrapposizioni concrete con almeno quattro attività distinte. Il 6 ottobre 2026, 391 account hanno rinominato 1.461 repository in "cracked-software" come esca (Lure repositories), cancellando collateralmente 610 branch "ci-sync". Il 18 ottobre, 25 account hanno creato repository "Windows RDP Runner" per cryptomining su Actions. Tra il 19 e il 20 ottobre, tre vittime hanno re-pushato commit Gheist contenenti un loader associato a PolinRider, gruppo attribuito alla Corea del Nord. Infine, 57 account della prima fase Gheist erano già stati compromessi dalla campagna Megalodon di maggio 2026.
"This campaign is leveraging compromised GitHub access. The same accounts are used by other actors and campaigns, which demonstrates how compromised credentials can move throughout the threat actor ecosystem" — Wiz Research
Le fonti dei token includono log di infostealer e compromissioni supply-chain precedenti, come quella del tool Trivy di marzo 2026. Circa due terzi degli account coinvolti non sono più disponibili su GitHub, indicando attività di risposta e rimozione dopo il report alla piattaforma.
Cosa fare adesso
Le organizzazioni con repository privati o GitHub Enterprise Server devono verificare se il controllo di approvazione per workflow è attivabile anche nei propri ambienti, dato che la protezione che ha bloccato Gheist sui repository pubblici non si applica automaticamente a questi scope. È necessario controllare i log di audit alla ricerca di esecuzioni su branch "ci-sync-*" completate e successivamente cancellate, pattern che indica attività Gheist riuscita.
Per il masking dei segreti, le pipeline devono implementare controlli aggiuntivi che rilevino encoding base32 nei log di esecuzione, poiché il filtro verbatim di GitHub non intercetta questa variante. Le organizzazioni che usano deployment environments con secret scoped devono rivedere la matrice di accesso: la variante Tool B di Gheist cicla esplicitamente gli environment per estrarre credenziali di produzione.
Sui runner self-hosted, il job "sync-host" cerca 31 formati di token inclusi provider AI; la verifica della presenza di questi token in chiaro sui runner, anche con il tool difettoso, riduce la superficie di esposizione. Infine, la sovrapposizione con Megalodon su 57 account indica che il pool di credenziali compromesse è condiviso: la rotazione dei token GitHub deve essere prioritaria per gli account già coinvolti in campagne precedenti.
Domande frequenti
Il controllo di approvazione di GitHub protegge anche i repository privati?
No. Secondo Wiz Research, il controllo attivo dal 28 luglio 2026 si applica ai repository pubblici, mentre su repository privati e GitHub Enterprise Server le esecuzioni del workflow Gheist hanno completato con successo.
L'esfiltrazione avviene attraverso server esterni controllati dall'attaccante?
No. Il tool scarica i log tramite le API stesse di GitHub e cancella le esecuzioni. Non emergono connessioni outbound verso domini attaccanti da bloccare a livello di rete.
Gheist e GhostAction sono la stessa campagna?
No. Wiz Research li distingue esplicitamente: GhostAction utilizza file workflow diversi ed esfiltra verso l'IP 193.32.204[.]199, mentre Gheist opera attraverso le API di GitHub con user agent "gheist".
Fonti
Ricevi DeafLetter
Una selezione settimanale di segnali, vulnerabilità e guide. Gli avvisi critici restano facoltativi.
Puoi cancellarti in ogni momento. Privacy policy.