Red Hot Cyber
Sicurezza Informatica, Notizie su Cybercrime e Analisi Vulnerabilità
Una giovane donna con occhiali e capelli ricci raccolti è seduta di profilo alla scrivania in un ufficio buio di notte, concentrata mentre scrive codice al computer. Davanti a lei ci sono due grandi monitor accesi che mostrano righe di programmazione su sfondo scuro. Sulla scrivania in legno si trovano una tastiera meccanica con retroilluminazione blu, un paio di cuffie, una tazza nera e un blocco note. Sullo sfondo, l'ambiente dell'ufficio è semi-buio, con grandi finestre che si affacciano sulle luci sfocate della città notturna.

Glassworm: la botnet che ha infettato gli sviluppatori ora è stata smantellata

4 Giugno 2026 07:01
In sintesi

La botnet Glassworm ha attaccato gli sviluppatori tramite estensioni per editor di codice e pacchetti npm e Python, infettando repository GitHub. La minaccia principale non risiede solo nella portata della botnet, ma anche nella facilità con cui gli sviluppatori possono essere presi di mira

CrowdStrike ha annunciato lo smantellamento della botnet Glassworm, che attaccava gli sviluppatori tramite estensioni per editor di codice, pacchetti npm e Python e infettava repository GitHub. L’operazione, condotta congiuntamente con Google e la Shadowserver Foundation, ha preso di mira simultaneamente quattro canali di comando e controllo attraverso i quali gli operatori di Glassworm trasmettevano istruzioni e nuovi moduli dannosi alle macchine infette.

La minaccia principale di Glassworm non risiedeva solo nella portata della botnet.

Sviluppatori sotto attacco

La campagna ha dimostrato quanto sia facile per gli sviluppatori eseguire attacchi. Una singola workstation infetta può fornire ai criminali l’accesso al codice sorgente, alle piattaforme cloud, alle pipeline CI/CD , alle credenziali e ai registri dei pacchetti. Dopodiché, il problema non è più locale: il codice dannoso può diffondersi ulteriormente lungo la catena di fornitura del software e colpire aziende che non sono nemmeno a conoscenza dell’infezione iniziale.

Advertising

Secondo CrowdStrike, gli operatori di Glassworm hanno preso di mira sistematicamente gli sviluppatori almeno dall’inizio del 2025. Gli aggressori hanno pubblicato estensioni trojanizzate per VS Code nella directory OpenVSX, camuffandole da strumenti comuni come tracker del tempo e formattatori di codice. Queste estensioni non colpivano solo VS Code, ma anche Cursor, Positron, Windsurf, VSCodium e altri editor compatibili con questo ecosistema.

La seconda linea di attacco è stata condotta tramite npm e pacchetti Python. Il codice dannoso è stato eseguito durante la normale installazione delle dipendenze, attraverso hook postinstalle script di installazione. Per lo sviluppatore, questo processo poteva apparire come un normale aggiornamento delle librerie, anche se la macchina stava già eseguendo codice di terze parti.

Il terzo obiettivo sono i repository di GitHub . CrowdStrike segnala che gli operatori di Glassworm hanno infettato oltre 300 repository utilizzando credenziali di sviluppatori rubate durante infezioni precedenti. Gli aggressori hanno sovrascritto force pushi branch predefiniti e aggiunto codice dannoso a quello che gli altri utenti si aspettavano essere un progetto legittimo.

Architettura dei C2 multiformi

La campagna ha preso di mira Windows, macOS e Linux. Le sue funzionalità includevano il furto di informazioni, la raccolta di credenziali e un vero e proprio strumento di accesso remoto basato su Node.js, che CrowdStrike chiama GlasswormRAT. “RAT” in questo contesto sta per “remote access tool” (strumento di accesso remoto), il che significa che consente all’operatore di controllare a distanza il sistema infetto.

L’infrastruttura di Glassworm era progettata per la sopravvivenza. Gli operatori non si limitavano a un singolo server di comando e controllo, che poteva essere rapidamente disattivato dal provider di hosting. Al contrario, la botnet utilizzava quattro canali diversi, ognuno dei quali contribuiva a localizzare i server di comando e controllo o a recuperare informazioni di configurazione.

Advertising

Il primo canale è stato instradato attraverso la blockchain di Solana. Gli indirizzi dei server C2, o server di controllo, sono stati registrati campi memo delle transazioni della blockchain. Questo sistema funziona come una cache pubblica: i dati sono visibili sulla rete e non scompaiono in seguito a un reclamo al fornitore di hosting perché sono già registrati nella blockchain.

Il secondo canale utilizzava la tabella hash distribuita (DHT) di BitTorrent. GlasswormRAT accedeva alla rete peer-to-peer di BitTorrent e cercava i dati di configurazione utilizzando chiavi pubbliche predefinite. Una rete di questo tipo non presenta un singolo punto di fallimento, il che la rende molto più difficile da disabilitare con metodi convenzionali.

Il terzo canale era nascosto all’interno di un servizio web legittimo. Glassworm utilizzava le intestazioni degli eventi di Google Calendar per trasmettere percorsi codificati in Base64 al server C2. Per i difensori, questo traffico appare allarmante: il calendario in sé non è un servizio dannoso, il che significa che il semplice blocco del dominio potrebbe compromettere le normali operazioni degli utenti.

Il quarto canale era più simile allo schema classico. L’infrastruttura malevola era collegata direttamente a server C2 ospitati da provider di VPS commerciali. Attraverso questi, gli operatori potevano distribuire i payload malware finali alle macchine infette.

Una combinazione di strumenti per rendere il malware altamente persistente

La combinazione di blockchain, BitTorrent, Google Calendar e server tradizionali ha fornito a Glassworm un margine di sicurezza. Se i difensori avessero disabilitato anche un solo canale, gli operatori avrebbero potuto reindirizzare i sistemi infetti verso un altro percorso e riprendere rapidamente il controllo. Pertanto, CrowdStrike, Google e la Shadowserver Foundation hanno interrotto simultaneamente tutti e quattro i canali. In seguito a ciò, le macchine infette hanno perso la capacità di ricevere nuovi comandi e payload dagli operatori.

CrowdStrike sottolinea che Glassworm si è evoluto nel corso di un anno. Gli operatori hanno cambiato linguaggio di programmazione, passando da JavaScript a Rust e Zig, estendendo i loro attacchi a diversi ecosistemi e costruendo infrastrutture di backup in caso di interruzioni. Questa persistenza è particolarmente pericolosa quando si prendono di mira gli sviluppatori: il furto di token, l’accesso ai repository e agli ambienti di lavoro potrebbero portare alla compromissione di progetti utilizzati da migliaia di altre organizzazioni.

L’azienda ritiene inoltre che i criminali siano probabilmente coinvolti nella sicurezza della catena di approvvigionamento. Le prove sono circostanziali: il malware, all’avvio, verificava la posizione geografica, la lingua e il fuso orario della vittima, per poi terminare silenziosamente se il sistema si trovava in un paese della CSI. Questa tattica è spesso utilizzata dai gruppi di criminali informatici della regione per evitare di attaccare obiettivi vicini. Il codice sorgente conteneva anche commenti in lingua russa. CrowdStrike sottolinea in particolare che nessun singolo indicatore da solo prova l’origine degli operatori: il controllo della posizione geografica può essere copiato e i commenti nel codice potrebbero essere stati creati da strumenti di intelligenza artificiale. Tuttavia, secondo l’azienda, lo schema generale è rimasto coerente per oltre un anno di osservazione.

A seguito dell’interruzione dell’infrastruttura, CrowdStrike ha pubblicato un indicatore di rete per la verifica delle infezioni. Tutte le macchine infette da Glassworm ora accedono a un indirizzo IP sicuro gestito da CrowdStrike: 164.92.88[.]210. L’azienda consiglia alle organizzazioni di controllare i log di rete e la telemetria delle workstation. Qualsiasi corrispondenza con questo indirizzo indica che l’host richiede un’ispezione e una pulizia immediate.

Per confermare l’infezione, CrowdStrike ha fornito anche due regole YARA. La prima regola cerca stringhe caratteristiche nello script GlasswormRAT. La seconda regola aiuta a rilevare il programma di installazione Python offuscato di Glassworm.

Concludendo

La vicenda di Glassworm mette in luce la debolezza degli attuali sistemi di protezione della catena di fornitura del software. Il rilevamento a posteriori è troppo tardi: un pacchetto dannoso può installarsi in pochi secondi e la protezione spesso si attiva solo dopo che i token sono stati rubati o uno script dannoso è stato eseguito.

Il problema è aggravato dalla struttura stessa degli ecosistemi di sviluppo. npm, PyPI, OpenVSX e GitHub contengono milioni di progetti, estensioni e dipendenze. I meccanismi di verifica integrati sono limitati e un malintenzionato può pubblicare rapidamente un nuovo pacchetto, incorporare codice dannoso nello script di installazione e colpire le prime vittime quasi immediatamente dopo la comparsa della dipendenza nel registro. Glassworm ha sfruttato questa velocità, passando continuamente da una piattaforma all’altra mantenendo l’accesso ai computer degli sviluppatori.

La sola scansione alla ricerca di file dannosi non eliminerà questa minaccia. Le difese dovrebbero includere la gestione delle dipendenze, il controllo delle estensioni degli editor, la limitazione delle autorizzazioni dei token, il monitoraggio dell’ambiente CI/CD e una risposta rapida al furto di credenziali. Ma è necessario interrompere anche l’infrastruttura esistente: se gli operatori continuano a gestire gli host infetti, possono reinviare il payload dannoso, cambiare strumenti e proseguire l’attacco attraverso un altro canale.

Glassworm è nato da un’idea semplice: raggiungere uno sviluppatore e, tramite lui, ottenere l’accesso al codice e agli utenti di qualcun altro. Gli operatori sfruttavano la fiducia negli strumenti di sviluppo, negli aggiornamenti, nei pacchetti e nei repository come meccanismo di diffusione. Interrompere quattro canali di controllo non elimina il rischio di workstation infette, ma offre alle aziende una finestra temporale per verificare, rimuovere i componenti dannosi e ripristinare l’accesso non autorizzato.


📢 Resta aggiornatoTi è piaciuto questo articolo? Rimani sempre informato seguendoci su 🔔 Google News.
Ne stiamo anche discutendo sui nostri social: 💼 LinkedIn, 📘 Facebook e 📸 Instagram.
Hai una notizia o un approfondimento da segnalarci? ✉️ Scrivici


Luigi Zullo 300x300
Ricercatore di sicurezza informatica con esperienza nell’analisi delle vulnerabilità, nella mitigazione del rischio cyber, nelle attività di red teaming ed ethical hacking e nella protezione di sistemi complessi. Specializzato in penetration testing e Threat Intelligence, contribuisce al rafforzamento della resilienza digitale di infrastrutture e reti aziendali.
Aree di competenza: Penetration Testing, Threat Intelligence, Red Teaming, Vulnerability Assessment, Incident Response