Shai-Hulud Infostealer Scansiona 469 Posizioni di Credenziali

Una recente variante del worm infostealer Shai-Hulud ha ampliato il numero di luoghi in cui cerca credenziali da 189 a 469, secondo una ricerca pubblicata da GitGuardian all'inizio di agosto. La nuova lista di obiettivi copre workstation di sviluppatori, sistemi di integrazione continua e consegna continua (CI/CD), configurazioni cloud e persino file di configurazione utilizzati da strumenti di sviluppo di intelligenza artificiale. Un infostealer è un malware progettato per raccogliere password, token di accesso e altri dettagli di accesso da una macchina infetta, e le credenziali sono le password o i token che programmi e persone usano per dimostrare la propria identità. Il cambiamento è importante perché gli attaccanti non cercano più di superare le barriere di fiducia. Stanno raccogliendo le credenziali esistenti che già fanno funzionare i sistemi software fidati.

Le catene di fornitura del software sono sempre dipese dalla fiducia. Gli sviluppatori si fidano di registri di pacchetti come npm o Docker Hub. Le organizzazioni si fidano dei manutentori dei progetti. I sistemi CI/CD si fidano delle credenziali e delle identità che vengono loro fornite, e le applicazioni si fidano delle dipendenze che scaricano durante una build. Gli attaccanti hanno capito che non hanno bisogno di rompere nessuna di queste fiducie. Devono solo trovare dove già si trovano credenziali e privilegi permanenti. Ecco perché la raccolta di credenziali è diventata l'elemento fondamentale per il successo dei worm infostealer. Shai-Hulud appartiene a una classe crescente di attacchi alla catena di fornitura che cercano in un ambiente già compromesso qualsiasi credenziale che possa aiutare l'attacco a continuare.

Il percorso da una credenziale rubata alla successiva è diretto. Un token trovato su una workstation di sviluppatore potrebbe aprire l'accesso al codice sorgente, e quel codice sorgente può contenere credenziali cloud, che possono quindi concedere accesso all'infrastruttura. Un token di accesso GitHub, che è una stringa di testo che consente a un programma o a una persona di accedere a un account GitHub, può consentire l'accesso in scrittura a repository aggiuntivi, mentre una credenziale di pubblicazione di pacchetti può permettere a un attaccante di pubblicare software attraverso un canale di cui gli sviluppatori già si fidano. Le credenziali diventano il tessuto connettivo tra un ambiente compromesso e il successivo. Le macchine moderne degli sviluppatori contengono molto più materiale di autenticazione del solo repository sorgente. Le credenziali appaiono in luoghi attesi come file .env, cronologia della shell e configurazione del gestore di pacchetti, ma si nascondono anche nelle cache dell'interfaccia a riga di comando, nei file di configurazione CI/CD, nelle impostazioni dell'ambiente di sviluppo integrato e sempre più nella configurazione utilizzata dagli assistenti di codifica AI. L'attaccante non sempre sa quale credenziale sia più importante prima di iniziare la raccolta, quindi raccoglie ciò che è disponibile e capisce cosa sblocca ciascuna in seguito.

I difensori dovrebbero affrontare il problema nella direzione opposta, secondo l'analisi di GitGuardian. I team di sicurezza devono identificare quali credenziali contano di più e affrontare la loro esposizione prima che un attaccante possa usarle. Le credenziali di pubblicazione di pacchetti meritano un'attenzione speciale perché trasformano il furto di credenziali in distribuzione di software. I token che gli sviluppatori usano per pubblicare pacchetti portano autorità su un pacchetto fidato che altri sviluppatori, sistemi di build e organizzazioni consumeranno automaticamente. Questa fiducia è ciò che gli attaccanti abusano. Le organizzazioni dovrebbero ridurre il numero di credenziali di pubblicazione permanenti disponibili da rubare e spostarsi verso un'autenticazione verificata a breve termine tramite OpenID Connect (OIDC), uno standard che consente a un servizio di verificare l'identità senza consegnare una password di lunga durata, o meccanismi simili con ambito limitato. Docker e GitHub Actions hanno recentemente spinto l'ecosistema in questa direzione con un'autenticazione più forte e un maggiore uso della pubblicazione fiducia. Qualsiasi credenziale di pubblicazione di lunga durata che rimane dovrebbe essere trattata come infrastruttura altamente sensibile.

Le credenziali collegano anche sistemi che i team di sicurezza spesso gestiscono separatamente. I team di sicurezza tradizionalmente pensano in termini di sicurezza del controllo del codice sorgente, sicurezza CI/CD, sicurezza cloud, sicurezza degli endpoint e sicurezza delle applicazioni. Ma un singolo sviluppatore può autenticarsi su GitHub, npm, AWS, Kubernetes (un sistema che esegue applicazioni containerizzate su molte macchine), API interne e infrastruttura di build in un normale giorno di lavoro, e le pipeline CI/CD spesso portano un insieme altrettanto diversificato di credenziali. Una credenziale lasciata in un ambiente di sviluppatore può rappresentare autorità da qualche parte completamente diversa. Il file potrebbe trovarsi su un laptop mentre la credenziale controlla una risorsa cloud o concede diritti di pubblicazione di pacchetti. Dove viene scoperto un segreto racconta solo parte della storia. Le organizzazioni che lavorano verso la maturità della gestione dei segreti devono anche sapere se la credenziale è valida, a quale identità appartiene, quale sistema la accetta, quali privilegi porta, quale ambiente raggiunge e chi possiede la sua correzione. Questo trasforma il rilevamento dei segreti in gestione del rischio delle credenziali.

Non ogni segreto esposto crea lo stesso rischio. Una lista con 100.000 segreti trovati non rappresenta 100.000 incidenti ugualmente urgenti. Alcune credenziali sono già non valide, altre raggiungono ambienti di sviluppo usa e getta, e un numero minore fornisce accesso a database di produzione, infrastruttura cloud, sistemi di distribuzione o pubblicazione di pacchetti. Trattare questi risultati in modo identico costruisce code invece di ridurre il rischio. La prima priorità dovrebbe essere rimuovere le chiavi di pubblicazione di pacchetti dal testo chiaro. Gli sviluppatori e l'automazione delle pipeline spesso scrivono chiavi di autenticazione in file di configurazione locali come parte dei normali flussi di lavoro, ma un segreto non deve essere stato committato su Git per essere disponibile al malware in esecuzione sulla macchina dello sviluppatore. Questo è uno dei motivi per cui i recenti attacchi alla catena di fornitura prendono di mira sempre più l'ambiente di sviluppo stesso. La credenziale di pubblicazione più difficile da rubare per un attaccante è quella che non esiste. Se deve esistere, più breve è la finestra in cui l'accesso può essere concesso, meglio è. L'obiettivo è eliminare l'autorità di pubblicazione riutilizzabile in testo chiaro e spostare la pubblicazione di pacchetti verso meccanismi a breve termine basati sull'identità dove supportati. La pubblicazione fiducia basata su OIDC è un esempio. La maggior parte delle piattaforme cloud si sta muovendo verso servizi di token di sicurezza federati come AWS STS, che consentono la verifica del carico di lavoro attraverso piattaforme dove gli artefatti vengono spinti.

Dopo le credenziali di pubblicazione, le organizzazioni dovrebbero concentrarsi sulle credenziali che forniscono accesso a sistemi di produzione critici. Una credenziale esposta legata a un ambiente di sviluppo isolato potrebbe creare danni limitati, mentre una credenziale valida con accesso in scrittura all'infrastruttura di produzione è un incidente completamente diverso. Una breve lista utile include account cloud di produzione, database che contengono informazioni sui clienti, infrastruttura di firma, cluster Kubernetes, strumenti di distribuzione e interfacce amministrative. La domanda chiave è cosa succede se un attaccante fa qualcosa di dannoso con l'accesso rubato. La validità è un filtro utile, e determinare il vero raggio di esplosione aiuta a prioritizzare quali sistemi affrontare per eliminare i segreti di lunga durata o almeno ruotarli. Le credenziali condivise creano percorsi nascosti tra ambienti. Una credenziale scoperta in staging potrebbe ancora autenticarsi contro la produzione. Un token copiato nell'ambiente locale di uno sviluppatore potrebbe mantenere privilegi destinati all'automazione, e la stessa credenziale potrebbe apparire in più sistemi molto tempo dopo che il suo scopo originale è stato dimenticato. Trovare il segreto è solo il primo passo; gli avvisi sono solo rumore se non lo mappano all'identità, ai privilegi, alle risorse, agli ambienti e ai proprietari dietro di esso.

Una volta gestite le credenziali di pubblicazione di pacchetti e l'accesso ovvio alla produzione, le organizzazioni possono lavorare sistematicamente attraverso l'inventario rimanente delle credenziali. L'obiettivo non è ruotare tutto a caso ma costruire un piano d'azione che rimuova continuamente le credenziali più utili dal percorso dell'attaccante. La validità è un buon punto di partenza. Una credenziale valida merita attenzione più immediata di una già scaduta o revocata, e su larga scala la distinzione conta enormemente. La ricerca State of Secrets Sprawl di GitGuardian ha trovato 28,65 milioni di nuovi segreti hardcoded aggiunti ai commit pubblici di GitHub solo nel 2025, un aumento del 34% anno su anno. Volumi di questa scala rendono il triage manuale irrealistico. I team devono determinare quali risultati rappresentano ancora autenticazione utilizzabile e spostarli verso la parte anteriore della coda. La validità da sola non racconta ancora tutta la storia. Una credenziale valida per un servizio di sviluppo condiviso merita attenzione, ma una credenziale valida con accesso amministratore a un account cloud di produzione merita considerevolmente di più. La prioritizzazione dovrebbe aggiungere contesto: se la credenziale è ancora valida, se raggiunge produzione, staging o sviluppo, quale identità rappresenta, quali privilegi ha quell'identità, quali risorse può accedere, dove altro viene utilizzata la credenziale e chi la possiede e può ruotarla o revocarla. Risposte che possono essere verificate trasformano una lista travolgente di segreti trapelati in un vero piano di rimedio.

La nuova ondata di attacchi Shai-Hulud dovrebbe portare a più di una pulizia una tantum delle credenziali. Le credenziali continueranno ad accumularsi mentre gli sviluppatori costruiscono software, i servizi si integrano, le pipeline evolvono e nuovi strumenti entrano nell'ambiente. La risposta deve diventare un ciclo ripetibile. Le organizzazioni hanno prima bisogno di ampia visibilità su tutte le credenziali, incluso il codice sorgente e la storia di Git, ma gli attacchi moderni suggeriscono di guardare ulteriormente nei sistemi CI/CD e negli ambienti degli sviluppatori dove si accumula materiale di autenticazione. Il rilevamento dovrebbe rispondere a dove esiste attualmente autorità riutilizzabile, e dovrebbe essere verificabile piuttosto che riflettere semplicemente i segreti noti già memorizzati in un vault. La percentuale di segreti che esistono al di fuori del vault è una metrica importante quando si affronta la sicurezza dei segreti su larga scala, perché i piani di rimedio che non tengono conto dei segreti orfani in testo chiaro sono destinati a fallire. La prevenzione deve fermare lo stesso strato di credenziali dal ricostruirsi bloccando nuovi segreti hardcoded, spostando i flussi di lavoro verso credenziali a breve termine dove possibile, proteggendo le credenziali negli ambienti degli sviluppatori e catturando nuova esposizione prima che diventi un altro grande progetto. Rilevamento, rimedio e prevenzione devono essere trattati come un ciclo continuo, non come una risposta di emergenza innescata dopo un attacco. Per i proprietari di siti web e i team più piccoli senza una funzione di sicurezza a tempo pieno, una revisione IT e infrastrutturale security-first come quella offerta da AEU-I può aiutare a costruire quell'inventario di credenziali e la baseline del minimo privilegio. La prossima variante di Shai-Hulud cercherà quasi certamente in un posto nuovo, espandendosi oltre le 469 posizioni già identificate. Gli attaccanti continueranno ad aggiungere percorsi e strumenti per sviluppatori perché gli ambienti software moderni sono pieni di autorità riutilizzabile. I difensori non vinceranno memorizzando ogni posto dove il prossimo infostealer potrebbe guardare. Vincono rimuovendo il privilegio permanente ed eliminando le credenziali esposte ovunque esistano, così che ogni volta che arriva un nuovo worm, ci sono meno chiavi trovabili da abusare.