UNC6201 sfrutta zero-day in Dell RecoverPoint: GRIMBOLT, Ghost NICs e persistenza stealth su VMware dalla Cina

UNC6201 entra nella scena delle minacce avanzate come un attore che non si limita a “bucare” un appliance e restare lì. La campagna ricostruita da Mandiant e dal Google Threat Intelligence Group descrive un modello operativo più ambizioso, centrato su infrastrutture VMware, su un controllo paziente dell’ambiente e su una capacità di adattamento che si misura nei dettagli: persistenza ottenuta modificando script legittimi, movimento laterale orchestrato con tecniche di pivoting poco comuni, e un’evoluzione del malware che, a settembre 2025, segna un salto di qualità con la sostituzione di BRICKSTORM a favore del nuovo GRIMBOLT. Il detonatore tecnico è una vulnerabilità classificata come zero-day in Dell RecoverPoint for Virtual Machines, tracciata come CVE-2026-22769 e valutata con CVSS 10.0. Il dato che cambia la lettura non è solo la gravità assoluta del punteggio, ma la finestra temporale: l’exploitation sarebbe attiva almeno dalla metà del 2024, quindi prima che la comunità potesse riconoscere in modo sistematico i segnali. È la classica asimmetria delle campagne “silenziose”: quando l’organizzazione si accorge di un appliance compromesso, spesso la compromissione non è appena avvenuta, ma sta già producendo effetti a catena in aree più profonde dell’infrastruttura. In questo quadro, l’accesso iniziale su appliance edge diventa la prima tessera di un percorso che punta a VMware come ambiente “centrale” dove transitano workload critici, credenziali, segmenti di rete e, in molti casi, la gestione stessa del data center. Le sovrapposizioni osservate con UNC5221, associato a Silk Typhoon, raccontano un ecosistema in cui TTP e infrastrutture possono incrociarsi senza coincidere completamente: GTIG non considera i cluster identici, ma l’ombra geopolitica e la coerenza del tradecraft spingono comunque verso una lettura ad alta sofisticazione.

CVE-2026-22769: quando un appliance diventa un trampolino verso l’intero perimetro virtuale

La vulnerabilità CVE-2026-22769 viene descritta come un punto di rottura capace di abilitare compromissioni ad altissimo impatto, con condizioni operative favorevoli: attacco remoto, complessità bassa, e un risultato finale che si traduce in pieno controllo del sistema bersaglio. In un mondo in cui molte organizzazioni trattano gli appliance come “scatole nere” difficili da monitorare, una zero-day con CVSS 10.0 su un componente legato al disaster recovery e alla gestione di macchine virtuali diventa un moltiplicatore. La scoperta emerge da indagini su appliance con C2 attivo e con tracce che collegano le compromissioni a componenti malware già noti nel contesto di campagne precedenti. È un punto importante perché ribalta la narrativa più comoda: non si parla di un rischio teorico o di una falla potenzialmente sfruttabile, ma di un vettore già usato per entrare, restare e spostarsi.

SLAYSTYLE e l’ingresso via Apache Tomcat Manager: il dettaglio che fa collassare la sicurezza “di default”

Uno degli elementi più disturbanti del caso è la modalità di deployment della web shell SLAYSTYLE. L’operatività descritta passa da Apache Tomcat Manager, con richieste web ripetute e un’autenticazione che sfrutta credenziali di default dell’utente admin, recuperabili in file di configurazione come tomcat-users.xml. Quando un ambiente lascia esposto un Manager con credenziali predefinite, il confine tra zero-day e misconfiguration si fa sottile: la campagna sfrutta un mix in cui la vulnerabilità accelera l’impatto, ma l’igiene di configurazione può trasformare la compromissione in una corsia preferenziale. Il caricamento di un archivio WAR malevolo tramite l’endpoint di deploy permette a UNC6201 di ottenere un’esecuzione comandi con privilegi elevati, fino al contesto root. In quella fase, l’appliance non è più un dispositivo “di servizio”, ma un nodo sotto controllo attivo, pronto a essere usato come piattaforma di lancio verso altri segmenti. La scelta di una web shell in questo punto della catena è funzionale: consente gestione remota, flessibilità, e un canale che può essere ruotato o dismesso senza cambiare l’impianto generale dell’operazione.

Persistenza su script legittimi: convert_hosts.sh come firma operativa

La persistenza attribuita a UNC6201 non si appoggia solo al malware, ma a una pratica classica nelle campagne mature: modificare un componente legittimo affinché esegua ciò che l’attaccante desidera ogni volta che il sistema si avvia. Nel caso descritto, lo script convert_hosts.sh viene alterato e richiamato in fase di boot tramite rc.local, inserendo un percorso o un hook che garantisce l’esecuzione della backdoor. Questo tipo di persistenza ha un vantaggio evidente dal punto di vista offensivo: non richiede un servizio “strano” immediatamente visibile, non introduce per forza nuove unità di sistema, e può essere mascherata dentro un file che, in molte organizzazioni, nessuno controlla con continuità. Dal punto di vista difensivo, è un incubo operativo perché sposta l’attenzione dall’EDR tradizionale all’integrità di file e script di distribuzione, cioè a un tipo di telemetria che spesso manca sugli appliance.

🔴 OSSERVATORIO INTELLIGENCE: LIVE

Da BRICKSTORM a GRIMBOLT: perché la compilazione AOT in C# cambia la partita

Il salto tecnologico più interessante nella campagna è la transizione che, a settembre 2025, sostituisce i binari BRICKSTORM con GRIMBOLT. Non è un semplice rebrand. GRIMBOLT viene descritto come una backdoor scritta in C# che usa compilazione AOT nativa, con un risultato pratico doppio: da un lato aumenta la performance su risorse limitate tipiche degli appliance, dall’altro complica la vita a chi analizza, perché l’artefatto finale non si comporta come un comune assembly gestito. La compilazione AOT è una scelta che ha senso operativo in un ambiente di appliance. Riduce dipendenze runtime, rende più prevedibile l’esecuzione, e può aiutare in contesti dove il footprint deve restare contenuto. Ma soprattutto genera un effetto collaterale per chi difende: l’analisi statica diventa più ardua, e l’identificazione delle funzioni non è più immediata come nei classici campioni .NET. Se a questo si somma la presenza di packing, la finestra di tempo tra intrusione e comprensione tecnica dell’artefatto può allungarsi, con conseguenze dirette sulla risposta. GRIMBOLT viene associato a un comportamento da remote shell, con un canale di comando e controllo che riusa schemi di infrastruttura già visti con BRICKSTORM. Questa continuità è tipica delle campagne che evolvono senza cambiare totalmente la catena: si migliora il tool, si ottimizza l’operatività, ma si conserva ciò che funziona in termini di gestione del C2 e di procedure interne.

Ghost NICs: pivoting stealth in VMware senza lasciare il rumore atteso

Il passaggio più “da manuale avanzato” del caso UNC6201 è l’uso di Ghost NICs per pivotare dentro ambienti VMware. L’idea è semplice e, proprio per questo, potente: creare interfacce di rete temporanee che abilitano un pivoting stealth, riducendo la visibilità rispetto a tecniche più rumorose. Non è un dettaglio estetico, è una dichiarazione di intenti: l’obiettivo non è solo entrare nell’appliance, ma muoversi in un contesto virtuale dove il traffico interno, le reti logiche e i port group diventano l’autostrada per raggiungere asset ad alto valore. In ambienti dove la segmentazione esiste solo sulla carta, o dove la gestione delle reti virtuali è demandata a team separati dalla sicurezza, la creazione di NIC temporanee può passare come operazione amministrativa “strana ma non impossibile”. È esattamente quella zona grigia che gli attori avanzati cercano: attività sufficientemente plausibili da non far scattare un allarme immediato, ma abbastanza efficaci da aprire percorsi nuovi.

Single Packet Authorization con iptables: 443 come esca, 10443 come porta reale

Accanto ai Ghost NICs, UNC6201 impiega una tecnica di protezione del proprio accesso che assomiglia a un’operazione di “hardening offensivo”: usare iptables per implementare un meccanismo di Single Packet Authorization. Il modello descritto controlla traffico su porta 443, cerca specifiche stringhe HEX e, se la condizione è soddisfatta, concede per un tempo limitato l’accesso a una porta diversa, come 10443, spesso per circa 300 secondi. La logica è brutale nella sua efficacia: dall’esterno, la superficie appare normale, e il servizio reale resta chiuso a chiunque non conosca il “segnale” corretto. È una forma di furtività che non si limita a nascondere un processo, ma nasconde la porta stessa, rendendo più difficile anche il lavoro di scansione e di hunting basato su esposizioni. Questa scelta racconta che UNC6201 tratta l’appliance compromesso come un asset da proteggere. In altre parole, non è un attacco opportunistico che brucia l’accesso. È un’operazione che punta a durare, a mantenere un canale stabile e a ridurre la probabilità di essere espulsa.

Dell rilascia consigli: la corsa tra patch e ricerca di compromissioni pregresse

Dell rilascia remediation per la vulnerabilità, invitando i clienti a seguire l’advisory ufficiale. Ma il punto operativo più importante, in casi del genere, è che la patch non chiude automaticamente il passato. Se l’exploitation è attiva dalla metà del 2024, ogni organizzazione che aggiorna oggi deve porsi una domanda che spesso viene evitata: l’appliance è stato compromesso prima dell’update? In contesti di APT e cluster avanzati, l’aggiornamento può interrompere il vettore, ma non rimuove persistenza già installata, non cancella web shell già caricate, e non elimina modifiche a script di boot che continuano a eseguire componenti malevoli. Il tema diventa allora la ricerca di segnali concreti: tracce di richieste verso Tomcat Manager, presenza di archivi WAR non attesi, file in directory Tomcat che non dovrebbero esistere, e soprattutto l’integrità di script come convert_hosts.sh. È un lavoro che richiede un approccio forense sugli appliance, non solo un check di versione.

L’ombra di VMware: perché le campagne sugli hypervisor restano un trend dominante

Il caso UNC6201 si inserisce in una dinamica ormai chiara: gli attori avanzati vedono VMware come uno snodo strategico. Un hypervisor non è solo un sistema, è un luogo dove convergono credenziali, gestione, traffico interno e asset ad altissimo impatto. Un attore che ottiene pivoting credibile in quell’area può muoversi con una libertà che raramente esiste sui singoli endpoint. È anche per questo che tecniche come Ghost NICs e SPA su iptables hanno un significato più grande del singolo dettaglio tecnico: raccontano un investimento, una cultura operativa, e un obiettivo di lungo periodo. La campagna descrive un tradecraft che non cerca spettacolarità. Cerca embedding quieto, cioè stare dentro senza fare rumore, costruire accesso ridondante, e usare l’appliance come cerniera tra edge e core. La presenza di tool come SLAYSTYLE e l’evoluzione verso GRIMBOLT mostrano una strategia che non si limita al “backdoor e via”, ma punta a una piattaforma modulare, adatta ad ambienti dove le risorse sono limitate e dove la visibilità difensiva è spesso inferiore rispetto a server e workstation.

GRIMBOLT come segnale di maturità: prestazioni, offuscamento e continuità operativa

La scelta di una backdoor C# AOT su appliance racconta un livello di maturità preciso. Non è la strada più comoda. È la strada più adatta a un contesto in cui l’attaccante vuole massimizzare l’efficienza, ridurre la dipendenza da runtime e rendere più dura l’analisi. In questo, GRIMBOLT diventa un indicatore di come stiano cambiando i malware “da appliance”: meno script grezzi, più componenti progettati per durare e per adattarsi a sistemi embedded o semi-embedded. La sostituzione di BRICKSTORM con GRIMBOLT non va letta come un cambio estetico, ma come una risposta a due pressioni: la necessità di restare invisibili e la necessità di operare in modo stabile su risorse limitate. È un equilibrio che solo attori con buona ingegneria offensiva riescono a mantenere.

Cosa cambia davvero per chi difende

In un incidente come questo, il rischio non è solo che qualcuno “entri” oggi. Il rischio è che qualcuno sia entrato ieri e sia ancora lì. Per questo, l’ordine mentale corretto non è patch e fine. È patch, e poi verifica. Verifica della configurazione di Tomcat Manager, verifica dell’assenza di credenziali di default operative, verifica dell’integrità degli script di boot, verifica delle directory Tomcat, verifica dei comportamenti di rete anomali legati a porte come 443 e 10443, verifica di creazioni temporanee di NIC e di regole iptables non attese. Il caso UNC6201 è un promemoria netto: gli appliance edge e i componenti di recovery/virtualizzazione non possono essere trattati come “infrastruttura neutra”. Sono bersagli. E quando un cluster dimostra di saperci vivere dentro per mesi, il costo della sottovalutazione non è più un singolo server. È l’intero tessuto virtuale su cui gira l’azienda.