Le conseguenze di Shai-Hulud 2 e cosa si potrebbe fare diversamente

Il worm npm Shai-Hulud 2.0 è uno di quegli incidenti a cui i team AppSec faranno riferimento nelle analisi post-mortem per anni.

Analizziamo cosa è successo, chi è stato colpito e come una piattaforma SSCS come ScribeHub avrebbe potuto aiutare le organizzazioni a prevenire o almeno a limitare drasticamente il raggio dell'esplosione.

1. Che cos'è Shai-Hulud 2.0?

Shai-Hulud è apparso per la prima volta nel settembre 2025 come worm autoreplicante che prende di mira l'ecosistema npm, compromettendo centinaia di pacchetti JavaScript e diffondendosi tramite credenziali rubate e ripubblicazione automatica. 

Solo un paio di mesi dopo, i ricercatori hanno iniziato a vedere un onda di follow-up molto più aggressiva e automatizzata, ora comunemente indicato come “Shai-Hulud 2.0”, “Sha1-Hulud 2.0” o “La Seconda Venuta”. 

Caratteristiche principali di Shai-Hulud 2.0:

• Focus sulla catena di fornitura. Invece di attaccare una sola azienda, attacca pacchetti npm affidabili e, in varianti successive, persino gli ecosistemi Java (Maven), avvelenando i componenti fondamentali utilizzati in migliaia di progetti.
• Verme autopropagante. Una volta compromesso un manutentore, crea automaticamente delle backdoor contro tutti i dei pacchetti di quel manutentore e li ripubblica, consentendo una diffusione esponenziale attraverso i grafici delle dipendenze.
• Ladro di informazioni che ruba segreti. Il payload raccoglie in modo aggressivo variabili ambientali, token GitHub e npm, credenziali cloud e segreti CI/CD dalle macchine degli sviluppatori e dalle pipeline di build. 
• Interruttore “dead-man” distruttivo. Se il malware non riesce a raggiungere il suo C2 o non riesce a propagarsi, alcune varianti tentano di cancellare la directory home dell'utente, trasformando la compromissione della supply chain in un potenziale incidente distruttivo.

2. Come funziona l'attacco – passo dopo passo

Diversi fornitori hanno osservato strumenti e script leggermente diversi, ma la kill chain complessiva si presenta più o meno così:

2.1 Punto d'appoggio iniziale: account del manutentore compromessi

Attaccanti:

1. Account dei manutentori npm/GitHub compromessi utilizzando token rubati in precedenza, phishing, riutilizzo delle password o MFA debole.
2. Ho utilizzato quegli account per pubblicare versioni trojanizzate di pacchetti legittimi – spesso con solo un aumento della versione a livello di patch, in modo da integrarsi nei normali schemi di aggiornamento.

Poiché i pacchetti erano firmati/pubblicati dai legittimi responsabili, apparivano affidabili agli occhi dei consumatori a valle.

2.2 Infezione tramite pipeline npm install / CI

Le organizzazioni hanno ritirato questi pacchetti:

• tramite normale installazione di npm nello sviluppo locale,
• o indirettamente in Pipeline CI / CD come parte di build automatizzate.

I pacchetti dannosi in genere sfruttati script del ciclo di vita npm (preinstallare, install, post-installazione) come vettori di esecuzione, scaricando ed eseguendo un payload di seconda fase come bundle.js, setup_bun.jso file offuscati di grandi dimensioni simili. 

2.3 Furto di credenziali e ricognizione ambientale

Una volta in esecuzione, il payload:

• Variabili di ambiente enumerate e file di configurazione locali.
• raccolto credenziali cloud, token GitHub/GitLab, token di accesso npm, chiavi SSH e altri segreti.
• Strumenti usati occasionalmente come Scansione in stile TruffleHog per cercare segreti nei repository.

Queste credenziali furono poi esfiltrati nei repository GitHub controllati dagli aggressori o altre infrastrutture C2, spesso nominate per mimetizzarsi (ad esempio, repository "Shai-Hulud" popolati con dump di ambienti rubati). 

2.4 Movimento laterale negli ecosistemi degli sviluppatori

Utilizzando i token rubati, il malware:

• Backdoor su tutti i pacchetti npm di proprietà dei manutentori compromessi, che iniettano gli stessi script dannosi e li ripubblicano.
• Planted flussi di lavoro dannosi di GitHub Actions e backdoor nei repository delle vittime per la persistenza e l'esfiltrazione continua durante le esecuzioni CI.
• In alcune varianti 2.0, estese oltre npm in Repository Maven, dimostrando una reale portata della catena di fornitura inter-ecosistema. 

Poiché molte librerie popolari si trovano in alto negli alberi delle dipendenze, un compromesso di pochi manutentori si traduce in decine di migliaia di repository interessati a valle.

3. Scala e impatto sulle vittime

I diversi fornitori di sicurezza riportano numeri leggermente diversi, ma tutti concordano su una cosa: Shai-Hulud 2.0 è enorme.

• I ricercatori sulla sicurezza stimano che più di 25,000 repository GitHub e al da centinaia a ~700 pacchetti sono stati colpiti nelle ondate successive, alcune delle quali appaiono in oltre un quarto degli ambienti cloud/codice hanno scansionato.
• Gli analisti lo chiamano uno degli attacchi alla supply chain npm più rapidi mai visti, con un'automazione che ha compromesso centinaia di pacchi in poche ore.
• Tra le vittime di alto profilo figurano progetti e pacchetti provenienti da Zapier, ENS Domains, PostHog, Postman, e altri, il che significa che sia i fornitori SaaS sia migliaia dei loro clienti avevano una potenziale esposizione.

3.1 Impatto tecnico diretto

Per le organizzazioni che hanno rimosso un pacchetto trojanizzato, le conseguenze tipiche includevano:

• Esposizione dei segreti CI/CD (chiavi del provider cloud, token di distribuzione, certificati di firma del codice, ecc.).
• Backdoor furtive nei repository GitHub e nelle azioni CI, consentendo agli aggressori di eseguire comandi arbitrari nelle build future.
• Manufatti manomessi: la possibilità che gli aggressori inseriscano logica dannosa nelle applicazioni sviluppate senza che gli sviluppatori se ne accorgano.
• Per alcuni sfortunati sviluppatori, un cancellazione distruttiva del $ HOME elenco quando è entrato in azione il fallback del malware.

3.2 Impatto aziendale

Da una prospettiva aziendale, questo si traduce in:

• Eventi di risposta agli incidenti su larga scala:I team IR hanno dovuto controllare ogni progetto utilizzando i pacchetti interessati, ruotare i token e talvolta bloccare le distribuzioni.
• Esposizione normativa e contrattuale: i settori regolamentati (finanza, sanità, fornitori governativi) ora si trovano ad affrontare la possibilità che dati regolamentati o chiavi di accesso al sistema critico siano stati esfiltrati tramite un pacchetto di terze parti.
• L'erosione della fiducia nell'open source: i responsabili della sicurezza e dell'ingegneria sono costretti a rivedere il loro modello di fiducia per i registri pubblici e a prendere in considerazione controlli più rigorosi sulla gestione delle dipendenze.

4. Dove le difese tradizionali faticano

Perché Shai-Hulud 2.0 ha superato così tante difese?

1. Si è trattato di un abuso di fiducia, non di una semplice vulnerabilità. I pacchetti erano "legittimi", ovvero pubblicati con i nomi dei veri manutentori, spesso provenienti da repository esistenti.
2. SCA/SAST statico non era sufficiente. Anche se i team avevano SBOM e scanner di vulnerabilità, molti di loro non cercavano comportamentale indicatori quali script del ciclo di vita sospetti o esfiltrazioni in uscita durante le build.
3. I veri obiettivi erano i segreti e la CI/CD. Molte organizzazioni hanno controlli e monitoraggi più deboli per gli ambienti CI/CD rispetto alla produzione, il che li rende obiettivi perfetti.
4. Mancanza di provenienza end-to-end. La maggior parte dei team non è riuscita a rispondere facilmente: "Quali build, artefatti e distribuzioni coinvolgono esattamente un pacchetto trojanizzato e quali sono puliti?"

Questo è esattamente il divario che sicurezza della catena di fornitura del software (SSCS) piattaforme come ScribeHub sono progettati per affrontare.

 

5. Come ScribeHub SSCS potrebbe aiutare a prevenire e mitigare gli attacchi in stile Shai-Hulud

Associamo le tecniche di Shai-Hulud 2.0 alle funzionalità che normalmente implementeresti con la piattaforma ScribeHub di Scribe Security e gli strumenti correlati (ad esempio, Valint policy-as-code).

5.1 Limitazioni all'ingestione delle dipendenze

Problema in Shai-Hulud 2.0:
Le organizzazioni hanno consumato automaticamente i pacchetti npm aggiornati (tramite ^/~ intervalli di versione, Renovate/Dependabot o script CI) con scarso controllo comportamentale.

Con ScribeHub:

• Controlli delle dipendenze basati su policy. Utilizzare i criteri Valint per limitare i registri e gli ambiti considerati "affidabili", applicare elenchi consentiti per i pacchetti critici e avvisare quando:
  • un nuovo manutentore pubblica una versione,
  • compaiono script del ciclo di vita inaspettati,
  • oppure un pacchetto acquisisce improvvisamente un nuovo comportamento di rete/esecuzione.
• Attestazione su componenti di terze parti. ScribeHub può acquisire e verificare attestazioni di provenienza e costruzione per i pacchetti dove disponibili (ad esempio, metadati in stile SLSA, Sigstore, in-toto), abilitando regole come "consumare solo dipendenze di cui ci fidiamo della provenienza."

Questo non risolve magicamente l'ecosistema npm, ma lo fa in modo significativo alza l'asticella prima che una nuova versione venga ammessa nelle tue build.

5.2 Rafforzare la pipeline CI/CD come “risorsa di prima classe”

Il valore principale di Shai-Hulud derivava dallo sfruttamento laptop per sviluppatori e nodi CI/CD come caveau segreti.

Utilizzo di ScribeHub:

• Attestazione della pipeline per ogni esecuzione.
  Ogni processo CI produce un'attestazione firmata che descrive:
  • quali repository e branch sono stati creati,
  • quali dipendenze e immagini del contenitore sono state utilizzate,
  • quali script sono stati eseguiti (inclusi gli hook del ciclo di vita),
  • e quali segreti sono stati scoperti.
• Quei dati arrivano in Il lago di prove di ScribeHub, fornendoti una cronologia a prova di manomissione di "chi ha costruito cosa, da dove, con quali input".
• Controlli runtime policy-as-code.
  Prima che un artefatto di build possa essere promosso a staging/produzione, un motore di policy convalida:
  • che sono stati utilizzati solo registri npm approvati,
  • che non ci siano script del ciclo di vita proibiti (ricciolo | colpo, offuscato bundle.js, ecc.) vengono eseguiti,
  • che il runner non veniva eseguito come root e non montava percorsi host sensibili.

Se Shai-Hulud inietta un ulteriore post-installazione script che esfiltra segreti, quelle corse fallire la politica e non raggiungono mai la produzione.

5.3 Analisi rapida del raggio dell'esplosione

Uno dei compiti più difficili in una campagna come questa è rispondere a:

"Dove esattamente abbiamo utilizzato le versioni trojanizzate del pacchetto X e cosa hanno toccato?"

Con ScribeHub:

• Ogni build, distribuzione e artefatto è associato a attestazioni collegate crittograficamente: dipendenze, dettagli dell'ambiente, SHA di commit, digest dei container, ecc.
• Quando un nuovo avviso dice "versioni 4.8.1–4.8.5 di qualche biblioteca fanno parte di Shai-Hulud 2.0", chiedi a ScribeHub:
  
  
  "Mostrami tutte le build degli ultimi 90 giorni che includevano quelle versioni e quali distribuzioni o immagini hanno prodotto."
  
• È quindi possibile rotazione segreta del bersaglio e bonificare esattamente dove serve, anziché ruotare tutto alla cieca (cosa che potrebbe essere irrealistica dal punto di vista operativo).

In altre parole, ScribeHub trasforma il panico di un intero ecosistema in un incidente delimitato e verificabile.

5.4 Proteggere i tuoi dati proprio i pacchi dall'essere trasformati in armi

Molte organizzazioni non solo consumano software open source, ma anche pubblicare Pacchetti utilizzati da clienti, partner o team interni. Se un account di un manutentore della tua organizzazione venisse compromesso, potresti diventare un vettore di propagazione involontario, proprio come i manutentori di Shai-Hulud.

ScribeHub può aiutarti:

• Richiedere attestazioni firmate dal tuo CI prima che un pacchetto possa essere pubblicato su npm o su un registro interno:
  • Le versioni del pacchetto che non sono accompagnate dalle attestazioni previste vengono rifiutate o segnalate.
• Monitoraggio continuo dei tuoi registri e repository:
  • Avvisi quando un pacchetto viene pubblicato da un ambiente di build sconosciuto o al di fuori delle pipeline CI approvate.
  • Rilevamento di nuove GitHub Actions o script npm non presenti nell'ultima versione "attendibile".

Questo lo rende molto più difficile per un aggressore con un token rubato per inserire silenziosamente una versione dannosa nel tuo namespace.

5.5 Prove per gli enti regolatori, i clienti e le parti interessate interne

Incidenti come Shai-Hulud 2.0 sono sempre più esaminati dagli enti regolatori e dai grandi clienti, soprattutto nei settori allineati con quadri normativi come NIST SSDF, PCI-DSS 4o requisiti di attestazione del software governativo.

Poiché ScribeHub mantiene un registrazione firmata e con timestamp dell'attività SDLC, puoi:

• Dimostrare quali build e release non sono state interessate da dipendenze trojanizzate.
• Fornire ai revisori prove concrete di:
  • politiche di dipendenza,
  • applicazione del privilegio minimo in CI,
  • e tempi di rotazione segreta dopo l'incidente.

Questo trasforma la conversazione da "pensiamo di stare bene" a "ecco la catena di custodia certificata per il nostro software".

6. Suggerimenti pratici per i responsabili della sicurezza

Riassumendo, ecco come riassumerei Shai-Hulud 2.0 e il ruolo che una piattaforma come ScribeHub può svolgere:

1. Supponiamo che l'ecosistema sia compromesso. I registri pubblici sono troppo attraenti come singoli punti di errore. Il tuo modello di sicurezza deve trattare le dipendenze esterne come non attendibili fino a prova contraria.
2. Passare da “scansiona e prega” a “attesta e fai rispettare”. La SCA classica e il linting rimangono importanti, ma Shai-Hulud 2.0 dimostra che abbiamo anche bisogno di:
   • forte provenienza,
   • build attestate,
   • e promozione di artefatti tutelata da policy.
3. Trattare CI/CD come produzione. Il worm prendeva di mira segreti e pipeline perché spesso rappresentano bersagli più facili rispetto agli ambienti di runtime più protetti.
4. Investire nella tracciabilità. Quando si verificherà il prossimo compromesso a livello di ecosistema – e accadrà – la tua capacità di rispondere alla domanda "Dove ci ha toccato?" nel giro di poche ore anziché di settimane farà la differenza tra un incidente controllato e una crisi su vasta scala.

ScribeHub SSCS non rende npm o open source magicamente sicuri, ma fornisce la visibilità, il controllo e la struttura probatoria necessari per resistere ad attacchi in stile Shai-Hulud con molto meno caos.

Se progetti il ​​tuo SDLC attorno ad attestazioni firmate continue, policy basate su prove e una solida igiene CI/CD, il prossimo "più grande attacco alla supply chain npm della storia" diventa un altro incidente da gestire, non una minaccia esistenziale per la tua attività.