(in)sicurezza digitale

2026-04-12 14:24:04

ShinyHunters colpisce Rockstar Games attraverso Anodot: la campagna Salesforce-Snowflake mette a rischio 400 aziende

Non è stato bucato Rockstar Games. Non è stato bucato Snowflake. È stato compromesso il fornitore SaaS che monitorava i costi cloud di Rockstar, e attraverso di lui gli attaccanti sono entrati nell’ambiente Snowflake del produttore di GTA come se fossero un servizio interno legittimo. L’11 aprile 2026, ShinyHunters ha pubblicato sul proprio dark web leak site la rivendicazione dell’attacco, fissando al 14 aprile la scadenza per il pagamento o la pubblicazione dei dati. Ma la storia di Rockstar è solo la punta dell’iceberg: il gruppo rivendica l’accesso ai dati di oltre 400 organizzazioni collegate a integrazioni Salesforce, in quella che si configura come una delle campagne di esfiltrazione dati più sistematiche del 2026.

Il vettore: Anodot come cavallo di Troia

Il punto di ingresso non è stato né Rockstar Games né Snowflake direttamente, ma Anodot, una piattaforma SaaS specializzata nel monitoraggio dei costi cloud e nell’anomaly detection per infrastrutture enterprise. Rockstar utilizza Anodot per la governance dei costi sulla propria infrastruttura cloud, e questo ha creato una superficie di attacco inaspettata: ShinyHunters ha compromesso l’infrastruttura di Anodot, estratto i token di autenticazione Snowflake presenti nei dati di configurazione del cliente, e li ha utilizzati per accedere all’ambiente Snowflake di Rockstar con credenziali del tutto legittime agli occhi dei sistemi di controllo.

Il meccanismo è elegante nella sua semplicità: un tool di monitoraggio dei costi cloud deve per definizione avere accesso in lettura alle metriche e ai dati dell’infrastruttura monitorata. Quei token di accesso — validi, non scaduti e provenienti da un IP “conosciuto” — sono diventati le chiavi del regno. I team di sicurezza di Rockstar, abituati a vedere traffico normalizzato da Anodot, non hanno rilevato anomalie per un periodo significativo. Quando l’esfiltrazione è stata individuata, ShinyHunters aveva già portato a termine l’operazione.

I dati in gioco: da GTA Online ai contratti riservati

La portata potenziale dell’esfiltrazione da Rockstar è notevole. I database Snowflake di una società come Rockstar Games contengono strati di dati estremamente sensibili: record finanziari di GTA Online e Red Dead Online, incluse le microtransazioni di decine di milioni di giocatori globali; dati di profilazione geografica e di spesa degli utenti; timeline di marketing interno con dettagli su lanci di prodotto futuri — GTA 6 su tutti — e, potenzialmente, contratti con Sony, Microsoft, doppiatori e label musicali. Se questi ultimi materiali fossero pubblicati, le implicazioni andrebbero ben oltre una multa GDPR: negoziazioni attive su IP, compensi e accordi esclusivi potrebbero essere compromesse.

Rockstar Games ha confermato l’incidente in una dichiarazione breve e misurata, affermando che l’attacco “non ha alcun impatto sulla nostra organizzazione o sui nostri giocatori”. Una posizione che i ricercatori di sicurezza hanno accolto con cauto scetticismo: le conseguenze di una breach su dati di questa natura raramente sono immediate o visibili, e tendono a manifestarsi nei mesi successivi sotto forma di leak mirati, manipolazioni di mercato o negoziazioni pilotate da materiale riservato.

La campagna allargata: 400+ organizzazioni nell’ecosistema Salesforce

Il caso Rockstar non è isolato ma fa parte di una campagna sistematica. ShinyHunters rivendica l’accesso ai dati di oltre 400 organizzazioni legate a integrazioni Salesforce, in quella che appare come un’operazione metodica contro l’ecosistema di fornitori SaaS interconnessi che gestiscono dati enterprise critici. Tra i nomi emersi figurano Cisco, la telco canadese Telus, l’operatore olandese Odido, e — in modo ancora non verificato indipendentemente — riferimenti a dati della Commissione Europea.

Due casi documentati nei giorni precedenti all’annuncio su Rockstar illustrano la dimensione operativa: Marcus & Millichap, società immobiliare statunitense quotata in borsa, ha visto rivendicata l’esfiltrazione di oltre 30 milioni di record Salesforce contenenti dati personali (PII); Abrigo, fornitore di software per il settore bancario, conta 1,7 milioni di record Salesforce potenzialmente compromessi. Entrambe le rivendicazioni portano la stessa firma e la stessa scadenza del 14 aprile 2026. La serialità dell’operazione suggerisce un accesso strutturale all’ecosistema Salesforce, probabilmente attraverso uno o più fornitori di integrazione condivisi.

ShinyHunters: anatomia di un’operazione di estorsione seriale

ShinyHunters non è un gruppo improvvisato. Attivo almeno dal 2020, il collettivo ha costruito un curriculum di breach di alto profilo che include la violazione di Ticketmaster (560 milioni di record nel 2024), Santander Bank, AT&T e decine di altre organizzazioni. Il modello operativo è consolidato e ripetibile: compromissione silenziosa dell’infrastruttura target o di un suo fornitore, esfiltrazione dei dati, pubblicazione della rivendicazione su dark web leak site con scadenza ravvicinata pensata per massimizzare la pressione psicologica sul management della vittima.

La scelta di attaccare la filiera dei fornitori SaaS — piuttosto che i target diretti — è una evoluzione tattica significativa e preoccupante. Strumenti come Anodot, che gestiscono token e credenziali di accesso ai dati cloud delle proprie aziende clienti, sono nodi ad altissimo valore nella catena di fornitura digitale. Un singolo breach di un fornitore SaaS condiviso può moltiplicare esponenzialmente il numero di vittime downstream, esattamente come accade negli attacchi alla supply chain software.

Raccomandazioni: gestire il rischio della fiducia transitiva

Il caso Rockstar-Anodot-Snowflake è un caso di studio esemplare sul concetto di fiducia transitiva non controllata. Quando si delega l’accesso ai propri dati a un fornitore terzo, si estende implicitamente la propria superficie di attacco all’intera catena di sicurezza di quel fornitore. Le misure difensive prioritarie includono: adozione di token di accesso a scope minimo e breve durata con rotazione automatica; IP allowlisting per le credenziali di accesso ai data warehouse; abilitazione obbligatoria di MFA anche per gli account di servizio Snowflake; monitoraggio del volume e dei pattern di query per identificare esfiltrazione massiva; e una procedura sistematica di vendor security assessment che includa evidenze SOC2 Type II e penetration test annuali prima di concedere accesso a dati sensibili.

La domanda che ogni CISO con integrazioni SaaS attive dovrebbe porsi oggi è semplice: sapete esattamente quali fornitori terzi hanno accesso — diretto o indiretto — ai vostri dati cloud? Avete verificato la loro postura di sicurezza di recente? E soprattutto: se uno di loro venisse compromesso domani, sareste in grado di revocare immediatamente l’accesso? La risposta a queste tre domande definisce la differenza tra una gestione proattiva del rischio di terze parti e la prossima vittima di ShinyHunters.

(in)sicurezza digitale

2026-04-12 09:37:29

UNC1069 trasforma Axios in un vettore di spionaggio: WAVESHAPER.V2 colpisce la supply chain npm

Per tre ore e diciannove minuti, tra la mezzanotte e le 03:20 UTC del 31 marzo 2026, chi ha eseguito npm install axios ha involontariamente invitato un RAT nordcoreano nei propri sistemi. L’attacco alla supply chain del pacchetto Axios — 70 milioni di download settimanali, il client HTTP più usato dell’ecosistema JavaScript — porta la firma di UNC1069, un cluster APT legato alla Corea del Nord e motivato finanziariamente che da anni prende di mira sviluppatori e infrastrutture crypto. L’operazione dimostra ancora una volta che il vettore più efficace per infiltrarsi in ambienti protetti non è un exploit zero-day: è la fiducia umana.

L’ingegneria sociale che ha aperto la porta

Tutto comincia mesi prima della compromissione vera e propria. Gli operatori di UNC1069 si sono avvicinati a Jason Saayman, maintainer principale di Axios su npm, fingendosi il fondatore di una società legittima e ben nota nel settore tech. Non si sono limitati a creare un profilo falso: hanno clonato digitalmente l’identità della persona reale, creando una replica convincente sia del soggetto sia dell’azienda. “Hanno calibrato ogni dettaglio specificamente su di me”, ha scritto Saayman nel post-mortem dell’incidente.

Il contatto si è trasformato in una chiamata video su Microsoft Teams. Durante il meeting, gli attaccanti hanno simulato un problema audio e hanno convinto Saayman a installare un componente “mancante” per risolvere l’incompatibilità. Il file che il maintainer ha eseguito non era una patch per Teams: era WAVESHAPER.V2, il RAT cross-platform del gruppo. Da quel momento UNC1069 disponeva delle credenziali npm di Saayman e del controllo sul suo ambiente di sviluppo.

La catena di attacco: da npm al C2 in tre passi

Una volta ottenuto l’accesso all’account npm, gli attaccanti hanno pubblicato due release backdoorate: axios@1.14.1 e axios@0.30.4. Entrambe iniettavano una dipendenza malevola — plain-crypto-js@4.2.1 — che non esiste nel registro legittimo npm. Il pacchetto conteneva SILKBELL, un dropper offuscato che si attivava automaticamente tramite un hook postinstall nello script setup.js, senza alcuna interazione da parte dell’utente o dello sviluppatore.

SILKBELL stabiliva una connessione con l’infrastruttura C2 di UNC1069 e scaricava WAVESHAPER.V2, adattando il payload al sistema operativo rilevato. Il comportamento variava per piattaforma:

• Windows: copia di powershell.exe in %PROGRAMDATA%\wt.exe, persistenza via chiave di registro HKCU\Software\Microsoft\Windows\CurrentVersion\Run con nome “MicrosoftUpdate” e batch nascosto system.bat.
• macOS: binario Mach-O installato in /Library/Caches/com.apple.act.mond, eseguito tramite zsh.
• Linux: backdoor Python scaricato in /tmp/ld.py ed eseguito con nohup.

WAVESHAPER.V2: capacità operative e firma anomala

La versione V2 del backdoor introduce comunicazione via JSON, raccolta estesa di informazioni di sistema e un set ampliato di comandi rispetto alla versione precedente documentata da Mandiant. Le principali funzionalità includono: peinject per l’iniezione in memoria di shellcode e PE, rundir per la ricognizione del filesystem con raccolta di metadati, esecuzione di script arbitrari e terminazione di processi. Il beaconing avviene via HTTP ogni 60 secondi verso la porta 8000 del server C2.

L’anomalia più curiosa — e paradossalmente più utile per i difensori — è la stringa User-Agent hardcodata in tutte e tre le varianti di piattaforma: mozilla/4.0 (compatible; msie 8.0; windows nt 5.1; trident/4.0). Un fingerprint da Internet Explorer 8 su Windows XP è immediatamente anomalo su qualsiasi macchina moderna, e ancor più su host macOS o Linux. Sebbene garantisca un routing coerente lato server C2, è un indicatore di compromissione banalmente rilevabile su qualunque proxy o SIEM moderno.

Attribuzione: UNC1069 e la rete finanziaria di Pyongyang

L’attribuzione a UNC1069 è stata effettuata in modo indipendente da Google Threat Intelligence Group (GTIG), Microsoft Threat Intelligence e Mandiant. Il cluster è tracciato sotto diversi alias: Sapphire Sleet, STARDUST CHOLLIMA, Alluring Pisces, BlueNoroff, CageyChameleon e CryptoCore. Attivo almeno dal 2018, UNC1069 è motivato finanziariamente e ha storicamente preso di mira istituzioni finanziarie, exchange di criptovalute e maintainer di pacchetti open source ad alta diffusione, nella logica di massimizzare il potenziale di accesso a valle.

Il collegamento tecnico più solido emerso dall’analisi è l’infrastruttura C2: il dominio sfrclak[.]com risolve sull’IP 142.11.206[.]73, e le connessioni da questo server sono state tracciate verso un nodo AstrillVPN precedentemente attribuito a UNC1069 in campagne separate. Il binario macOS presenta poi sovrapposizioni significative con WAVESHAPER nella versione originale documentata da Mandiant, rendendo la catena di attribuzione robusta e multi-vendor.

Impatto e analisi del blast radius

La finestra di esposizione — circa tre ore — ha limitato il numero diretto di compromissioni. eSentire ha identificato 19 organizzazioni clienti colpite, principalmente nel settore dello sviluppo software in Nord America ed EMEA. Tuttavia la nuova analisi pubblicata il 12 aprile 2026 sottolinea come il “blast radius” reale vada ben oltre queste cifre dirette: pipeline CI/CD, container Docker, ambienti serverless e toolchain di build che eseguono automaticamente npm ci potrebbero aver scaricato le versioni malevole senza che gli sviluppatori ne fossero consapevoli, specialmente in organizzazioni prive di monitoraggio sui log di installazione npm.

Indicatori di Compromissione (IoC)

# Pacchetti npm malevoli
axios@1.14.1
axios@0.30.4
plain-crypto-js@4.2.1

# Hash file
SILKBELL (setup.js): e10b1fa84f1d6481625f741b69892780140d4e0e7769e7491e5f4d894c2e0e09
Windows RAT:         617b67a8e1210e4fc87c92d1d1da45a2f311c08d26e89b12307cf583c900d101

# Infrastruttura C2
IP:       142.11.206[.]73
Domini:   sfrclak[.]com
          callnrwise[.]com
Endpoint: hxxp://sfrclak[.]com:8000/6202033
Porta:    8000 (beaconing HTTP, intervallo 60s)

# User-Agent anomalo (presente su Windows, macOS e Linux)
"mozilla/4.0 (compatible; msie 8.0; windows nt 5.1; trident/4.0)"

# Persistenza Windows
Chiave registro: HKCU\Software\Microsoft\Windows\CurrentVersion\Run -> "MicrosoftUpdate"
File: %PROGRAMDATA%\wt.exe (copia mascherata di powershell.exe)
File: system.bat (nascosto)

# Persistenza macOS
/Library/Caches/com.apple.act.mond

# Persistenza Linux
/tmp/ld.py (eseguito con nohup)

Raccomandazioni per i difensori

Chi ha eseguito npm install o npm ci il 31 marzo 2026 tra le 00:21 e le 03:20 UTC deve considerare i propri ambienti compromessi fino a prova contraria. Le azioni prioritarie: verificare i log di installazione npm per la presenza di axios@1.14.1, axios@0.30.4 o plain-crypto-js; controllare il traffico di rete in uscita verso 142.11.206.73 su porta 8000 con il caratteristico User-Agent IE8; cercare la chiave di registro “MicrosoftUpdate” nel percorso Run e il file wt.exe in %PROGRAMDATA% su sistemi Windows.

Sul piano preventivo, le pratiche raccomandate includono: pinning esplicito delle versioni nei file lock, disabilitazione degli aggiornamenti automatici delle dipendenze, implementazione di policy di “release cooldown” supportate dai principali package manager, monitoraggio continuo dell’esecuzione degli hook postinstall, e adozione di soluzioni di Software Composition Analysis (SCA) che alertino su nuove dipendenze transitive non attese. L’incidente Axios dimostra che anche i pacchetti più fidati e consolidati possono diventare vettori di attacco: la fiducia cieca nell’ecosistema open source è un lusso che le organizzazioni non possono più permettersi.

(in)sicurezza digitale

2026-04-11 08:02:26

Operazione Olalampo: MuddyWater sfrutta Rust e Telegram per spiare il Medio Oriente

Dal gennaio 2026, il gruppo iraniano MuddyWater conduce una campagna di spionaggio sofisticata contro organizzazioni governative, energetiche e infrastrutturali del Medio Oriente e Nord Africa. L’Operazione Olalampo segna un salto qualitativo nelle capacità offensive del gruppo: malware scritto in Rust, sviluppo assistito da intelligenza artificiale e un canale di comando-e-controllo nascosto nei bot di Telegram.

Chi è MuddyWater e perché è pericoloso

MuddyWater — conosciuto anche come Seedworm, TA450, Mango Sandstorm ed Earth Vetala — è un gruppo APT ritenuto collegato al Ministero dell’Intelligence e Sicurezza iraniano (MOIS). Attivo da almeno il 2017, il gruppo ha nel tempo ampliato il proprio arsenale tecnico passando da strumenti commerciali come AnyDesk e SimpleHelp a malware completamente custom. L’Operazione Olalampo rappresenta la più recente e sofisticata evoluzione di questa traiettoria.

La catena d’attacco: da una macro Excel al controllo totale

L’infezione inizia con una campagna di spear-phishing mirata: le vittime ricevono email con allegati Microsoft Office (principalmente Excel) contenenti macro VBA malevole. Una volta attivata la macro, il codice decodifica ed esegue il payload iniziale in memoria, avviando una catena a più stadi progettata per massimizzare la furtività.

• Stadio 1 — GhostFetch: downloader di prima fase con funzioni di profilazione del sistema, controlli anti-debug e anti-VM, ed esecuzione in memoria del payload successivo.
• Stadio 2 — GhostBackDoor: backdoor completa con supporto per remote shell, operazioni sui file, esecuzione di comandi arbitrari e meccanismi di persistenza.
• HTTP_VIP: downloader alternativo che effettua ricognizione del sistema, si autentica al C2 e può distribuire AnyDesk per l’accesso remoto diretto, oltre a monitorare gli appunti di sistema.
• CHAR: backdoor scritta interamente in Rust, capace di esecuzione di comandi, accesso a PowerShell, operazioni di reverse proxy e deploy di proxy SOCKS5.

Il cuore dell’operazione: Telegram come infrastruttura C2

L’elemento più interessante di questa campagna è l’uso di un bot Telegram come canale di comando-e-controllo per la backdoor CHAR. Il bot — con display name “Olalampo” e username stager_51_bot — consente agli operatori di inviare comandi ai sistemi compromessi attraverso l’infrastruttura legittima di Telegram, rendendo il traffico indistinguibile da quello normale. Questo approccio offre tre vantaggi tattici significativi: il traffico viene cifrato end-to-end, si mimetizza nel traffico legittimo di messaggistica aziendale, e Telegram è molto difficile da bloccare completamente nei contesti aziendali.

Il monitoraggio del bot C2 ha permesso ai ricercatori di Group-IB di osservare direttamente le attività post-exploitation: comandi eseguiti, strumenti distribuiti e tecniche di raccolta dati utilizzate dagli operatori.

Sviluppo assistito da IA: una nuova frontiera per gli APT

Un dettaglio rivelatore nell’analisi del malware è la presenza di stringhe di debug contenenti emoji — un pattern tipico del codice generato o rifinito con l’assistenza di grandi modelli linguistici (LLM). Questo suggerisce che MuddyWater stia integrando strumenti di intelligenza artificiale nel proprio ciclo di sviluppo malware, potenzialmente accelerando la creazione di nuove varianti e riducendo gli errori. La scelta di Rust per CHAR va nella stessa direzione: Rust è un linguaggio relativamente giovane, ma molto popolare nei progetti LLM, cross-platform per definizione e che produce binari difficili da analizzare con i tradizionali strumenti di reverse engineering.

Infrastruttura e indicatori di compromissione

L’analisi DNS condotta da ricercatori indipendenti ha portato all’identificazione di quattro domini malevoli, tutti registrati tramite Namecheap con indirizzi di registrazione in Islanda — una tecnica di anonimizzazione comune tra gli attori state-sponsored. I domini risultano relativamente recenti, creati tra ottobre 2025 e febbraio 2026, confermando un’attiva preparazione dell’infrastruttura nelle settimane precedenti la campagna.

## Domini C2 identificati
jerusalemsolutions[.]com
miniquest[.]org
codefusiontech[.]org

## Indirizzi IP
162[.]0[.]230[.]185
209[.]74[.]87[.]100

## Telegram C2
Bot username: stager_51_bot
Bot display name: Olalampo

## Note infrastruttura
Registrar: Namecheap
Posizione registrazione: Islanda
Periodo creazione domini: 10/2025 – 02/2026
Comunicazioni victim-IoC osservate: 10 IP unici su 3 ASN (01/25–02/25/2026)

Settori e geografie colpite

I target primari dell’Operazione Olalampo includono agenzie governative, operatori di infrastrutture critiche, aziende del settore energetico, operatori di telecomunicazioni e professionisti di alto profilo nelle regioni MENA (Medio Oriente e Nord Africa). La scelta dei target è coerente con gli obiettivi di intelligence strategica del MOIS: raccolta di informazioni su politica estera, accordi energetici e comunicazioni riservate di governi nella sfera di influenza dell’Iran.

Consigli per i difensori

La natura dell’Operazione Olalampo richiede un approccio difensivo su più livelli. Limitare o monitorare il traffico verso i server Telegram (t.me, api.telegram.org) nei perimetri aziendali può bloccare il canale C2 principale, anche se ciò richiede un’analisi del rischio rispetto all’uso legittimo della piattaforma. A livello email, rafforzare i controlli sugli allegati Office con macro e abilitare Protected View/AMSI per documenti provenienti da fonti esterne è un primo scudo efficace. Sul fronte EDR, è fondamentale cercare attività anomale di PowerShell, processi figlio di applicazioni Office, e l’esecuzione di binari Rust non firmati. Infine, la presenza di processi AnyDesk o SimpleHelp avviati da percorsi inusuali dovrebbe costituire un alert ad alta priorità.

(in)sicurezza digitale

2026-04-11 08:03:16

GlassWorm: il worm che infetta tutti gli IDE tramite un’estensione OpenVSX contraffatta

Un’estensione contraffatta nel marketplace OpenVSX installa silenziosamente un dropper compilato in Zig che individua e infetta tutti gli IDE compatibili con VS Code presenti sulla macchina, per poi deployare un RAT con C2 su blockchain Solana e un’estensione Chrome per rubare sessioni e keystroke. La campagna GlassWorm è attiva da oltre un anno e ha appena compiuto il suo salto evolutivo più sofisticato.

Una campagna che cresce da un anno

GlassWorm non è una minaccia nuova: Aikido Security ne traccia l’evoluzione dal marzo 2025, quando fu individuata la prima variante nascosta in pacchetti npm attraverso caratteri Unicode invisibili per offuscare il payload. Da allora, la campagna ha iterato costantemente le proprie tecniche, arrivando oggi a una versione che colpisce non un singolo editor, ma l’intero ecosistema degli ambienti di sviluppo installati su una macchina — con una catena di infezione a più stadi difficile da individuare con le sole difese tradizionali.

Il vettore iniziale: un’estensione che finge di essere WakaTime

Il punto di ingresso è un’estensione pubblicata sul marketplace OpenVSX sotto il nome specstudio/code-wakatime-activity-tracker. L’estensione si spaccia per WakaTime, uno strumento molto diffuso tra gli sviluppatori che tiene traccia del tempo trascorso nel codice. Una volta installata, esegue immediatamente un codice di installazione minimale — dove un modulo punta a binari nativi Node.js compilati per la piattaforma target.

Il dropper Zig: fuori dalla sandbox JavaScript

Il vero cuore della tecnica è l’uso di binari nativi Node.js (file .node) compilati con Zig — un linguaggio di sistema relativamente giovane e poco presidiato dai motori antivirus. Questi addon vengono caricati direttamente nel runtime di Node con accesso completo al sistema operativo, bypassando completamente la sandbox JavaScript di VS Code. Il comportamento è fondamentalmente diverso da quello di un’estensione normale: non è codice JS interpretato con permessi limitati, ma una libreria nativa con diritti equivalenti al processo padre. I binari identificati sono specifici per piattaforma: su Windows viene deployato win.node (PE32+ DLL), mentre su macOS viene utilizzato mac.node (Universal Mach-O). Quest’ultimo conteneva simboli di debug rivelatori, con un percorso che ha permesso ai ricercatori di identificare il developer environment dell’autore.

Autopropagazione: infettare ogni IDE sulla macchina

Una volta eseguito, il dropper Zig non si limita a compromettere l’IDE corrente: scansiona il filesystem alla ricerca di tutti gli ambienti di sviluppo compatibili con le estensioni VS Code. Su Windows controlla le directory %LOCALAPPDATA%\Programs\ e %ProgramFiles%; su macOS la cartella /Applications/. Gli IDE target includono Microsoft VS Code e VS Code Insiders, ma anche i fork come Cursor (AI-first IDE in rapida adozione), Windsurf, VSCodium e Positron. Ogni editor trovato viene infettato con una seconda estensione malevola, installata silenziosamente tramite CLI usando il parametro –install-extension. Il secondo stadio si maschera da una estensione di auto-import con milioni di installazioni, scaricato da un repository GitHub sotto controllo degli attaccanti.

Il payload finale: Solana come C2, RAT e furto di sessioni Chrome

La seconda estensione malevola implementa le capacità di spionaggio vere e proprie. Il meccanismo di C2 è particolarmente innovativo: invece di puntare a un server fisso, il malware interroga la blockchain Solana per recuperare l’indirizzo del server di comando — una tecnica che rende il blocco dell’infrastruttura C2 praticamente impossibile senza bloccare l’intera blockchain. Tra le funzionalità documentate ci sono: geofencing contro sistemi con impostazioni locali russe (l’esecuzione viene saltata), esfiltrazione di segreti, token di sessione e chiavi API dal workspace dello sviluppatore, installazione di un RAT persistente con comunicazione cifrata, e deploy di un’estensione Chrome malevola per il furto di cookie di sessione e keystroke logging.

Indicatori di compromissione

## Estensioni malevole OpenVSX
specstudio/code-wakatime-activity-tracker  (1° stadio)
floktokbok.autoimport                       (2° stadio)

## Hash SHA-256 dei binari nativi Zig
win.node (Windows PE32+ DLL):
  2819ea44e22b9c47049e86894e544f3fd0de1d8afc7b545314bd3bc718bf2e02

mac.node (macOS Universal Mach-O):
  112d1b33dd9b0244525f51e59e6a79ac5ae452bf6e98c310e7b4fa7902e4db44

## Repository GitHub per distribuzione stage-2
ColossusQuailPray/oiegjqde

## Debug artifact (attributione autore)
/Users/davidioasd/Downloads/vsx_installer_zig

## IDE target confermati
VS Code, VS Code Insiders, Cursor, Windsurf, VSCodium, Positron

Perché questa campagna è un segnale d’allarme per i team di sicurezza

GlassWorm dimostra come il marketplace delle estensioni IDE sia diventato una superficie d’attacco matura e sfruttata attivamente. La compromissione di un singolo sviluppatore può propagarsi a tutta l’organizzazione attraverso repository git, ambienti CI/CD e pipeline di build condivisi — con un impatto potenziale molto superiore a quello di un malware che colpisce un endpoint generico. Il fatto che il dropper salti deliberatamente i sistemi russi suggerisce un attore state-sponsored o comunque con motivazioni geograficamente definite, probabilmente orientato verso organizzazioni di sviluppo software in occidente e in Asia.

Consigli per i difensori

I team di sicurezza dovrebbero esaminare l’elenco delle estensioni installate su tutti gli IDE degli sviluppatori, con particolare attenzione a estensioni non presenti nel Visual Studio Marketplace ufficiale ma solo su OpenVSX. L’introduzione di policy di allowlist per le estensioni VS Code, già supportata dalla funzionalità di Policy Management di VS Code, è oggi una misura consigliata in ambienti corporate. A livello di EDR, alert sulla creazione di file .node in directory di estensioni IDE e sull’esecuzione di processi IDE con parametri –install-extension da processi non interattivi sono indicatori ad alta fedeltà. L’analisi dei log di rete alla ricerca di chiamate RPC verso nodi Solana da processi Node.js può aiutare a rilevare la fase di C2 in modo precoce.