Gheist ruba i segreti GitHub: 13.500 branch malevoli e 850 account violati

🛡️ Executive Summary

• Wiz Research identifica oltre 13.500 branch malevoli distribuiti attraverso più di 850 account GitHub compromessi, utilizzati dalla campagna Gheist per sottrarre credenziali.
• Gli attaccanti sfruttano GitHub Actions per trasferire i segreti nei log delle esecuzioni e recuperarli attraverso le API ufficiali, evitando infrastrutture esterne di esfiltrazione.
• Le nuove protezioni GitHub hanno bloccato gli attacchi osservati nei repository pubblici, ma Wiz documenta esecuzioni riuscite nei repository privati e negli ambienti enterprise.

Gheist è una campagna automatizzata che sfrutta token GitHub compromessi per inserire workflow malevoli nei repository, estrarre credenziali attraverso i log di GitHub Actions e cancellare rapidamente le tracce delle esecuzioni. La ricerca pubblicata il 25 ottobre 2026 da Wiz Research documenta oltre 13.500 branch malevoli individuati in più di 850 account compromessi, con attività osservate a partire dal 15 settembre e ancora in evoluzione al 24 ottobre. Il dato più significativo riguarda l’efficacia delle contromisure introdotte da GitHub: mentre gli attacchi osservati contro repository pubblici sono stati bloccati, quelli diretti ai repository privati e agli ambienti enterprise hanno consentito di eseguire workflow, accedere ai segreti e utilizzare credenziali cloud. La campagna dimostra come un’identità di sviluppo compromessa possa trasformare le normali funzionalità CI/CD in un meccanismo di esfiltrazione.

Gheist sfrutta token rubati per modificare migliaia di repository GitHub

La campagna prende il nome dallo user agent gheist utilizzato dagli strumenti automatici per comunicare con le API GitHub. La ricerca originale pubblicata da Wiz Research, firmata da Rami McCarthy e Hila Ramati, ricostruisce un’operazione che non richiede lo sfruttamento di una vulnerabilità software della piattaforma, ma utilizza credenziali legittime precedentemente sottratte per accedere ai repository raggiungibili dagli account compromessi. Una volta ottenuto un token valido con autorizzazioni sufficienti, l’attaccante crea un branch identificato dal prefisso ci-sync-, seguito da sei caratteri, e inserisce il file .github/workflows/sync-check.yml attraverso un commit con messaggio ci: sync config. L’aggiunta del workflow permette di avviare automaticamente una nuova esecuzione GitHub Actions in risposta all’evento push, utilizzando l’infrastruttura ordinaria della piattaforma. Il processo può essere replicato su ogni repository accessibile al token compromesso, trasformando una singola credenziale in uno strumento capace di raggiungere numerosi progetti e organizzazioni. Wiz ha recuperato oltre 13.500 branch riconducibili alla campagna, ma questo numero non equivale ad altrettante compromissioni riuscite o a 13.500 repository distinti, poiché una parte delle esecuzioni è stata bloccata e gli stessi repository possono comparire in più operazioni. Le origini documentate delle credenziali comprendono log di infostealer e precedenti compromissioni della supply chain, fra cui quella che aveva coinvolto Trivy nel marzo 2026. Il meccanismo si inserisce nella progressiva trasformazione degli attacchi GitHub Actions contro la supply chain e gli ambienti di sviluppo, dove il problema non è soltanto l’alterazione del codice sorgente, ma l’accesso alle identità e ai privilegi utilizzati per automatizzare le operazioni.

Leggi anche: GhostAction travolge GitHub: 1.900 account e 30.000 repository nel mirino

GitHub Actions diventa il canale di esfiltrazione dei segreti CI/CD

Il funzionamento di Gheist si distingue da molte campagne tradizionali perché non richiede un server esterno di comando e controllo per recuperare i dati sottratti. Il workflow sync-check viene configurato per stampare nei propri log informazioni dell’ambiente di esecuzione e segreti disponibili attraverso il contesto GitHub Actions, trasformandoli mediante codifica Base32. La scelta è rilevante perché i sistemi di mascheramento dei segreti intervengono normalmente quando riconoscono nei log valori sensibili corrispondenti alle credenziali registrate, mentre la rappresentazione codificata può impedire il riconoscimento diretto della stringa originale. Una volta terminata l’esecuzione, lo strumento malevolo scarica il log attraverso le API ufficiali di GitHub e cancella il workflow run pochi secondi dopo. I dati vengono quindi trasferiti utilizzando l’infrastruttura GitHub, senza generare necessariamente una connessione verso un dominio controllato dall’attaccante che i tradizionali filtri di rete potrebbero intercettare. Un dettaglio significativo è la presenza di permissions: {} nella configurazione malevola: questa impostazione limita i privilegi del token automatico assegnato al job, ma non impedisce l’accesso ai segreti disponibili nel relativo contesto di esecuzione. La seconda variante degli strumenti Gheist introduce inoltre una matrice dedicata agli ambienti di deployment, permettendo di tentare l’accesso anche alle credenziali associate agli environment, comprese quelle utilizzate per operazioni di produzione quando non sono presenti ulteriori controlli di approvazione. L’impatto supera pertanto il semplice furto di un personal access token, perché la compromissione iniziale può esporre credenziali per servizi cloud, registri di pacchetti, applicazioni aziendali e infrastrutture di distribuzione software. La dinamica presenta analogie con le campagne che ricercano credenziali AI, cloud e CI/CD attraverso la supply chain npm, ma Gheist concentra il trasferimento dei dati direttamente nei log della piattaforma compromessa.

GitHub blocca i repository pubblici ma quelli privati rimangono esposti

Uno degli aspetti più importanti dell’indagine riguarda la differenza tra repository pubblici e privati nell’applicazione delle protezioni di GitHub Actions. Il 28 luglio 2026, GitHub ha introdotto un sistema automatico che trattiene le esecuzioni considerate potenzialmente malevole nei repository pubblici fino all’approvazione di un collaboratore autorizzato. Il comunicato ufficiale di GitHub sulle nuove protezioni dei workflow precisa che il controllo viene applicato automaticamente, senza richiedere configurazioni manuali, e che l’approvazione deve essere effettuata attraverso una sessione web autenticata. Wiz ha verificato che tutti i workflow Gheist osservati nei repository pubblici esaminati erano stati trattenuti nello stato action_required, impedendo l’esecuzione del payload. La protezione ha quindi funzionato contro il campione analizzato, ma presenta un limite rilevante: non si applica automaticamente ai repository privati né a GitHub Enterprise Server. In questi ambienti Wiz ha individuato esecuzioni completate e successivamente cancellate attraverso lo user agent della campagna, oltre a registrazioni che confermano il coinvolgimento delle credenziali utilizzate dai workflow. I log CloudTrail hanno mostrato anche assunzioni di ruoli AWS da parte di processi GitHub Actions avviati dai branch controllati dagli attaccanti, dimostrando che l’esecuzione non era rimasta confinata al repository. In un’organizzazione enterprise, gli operatori hanno utilizzato rapidamente token appartenenti a differenti utenti e account di automazione, clonando repository privati prima di introdurre i workflow malevoli. Successivamente, credenziali cloud appartenenti alla stessa organizzazione sono state impiegate per enumerare risorse AWS Secrets Manager. Il risultato evidenzia una distinzione importante: i repository privati proteggono la visibilità del codice verso l’esterno, ma non garantiscono automaticamente una maggiore sicurezza quando vengono compromesse le identità autorizzate ad accedervi.

Gheist prende di mira i runner self-hosted e le credenziali cloud

L’evoluzione della campagna mostra un progressivo ampliamento degli obiettivi. Wiz identifica due varianti operative, distinguibili anche attraverso le modalità di generazione dei branch. La seconda ha introdotto il 28 settembre ulteriori controlli sui tempi di esecuzione e una matrice per gli environment, mentre il 19 ottobre ha aggiunto un nuovo job denominato sync-host, destinato apparentemente ai repository che dispongono di runner self-hosted registrati. A differenza dei runner temporanei gestiti da GitHub, questi sistemi possono essere installati su server aziendali persistenti e possedere accesso a file locali, credenziali cloud, container e risorse interne. Il payload individuato da Wiz tenta di raccogliere informazioni sul sistema operativo, processi attivi, cronologia dei comandi e file sensibili, cercando 31 differenti formati di token, comprese chiavi riconducibili a fornitori AI come Anthropic, Hugging Face, Groq e Nvidia. Fra gli obiettivi figurano file .env, chiavi private, stati Terraform, credenziali GitHub e GitLab Runner e token di servizio Kubernetes. La ricerca descrive anche un tentativo di utilizzare il socket Docker per raggiungere il filesystem dell’host attraverso un container, oltre a operazioni di ricerca delle credenziali associate ai ruoli delle istanze AWS e ai servizi cloud. La variante presenta tuttavia errori implementativi: utilizza un percorso errato per alcuni file del runner, contiene un’espressione regolare difettosa per determinate credenziali e non riesce a recuperare i token GCP e Azure nel modo previsto. Questi difetti limitano l’efficacia del codice osservato, ma non eliminano il rischio derivante dall’esecuzione di workflow malevoli su sistemi aziendali. La possibilità di eseguire codice su un runner persistente amplia la superficie d’attacco dal repository all’infrastruttura sottostante, soprattutto quando il runner dispone di accesso ai servizi cloud o al socket Docker senza restrizioni adeguate.

Le credenziali compromesse collegano Gheist ad altre campagne malware

Wiz ha osservato ulteriori attività sugli stessi account utilizzati da Gheist, senza poter dimostrare che tutte appartengano necessariamente al medesimo operatore. Il 6 ottobre, 391 account sono stati coinvolti nella modifica dei nomi di circa 1.461 repository, trasformati in esche che richiamavano software piratato e strumenti per criptovalute. L’operazione ha prodotto incidentalmente la scomparsa di 610 branch ci-sync, mentre 166 account coinvolti nella rinomina non comparivano nelle attività Gheist, suggerendo un insieme di credenziali compromesse più ampio rispetto a quello attribuito alla singola campagna. Il 18 ottobre, altri 25 account hanno creato repository denominati Windows RDP Runner nell’arco di nove minuti, in un apparente tentativo di utilizzare gratuitamente le risorse di calcolo offerte da GitHub Actions. Sono emerse anche sovrapposizioni con PolinRider, malware collegato ad attività nordcoreane che nasconde codice JavaScript all’interno dei file di configurazione dei progetti. In alcuni repository, i ricercatori hanno individuato loader aggiunti a vite.config.js e script eseguiti prima delle operazioni di sviluppo e compilazione. La presenza dello stesso account in più campagne non costituisce tuttavia una prova di coordinamento operativo. Lo dimostrano anche i 57 account della prima fase Gheist precedentemente coinvolti nella campagna Megalodon del maggio 2026, che aveva già evidenziato il rischio di utilizzare identità di sviluppo compromesse per distribuire backdoor e alterazioni nei repository. Il precedente attacco Megalodon contro GitHub e i progetti Laravel rappresenta quindi un collegamento concreto, ma non autorizza ad attribuire automaticamente Gheist agli stessi responsabili. La ricerca descrive piuttosto un ecosistema nel quale token rubati, credenziali recuperate dagli infostealer e accessi derivanti da precedenti incidenti possono essere riutilizzati da campagne differenti, aumentando la durata e l’estensione del rischio anche dopo la conclusione dell’attacco iniziale.

Continua con:

GitHub Actions diventa una botnet mentre GitHub restringe il bug bounty

GitHub e PyPI introducono difese temporali contro la supply chain

Come individuare Gheist e contenere la compromissione dei repository

La risposta difensiva deve partire dalla ricerca di branch ci-sync- seguiti da sei caratteri, commit con messaggio ci: sync config e workflow inattesi nel percorso .github/workflows/sync-check.yml. Gli amministratori devono correlare queste evidenze con gli audit log GitHub, cercando esecuzioni completate e cancellate rapidamente e richieste API associate allo user agent gheist. Nei sistemi che utilizzano l’autenticazione OIDC verso i fornitori cloud, è necessario verificare la presenza di assunzioni di ruolo originate da branch ci-sync-, perché tali eventi possono rivelare un’attività malevola anche quando i log GitHub siano stati eliminati o non siano più disponibili. Per i runner self-hosted, Wiz indica come elementi da ricercare i file .gdmp_pat, .gdmp_patg e .gdmp_sweep, insieme al marcatore gdmp-pivot presente nei log delle operazioni. In presenza di una compromissione confermata, la semplice cancellazione del branch o del workflow non elimina l’esposizione dei segreti, poiché gli attaccanti possono aver già scaricato le informazioni attraverso le API. Occorre quindi revocare i token utilizzati per introdurre le modifiche, verificare i dispositivi dei titolari alla ricerca di infostealer e ruotare tutte le credenziali accessibili al repository interessato, comprese quelle dell’organizzazione e degli environment. Qualora un job malevolo sia stato eseguito su un runner self-hosted, la macchina e le credenziali associate devono essere trattate come potenzialmente compromesse, con verifiche estese ai ruoli cloud e agli accessi persistenti. La prevenzione richiede inoltre autorizzazioni granulari, token temporanei, controlli sulle modifiche ai workflow, protezione degli ambienti di produzione e policy OIDC limitate a branch o environment autorizzati. Per le software house e le imprese italiane che utilizzano GitHub per compilare e distribuire applicazioni, Gheist dimostra che il furto di un token non rappresenta soltanto un problema di autenticazione, ma può compromettere l’intera catena di sviluppo, esponendo codice proprietario, credenziali di produzione e infrastrutture cloud attraverso funzionalità legittime della piattaforma.