Il 26 maggio 2026 un’operazione coordinata tra CrowdStrike, Google e la Shadowserver Foundation ha smantellato Glassworm, una botnet specializzata negli attacchi contro sviluppatori software e infrastrutture open source.
L’azione ha colpito simultaneamente tutti i canali di comando e controllo del malware, interrompendo la capacità degli operatori di distribuire nuovi payload o mantenere il controllo dei sistemi compromessi. Glassworm rappresenta uno dei casi più sofisticati mai documentati nell’ambito della software supply chain security: gli attaccanti non puntavano alle aziende finali, ma agli sviluppatori stessi, sfruttando account GitHub, ambienti CI/CD, registri npm, repository Python e marketplace di estensioni VSCode.
Come funzionava l’infrastruttura e cosa rubava
Secondo l’analisi pubblicata da CrowdStrike, Glassworm era operativo almeno dall’inizio del 2025. Il gruppo distribuiva estensioni trojanizzate per VSCode e piattaforme derivate come Cursor, Windsurf e VSCodium attraverso il marketplace OpenVSX, pubblicando parallelamente pacchetti npm e moduli Python con codice dannoso attivato tramite script postinstall.
L’infrastruttura di comando e controllo era costruita per resistere ai takedown parziali: Glassworm operava contemporaneamente su server VPS convenzionali, rete BitTorrent DHT, memo transaction sulla blockchain Solana ed eventi Google Calendar usati come dead drop per i percorsi verso i server C2. Proprio questa resilienza ha richiesto un abbattimento simultaneo dell’intera infrastruttura da parte dei tre partner.
Una volta compromesso il sistema, il malware installava GlasswormRAT, un remote access tool scritto in Node.js capace di eseguire codice remoto, creare tunnel SOCKS, avviare sessioni VNC nascoste ed espandersi lateralmente. CrowdStrike ha documentato oltre 300 repository GitHub contaminati attraverso commit forzati e modifiche ai workflow automatici. Gli attaccanti miravano a token GitHub, credenziali npm, chiavi OpenVSX, cookie di autenticazione, wallet crypto e segreti nei file .env.
Le tecniche di evasione erano particolarmente avanzate: alcune varianti usavano caratteri Unicode invisibili per nascondere codice durante le review manuali, altre implementavano meccanismi “sleeping payload” che attivavano le funzioni offensive solo dopo aggiornamenti successivi del pacchetto. Il malware evitava inoltre l’esecuzione nei paesi CIS, e diversi ricercatori hanno identificato commenti in lingua russa nel codice analizzato.
Cosa devono fare ora sviluppatori e aziende
Il takedown ha interrotto i server di comando, ma non elimina automaticamente le infezioni già presenti. Le workstation che hanno installato estensioni o pacchetti alterati restano potenzialmente compromesse, rendendo urgente una verifica approfondita degli ambienti di sviluppo.
Le priorità immediate riguardano un audit completo delle estensioni VSCode installate, la rotazione dei token GitHub e npm, il controllo dei workflow GitHub Actions e una revisione dei commit recenti nei repository principali. È consigliata anche un’analisi delle dipendenze Python e Node.js per individuare eventuali pacchetti alterati ancora presenti.