Smantellamento di Glassworm: quando il C2 si nasconde in Solana, BitTorrent e Google Calendar

Alle 14:00 UTC del 2026-05-26, CrowdStrike, Google e la Shadowserver Foundation hanno eseguito un'azione coordinata di smantellamento contro Glassworm — una botnet auto-propagante che da oltre un anno distribuiva estensioni VS Code troianizzate, pacchetti npm e commit forzati su GitHub. La novità non è il malware. La novità è dove il malware andava a leggere i suoi comandi. Glassworm operava il command-and-control su quattro canali paralleli: i campi memo delle transazioni sulla blockchain Solana, la tabella distribuita peer-to-peer di BitTorrent (DHT), i titoli degli eventi su Google Calendar e una piccola flotta di VPS commerciali. Dal punto di vista di un NDR signature-based, di un NGFW e di un sistema di reputation outbound, i primi tre canali sembrano uno sviluppatore che usa cripto, torrent e Google Workspace. Cioè la maggior parte degli sviluppatori.

Cosa è stato effettivamente smantellato

L'azione coordinata ha colpito in simultanea tutti e quattro i canali C2, non il malware sottostante. CrowdStrike descrive l'operazione come la disarticolazione dell'infrastruttura di comando "resiliente" di Glassworm: Google ha revocato gli account Workspace usati come dead drop sui Calendar, Shadowserver ha effettuato sinkhole sullo strato VPS e sulle chiavi DHT BitTorrent, e CrowdStrike ha gestito il lato Solana via attribuzione on-chain e flagging dei wallet. BleepingComputer riporta che la campagna è responsabile della distribuzione di almeno 73 estensioni "sleeper" sul marketplace OpenVSX e di "più di 400 artefatti software" complessivi tra GitHub e npm. CrowdStrike cita autonomamente più di 300 repository GitHub con force-push malevoli realizzati con credenziali raccolte da infezioni precedenti.

Il malware in sé non è scomparso. Le macchine sviluppatore già infette restano impiantate; hanno semplicemente perso la possibilità di ricevere nuovi task — finché gli operatori non ricostruiscono lo strato C2, cosa che faranno, perché le botnet di supply chain sono economicamente razionali e hanno alle spalle una storia di ritorni online a poche settimane da ogni takedown, a partire da Storm Worm nel 2008.

I quattro canali C2 — e perché ognuno era invisibile

Il design di C2 di Glassworm è la parte su cui i difensori dovrebbero fermarsi a riflettere. Ogni canale è stato scelto perché vive dentro un flusso che il filtro outbound di un'enterprise è pagato per lasciar passare.

Memo Solana. Le transazioni Solana includono un campo memo opzionale — qualche centinaio di byte di testo libero pensati per usi legittimi come associare un ID cliente a un pagamento. Glassworm codificava gli indirizzi dei propri server C2 in quei memo. Il costo per pubblicare un memo è una frazione di centesimo. Visto dal cavo, un host infetto che interroga gli endpoint RPC Solana (api.mainnet-beta.solana.com e simili) è indistinguibile da uno sviluppatore che usa un wallet personale sulla rete pubblica. Non c'è un dominio da bloccare senza spaccare la blockchain pubblica.

BitTorrent DHT. La tabella distribuita peer-to-peer di BitTorrent è un key-value store globalmente condiviso progettato per resistere alla censura. Glassworm interrogava la DHT per dati di configurazione memorizzati su chiavi pubbliche hardcoded e controllate dagli operatori. Il pattern di traffico è UDP verso migliaia di peer su provider residenziali e di hosting — visivamente identico a un client torrent. Pochi enterprise oggi bloccano BitTorrent al gateway, perché le distribuzioni Linux e le patch di gaming lo usano legittimamente.

Titoli di eventi su Google Calendar. Questo è il più elegante dei quattro. Gli operatori di Glassworm creavano eventi su Google Calendar i cui titoli contenevano frammenti di path C2 codificati in Base64. Gli host infetti facevano polling sulla API legittima di Google Calendar per gli eventi su calendari controllati dagli attaccanti. Dal perimetro è traffico verso calendar.google.com con sessione Workspace autenticata. Nessun prodotto di reputation outbound sul mercato classifica google.com come malevolo. Al difensore si chiede di scegliere tra bloccare Calendar in toto o accettare che qualunque stringa in qualunque titolo evento sia un potenziale dead drop.

VPS commerciali. Il quarto canale è quello noioso — C2 tradizionale su VPS in affitto. Esiste come fallback per quando gli altri tre fanno più rumore del solito. Anche questo strato veniva ruotato abbastanza frequentemente da far scadere i feed di domain reputation prima della detection.

Il punto difensivo è che i primi tre canali sono categoricamente diversi dal VPS. Non sono infrastruttura C2 che i difensori non hanno individuato; sono infrastruttura C2 progettata per essere statisticamente indistinguibile dal traffico legittimo. Bloccare il protocollo spacca l'uso legittimo. Bloccare la destinazione spacca l'uso legittimo. Il segnale — se c'è — sta nel comportamento delle chiamate, non nelle chiamate stesse.

Come le macchine degli sviluppatori sono finite lì

L'ingresso di Glassworm è stato il marketplace OpenVSX e in misura minore pacchetti npm troianizzati e (secondo CrowdStrike) PyPI. Secondo BleepingComputer, 73 estensioni sleeper su OpenVSX trasportavano payload Glassworm. OpenVSX è il registry open-source da cui gli editor derivati da VSCode (VSCodium, Theia, Gitpod, Eclipse Che) scaricano le estensioni. Non ha la stessa pipeline di review del marketplace ufficiale Microsoft. Un'installazione vsx è un'installazione package.json — l'estensione esegue JavaScript nel contesto dell'editor, con gli stessi permessi filesystem dello sviluppatore.

Una volta installato, Glassworm raccoglieva credenziali dalla macchina sviluppatore — git credential manager, cookie del browser, PAT in cache dell'IDE, token npm — e usava quelle credenziali per fare force-push di commit malevoli sui repository su cui la vittima aveva diritti di scrittura. È così che la campagna ha raggiunto 300+ repository GitHub senza che gli operatori dovessero mai compromettere GitHub. È anche il motivo per cui CrowdStrike classifica il comportamento di Glassworm come auto-propagante: la propagazione di secondo livello non vive sull'infrastruttura degli operatori.

CrowdStrike segnala check di locale e timezone nell'impianto che fanno uscire silenziosamente su macchine configurate per Paesi CIS — la firma di lunga data degli operatori russofoni, anche se nessuna attribuzione pubblica a un attore noto è stata fatta.

Perché il vostro stack non l'ha visto

La domanda da post-mortem è l'unica che conta. Difensori con SOC, SIEM, EDR moderno, appliance NDR e NGFW di fascia alta non hanno visto Glassworm per oltre un anno. Il motivo non è la pigrizia. È il design dello stack di detection.

"Vediamo egress verso calendar.google.com. Vediamo egress verso api.mainnet-beta.solana.com. Vediamo peer BitTorrent. Nessuno di questi è in blocklist, nessuno ha reputation bassa, e abbiamo utenti legittimi che li toccano ogni giorno. Su cosa avremmo dovuto generare alert?"

È una parafrasi di praticamente ogni analista NDR che ha riletto la IOC list di Glassworm questa settimana. Hanno ragione. La detection signature-based e reputation-based non risolve questa categoria, perché la signature è traffico legittimo.

Il segnale rilevabile esiste, ma vive dove i motori signature non guardano:

• Timing del beacon. La cadenza di polling di Glassworm contro l'API Calendar e l'RPC Solana è regolare in un modo che l'uso umano di uno sviluppatore non è. Una volta che hai una baseline di come si comporta un utente Workspace reale, il battito del bot è visibile.
• Contesto endpoint. Un laptop sviluppatore che improvvisamente inizia a interrogare RPC Solana senza averlo mai fatto è un'anomalia comportamentale anche se Solana non è in nessuna blocklist. Il segnale è nel cambiamento, non nella destinazione.
• Asimmetria di volume su infrastruttura condivisa. Host che tirano configurazione dalla DHT BitTorrent ogni pochi minuti per settimane, senza alcun payload di download torrent corrispondente, stanno facendo girare un control plane — non un client torrent.
• Correlazione processo-rete. Un processo di un'estensione VSCode che fa chiamate outbound verso una API Google è normale. Lo stesso processo estensione che fa chiamate verso un endpoint RPC Solana non lo è.

Questi quattro segnali sono tutti statistici, non signature-based. Sono esattamente ciò che un modello deep-learning di rete addestrato su traffico baseline classifica come deviazione — ed esattamente ciò che i prodotti perimetrali sul lato ricezione del ciclo di procurement non generano.

Cosa resta del problema di detection

Glassworm è un punto di svolta in un pattern che si costruisce da tre anni. Le ondate di typo-squatting npm del 2023 erano rilevabili al registry. Il problema SLSA-attested-but-malicious del 2024 era rilevabile al layer di attestation. L'approccio C2-in-canali-legittimi di Glassworm è rilevabile solo sul cavo, in tempo reale, contro un modello comportamentale — perché quando il pacchetto è installato e l'impianto sta girando, attestation, reputation e signature hanno già passato i loro check legittimamente.

Il takedown comprerà ai difensori qualche settimana. Le 73 estensioni OpenVSX sono rimosse. Gli account Calendar revocati. I wallet Solana flaggati. Niente di tutto questo previene la prossima iterazione, che userà una blockchain diversa, un equivalente-Calendar diverso e un overlay peer-to-peer diverso. Il design "C2 nascosto nel traffico legittimo" è ora parte del toolbox dell'attaccante, e i prodotti perimetrali che l'hanno mancato la prima volta lo mancheranno la prossima — perché la detection mancata non è un fallimento di vendor, è un fallimento di categoria.

Dove si colloca Zero Hunt nel mondo post-Glassworm

Questo scenario è esattamente quello per cui è stato ingegnerizzato il pilastro AI Traffic Analysis della piattaforma Zero Hunt. L'appliance esegue un modello deep-learning proprietario con quattro inference head paralleli — traffico sospetto, classificazione malware, identificazione del tipo di attacco, fingerprinting applicativo — addestrato su miliardi di sequenze PCAP e inferito localmente sulla GPU dell'appliance a 2.7+ Gbit/s. Non chiama un feed di reputation. Non ha bisogno che una destinazione sia in blocklist. Guarda la forma del traffico: timing, asimmetria di volume, correlazione processo-flusso, deviazione dalla baseline dell'host stesso.

Un'estensione VSCode su un laptop sviluppatore che fa beacon ogni 90 secondi verso un endpoint RPC Solana su una macchina che non aveva attività crypto pregresse è una deviazione. Un laptop residenziale che pubblica query DHT BitTorrent senza payload torrent è una deviazione. Una sessione Workspace autenticata il cui pattern di chiamate API Calendar non somiglia a un umano che controlla la propria agenda è una deviazione. Nessuna di queste è una chiamata di reputation. Tutte succedono sul cavo, localmente, in tempo reale — che è l'unico posto in cui la classe di problemi Glassworm è rilevabile.

Il pilastro complementare di pentest generativo chiude il cerchio sul lato perimetro: validazione continua che il percorso di attacco effettivamente usato dalla campagna Glassworm — installazione plugin IDE → credential harvest → outbound verso API non-aziendale — sia una delle catene rigenerate per ambiente dallo swarm di 10 agenti, backtestate via AI Gym prima di girare su rete reale. E sul lato compliance, ogni detection traffic-side e ogni finding di validazione continua sono mappate su controlli NIS2, DORA e ISO 27001 con evidenza firmata ECDSA, in modo che la capability di detection della supply chain si traduca direttamente in prova auditor-ready.

Se vuoi vedere come si comporta la detection di classe Glassworm contro il tuo perimetro e il traffico dei tuoi sviluppatori, apri una conversazione. Il takedown è stata la metà facile. La detection è la metà che resta in carico al difensore.