GitHub e wfx-loot: passaggi per rilevare e contenere il furto di segreti

La campagna wfx-loot ha raggiunto 4.837 account compromessi e ha verificato i permessi di scrittura in 61.764 repository GitHub; in almeno 1.835 ha eseguito codice che ha sottratto segreti e credenziali cloud, secondo Aikido. Il segnale iniziale è una pull request intitolata docs: dependency audit notes, ma trovarla non basta per sapere se il ladro è stato eseguito.

Gli aggressori hanno usato credenziali rubate per sondare i repository, compresi quelli a cui gli account accedevano come collaboratori. Poi iniettavano uno script nei flussi di GitHub Actions, negli script shell o in un hook di installazione di npm, e spesso cancellavano le modifiche e i registri. L'assenza di un registro non esclude l'esfiltrazione: i ricercatori consigliano di considerare esposti i segreti se il payload è stato eseguito.

1. Cerca i segnali in ogni repository

1. Controlla tutti i repository in cui il tuo account o i tuoi account di automazione potevano scrivere dal 10 novembre. Aikido indica che la campagna è iniziata intorno alle 12:45 UTC di quel giorno. Includi i repository delle organizzazioni e quelli accessibili come collaboratore, non solo quelli appartenenti al tuo utente. L'ambito seguiva i permessi di scrittura.

2. Cerca un branch wfx-docs e una pull request intitolata docs: dependency audit notes. Fai attenzione anche ai branch brevi con nomi come chore/ seguito da otto caratteri casuali, oppure ci-check- seguito da quattro cifre. Questa pull request è una prova di accesso: da sola non è il payload, ma Aikido considera compromesso l'account che l'ha aperta, anche se non ci sono altre modifiche.

3. Esamina la cronologia dei commit alla ricerca di ci: refresh build cache, chore: add ci helper e chore: add dependency audit workflow. Tra gli indicatori compaiono anche ci: restore e ci: cleanup, usati nella successiva operazione di pulizia. I messaggi dei commit possono rivelare l'iniezione, anche se la modifica è già stata annullata.

4. Ispeziona i file e le modifiche associate: una modifica a un flusso esistente, un nuovo file in .github/workflows/ con un nome simile a build-audit-, oppure uno script nascosto .ci- collegato a un hook in package.json. StepSecurity ha inoltre osservato codice aggiunto a script shell già eseguiti dai flussi. Non limitarti quindi a controllare i file dei workflow.

2. Scopri se il codice è stato eseguito

1. Nella cronologia di Actions, controlla le esecuzioni intorno al commit sospetto e cerca salti nella numerazione. Aikido descrive l'assenza di un numero di esecuzione come un segnale più affidabile rispetto alla ricerca di artefatti: l'aggressore eliminava esecuzioni e registri, a volte in meno di un minuto. Un salto può essere l'unica traccia visibile.

2. Non considerare pulita un'esecuzione solo perché non trovi artefatti con nomi come wfx-loot-, voci di cache con wfx- o riepiloghi contrassegnati con WFX-BEGIN. Aikido spiega che questi metodi erano disattivati nei campioni di questa campagna che ha analizzato; inoltre, l'invio poteva avvenire tramite altri canali. L'assenza di questi indicatori non dimostra che i dati non siano stati estratti.

3. Se il repository pubblicava pacchetti automaticamente, verifica se una delle modifiche si è propagata. Aikido ha identificato digitalelvis/neuronai-studio 3.14.3 su Packagist e github.com/onuragtas/docker-env nelle versioni v1.0.278 e v1.0.280. The Hacker News segnala anche il modulo github.com/vkuznet/gocurl nella pseudoversione v0.0.0-20261111095532-8d5aad0cb0da. In quest'ultimo caso, la sua analisi indica che il flusso malevolo non era stato eseguito. Verifica la versione esatta prima di intervenire.

4. Valuta separatamente le macchine che hanno installato o aperto il pacchetto Packagist 3.14.3: Aikido consiglia di considerarle compromesse. The Hacker News precisa che una normale installazione di Composer non esegue il ladro, ma può farlo un npm install all'interno della directory del pacchetto. Per le versioni interessate del modulo Go, il payload si trovava solo in un file di workflow; Aikido e The Hacker News sottolineano che il codice Go e i binari pubblicati non sono cambiati, pur raccomandando di ritirare quelle versioni.

3. Contieni l'accesso e ruota ciò che potrebbe essere stato esposto

1. Se confermi che il payload è stato eseguito, considera esposti tutti i segreti, le variabili, i token e i ruoli cloud a cui quei flussi potevano accedere. Ruotali immediatamente. Lo script era progettato per raccogliere credenziali di GitHub Actions, AWS, Azure e Google Cloud, tra le altre, oltre a file di configurazione, chiavi SSH e credenziali degli strumenti di sviluppo. Limita la rotazione all'insieme corretto, ma non restringerlo basandoti sull'intuito.

2. Revoca le credenziali degli account e delle automazioni che hanno aperto le pull request o inviato i commit sospetti. SafeDep, citato da The Hacker News, consiglia di revocare token, autorizzazioni delle app OAuth, chiavi SSH e sessioni, oltre ad attivare l'autenticazione a due fattori. Controlla in particolare gli account bot con permessi di scrittura: StepSecurity ha osservato commit pubblicati da account automatizzati.

3. Cerca segnali di persistenza nei provider cloud a cui il flusso aveva accesso. The Hacker News consiglia di controllare in Entra ID le credenziali federate con prefisso wfx-ci-; in AWS CloudTrail, le sessioni AssumeRoleWithWebIdentity o i nomi wfx- seguiti dagli eventi CreateAccessKey o UpdateAssumeRolePolicy; e in GCP, le chiamate GenerateAccessToken e SignJwt provenienti dall'identità del workload di GitHub. Aikido descrive modifiche che potevano mantenere l'accesso anche dopo la rotazione dei segreti.

4. Controlla anche i registri di HashiCorp Vault e i ruoli cloud associati ai flussi interessati. The Hacker News suggerisce di cercare in Vault accessi JWT dall'emittente OIDC di GitHub. Se un ruolo o una policy è stato modificato, ripristina la configurazione legittima ed elimina le credenziali non autorizzate; non considerare risolto l'incidente solo perché i vecchi token non funzionano più.

5. Se trovi modifiche malevole, conserva i dati disponibili per l'indagine prima di ripulire il repository e rimuovi o annulla il codice iniettato. Controlla branch, flussi, script shell e hook di npm. L'annullamento delle modifiche da parte dell'aggressore non è una correzione: potrebbe aver eseguito il codice ed estratto credenziali prima di cancellare le proprie tracce.

Errori che possono lasciare l'accesso aperto

Non confondere la pull request di prova con il payload. La prima dimostrava che un account poteva scrivere nel repository; il payload malevolo arrivava in seguito e non in tutti i casi. Al contrario, trovare solo la pull request non significa che l'account sia sicuro: Aikido considera compromesso l'account che l'ha aperta.

Non fidarti solo del fatto che le modifiche siano scomparse, che il flusso risulti corretto o che manchino artefatti. Gli aggressori annullavano i commit ed eliminavano le esecuzioni, e StepSecurity ha documentato che il codice poteva anche essere nascosto in script già usati dall'automazione. Verifica la cronologia e l'accesso al cloud, non solo lo stato attuale dell'albero dei file.

Infine, non applicare la stessa conclusione a tutti i pacchetti. Packagist 3.14.3 può eseguire il codice se viene lanciato npm install nella sua directory; le versioni di docker-env contengono il payload in un workflow, non nel codice Go né nei binari, secondo Aikido. Anche la versione di gocurl segnalata da The Hacker News contiene il codice in un workflow che non era stato eseguito. Le risposte devono tenere conto di queste differenze, senza però lasciare disponibili le versioni identificate.

Fonti: TechRadar, BleepingComputer, Aikido Security, StepSecurity, The Hacker News