Attacco alla supply chain Mini Shai-Hulud: perché questa campagna cambia il modo in cui i difensori dovrebbero pensare al software affidabile

L'attacco alla catena di approvvigionamento denominato "Mini Shai-Hulud" non è semplicemente l'ennesimo episodio legato a un pacchetto dannoso. Tale campagna ha sfruttato in modo improprio infrastrutture di rilascio legittime, tra cui flussi di lavoro di pubblicazione affidabili, pipeline con firma di provenienza e ambienti di sviluppo. Queste tecniche riescono particolarmente bene a far apparire normali le attività dannose, poiché il codice supera la maggior parte dei controlli standard di verifica e integrità.

Secondo l’analisi post mortem di TanStack pubblicata dall’ , i pacchetti TanStack compromessi recavano attestati di provenienza validi, generati dalla pipeline di pubblicazione affidabile “ GitHub ” del progetto stesso. Anche nei casi in cui le attestazioni di provenienza fossero valide, la provenienza di per sé non era sufficiente. La campagna, attribuita al gruppo di hacker TeamPCP, ha poi utilizzato le credenziali di pubblicazione sottratte per diffondere la campagna attraverso ulteriori pacchetti.

Molti dei controlli che i team di sicurezza hanno impiegato anni a implementare sono stati progettati per verificare l’autenticità, non l’intenzione. In questa campagna, i controlli di autenticità risulterebbero comunque superati, nonostante il software fornito fosse compromesso.

Cosa è accaduto nell’attacco alla catena di approvvigionamento di Mini Shai-Hulud

Come riportato pubblicamente in tutta la comunità di sicurezza Community , questa campagna ha interessato oltre 170 pacchetti su npm e PyPI e ha coinvolto ecosistemi con un’enorme portata a valle. L'attacco ha preso di mira strumenti e librerie di sviluppo ampiamente utilizzati, tra cui pacchetti legati a framework front-end, SDK di intelligenza artificiale, strumenti di automazione aziendale e infrastrutture di ricerca.

A grandi linee, la campagna ha funzionato in questo modo:

• Gli autori dell'attacco hanno dirottato un percorso di pubblicazione attendibile compromettendo il processo di compilazione stesso.
• Le versioni dannose dei pacchetti sono state pubblicate attraverso flussi di lavoro legittimi e recavano attestati di provenienza validi.
• Una volta installati, tali pacchetti sottraevano le credenziali dai computer degli sviluppatori e dai server CI/CD.
• Il malware ha quindi utilizzato tali credenziali rubate per pubblicare ulteriori pacchetti compromessi.
• Sono stati aggiunti meccanismi di persistenza per resistere ai tentativi di pulizia e proseguire il furto delle credenziali.

È proprio questo che ha conferito alla campagna un carattere simile a quello di un worm. Ogni ambiente appena compromesso potrebbe diventare un punto di diffusione per la prossima ondata.

Perché questo attacco è diverso

Ha abusato delle procedure di rilascio basate sulla fiducia, non solo della fiducia nei pacchetti

L'autore dell'attacco ha dirottato una pipeline di rilascio legittima, anziché limitarsi a pubblicare evidenti typosquat o pacchetti contraffatti. Le versioni dannose conservavano segnali di provenienza validi, il che evidenzia che i controlli di autenticità da soli non erano sufficienti.

Se il Suo unico o principale controllo consiste nel verificare se un pacchetto provenga dalla pipeline prevista, ciò non è sufficiente. La pipeline costituiva il vettore di attacco, e il Mini Shai-Hulud sarebbe risultato legittimo nei controlli standard volti a verificare e confermare quale pipeline avesse generato un artefatto, senza accertare se il contenuto dell’artefatto fosse intenzionale.

Si è diffuso attraverso l’identità, non solo attraverso il codice

Questa campagna era fortemente incentrata sull’identità e si è svolta all’interno di un ecosistema caratterizzato da un’estrema proliferazione di segreti. La portata dei segreti esposti nell’ecosistema ha consentito a tale fenomeno di diffondersi: GitGuardian ha segnalato che nel 2025 sono stati resi pubblici su GitHub 28,65 milioni di nuovi segreti hardcoded.

Anziché affidarsi esclusivamente a un'esecuzione una tantum, si è concentrata sul furto di credenziali dai computer degli sviluppatori e dai server CI/CD. Una volta che gli autori degli attacchi si erano impossessati di tali identità, è stata proprio la distribuzione del software a fungere da meccanismo di diffusione. Era destinato agli ambienti di sviluppo come livello di persistenza.

La campagna ha integrato meccanismi di persistenza negli strumenti di sviluppo e nei percorsi di configurazione locali, tra cui , le directory relative agli IDE e gli ambienti di programmazione assistiti dall’intelligenza artificiale. La persistenza nel file .claude/settings.json (un hook SessionStart che viene rieseguito ad ogni sessione di Claude Code) e nel file .vscode/tasks.json (che viene eseguito automaticamente all’apertura della cartella) implica che il semplice comando "npm uninstall" non sia sufficiente a rimuoverlo.

Come funzionava la catena di attacco

Sebbene le modalità di attuazione variassero a seconda del pacchetto e dell’ecosistema, la campagna combinava in linea di massima l’ la compromissione della catena di approvvigionamento, il furto di credenziali e l’autopropagazione.

Cosa il malware ha cercato di sottrarre

Reporting L’analisi relativa all’attacco alla catena di approvvigionamento “Mini Shai-Hulud” evidenzia un ampio raggio d’azione nella raccolta dei dati. L'obiettivo non era limitarsi a un solo tipo di gettone. Nel Q3 2025, Sonatype ha rilevato che il 37% dei pacchetti open source dannosi ha come obiettivo l’esfiltrazione di dati, e questa campagna ha seguito lo stesso schema. È stato progettato per raccogliere qualsiasi elemento utile ai fini del movimento laterale, della persistenza e della compromissione successiva.

Tra gli obiettivi più comuni figuravano:

• Credenziali del fornitore di servizi cloud
• Token del registro dei pacchetti
• Segreti della pipeline CI/CD
• Credenziali Git e token di controllo del codice sorgente
• File di configurazione di Kubernetes, token degli account di servizio e credenziali o token che consentono l’accesso ai gestori di segreti
• Chiavi SSH
• File di configurazione dello sviluppatore locale
• Impostazioni degli strumenti di sviluppo per l'intelligenza artificiale
• Dati relativi ai portafogli di criptovalute in alcune varianti

Le squadre di intervento non dovrebbero ragionare secondo lo schema “sostituire il token npm e andare avanti”. Se un pacchetto infetto venisse eseguito in un ambiente sensibile, il raggio d’azione dell’esplosione risulterebbe probabilmente molto più ampio.

Segnali che potrebbero indicare che siete stati colpiti

I team di sicurezza incaricati di indagare su potenziali vulnerabilità dovrebbero esaminare sia le dipendenze che il comportamento dell' endpoint . Non si tratta solo di un problema di composizione del software.

Segni relativi al livello di dipendenza

Inizi con:

• File di blocco che fanno riferimento alle versioni interessate
• Registri di installazione dei pacchetti a partire dalla versione 11 maggio
• Script del ciclo di vita non previsti, quali preinstall o prepare
• Dipendenze opzionali sospette o riferimenti a pacchetti basati su Git
• Archivi tar di dimensioni insolitamente grandi o file offuscati incorporati

Segnali a livello di endpoint e di ambiente

Cercate anche:

• Modifiche impreviste nelle directory .vscode/, , .claude/ o
• LaunchAgent non autorizzati o servizi systemd a livello utente
• Nuovi file di flusso di lavoro aggiunti ai repository
• Connessioni in uscita verso infrastrutture sospette durante l’installazione del pacchetto
• Eventi di pubblicazione dei pacchetti che i responsabili non riconoscono
• Repository pubblici sospetti o commit creati con credenziali rubate

Segni a livello di rete e comportamentali

Anche le principali segnalazioni di incidenti indicano l’esistenza di canali di esfiltrazione ridondanti. Ciò significa che gli addetti alla sicurezza non dovrebbero dare per scontato che il blocco di un dominio elimini il rischio. Da tenere d’occhio:

• Chiamate API insolite alle piattaforme di hosting di codice
• Traffico verso domini noti come controllati da malintenzionati, API pubbliche di hosting di codice utilizzate per l’esfiltrazione, endpoint webhook, infrastrutture correlate a Tor o gateway IPFS, qualora fossero stati rilevati
• Accesso improvviso a servizi di metadati, archivi locali o repository di token
• Comportamento del processo che legge le variabili d’ambiente, gli archivi di token, la cronologia della shell, le credenziali del gestore di pacchetti o altri file contenenti informazioni riservate sulle postazioni di lavoro degli sviluppatori e sui server di integrazione continua (CI)

Come reagire all’attacco alla catena di approvvigionamento denominato “Mini Shai-Hulud”

Si tratta di un incidente che richiede il coordinamento sia dei servizi di sicurezza che delle operazioni IT. Una risposta efficace segue solitamente una sequenza rigorosa.

Misure immediate

• Verifichi se siano state installate le versioni dei pacchetti interessate.
• Si raccomanda di isolare le postazioni di lavoro degli sviluppatori e gli ambienti CI/CD interessati prima di revocare le credenziali.
• Si prega di coordinarsi con IR affinché la revoca dei token non attivi una logica distruttiva nota sugli host ancora connessi.
• Prima di apportare modifiche di ampia portata, verifichi la presenza di eventuali artefatti di persistenza.
• Si prega di conservare le prove forensi, ove possibile.
• Verifichi se alcuni pacchetti di cui è responsabile siano stati ripubblicati in modo imprevisto.

Perché il sequenziamento è importante

Il malware è dotato di un meccanismo di disattivazione automatica. Un demone di persistenza (gh-token-monitor) interroga l'indirizzo GitHub ogni 60 secondi. Quando rileva la revoca di un token (risposta HTTP 40X ), esegue il comando `rm -rf ~/` — una cancellazione completa della directory home. Ciò significa che gli addetti alla sicurezza devono isolare gli ambienti compromessi prima di revocare le credenziali. Eseguire l'operazione nell'ordine sbagliato attiva il carico distruttivo. Per questo motivo, una reazione matura in questa situazione non consiste semplicemente nel dire: «Revocate tutto immediatamente». È:

• Isolare prima di tutto
• Verificare la persistenza
• Immagine, se necessaria
• Quindi ruotare e correggere secondo una sequenza controllata

Le organizzazioni che hanno investito in soluzioni di risposta agli incidenti di tipo “ ” e in operazioni di sicurezza sono in una posizione migliore per coordinare tale sequenza tra endpoint, identità e flussi di lavoro forensi.

Cosa ci dice questo episodio sulla fiducia nel software

L’attacco alla catena di approvvigionamento denominato “Mini Shai-Hulud” mette in luce un punto debole che molte organizzazioni presentano ancora: esse equiparano i dati firmati, ufficiali o con provenienza certificata alla sicurezza.

Si tratta comunque di segnali significativi. Ma da sole non sono sufficienti.

Un modello più completo comprende ora tutti i seguenti elementi:

• Verifica della provenienza del software
• Ritardo nell’adozione delle versioni appena pubblicate
• Limitazione dell'esecuzione degli script durante l'installazione
• Monitoraggio del comportamento in fase di esecuzione durante le operazioni di compilazione e installazione
• Riduzione dell’esposizione delle informazioni riservate nei processi CI/CD
• Monitorare gli endpoint degli sviluppatori con lo stesso rigore utilizzato per i server

Misure concrete di rafforzamento della sicurezza che i team dovrebbero attuare sin da ora

La risposta corretta a lungo termine non consiste nell’evitare i pacchetti spinti dal panico. Si tratta di un indurimento a strati.

Controlli di compilazione e pacchettizzazione

Tutti questi elementi fanno parte di una più ampia strategia di difesa della catena di fornitura del software, denominata “ ” ( ), che parte dal presupposto che anche i flussi di lavoro affidabili possano comunque essere oggetto di abuso.

Controlli relativi all’identità e alla riservatezza

• Ridurre le credenziali di pubblicazione a lunga durata
• Definire con precisione le identità CI/CD
• Autorizzazioni distinte per la compilazione, il rilascio e la distribuzione
• Ridurre al minimo i segreti presenti sui runner
• Verifichino regolarmente le impostazioni relative all’accesso alla pubblicazione dei pacchetti e all’aggiramento dell’autenticazione a due fattori

Controlli relativi agli endpoint e all’ambiente di sviluppo

• Monitorare i percorsi di configurazione IDE e gli hook di avvio
• Considerate le directory degli strumenti di sviluppo come elementi rilevanti ai fini della sicurezza, non come elementi innocui
• Elenco in cui sono memorizzate le credenziali cloud e i token di registro
• Si verifichi la rimozione dei dati persistenti, non solo l’eliminazione del pacchetto

Cosa richiede una risposta efficace da parte della catena di approvvigionamento

Non si tratta solo di un problema di vulnerabilità di un pacchetto software. Si tratta al tempo stesso di un problema di endpointe, di identità e di risposta operativa.

In sintesi: se gli sviluppatori o i sistemi di compilazione automatizzata della vostra organizzazione hanno installato componenti interessati a partire dalla versione 11 maggio, considerate tali ambienti come compromessi. Poiché la diffusione si basava su identità rubate, ogni ambiente compromesso poteva diventare un punto di distribuzione.

Si tratta del primo caso documentato di un attacco alla catena di approvvigionamento a diffusione autonoma che ha generato pacchetti dannosi dotati di attestati di provenienza validi e conformi agli standard del settore. I livelli della catena di fornitura per gli artefatti software (SLSA) hanno funzionato come previsto. L'ecosistema riteneva di aver risolto più problemi di quanti ne abbia effettivamente risolti. La provenienza conferma quale pipeline abbia generato un artefatto, non se la pipeline abbia funzionato come previsto.

L'autore dell'attacco non ha falsificato una ricevuta. Si sono introdotti in cucina e hanno preparato un pasto avvelenato utilizzando i fornelli del ristorante stesso. La ricevuta era tecnicamente corretta.

Il gruppo TeamPCP (noto anche come DeadCatx3, PCPcat, ShellForce, CipherForce) ha preso sistematicamente di mira la catena di fiducia stessa:

• Marzo 2026: Trivy, uno scanner di sicurezza open source — gli strumenti utilizzati dai responsabili della sicurezza (Microsoft)
• 2026 aprile: Bitwarden CLI, un gestore di password — archivi di credenziali
• Maggio 2026: il "worm" dell'ecosistema npm/PyPI — la catena di approvvigionamento del software in senso lato

Il gruppo ha annunciato una partnership con Vect, un’organizzazione che opera nel settore del ransomware-as-a-service (Unit 42). Tra gli indicatori di attribuzione figura un “kill switch” specifico per la versione russa (Microsoft). Indipendentemente dal fatto che sia coinvolto un unico operatore o più affiliati, il quadro emerso suggerisce che gli strumenti utilizzati per gli attacchi alla catena di approvvigionamento stiano raggiungendo un livello di maturità all’interno delle reti affiliate al ransomware.

Gli attacchi alla catena di approvvigionamento sono spesso precursori di attacchi più gravi, tra cui il ransomware, piuttosto che semplici episodi isolati di furto di credenziali. Le recenti campagne che sfruttano in modo improprio marchi di software affidabili quali Notepad++ e i relativi canali di download confermano che i canali di distribuzione del software continuano a rappresentare obiettivi di grande valore.

Per i difensori, ciò si articola in tre fasi e nelle relative tempistiche:

1. Azioni immediate da considerare prioritarie (ore)

• Si prega di verificare i file di blocco e i log CI per individuare eventuali versioni dei pacchetti interessati installate a partire da 11 maggio
• Qualora venisse confermata l’esposizione, si proceda all’isolamento dell’ambiente prima di revocare i token
• Verifichi la presenza di nomi di file noti associati alla persistenza, quali , com.user.gh-token-monitor.plist, , , gh-token-monitor.service e; inoltre, cerchi eventuali LaunchAgent non autorizzati funzionalmente equivalenti, servizi utente, attività cron, modifiche all’avvio della shell e hook di avvio di IDE/strumenti.
• Verifichi la presenza di payload di persistenza inseriti nelle directory .claude/ e .vscode/
• Si raccomanda di ruotare tutte le credenziali accessibili da qualsiasi ambiente esposto, non solo i token npm

2. Interventi a breve termine (giorni)

• Verificare i manifesti delle dipendenze, i file di blocco, i log della CI, le cache, le immagini dei runner e gli eventuali SBOM generati per i pacchetti e le versioni interessati, compresi i pacchetti legati al front-end, all’automazione aziendale, alla ricerca e agli strumenti di intelligenza artificiale
• Se i runner CI/CD disponessero di credenziali di pubblicazione su PyPI durante l'esecuzione di pacchetti npm compromessi, si proceda alla rotazione anche di tali credenziali
• Si raccomanda di verificare i flussi di lavoro delle azioni GitHub che utilizzano pull_request_target insieme a checkout di codice non attendibile, GITHUB_TOKEN con ambito di scrittura, segreti esposti o riutilizzo della cache oltre i confini di affidabilità, poiché tali combinazioni possono compromettere l’integrità dei flussi di lavoro

3. Azioni strategiche (questa settimana e oltre)

• Ritardi minimi nella divulgazione: anche un ritardo di soli 3 giorni avrebbe fornito un margine di sicurezza contro questa campagna, in linea con le linee guida della CISA sulla mitigazione degli attacchi alla catena di approvvigionamento che si sviluppano rapidamente. Si raccomanda di implementare tale funzionalità tramite il parametro `min-release-age` in pnpm oppure di utilizzare il parametro ` Enforce ` tramite un motore di gestione dei registri e degli artefatti proxy per i gestori di pacchetti che non lo supportano in modo nativo.
• Assicurare che le dipendenze corrispondano a versioni precise e ai file di blocco Enforce , compresi i relativi hash di integrità registrati
• Impostare ignore-scripts=true in .npmrc per gli ambienti CI
• Considerate gli attacchi alla catena di approvvigionamento come un segnale precursore di una compromissione più ampia dell’azienda

Domande che i team di sicurezza dovrebbero porsi in questo momento

Qualche sviluppatore o ambiente di integrazione continua (CI) ha installato le versioni interessate dopo il 11 maggio?

Se la risposta è affermativa, si presuma che vi sia stata una compromissione fino a prova contraria.

Quali segreti erano presenti in tali ambienti al momento dell’esecuzione?

Concentratevi innanzitutto sul cloud, sulla pubblicazione dei pacchetti, sul controllo del codice sorgente e sulle identità di distribuzione.

Sono stati modificati o ripubblicati in modo imprevisto repository o pacchetti sotto la Sua responsabilità?

Questa campagna si è diffusa autonomamente. Il Suo ambiente potrebbe essere stato sia una vittima che un punto di distribuzione. In tal caso, è possibile che le Sue credenziali di pubblicazione siano state utilizzate per compromettere la sicurezza di altri utenti.

Potrebbe verificare che la persistenza sia stata rimossa dagli endpoint?

Non si limiti a eliminare i moduli dei nodi o a ripristinare i file di blocco.

Trasformare i rischi della catena di approvvigionamento in risposte concrete con l’ Tanium

Tanium Guardian e il dashboard “ : Mini Shai-Hulud Supply Chain Compromise” offrono ai team di sicurezza e alle operazioni IT una visione condivisa e in tempo reale dello stato di “ endpoint ” lungo l’intera superficie di attacco degli sviluppatori:

• Aiutateci a identificare gli endpoint su cui potrebbero essere in esecuzione i pacchetti npm e PyPI interessati, utilizzando i dati SBOM, ove disponibili
• Analisi delle macchine per la lavorazione superficiale con Node.js, Python e strumenti di intelligenza artificiale quali Claude Code installati
• Individuare gli indicatori di persistenza — LaunchAgents, servizi a livello utente e hook di avvio di IDE o strumenti — utilizzando domande predefinite che vengono eseguite sulla base dei dati telemetrici in tempo reale di endpoint
• Verifichi lo stato della pulizia in tutte le configurazioni dei runner CI/CD e in tutte le superfici di esposizione delle credenziali, non solo nei registri dei pacchetti

Le organizzazioni che dispongono già dell’agente “ Tanium ” possono utilizzare i contenuti esistenti di Guardian senza che sia necessaria l’installazione di ulteriori agenti.

La risposta non dovrebbe limitarsi alla revisione del registro o dell’archivio. Gli endpoint degli sviluppatori e i runner CI/CD rientrano nel percorso di attacco. Tanium Consente ai team di sicurezza e alle operazioni IT di confermare l’esposizione, verificare la rimozione della persistenza e coordinare le misure correttive partendo dalla stessa visione dello stato attuale, anziché fare affidamento su artefatti di build statici o su controlli manuali effettuati in ritardo.

Domande frequenti sull’attacco alla catena di approvvigionamento di Mini Shai-Hulud

Gli attacchi alla catena di approvvigionamento come Mini Shai-Hulud sollevano questioni che vanno ben oltre le procedure standard di risposta agli incidenti di tipo “ ”.

Di seguito sono riportate alcune domande ricorrenti che i team di sicurezza si pongono riguardo a questa campagna e alle sue implicazioni per la fiducia nel software in futuro.

È ancora possibile fidarsi della provenienza certificata dei pacchetti?

Può comunque rivelarsi utile, ma non dovrebbe essere considerato un indicatore di sicurezza completo. La provenienza indica da dove proviene qualcosa. Ciò non dimostra che la conduttura non sia stata oggetto di abuso.

Le squadre dovrebbero revocare immediatamente i token rubati?

Non alla cieca. In caso di incidenti caratterizzati da una logica di revoca distruttiva, è necessario dare priorità all’isolamento e all’indagine, affinché le azioni di risposta non provochino ulteriori danni.

Qual è la misura di controllo preventivo più efficace che la maggior parte delle squadre continua a trascurare?

Un periodo di attesa prima di utilizzare le versioni dei pacchetti appena pubblicate rimane una delle misure di controllo più semplici ed efficaci, soprattutto di fronte a eventi che si verificano rapidamente nella catena di approvvigionamento.

Perché questa campagna è importante anche al di là della cerchia degli sviluppatori?

Poiché le workstation degli sviluppatori e i runner CI/CD contengono spesso credenziali cloud, diritti di distribuzione e identità per la pubblicazione dei pacchetti. La loro compromissione può rapidamente trasformarsi in un incidente aziendale di più ampia portata.

Tanium è progettato per integrare le iniziative e i controlli esistenti in materia di sicurezza della catena di fornitura e di sicurezza delle applicazioni , collegando l’esposizione dei pacchetti, lo stato dell’ endpoint , la convalida della persistenza e la verifica della risposta, in modo che i reparti di sicurezza e le operazioni IT possano agire sulla base dello stesso quadro in tempo reale.
Prenoti oggi stesso una demo per scoprire come Tanium coordini la risposta della catena di fornitura tra endpoint e identità.