ViteVenom colpisce npm con pacchetti Vite falsi e un C2 basato su blockchain

🛡️ Executive Summary

• ViteVenom impersona pacchetti Vite e Vitest attraverso namespace credibili e combina release pulite e infette per ridurre i sospetti.
• Il malware risolve dinamicamente l’infrastruttura C2 attraverso wallet Tron, Aptos e transazioni BSC, quindi avvia un RAT Node.js persistente.
• Wallet, chiavi XOR e payload condivisi con ChainVeil collegano le campagne allo stesso operatore con un elevato grado di confidenza.

Una nuova campagna di supply chain attack contro npm prende di mira gli sviluppatori che utilizzano Vite e Vitest. Denominata ViteVenom, l’operazione ha distribuito sette pacchetti malevoli tra il 29 giugno e il 3 luglio 2026, utilizzando scope e nomi progettati per sembrare componenti ufficiali dell’ecosistema frontend. Il payload finale è un Remote Access Trojan da circa 77 KB, mantenuto in esecuzione attraverso un processo Node.js separato e collegato a un’infrastruttura di comando multilivello basata su Tron, Aptos e BNB Smart Chain. Le sovrapposizioni con la precedente campagna ChainVeil indicano che lo stesso operatore ha affinato tempi, offuscamento e resilienza del delivery.

ViteVenom prosegue direttamente l’operazione ChainVeil

L’attribuzione tecnica a ChainVeil non si basa soltanto sulla somiglianza generale dei pacchetti. ViteVenom riutilizza componenti infrastrutturali e crittografici che difficilmente potrebbero coincidere per caso: gli stessi wallet Tron e Aptos impiegati nel secondo livello della catena, endpoint BSC condivisi, identiche chiavi di decrittazione XOR e lo stesso RAT finale. Cambiano invece i wallet iniziali, alcuni server di comando e controllo e i nomi scelti per raggiungere gli sviluppatori. Questa combinazione indica una continuità operativa accompagnata da tentativi di compartimentazione. L’attore sostituisce gli elementi più esposti e facilmente bloccabili, ma conserva quelli più profondi e costosi da ricostruire. La campagna si inserisce in un’ondata ormai sistemica di compromissioni del registro npm, già descritta nell’analisi sull’allarme supply chain tra pacchetti npm infetti, repository GitHub e nuove difese del registry. ViteVenom conferma che la rimozione di una prima serie di pacchetti non interrompe necessariamente l’operazione: l’infrastruttura e il payload possono essere riproposti con identità diverse nel giro di pochi giorni.

Gli scope imitano Vite e Vitest per ingannare gli sviluppatori

I sette pacchetti utilizzano namespace come @vite-pro/, @vite-ts/, @vitets/, @vite-mcp/ e @vite-tab/, costruiti per richiamare l’aspetto dei componenti ufficiali o di estensioni professionali. Il caso più insidioso è @vitets/vite-ts, che differisce visivamente di un solo carattere dal namespace legittimo @vitest/. In un terminale, in un file package.json o all’interno di una guida copiata rapidamente, la differenza può passare inosservata. La scelta degli scope aumenta la credibilità perché molti sviluppatori associano il prefisso a un’organizzazione verificata o a una famiglia coerente di pacchetti, anche se npm non garantisce che un nome simile appartenga realmente al progetto imitato.

L’operatore sfrutta quindi typosquatting, brand impersonation e abitudini di installazione automatica. Il bersaglio è particolarmente redditizio: Vite e Vitest sono utilizzati in applicazioni frontend moderne, ambienti di sviluppo e pipeline di test, dove un pacchetto installato può accedere a token, repository, variabili d’ambiente e credenziali cloud. La stessa debolezza è emersa nel caso del pacchetto npm che imitava un parser PostCSS e distribuiva un RAT Windows, dimostrando come una differenza minima nel nome possa trasformarsi in una compromissione completa della workstation.

Le versioni pulite e malevole complicano l’analisi della cronologia

Alcuni pacchetti non risultano dannosi in ogni release. @uw010010/vite-tree, per esempio, alterna versioni apparentemente pulite e versioni contenenti il payload. Questa strategia consente all’attore di costruire una cronologia credibile, superare controlli iniziali e introdurre il codice malevolo soltanto in un aggiornamento successivo. Un team può quindi approvare una dipendenza dopo averne analizzato una prima versione e ricevere il malware quando il lockfile viene aggiornato o una pipeline risolve automaticamente una release più recente. L’alternanza rende inoltre meno affidabili le valutazioni basate esclusivamente sul nome del pacchetto: la presenza della dipendenza deve essere correlata alla versione precisa e alla data di pubblicazione. Lo stesso schema è stato osservato in precedenti campagne npm nelle quali account o progetti inizialmente legittimi sono stati trasformati in canali di distribuzione, come nel caso della compromissione AsyncAPI attribuita al worm Miasma. Per questo le organizzazioni non devono limitarsi a chiedere se una libreria sia conosciuta, ma devono verificare integrità, provenienza e comportamento di ogni nuova release.

La blockchain viene usata come directory resiliente del comando e controllo

La catena di ViteVenom utilizza un sistema C2 a quattro livelli. Nella prima fase il malware imposta un marker della campagna e prepara le stringhe offuscate. Successivamente interroga wallet Tron e, in caso di errore, utilizza Aptos come percorso alternativo. Le informazioni recuperate conducono a transazioni sulla BNB Smart Chain, all’interno delle quali sono conservati puntatori o dati necessari a individuare e decodificare lo stadio successivo. Il payload viene ricostruito attraverso una chiave XOR incorporata nel codice e infine collegato all’infrastruttura operativa. La blockchain non ospita necessariamente l’intero malware: funziona come un registro pubblico distribuito dal quale recuperare riferimenti aggiornabili e difficili da rimuovere. Se un dominio viene bloccato, l’operatore può pubblicare una nuova indicazione attraverso una transazione senza aggiornare tutti i pacchetti già installati. La tecnica richiama quella impiegata da Tsundere, botnet Node.js che utilizzava Ethereum per rendere resiliente il proprio C2. L’abuso di reti pubbliche decentralizzate costringe i difensori a distinguere tra normale traffico Web3 e attività di risoluzione malevola.

L’operatore riduce da sei secondi a 300 millisecondi il secondo stadio

Rispetto a ChainVeil, ViteVenom ottimizza sensibilmente la fase denominata Stage 2B. Il tempo necessario per risolvere i riferimenti blockchain e ottenere il payload passa da circa sei secondi a circa 0,3 secondi. La riduzione può sembrare marginale, ma ha valore operativo: una catena più rapida diminuisce la finestra nella quale sandbox e strumenti di analisi possono interrompere il processo, riduce i timeout e rende l’esecuzione meno visibile all’utente. L’ottimizzazione dimostra inoltre che l’attore misura le prestazioni del malware e modifica il codice sulla base dei risultati delle campagne precedenti. Non si tratta quindi di pacchetti pubblicati casualmente, ma di un progetto mantenuto e sottoposto a iterazioni. La rapidità del resolver può essere ottenuta riducendo le query, memorizzando alcuni risultati, cambiando gli endpoint o rendendo più efficiente la decodifica. L’evoluzione tra le due campagne fornisce ai difensori un’indicazione importante: gli indicatori statici devono essere accompagnati dall’analisi del comportamento e delle infrastrutture condivise, perché nomi e server di primo livello possono cambiare più velocemente delle componenti profonde.

Il RAT resta attivo come processo Node.js separato

Una volta completata la risoluzione, il payload finale viene decifrato e avviato come processo Node.js detached, indipendente dal comando che ha inizialmente installato o importato il pacchetto. Questa modalità consente al RAT di continuare a funzionare dopo la chiusura del terminale, della build o dell’IDE. Il malware comunica con il server C2 all’indirizzo 198.105.127.210 attraverso WebSocket o HTTP, mantenendo un canale bidirezionale utile a ricevere comandi e inviare dati. La scelta di Node.js è coerente con l’ambiente bersaglio: il runtime è già presente sulle workstation che utilizzano Vite, quindi il processo può apparire compatibile con normali attività di sviluppo. La persistenza non richiede necessariamente un servizio Windows o una chiave di avvio tradizionale, ma può essere sostenuta da script del progetto, processi in background e nuove esecuzioni durante le build. Il confine tra strumento legittimo e attività malevola diventa così più difficile da osservare, soprattutto negli ambienti dove numerosi processi Node comunicano regolarmente con servizi esterni.

Offuscamento e controlli di integrità ostacolano l’analisi automatica

ViteVenom nasconde stringhe, comandi, URL delle blockchain e chiavi XOR attraverso array indicizzati e rimescolati sulla base di un seed. Il codice non contiene quindi riferimenti leggibili direttamente, ma calcola durante l’esecuzione l’indice da utilizzare per recuperare ogni valore. Sono presenti controlli ripetuti sull’integrità degli array, progettati per individuare modifiche effettuate da analisti o strumenti automatici. Il malware integra inoltre un cooldown anti-replay di 30 secondi, che impedisce la ripetizione immediata di alcune operazioni, e sostituisce parole chiave riconoscibili per ridurre l’efficacia delle regole statiche. Queste tecniche non rendono il codice impossibile da analizzare, ma aumentano il costo della ricerca e possono far fallire sandbox che eseguono il pacchetto una sola volta per pochi secondi. La combinazione tra offuscamento locale e risoluzione blockchain sposta inoltre parte della logica fuori dal pacchetto pubblicato: lo scanner vede solo il resolver, mentre gli elementi più sensibili vengono recuperati durante l’esecuzione.

I sette pacchetti devono essere rimossi e le workstation considerate compromesse

Gli ambienti devono cercare @uw010010/vite-tree, @vite-tab/tab, @vite-ln/build-ts, @vite-mcp/vite-type, @vite-pro/vite-ui, @vitets/vite-ts e @vite-ts/vite-ui, con particolare attenzione alle release pubblicate tra il 29 giugno e il 3 luglio. La semplice rimozione dal package.json non è sufficiente se una versione malevola è già stata eseguita. Occorre eliminare node_modules, rigenerare i lockfile da una sorgente verificata, controllare i processi Node.js persistenti e cercare connessioni verso l’indirizzo C2 e gli endpoint blockchain associati. Token npm, credenziali GitHub, chiavi SSH, segreti cloud e variabili conservate nei file .env devono essere ruotati quando la workstation ha eseguito il pacchetto. I log di CI/CD devono essere esaminati per verificare eventuali download o esecuzioni anomale. La campagna mostra infatti che l’obiettivo non è soltanto il computer dello sviluppatore: il RAT può diventare il primo passaggio verso repository privati, registri dei pacchetti e infrastrutture di produzione.

La difesa richiede lockfile, registry controllati e provenienza verificabile

Le organizzazioni devono impedire l’installazione libera di dipendenze provenienti direttamente dal registro pubblico. Registry privati, proxy interni e allowlist consentono di bloccare nuovi namespace fino alla verifica. I lockfile devono essere trattati come componenti di sicurezza, sottoposti a revisione e aggiornati soltanto attraverso pull request controllate. È opportuno verificare la provenienza dei pacchetti, la storia dei maintainer, l’età del progetto, la frequenza dei rilasci e la presenza di script preinstall o postinstall. Le novità introdotte da npm per limitare gli script automatici e rafforzare la pubblicazione riducono parte del rischio, ma non impediscono a un’applicazione di importare codice malevolo durante la normale esecuzione. ViteVenom sfrutta soprattutto la fiducia nel nome e nell’ecosistema imitato. Per questo l’aggiornamento tempestivo non è sempre una difesa: nel supply chain attack può essere proprio l’installazione dell’ultima versione a introdurre il malware. La sicurezza richiede quindi aggiornamenti controllati, analisi differenziale del codice e verifica continua del comportamento delle dipendenze.