GlassWorm emerge come il primo worm auto-propagante che sfrutta tecniche di offuscamento basate su caratteri Unicode non stampabili per infettare estensioni di editor su OpenVSX e, in seguito, su Microsoft Marketplace. La scoperta, attribuita a Koi Security, individua la compromissione iniziale nell’estensione CodeJoy versione 1.8.3 e descrive una campagna multifase che unisce metodi stealth, comando e controllo decentralizzato e un modulo di accesso remoto avanzato denominato ZOMBI. Il vettore sfrutta l’aggiornamento automatico delle estensioni per propagare codice malevolo senza interazione diretta dell’utente, permettendo la raccolta di credenziali, token e wallet crypto, la diffusione di payload aggiuntivi e la trasformazione delle macchine infette in nodi proxy e server HVNC. L’attacco si caratterizza per una resilienza straordinaria grazie alla combinazione di blockchain Solana e backup su Google Calendar come canali di comando ridondanti.
Cosa leggere
Scoperta e tempistica

Koi Security ha identificato comportamenti anomali nell’estensione CodeJoy durante un’analisi di rischio automatico. Le modifiche sospette nella release 1.8.3 hanno portato all’attenzione il pattern di connessioni di rete e l’accesso a credenziali non correlate a funzionalità di produttività. La prima transazione su Solana citata come esempio risale al 15 ottobre 2025 e contiene un memo che decodifica in un URL di payload. Il rilevamento ha seguito una sequenza rapida: sette estensioni su OpenVSX hanno mostrato compromissioni il 17 ottobre 2025; Koi ha perfezionato l’analisi il 18 ottobre 2025; una successiva compromissione è stata osservata su Microsoft Marketplace il 19 ottobre 2025. L’incidente si colloca cronologicamente a un mese dall’ondata Shai Hulud che aveva colpito l’ecosistema npm, segnalando una nuova fase evolutiva degli attacchi alla supply chain del software.
Tecniche di invisibilità e payload Unicode

La peculiarità tecnica di GlassWorm risiede nell’uso di selettori di variazione Unicode non stampabili per nascondere porzioni di codice eseguibile all’interno del sorgente JavaScript. Questi caratteri appartengono alla specifica Unicode e appaiono negli editor come spazi vuoti o linee bianche, sfuggendo alle revisioni manuali, alle diff visuali di repository e a molte analisi statiche che non normalizzano la presenza di caratteri non stampabili. L’interprete JavaScript esegue comunque il codice, permettendo l’attivazione del payload. Questa tecnica rompe l’assunto fondamentale secondo cui il codice visibile corrisponde al codice eseguito e introduce una superficie di attacco che richiede strumenti di analisi in grado di rilevare e normalizzare varianti Unicode invisibili prima dell’esecuzione.
Architettura comando e controllo su Solana e Google Calendar

GlassWorm adotta una strategia di comando e controllo a più livelli per aumentare resilienza e anonimato. Il canale primario sfrutta la blockchain Solana interrogando un wallet hardcoded con indirizzo 28PKnu7RzizxBzFPoLp69HLXp9bJL3JFtT2s5QzHsEA2. Il worm legge il campo memo delle transazioni per recuperare un oggetto JSON che contiene un URL codificato in base64. Una transazione di esempio con ID 49CDiVWZpuSW1b2HpzweMgePNg15dckgmqrrmpihYXJMYRsZvumVtFsDim1keESPCrKcW2CzYjN3nSQDGG14KKFM decodifica in http://217.69.3.218/qQD%2FJoi3WCWSk8ggGHiTdg%3D%3D, fornendo un link verso il payload off-chain.

Il costo di aggiornamento via Solana è trascurabile (ordine di micro-SOL), rendendo il canale economico e resistente alla censura. Per ridondanza il worm usa Google Calendar come canale secondario: un evento pubblico contiene nel titolo un URL base64-encoded che punta allo stesso IP di payload, con l’organizzatore identificato come [email protected] e un link di backup https://calendar.app.google/M2ZCvM8ULL56PD1d6. Questa duplice strategia rende difficile prendere offline l’infrastruttura C2 con un singolo intervento.
Fasi dell’infezione e raccolta credenziali
GlassWorm si articola in più stadi ben distinti. Il primo stadio nasconde il payload Unicode nel codice sorgente dell’estensione e attiva l’esecuzione sull’ambiente della vittima. Il secondo stadio interroga Solana per recuperare l’URL del payload successivo. Il terzo stadio scarica il payload crittografato dall’indirizzo IP 217.69.3.218; il contenuto arriva codificato base64 e si decritta con AES-256-CBC, con chiavi passate in header HTTP personalizzati. Questo stadio si focalizza sulla raccolta di credenziali e token: vengono estratti token NPM, token GitHub, credenziali OpenVSX, credenziali Git e informazioni su 49 wallet di criptovalute, tra cui istanze legate a MetaMask, Phantom e Coinbase Wallet. L’attacco già documentato mostra la capacità di intercettare segreti locali e di esportarli verso endpoint controllati dall’attaccante.
Capacità del RAT ZOMBI e persistenza

Lo stadio quattro dispiega il modulo di accesso remoto ZOMBI, un RAT offuscato in JavaScript che attiva funzionalità avanzate. ZOMBI installa proxy SOCKS per instradare traffico, abilita moduli WebRTC per connessioni P2P e implementa DHT BitTorrent per distribuzione decentralizzata dei comandi. Sulle macchine Windows ZOMBI persiste tramite chiavi di registro, aggiungendo voci a HKCU\Software\Microsoft\Windows\CurrentVersion\Run e HKLM\Software\Microsoft\Windows\CurrentVersion\Run, e attiva moduli HVNC per accesso desktop invisibile. Il RAT si autocura e riavvia al fallimento, mascherando processi e sessioni in modo da non apparire facilmente nei tool standard di gestione. Le capacità di pivoting e reconnaissance permettono l’accesso a reti interne, l’esfiltrazione di codice sorgente e l’uso delle workstation come relay per ulteriori attacchi.
Meccanismi di propagazione e impatto sulla supply chain
GlassWorm opera come worm auto-propagante: una volta raccolte credenziali di sviluppatori, il malware usa quegli account per pubblicare versioni malevole di altre estensioni su OpenVSX e repository correlati. Questo meccanismo trasforma ogni nuova vittima in un vettore di infezione, generando una crescita esponenziale tipica dei worm. La diffusione sfrutta la fiducia implicita nelle catene di aggiornamento automatico degli editor, consentendo a payload malevoli di raggiungere utenti senza alcuna azione da parte loro. L’impatto sulla supply chain è grave: pacchetti e estensioni legittime possono diventare veicoli di compromissione, aumentando il rischio per organizzazioni che fanno affidamento su tool e librerie open source.
Estensioni colpite e indicatori di compromissione
L’analisi di Koi indica una lista significativa di estensioni compromesse su OpenVSX e Microsoft Marketplace. Tra le estensioni segnalate figurano [email protected] (poi 1.8.4), [email protected], [email protected], [email protected] e numerosi altri package che, seppure diversi per nome, contengono pattern di codice sovrapponibili. Il totale delle installazioni impattate raggiunge le 35.800. Indicatori di compromissione includono la presenza di sequenze Unicode non stampabili nel sorgente, connessioni verso 217.69.3.218, richieste a endpoint che restituiscono payload base64, uso dell’indirizzo wallet Solana 28PKnu7RzizxBzFPoLp69HLXp9bJL3JFtT2s5QzHsEA2 e riferimenti al calendario Google con l’organizzatore [email protected]. La comparsa di header HTTP anomali contenenti chiavi di decrittazione costituisce ulteriore segnale operativo.
Risposta e mitigazione
La risposta tecnica richiede misure immediate e multilivello. I marketplace devono applicare analisi di normalizzazione Unicode automatizzate sulle submission e sulle diff di aggiornamento. I tool di scansione del codice devono includere routine che rimuovono o evidenziano caratteri non stampabili e che verificano la corrispondenza tra codice visualizzato e codice eseguibile. Le policy di aggiornamento automatico dovrebbero prevedere fasi di quarantena per file che effettuano connessioni di rete o accedono a credenziali sensibili. Gli sviluppatori devono ruotare token e chiavi presi da ambienti compromessi e abilitare l’autenticazione a più fattori per account NPM, GitHub e OpenVSX. La mitigazione richiede anche la rimozione rapida delle release malevole, il reset delle chiavi di accesso e la revisione forense delle build pubblicate con account sospetti.

GlassWorm introduce una nuova classe di minaccia alla supply chain del software basata su codice invisibile e canali C2 decentralizzati. L’uso combinato di selettori Unicode non stampabili, blockchain come canale di comando e backup su servizi applicativi pubblici rende il worm particolarmente resistente e difficile da estinguere. La difesa richiede l’adozione di controlli automatizzati che includano la normalizzazione Unicode, il controllo delle richieste di rete nelle estensioni e la verifica delle modifiche binarie rispetto al codice sorgente visibile. I marketplace devono aggiornare le policy di revisione per includere controlli di integrità eseguibile/visuale e routine anti-offuscamento. La responsabilità degli sviluppatori e dei gestori di repository resta cruciale: senza interventi coordinati il rischio di diffusione rapida e danni persistenti rimane elevato.