GhostAction aggiunge uno stealer persistente a 94 repository
GhostAction ha esteso la propria supply chain attack, passando dai workflow GitHub Actions malevoli al phishing e a uno stealer di credenziali nascosto in un file presentato come web font. OpenSourceMalware ha identificato il componente di seconda fase in 94 repository compromessi e ha affermato che può rimanere attivo sul computer di uno sviluppatore anche dopo la rimozione del workflow originale. Una supply chain attack compromette un software o il relativo processo di sviluppo, consentendo al codice malevolo di raggiungere maintainer, progetti e utenti downstream.
Inizialmente, la campagna si basava sui workflow GitHub Actions, file presenti nei repository che indicano a GitHub quando e come eseguire job automatizzati. OpenSourceMalware ha dichiarato che, successivamente, l'operatore ha registrato my-github[.]com il 9 ottobre 2026 e lo ha indirizzato verso 193.32.204[.]199. Quell'indirizzo era già utilizzato per ricevere le informazioni raccolte dal workflow malevolo. La registrazione è avvenuta 17 giorni dopo quella di my-gitlab[.]com, ma gli investigatori non hanno stabilito che entrambi i domini siano controllati dallo stesso operatore. Le infrastrutture differiscono per registrar, record di registrazione, coppie di nameserver Cloudflare, provider Internet, indirizzi IP e configurazioni DNS; inoltre, i ricercatori non hanno trovato certificati condivisi né prove di account comuni.
Il giorno in cui è stato registrato my-github[.]com, il dominio è stato utilizzato per inviare un messaggio di phishing al maintainer di un progetto open source. Il phishing è un messaggio ingannevole progettato per indurre qualcuno a cedere l'accesso a un account o altre informazioni sensibili. Inviata da noreply@my-github[.]com, l'email si spacciava per una notifica di sicurezza di GitHub e sosteneva che fosse stato rilevato un accesso sospetto a Mosca, in Russia. Invitava il destinatario ad aprire un link presentato come mezzo per proteggere l'account.
OpenSourceMalware ha affermato che la pagina collegata funzionava come reverse proxy, un intermediario che inoltra il traffico tra un utente e un servizio autentico intercettando al contempo la sessione. Raccoglieva la password e il codice di two-factor authentication (2FA) della vittima, quindi utilizzava JavaScript iniettato per autorizzare un'applicazione OAuth. OAuth è un metodo che consente di concedere a un'applicazione l'accesso a un account senza fornirle direttamente la password. Gli scope richiesti, repo, workflow e read:org, che definivano l'accesso richiesto, permettevano di leggere e scrivere nei repository, modificare i file dei workflow GitHub Actions e visualizzare l'appartenenza alle organizzazioni e i relativi dati.
La pagina automatizzava anche l'OAuth device flow di GitHub. Il suo script otteneva un device code e uno user code, caricava la pagina di accesso del dispositivo, estraeva i form pertinenti, inseriva lo user code e inviava l'autorizzazione attraverso la sessione autenticata e inoltrata tramite proxy della vittima. La vittima non doveva inserire il device code né approvare consapevolmente l'applicazione. L'access token risultante, una credenziale digitale riutilizzabile, veniva inviato a my-github[.]com tramite la porta TCP 8443. Grazie all'accesso a livello di repository, l'operatore poteva enumerare i progetti attraverso l'application programming interface (API) di GitHub e inserire file malevoli in .github/workflows/.
La seconda fase era progettata per spostare l'esecuzione dai sistemi di GitHub ai computer degli sviluppatori. Aggiungeva tre file ai repository interessati. Il primo era una configurazione tasks.json di Microsoft Visual Studio Code contenente un trigger runOn: folderOpen, che avviava un task quando la cartella del progetto veniva aperta in VS Code. Il secondo era public/fonts/fa-solid-400.woff2, che sembrava un font ma conteneva lo stealer di credenziali. Il nome del file corrispondeva a quello utilizzato nella campagna Fake Font/PolinRider nel gennaio 2026. Il terzo file era un altro workflow GitHub Actions, destinato a essere eseguito qualora lo stealer locale non si fosse avviato.
Secondo OpenSourceMalware, il payload camuffato cercava AWS keys, PyPI e npm tokens, Git logins, Kubernetes cluster credentials, SSH private keys e credenziali per Anthropic Claude e Google Gemini. Questi secret possono consentire l'accesso a risorse cloud, account per la pubblicazione di software, repository di codice sorgente, cluster, sistemi remoti e servizi di intelligenza artificiale. Il task di VS Code installava inoltre un cron job, un comando pianificato sui sistemi Unix-like, che eseguiva ogni cinque minuti il codice fornito dall'attaccante. Le informazioni rubate venivano trasmesse allo stesso server mediante HTTP non cifrato sulla porta 8080.
Il workflow di continuous integration (CI) di fallback, ossia un job automatizzato del repository, era basato sul workflow malevolo originale, ma cercava ulteriori formati di credenziali. Se il caricamento diretto non riusciva, tentava di inserire i risultati in un gist GitHub segreto. OpenSourceMalware ha osservato il workflow con otto nomi di file: lint.yml, ci-check.yml, build-check.yml, repo-health.yml, audit.yml, code-review.yml, test-suite.yml e cache-cleanup.yml.
I 94 repository interessati appartenevano a 66 proprietari. Quindici erano stati successivamente eliminati, rinominati o resi privati. Tra i 79 rimasti accessibili, molti sembravano inattivi. Uno non veniva modificato da oltre nove anni, mentre 65 non ricevevano commit da più di un anno. I repository abbandonati restano comunque rilevanti perché sviluppatori o sistemi automatizzati potrebbero conservare vecchie copie, mentre le credenziali esposte tramite un workflow o un clone locale possono continuare a essere utilizzabili fino alla loro revoca.
OpenSourceMalware ha dichiarato che GitHub ha iniziato a impedire l'esecuzione del workflow di prima fase il 9 ottobre. Di conseguenza, le ondate di attacchi del 10 e del 12 ottobre non hanno estratto alcun secret. La seconda fase è comparsa sei giorni dopo il blocco e non richiedeva un GitHub-hosted runner, perché poteva avviarsi quando uno sviluppatore apriva localmente la cartella. I ricercatori non hanno potuto stabilire se l'intervento di GitHub abbia causato questo cambiamento, ma solo che l'operatore ha spostato l'esecuzione in un ambiente esterno ai controlli dei workflow.
Gli sviluppatori potenzialmente interessati dovrebbero utilizzare un dispositivo pulito per revocare gli accessi e i token GitHub, cambiare le password, verificare la presenza dei file aggiunti nei repository, sostituire ogni credenziale accessibile ai workflow e avvisare chiunque abbia clonato i progetti. OpenSourceMalware ha affermato che l'operatore rimane non identificato e sembrava avere un'esperienza limitata: il filtro delle variabili d'ambiente non rilevava la maggior parte delle API keys, la scansione della home directory poteva andare in timeout e perdere i propri risultati, e un solo indirizzo IP gestiva l'esfiltrazione, il phishing e vistose scansioni di Internet. Questa sovrapposizione dell'infrastruttura ha continuato a rendere individuabili le infezioni attraverso ricerche relative all'indirizzo.
Per le organizzazioni che stanno rivalutando gli accessi degli sviluppatori e l'esposizione dei repository, AEU-I offre servizi IT, infrastrutturali e di consulenza incentrati sulla sicurezza. L'incidente dimostra perché la sola rimozione di un workflow malevolo potrebbe non essere sufficiente quando un repository ha anche distribuito codice capace di persistere sui computer degli sviluppatori e copiare credenziali da diversi servizi connessi.