La blockchain diventa arsenale: smart contract al comando di worm supply chain

Gli attori della minaccia hanno convertito la decentralizzazione da promessa tecnologica in vettore offensivo. Il 7 ottobre 2026 Unit 42 di Palo Alto Networks ha pubblicato un'analisi tecnica che documenta l'evoluzione sistematica delle infrastrutture C2 verso architetture Web3, con due campagne attive — ChainDrop e PolinRider — che combinano infezione di pacchetti open-source e comando tramite smart contract blockchain. La posta in gioco supera il singolo compromesso: i domini statici tradizionalmente usati per controllare botnet possono essere bloccati, revocati o sequestrati. Gli endpoint scritti su blockchain no.

Da domini sequestrabili a smart contract immutabili

L'evoluzione documentata da Unit 42 è strutturale, non ornamentale. Secondo il report, gli attori della minaccia "hanno aggiornato sistematicamente l'infrastruttura C2 per utilizzare Web3, nota anche come Web 3.0 o architetture web blockchain decentralizzate". Il passaggio è funzionale: gli scanner di sicurezza e gli strumenti di analisi statica rilevano rapidamente domini e IP hardcoded nel codice malevolo, rendendo i takedown una contromisura efficace. Gli smart contract non offrono la stessa superficie di attacco.

Il meccanismo si articola in due campagne distinte. ChainDrop, attribuita alla famiglia Shai-Hulud, sfrutta EtherHiding su Ethereum: le transazioni smart contract contengono informazioni dinamicamente criptate che risolvono in endpoint di esfiltrazione IP o domini. Una singola transazione aggiorna l'intera rete di nodi compromessi. PolinRider implementa un'architettura più distribuita, con query multi-chain che attraversano TRON, Aptos e Binance Smart Chain, affiancate dalla tecnica zero-data NullReceiver come canale backup se i gateway RPC o le lookup multi-chain vengono bloccati.

"Threat actors have systematically upgraded their command-and-control (C2) infrastructure to use Web3, also known as Web 3.0 or decentralized blockchain web architectures"

Il payload: non pacchetti innocui ma runtime completi

Il vettore di infezione resta il supply chain poisoning, ma la tecnica di esecuzione è più aggressiva della media documentata. ChainDrop inietta preinstall script in pacchetti npm legittimi o con nomi simili a quelli attendibili. Al momento dell'installazione, lo script scarica il runtime Bun — un JavaScript runtime alternativo a Node.js — e lo utilizza per eseguire un credential harvester offuscato. La scelta di Bun non è casuale: il runtime è meno monitorato delle toolchain standard e offre prestazioni che accelerano l'esecuzione in memoria.

La persistenza supera il singolo package manager. ChainDrop inietta hook di task persistenti che si attivano automaticamente quando uno sviluppatore apre un progetto o avvia una sessione di AI coding. L'automazione degli IDE e dei copilot di generazione codice diventa così trigger di riattivazione, non solo ambiente di sviluppo.

Raccolta credenziali dalla memoria, non dal disco

La differenza tecnica più rilevante per le difese enterprise sta nel bersaglio della raccolta. ChainDrop cerca credenziali non solo su disco ma nella memoria dei processi di build attivi. Il meccanismo è memory-aware: cattura IAM keys ephemeral, CI/CD worker tokens e chiavi OIDC federation a breve durata. Questi secret hanno vita spesso inferiore all'ora, ma sono sufficienti per ottenere accesso diretto a console e API di gestione cloud. Secondo il report, questo accesso bypassa MFA se altri controlli non sono presenti.

La distinzione è cruciale. I token CI/CD e le chiavi OIDC non sono archiviati in file .env o nei gestori di secret tradizionali: vengono generati al volo dai provider di identità e iniettati nei job di build. La loro natura transitoria li rende invisibili a scansioni periodiche del filesystem, ma esposti in memoria durante l'esecuzione del processo. Il malware che colma questa lacuna opera in un blind spot diffuso.

L'architettura ibrida: quando una catena non basta

PolinRider implementa una logica di ridondanza che riflette la maturità operativa degli attori. I loader risolvono dinamicamente gli endpoint C2 usando meccanismi Web3 che spaziano da query multi-chain a tecniche zero-data. L'architettura è ibrida per design: se il traffico verso una chain viene bloccato o monitorato, il failover automatico sposta il canale su un'altra rete o su trasferimenti zero-data come NullReceiver.

La campagna si espande su multipli registry: npm, Go modules, Packagist. I loader sono nascosti in file di configurazione repository, risorse web e automazione workspace IDE. La distribuzione poliregistry aumenta la superficie di esposizione e complica la correlazione tra campagne, poiché gli stessi meccanismi C2 servono pacchetti con ecosistemi diversi.

Cosa fare adesso

Le implicazioni operative del report richiedono tre azioni concrete per i team di sicurezza che gestiscono pipeline CI/CD e ambienti cloud enterprise.

Primo: monitorare l'esecuzione di runtime non standard nei job di build. La campagna ChainDrop scarica esplicitamente Bun per evadere il monitoring di Node.js. Identificare l'installazione o l'esecuzione di Bun — o di altri runtime alternativi — all'interno di pipeline automatizzate costituisce indicatore di compromissione specifico al caso documentato.

Secondo: analizzare il traffico di rete verso endpoint RPC blockchain nelle reti aziendali. Le query EtherHiding su Ethereum e le lookup multi-chain su TRON, Aptos e Binance Smart Chain generano pattern di connessione distinguibili. Il report documenta che queste query avvengono durante la risoluzione C2, non in fasi precedenti dell'infezione.

Terzo: implementare visibility sulla memoria dei processi di build, non solo sul filesystem. Il credential harvesting di ChainDrop opera esclusivamente in memoria per catturare IAM keys ephemeral, CI/CD worker tokens e chiavi OIDC federation. Strumenti che rilevano solo accesso a file .env o gestori di secret tradizionali non coprono questa superficie di attacco.

Perché è importante

Il 2026 Unit 42 Global Incident Response Report identifica le compromissioni software supply chain come leading initial access vector per ambienti cloud enterprise. La convergenza con architetture C2 Web3 elimina un punto di fragilità storico per gli attori della minaccia: la dipendenza da infrastrutture centralizzate sequestrabili.

La metrica di oltre 400 pacchetti npm infetti da ChainDrop quantifica la scalabilità del vettore. La distribuzione poliregistry di PolinRider — npm, Go modules, Packagist — indica che la tecnica non è confinata a un ecosistema. L'uso di smart contract per aggiornamenti dinamici C2 rende ogni singolo pacchetto compromesso un nodo potenzialmente ricollegabile a infrastrutture non ancora identificate al momento del rilevamento.

Il report non quantifica il numero di vittime enterprise effettivamente compromesse oltre alla metrica dei pacchetti infetti. Non è documentato se le campagne siano attribuite a gruppi distinti o a un unico attore. Il timeframe esatto di attività non emerge dal materiale analizzato.

Domande frequenti

Perché Bun e non Node.js standard?

Il report indica che ChainDrop scarica runtime Bun per eseguire il payload. La scelta riflette probabilmente il profilo di rilevamento: Bun è meno monitorato dalle soluzioni EDR rispetto a Node.js e offre prestazioni superiori per operazioni in memoria, riducendo la finestra temporale di esposizione del processo malevolo.

Le transazioni blockchain sono pubbliche: perché non basta tracciarle?

Le transazioni sono pubbliche ma i contenuti sono criptati dinamicamente. Gli smart contract contengono endpoint cifrati che i loader sanno decodificare. Il monitoraggio del traffico blockchain richiede competenze e infrastrutture diverse dal threat intelligence tradizionale.

I pacchetti compromessi sono stati rimossi dai registry?

Il dossier non specifica lo stato attuale dei pacchetti infetti nei repository npm, Go e Packagist. La metrica di oltre 400 pacchetti npm si riferisce al totale documentato dalla campagna ChainDrop, non necessariamente al numero attualmente disponibile.

Le informazioni sono basate sulla fonte citata e aggiornate al momento della pubblicazione.

Fonti

• https://unit42.paloaltonetworks.com/web3-cloud-supply-chain-attacks/
• https://unit42.paloaltonetworks.com/tools/
• https://unit42.paloaltonetworks.com/atoms/
• https://unit42.paloaltonetworks.com/about-unit-42/