GlassWorm inaugura una nuova fase operativa spostando il proprio raggio d’azione su macOS, sfruttando estensioni malevole pubblicate su OpenVSX e una infrastruttura di comando e controllo basata su Solana, confermando un’evoluzione rapida e mirata che colpisce direttamente sviluppatori, ambienti crypto e progetti web3.
La nuova ondata, osservata a partire dal 19 dicembre 2025, rappresenta la quarta wave documentata della campagna GlassWorm e segna un cambio strategico netto. Dopo aver colpito prevalentemente ambienti Windows, l’attore dimostra una conoscenza approfondita dell’ecosistema Apple e adatta le proprie tecniche per massimizzare l’impatto sui sistemi macOS, sempre più diffusi tra sviluppatori e startup crypto. Le estensioni infette hanno raggiunto circa 50.000 download prima di essere segnalate, evidenziando una falla strutturale nei meccanismi di fiducia dei marketplace open source.
Cosa leggere
Il pivot strategico di GlassWorm verso macOS
Il passaggio da Windows a macOS non è casuale. Gli operatori di GlassWorm “pescano dove il valore è più alto”, concentrandosi su ambienti di sviluppo ricchi di chiavi crittografiche, credenziali cloud e accessi a repository sensibili. Questa quarta wave è esclusivamente macOS, un segnale chiaro di specializzazione e maturità tecnica.
Le tecniche cambiano radicalmente. Al posto di PowerShell e binari Windows, il malware utilizza AppleScript per l’esecuzione stealth, LaunchAgents per garantire la persistenza e comandi di sistema per accedere direttamente ai database del Keychain. Non si tratta di un porting superficiale, ma di un adattamento profondo alle logiche di sicurezza del sistema operativo Apple, segno di un attore esperto e ben finanziato.
Estensioni VS Code come vettore di infezione
La distribuzione avviene tramite estensioni per Visual Studio Code pubblicate su OpenVSX, apparentemente legittime e allineate a nomi e funzionalità popolari nell’ecosistema frontend. Tra quelle identificate figurano pacchetti che imitano strumenti diffusi come formatter, temi e utility per framework web.

Il payload malevolo è nascosto in JavaScript compilato e crittografato, rendendo inefficaci molte analisi statiche. Una singola porzione di codice, individuata nelle prime decine di righe dei file principali, contiene un payload AES-256-CBC con chiave e vettore di inizializzazione hardcoded, un dettaglio che consente di attribuire con elevata confidenza le diverse estensioni allo stesso attore.
Il meccanismo introduce anche una novità cruciale: un ritardo di 15 minuti prima dell’esecuzione del codice malevolo. Questo intervallo supera i timeout tipici delle sandbox automatizzate, che spesso non analizzano il comportamento oltre pochi minuti. L’estensione appare pulita al momento della pubblicazione e dell’installazione, attivando il payload solo quando l’utente reale è ormai coinvolto.
Comando e controllo su Solana e infrastruttura rinnovata
Il cuore operativo di GlassWorm resta invariato nel concetto ma evoluto nella forma. Il malware interroga la blockchain Solana per recuperare l’endpoint di comando e controllo, leggendo dati codificati nei memo delle transazioni. Questo approccio decentralizzato rende estremamente complesso il takedown dell’infrastruttura, poiché non esiste un singolo dominio o server da disabilitare.
La wave di dicembre introduce un nuovo wallet Solana, distinto da quelli utilizzati nelle campagne precedenti, e un server di esfiltrazione dedicato. Alcuni indirizzi IP risultano condivisi con wave precedenti, confermando la continuità operativa dell’attore. La separazione tra C2 e server di upload dei dati aumenta la resilienza complessiva della campagna e riduce il rischio di interruzione.
Furto massivo di credenziali e dati sensibili
Una volta attivo, GlassWorm esegue una raccolta sistematica di informazioni ad alto valore. Il malware è in grado di sottrarre credenziali e dati da oltre 50 wallet crypto, sia browser-based sia desktop, colpendo estensioni e applicazioni ampiamente utilizzate nell’ecosistema web3.
Il furto non si limita al mondo crypto. Vengono esfiltrati token GitHub, credenziali NPM, intere directory SSH, cache Git e configurazioni di sistema. L’accesso diretto al Keychain consente di recuperare password di sistema, VPN e applicazioni, mentre i dati dei browser permettono session hijacking e accesso non autorizzato a servizi cloud.
Tutto il materiale viene staged in una directory temporanea, compresso e inviato al server di esfiltrazione. La procedura è silenziosa e difficilmente rilevabile senza un monitoraggio comportamentale avanzato.
La nuova minaccia: trojanizzazione dei wallet hardware
L’aspetto più allarmante della quarta wave è l’introduzione di una capacità latente di sostituzione delle applicazioni per wallet hardware. Il codice analizzato mostra routine dedicate a identificare software come Ledger Live e Trezor Suite, rimuovere la versione legittima e installarne una trojanizzata.
Al momento dell’osservazione, il payload restituito dal C2 risultava vuoto e non veniva installato grazie a controlli di dimensione minima. Questo dettaglio suggerisce che la funzionalità sia pronta ma non ancora attivata, probabilmente in attesa di un payload definitivo. Se utilizzata, questa tecnica consentirebbe di manipolare indirizzi di ricezione, intercettare comunicazioni con il dispositivo hardware e compromettere la sicurezza percepita dei wallet fisici.
Un pattern evolutivo guidato dalla ricerca di sicurezza
L’analisi storica delle campagne GlassWorm rivela un adattamento diretto alle pubblicazioni dei ricercatori. Le prime wave sfruttavano Unicode invisibile, poi sostituito da binari Rust quando la tecnica è stata esposta. L’analisi dei binari Rust ha portato a questa nuova fase basata su JavaScript crittografato e ritardi temporali. Ora, con l’attenzione crescente su Windows, l’attore si sposta su macOS.
Ogni esposizione pubblica genera un miglioramento operativo nel giro di settimane. La presenza di infrastruttura condivisa tra le wave dimostra che non si tratta di imitatori, ma di un unico threat actor che evolve rapidamente il proprio tooling.
Implicazioni per la supply chain open source
Il caso GlassWorm mette in luce una criticità strutturale: le estensioni open source possono accumulare decine di migliaia di download prima di essere identificate come malevole. Le tecniche di evasione adottate, dal ritardo temporale al C2 su blockchain, superano facilmente i controlli automatici tradizionali. Per sviluppatori e organizzazioni, questo scenario impone un cambio di paradigma. La fiducia implicita nei marketplace non è più sufficiente. Solo analisi comportamentali continue, controlli post-installazione e una maggiore consapevolezza del rischio supply chain possono ridurre l’impatto di campagne come GlassWorm.
Uno scenario destinato a evolvere
Tutti gli indicatori suggeriscono che GlassWorm non si fermerà a questa wave. Le capacità non ancora attivate, come la trojanizzazione dei wallet hardware, indicano una preparazione per fasi successive. Il monitoraggio delle estensioni, dell’infrastruttura Solana e dei pattern di distribuzione diventa essenziale per anticipare le prossime mosse. La minaccia dimostra come l’ecosistema open source, pur rimanendo un pilastro dell’innovazione, sia sempre più sfruttato come superficie di attacco strategica. GlassWorm rappresenta un caso emblematico di malware moderno, adattivo e profondamente integrato nei flussi di lavoro degli sviluppatori.
Domande frequenti su GlassWorm
GlassWorm colpisce solo macOS in questa fase
Sì, la quarta wave osservata a dicembre 2025 è focalizzata esclusivamente su macOS, dopo campagne precedenti orientate a Windows.
Perché GlassWorm usa la blockchain Solana come C2
L’uso di Solana consente di distribuire endpoint di comando in modo decentralizzato, rendendo difficile il takedown e la blacklist dell’infrastruttura.
Le estensioni VS Code erano visibilmente malevole
No, le estensioni apparivano legittime e utilizzavano payload crittografati con ritardi di esecuzione per eludere i controlli automatici.
I wallet hardware sono già compromessi
La capacità di sostituire le applicazioni dei wallet hardware è presente nel codice, ma al momento dell’analisi non risultava attiva, indicando una possibile fase futura della campagna.