npm-incident-response

English | Português

Scanner autonomo per l'incidente della supply chain keyv/cacheable ("Shai-Hulud: Here We Go Again", 4 agosto 2026) — oltre 440 pacchetti npm compromessi da un worm auto-propagante che ruba le credenziali cloud/CI e impianta la persistenza con un dead-man's switch.

Rileva, in pochi minuti e senza installare nulla:

• Pacchetti compromessi in package-lock.json, npm-shrinkwrap.json, yarn.lock (v1 e Berry), pnpm-lock.yaml e bun.lock — incluse le dipendenze transitive, con l'intera catena (es. eslint → file-entry-cache → flat-cache → [email protected]);
• Payload installati in node_modules (nome + hash SHA-256 degli artefatti noti);
• Varianti non ancora presenti nelle liste IOC (euristica: script di lifecycle sospetti, file con i nomi del worm) — sempre marcate come SUSPECT, mai confermate senza hash;
• Impianti di persistenza sull'host: LaunchAgent (macOS), servizio utente systemd + linger (Linux), hook in .claude/settings.json e .vscode/tasks.json, artefatti temporanei (bun-dl-*);
• Il dead-man's switch: l'impianto monitora un token GitHub ed esegue un comando remoto quando la revoca restituisce 4xx. Ruotare le credenziali prima di pulire l'host fa scattare la trappola — il report ti avvisa e l'ordine di risposta qui sotto evita l'errore.

Comprendere l'attacco

1. L'account del maintainer delle famiglie keyv/cacheable è stato compromesso; l'attaccante ha pubblicato nuove versioni con un hook "preinstall": "node setup.mjs" — codice che viene eseguito prima dell'installazione del pacchetto, con i privilegi di chi ha lanciato npm install.
2. setup.mjs scarica il runtime Bun da GitHub ed esegue il payload al suo interno — evasione contro gli strumenti che monitorano solo i processi node.
3. Math_Symbol.js (~728 KB, offuscato) ruba le credenziali: metadati delle istanze AWS, chiavi AWS/GCP/Azure, token Vault, service account Kubernetes, segreti di GitHub Actions, token npm, più una scansione generica con regex per chiavi private e bearer token su disco.
4. È un worm: con il token npm rubato, inietta lo stesso hook in altri pacchetti che quell'identità può pubblicare, ricalcola gli hash di integrità e ripubblica. È così che è passato da ~10 a centinaia di pacchetti.
5. Esfiltra senza un C2 fisso (repository GitHub creati al volo, DNS) e lascia una trappola dietro di sé — vedi sotto.

I due vettori (il secondo è più sottile)

• Vettore A — installazione: chiunque abbia eseguito npm install/npm ci con gli script di lifecycle abilitati dal 2026-08-04 09:35 UTC. Con --ignore-scripts, l'hook non è stato eseguito.
• Vettore B — clone: il repository sorgente è stato dotato di hook di avvio automatico in .claude/settings.json (SessionStart) e .vscode/tasks.json (folderOpen) che eseguono il loader quando la cartella clonata viene aperta — niente npm install, nulla installato. Questo include chi ha clonato il repo per investigare l'incidente e gli agenti AI di coding che hanno aperto la directory — uno dei primi casi pubblici di hook di agenti AI (.claude/) usati come vettore di supply chain.

La trappola (dead-man's switch)

L'impianto installa un "watcher" (gh-token-monitor) mantenuto attivo da un LaunchAgent (macOS) o da un servizio utente systemd + loginctl enable-linger (Linux). Ogni 60 secondi valida il token GitHub rubato contro l'API. Finché il token funziona, non succede nulla. Quando la risposta diventa 4xx — cioè nel momento in cui revochi il token — esegue, via eval, il contenuto di ~/.config/gh-token-monitor/handler: un comando arbitrario definito da remoto dall'attaccante. Le analisi pubbliche non sanno cosa contenga — potrebbe essere distruzione di dati, re-impianto, ransomware o nulla. Il rischio non è valutabile; è per questo che l'ordine di risposta è assoluto.

Tre proprietà che cambiano la risposta:

• Isolare la rete è sicuro: senza connettività non c'è risposta HTTP, quindi niente 4xx — la trappola non scatta e l'exfiltrazione si ferma. Isola prima, non spegnere (la memoria volatile è una prova).
• È a colpo singolo e si auto-ripulisce dopo lo scatto — il comportamento diventa inspiegabile, senza alcun artefatto da investigare.
• TTL ~24h: il watcher si autodistrugge dopo un giorno. L'assenza di artefatti non dimostra che la macchina fosse pulita — lo scanner avvisa di questo in modalità host.

Perché le difese abituali generalmente non lo individuano

• "La firma era valida" — [email protected] è stato distribuito con un'attestazione SLSA che ha superato i controlli. La provenienza attesta l'integrità della build, non della sorgente: il workflow legittimo ha compilato codice già trojanizzato.
• "Il diff del codice non è cambiato" — corretto: la libreria in sé non è stata modificata. La malizia sta in package.json (l'hook preinstall) e in due nuovi file aggiunti al pacchetto (setup.mjs, Math_Symbol.js).
• "Non usiamo keyv" — in realtà sì, indirettamente: la catena più comune è eslint → file-entry-cache → flat-cache → keyv. È per questo che lo scanner mostra la catena in ogni riscontro.
• "Nessuno ha eseguito npm install" — non basta: vedi Vettore B.

Cos'è lo script in questo repository

scan.mjs ha le seguenti proprietà — importanti per chiunque stia rispondendo a un incidente di supply chain:

• Un singolo file, ~880 righe leggibili, zero dipendenze. Niente npm install. Fai l'audit dell'intero scan.mjs in 15 minuti prima di eseguirlo.
• Zero egress. Nessun dato lascia la tua macchina. Nessuna telemetria, nessun "invio del risultato per l'analisi". L'unica operazione di rete è --update (scarica un manifest IOC aggiornato), esplicita e opzionale.
• Sola lettura. Lo scanner non modifica, rimuove o esegue nulla di ciò che trova.
• Funziona offline. docker run --network=none o una macchina isolata: basta copiare scan.mjs + iocs.json.

Come usarlo nella tua azienda

Requisito: Node.js ≥ 18 (qualsiasi macchina con npm ce l'ha già). Scarica i due file — scan.mjs + iocs.json — e basta: nessuna installazione.

Attenzione: se hai clonato l'intero repository, la cartella fixtures/ contiene IOC inerti usati nei test (nomi e versioni reali, contenuto fittizio — nessun malware). Lo scanner la salta automaticamente e lo segnala nell'output; i riscontri da essa compaiono solo se la scannerizzi apposta.

Ci sono due modalità di esecuzione che rispondono a domande diverse, ed è questo che decide dove eseguirlo:

• La modalità repo legge i lockfile e node_modules — e i lockfile vivono in git, quindi può essere centralizzata: una persona scansiona tutti i repository dell'azienda.
• La modalità host cerca l'impianto (watcher, LaunchAgent/systemd, hook IDE), che vive sulla macchina dove il codice è stato eseguito — non è in git e non può essere centralizzata.

Passo 1 — AppSec scansiona tutti i repository (una persona, una macchina)

node scan.mjs repo /folder/with/all/the/repos --json=result.json --html=report.html

Risponde alla domanda "quali progetti sono esposti" in pochi minuti, senza coinvolgere nessuno. Accetta più percorsi; percorre le sottodirectory (monorepo e workspace inclusi).

Passo 2 — chi ha lavorato sui progetti colpiti scansiona la propria macchina

Per ogni progetto con un riscontro, identifica chi lo ha toccato dal 2026-08-04 09:35 UTC (git log, log CI). Queste persone eseguono, sulla propria macchina:

node scan.mjs        # current directory + host, in ~30 seconds