La botnet Glassworm rappresentava una delle infrastrutture malevole più sofisticate emerse contro l’ecosistema degli sviluppatori software perché combinava tecniche di supply-chain compromise, decentralizzazione del comando e controllo e abuso di servizi cloud legittimi per garantire persistenza e resilienza operativa. Il 26 maggio 2026, CrowdStrike ha annunciato il takedown coordinato dell’infrastruttura grazie a un’operazione condotta insieme a Google e alla Shadowserver Foundation, neutralizzando simultaneamente quattro layer distinti di comando e controllo usati dagli attaccanti. La campagna prendeva di mira sviluppatori software attraverso estensioni trojanizzate di VS Code, repository GitHub avvelenati, pacchetti npm e librerie Python infette, con l’obiettivo di compromettere workstation di sviluppo e aprire la strada a operazioni supply-chain su larga scala. Gli operatori, probabilmente collegati ad ambienti russi, avevano progettato un’architettura altamente ridondante basata su Solana blockchain, BitTorrent DHT, eventi di Google Calendar usati come dead-drop e server VPS tradizionali. L’operazione di takedown interrompe ora la distribuzione di nuovi payload e impedisce agli attaccanti di inviare ulteriori istruzioni ai sistemi compromessi, creando una finestra critica per la remediation delle vittime.
Cosa leggere
CrowdStrike colpisce simultaneamente tutti i layer del comando e controllo
L’operazione coordinata contro Glassworm è stata progettata per eliminare contemporaneamente ogni canale di comunicazione usato dalla botnet. Il team Counter Adversary Operations di CrowdStrike ha eseguito il takedown il 26 maggio 2026 alle 14:00 UTC, sincronizzando l’intervento su tutti i layer del C2 per impedire agli operatori di spostarsi rapidamente da una infrastruttura all’altra. Questa strategia si è rivelata decisiva perché l’architettura della botnet era stata costruita proprio per resistere alla neutralizzazione parziale di singoli componenti. La collaborazione con Google ha consentito di bloccare il canale basato su Google Calendar, mentre la Shadowserver Foundation ha contribuito al coordinamento tecnico e al sinkholing delle comunicazioni residue. Dopo il takedown, i dispositivi infetti hanno iniziato a effettuare beaconing verso l’indirizzo IP 164.92.88.210, controllato da CrowdStrike e utilizzato come sinkhole sicuro per intercettare il traffico residuo della botnet. Questo passaggio ha un valore operativo enorme perché consente agli analisti di identificare sistemi ancora compromessi e impedisce agli attaccanti di ristabilire il controllo sui client infetti. Contestualmente, CrowdStrike ha pubblicato nuove YARA rules per facilitare il rilevamento del malware e accelerare la remediation nelle organizzazioni colpite. Le firme individuano stringhe e pattern specifici legati sia al downloader sia al GlasswormRAT, permettendo di scansionare rapidamente ambienti Windows, Linux e macOS alla ricerca di compromissioni attive.
Glassworm usava Solana blockchain come layer stealthy per il C2
Uno degli elementi più avanzati della botnet Glassworm era l’uso della blockchain Solana come parte integrante dell’infrastruttura di comando e controllo. Gli operatori codificavano indirizzi e parametri C2 all’interno dei campi memo delle transazioni blockchain, creando un livello di indirection che nascondeva i server reali dietro dati apparentemente innocui. Questo approccio consentiva alla botnet di recuperare istruzioni senza dipendere esclusivamente da domini o indirizzi IP statici. La blockchain diventava così un archivio distribuito e pubblico di configurazioni operative accessibili dai malware installati sui sistemi compromessi.
L’uso di Solana offriva agli attaccanti velocità elevate, costi ridotti e una infrastruttura decentralizzata difficile da neutralizzare con i metodi convenzionali. La scelta della blockchain come layer di supporto al C2 dimostra come gli attori malevoli stiano progressivamente adottando tecnologie decentralizzate per aumentare resilienza, anonimato operativo e capacità di persistenza. Invece di mantenere server centralizzati vulnerabili a takedown legali o sequestri infrastrutturali, gli operatori sfruttavano una rete distribuita che rendeva più difficile correlare i movimenti del malware alle infrastrutture effettive di comando. Questo modello complica enormemente il lavoro difensivo perché obbliga i ricercatori ad analizzare transazioni blockchain, campi memo e pattern di configurazione on-chain oltre ai tradizionali indicatori di compromissione basati su rete.
BitTorrent DHT e Google Calendar rafforzavano la resilienza della botnet
La blockchain non era l’unico elemento innovativo dell’infrastruttura Glassworm. Gli attaccanti avevano costruito un ecosistema multilivello che includeva anche BitTorrent Distributed Hash Table e Google Calendar come canali di supporto al comando e controllo. Nel caso del layer BitTorrent DHT, il malware utilizzava chiavi pubbliche hardcoded per interrogare dati di configurazione distribuiti in una rete peer-to-peer decentralizzata. Questo consentiva agli operatori di pubblicare parametri e riferimenti senza dipendere da infrastrutture centralizzate facilmente individuabili. Il layer basato su Google Calendar sfruttava invece eventi appositamente creati, i cui titoli contenevano percorsi C2 codificati in Base64. In pratica, un servizio cloud legittimo veniva trasformato in un dead-drop digitale usato dal malware per recuperare informazioni operative. L’abuso di piattaforme ampiamente utilizzate complica ulteriormente il rilevamento, perché il traffico verso servizi Google o reti BitTorrent può confondersi con attività lecite presenti in molti ambienti aziendali e di sviluppo. La forza di Glassworm stava proprio nella ridondanza: se un layer fosse stato neutralizzato, il malware avrebbe potuto continuare a recuperare configurazioni dagli altri canali disponibili. Solo il takedown simultaneo orchestrato da CrowdStrike ha permesso di interrompere davvero la capacità operativa della botnet. Questa architettura mostra chiaramente come le moderne minacce avanzate non si affidino più a un singolo server C2, ma a ecosistemi distribuiti costruiti per sopravvivere a blocchi parziali e operazioni di interdizione.
La botnet prendeva di mira sviluppatori e pipeline supply-chain
L’obiettivo principale di Glassworm erano gli sviluppatori software e le infrastrutture di sviluppo. Gli attaccanti compromettevano estensioni per ambienti come VS Code, Cursor, Windsurf, VSCodium e Positron, distribuendole attraverso piattaforme come OpenVSX. Parallelamente, venivano inseriti hook malevoli in pacchetti npm e librerie Python, mentre oltre 300 repository GitHub risultavano avvelenati con codice e credenziali rubate. Questa strategia rendeva estremamente pericolosa la campagna perché una singola workstation di sviluppo compromessa poteva trasformarsi nel punto di ingresso per operazioni supply-chain in grado di colpire migliaia di organizzazioni downstream. Il malware principale, noto come GlasswormRAT, era scritto in Node.js e includeva funzionalità di accesso remoto, credential harvesting ed esfiltrazione di dati. Il codice mostrava inoltre chiari indicatori di attribuzione geografica: controllava locale, lingua e fuso orario per terminare immediatamente l’esecuzione su sistemi presenti nei paesi CIS, mentre numerosi commenti nel sorgente erano scritti in russo. Gli esperti ritengono che gli operatori abbiano progressivamente evoluto il framework dal 2025, introducendo anche componenti sviluppati in Rust e Zig per migliorare stealthiness e portabilità cross-platform. L’attenzione verso sviluppatori e pipeline CI/CD conferma una tendenza sempre più preoccupante nel panorama delle minacce moderne: colpire gli ambienti di sviluppo permette di compromettere software distribuito a valle e moltiplicare l’impatto di una singola infezione iniziale.
Le YARA rules aiutano a identificare sistemi compromessi
Dopo il takedown, CrowdStrike ha pubblicato nuove YARA rules per facilitare la rilevazione di Glassworm e accelerare le attività di incident response. Le regole identificano stringhe specifiche presenti nei componenti del malware, inclusi riferimenti a funzioni come “DownloadManager”, “start_socks” e URL collegati a nodejs.org. Una seconda firma si concentra invece sul downloader Python della botnet, rilevando script compressi tramite zlib e istruzioni basate su “exec compile”. Questi indicatori consentono agli amministratori di effettuare scansioni rapide su endpoint Windows, Linux e macOS e verificare la presenza di componenti riconducibili alla campagna. Il comportamento di beaconing verso l’indirizzo IP 164.92.88.210 rappresenta inoltre un indicatore di compromissione estremamente utile per le organizzazioni. I sistemi che continuano a tentare connessioni verso questo sinkhole risultano infatti probabilmente infetti o non completamente bonificati. CrowdStrike invita le aziende a isolare immediatamente tali host, verificare eventuali modifiche a repository interni e controllare pipeline CI/CD, pacchetti software e credenziali esposte. Il valore del takedown non risiede soltanto nell’interruzione delle comunicazioni C2, ma anche nella finestra temporale che offre alle vittime per eseguire remediation senza il rischio di ricevere nuovi payload o aggiornamenti malevoli dalla botnet.
Il takedown di Glassworm dimostra la nuova complessità delle botnet moderne
L’operazione contro Glassworm evidenzia come le moderne botnet stiano evolvendo verso modelli sempre più distribuiti, resilienti e difficili da neutralizzare. Gli attaccanti non si limitano più a usare server C2 centralizzati, ma costruiscono ecosistemi multi-layer che integrano blockchain, reti peer-to-peer, servizi cloud legittimi e infrastrutture VPS tradizionali. Questa frammentazione rende inefficace un approccio difensivo basato esclusivamente sul blocco di domini o indirizzi IP. Il caso Glassworm dimostra anche quanto il settore dello sviluppo software sia diventato un obiettivo strategico per gli attori malevoli. Compromettere toolchain, editor di codice, package manager e repository consente infatti di propagare malware lungo intere catene di distribuzione software, trasformando una singola infezione in una minaccia sistemica.
La collaborazione tra CrowdStrike, Google e Shadowserver Foundation ha mostrato che anche infrastrutture altamente distribuite possono essere neutralizzate attraverso azioni coordinate e simultanee. Tuttavia, il caso sottolinea anche la crescente necessità di integrare threat intelligence, analisi blockchain, monitoraggio cloud e controllo delle supply-chain software dentro le strategie di sicurezza moderne. Gli operatori di Glassworm avevano costruito un framework pensato per sopravvivere a blocchi parziali e per mantenere la capacità operativa anche in presenza di interruzioni infrastrutturali. Il successo del takedown dimostra che le minacce avanzate possono essere contenute, ma richiedono coordinamento internazionale, capacità tecniche elevate e rapidità di esecuzione per evitare che evolvano in compromissioni supply-chain su larga scala.
Iscriviti alla Newsletter
Non perdere le analisi settimanali: Entra nella Matrice Digitale.
Matrice Digitale partecipa al Programma Affiliazione Amazon EU. In qualità di Affiliato Amazon, ricevo un guadagno dagli acquisti idonei. Questo non influenza i prezzi per te.
