Volt Typhoon e l’arte di scomparire: vivere di OT, log scarsi e tanta pazienza

Dall’intervento di Stefano Maccaglia, Director of Incident Response e Red Team di NetWitness, alla 14ª Cyber Crime Conference (Roma, Auditorium della Tecnica, 6-7 maggio 2026).

Quando un avversario sceglie il silenzio come strategia, la difesa deve cambiare grammatica. È la tesi con cui Stefano Maccaglia, alla guida dell’Incident Response globale di NetWitness, ha chiuso una delle sessioni più tecniche della prima giornata della 14ª Cyber Crime Conference, portando in sala un caso poco raccontato di compromissione attribuita a Volt Typhoon: un attacco mirato al cuore della logistica navale just-in-time europea, condotto senza malware visibile, senza rumore di rete e con un obiettivo netto, restare dentro il più a lungo possibile.

Il team di Maccaglia, lo ricordiamo, affonda le radici nelle attività di IR nate nel 2011 in seguito al breach di RSA Security ed è oggi specializzato nelle investigazioni di cyber espionage e cyber crime di matrice sofisticata, in particolare quelle riconducibili ad attori state-sponsored.

Volt Typhoon, un attore che non improvvisa

Volt Typhoon, ricondotto con elevata confidenza al perimetro del cyber espionage cinese, è oggi uno degli attori più problematici a livello globale per chi gestisce infrastrutture critiche. La sua firma operativa, ha sintetizzato Maccaglia, poggia su tre pilastri:

• living-off-the-land (LOTL), ovvero lo sfruttamento di file eseguibili, applicazioni e strumenti già presenti nei sistemi della vittima;
• compromissione di supply chain e di partner terzi a basso presidio di sicurezza;
• persistenza prolungata e pre-positioning in vista di possibili azioni disruptive

L’obiettivo non è quasi mai l’azione immediata contro il target finale. È, piuttosto, il posizionamento. Da qui un dwell time tipicamente molto ampio, tracce volutamente esigue sugli endpoint e movimenti laterali al limite della soglia di visibilità.

Maccaglia ha insistito su un punto culturale prima ancora che tecnico: questo attore non improvvisa. Studia in modo metodico le debolezze sociali, organizzative e di IT del bersaglio, mappa il personale chiave, modella i propri orari operativi sui working hours della vittima, e solo dopo si attiva, aprendo varchi nelle aree meno presidiate. È un comportamento, ha osservato, che lo rende riconoscibile rispetto agli attori attualmente molto attivi nello stesso teatro mediorientale: a diffenza degli iraniani, ad esempio, che sono piuttosto rumorosi, Volt Typhoon è invisibile.

La firma operativa: LOTL, fileless, tunnel cifrati

La toolchain di Volt Typhoon, sul piano tecnico, è coerente con quanto rilevato dalle principali agenzie occidentali. Le tecniche fileless, con esecuzione in memoria, sono il tratto distintivo: PowerShell, WMI, .NET assemblies eseguiti senza scrittura su disco, con largo uso di LOLBin come rundll32, mshta, certutil, regsvr32, msiexec. A questo si aggiunge l’utilizzo opportunistico di software di gestione remota legittimi che gli attaccanti trovano già installati negli ambienti compromessi, AnyDesk, ScreenConnect, Atera, e che riconoscono immediatamente come scorciatoia operativa: non li installano, li ereditano.

Sul piano del traffico, l’attore predilige tunnel SSL e canali cifrati che si confondono nel normale HTTPS aziendale, anche per attraversare segmentazioni di rete. L’esfiltrazione, dove esiste, si appoggia in modo elegante a servizi commerciali comuni come AWS o Dropbox, scegliendo di volta in volta lo stack meno appariscente sul perimetro della vittima. Non si tratta di una scelta programmata a tavolino: è una scelta opportunistica, fatta sul campo, in funzione di ciò che l’attaccante trova disponibile e poco monitorato.

I precedenti: dalle infrastrutture critiche USA a Guam

Maccaglia ha richiamato due casi-scuola ormai documentati anche dalle autorità statunitensi.

Il primo è la compromissione di infrastrutture critiche statunitensi nel 2023, con bersagli nei comparti power grid e trasporto marittimo continentale. In quel contesto, la persistenza è stata realizzata in modo emblematico direttamente sui router SOHO presenti nelle filiali periferiche delle organizzazioni colpite. Apparati di piccolo cabotaggio, tipicamente non patchati: i bollettini di vendor come D-Link, ha osservato Maccaglia con una battuta, vengono letti da pochi e implementati da ancora meno. La periferia non presidiata diventa così l’anticamera dell’infrastruttura, mentre il data center, crown jewel di qualunque programma di sicurezza, viene volutamente evitato.

Il secondo caso è la compromissione del comparto telco di Guam (2023), dove l’attaccante ha sfruttato vulnerabilità in apparati Fortinet (CVE-2022-42475 e CVE-2023-27997) all’epoca non ancora pienamente note, in particolare sui VPN concentrator, per poi muoversi con tecniche LOTL e mantenere persistenza tramite strumenti legittimi di amministrazione e VPN come Ngrok e SoftEther.

In entrambi i casi, l’obiettivo non è stato condurre azioni di sabotaggio. È stato il pre-positioning: prepararsi a poterle eventualmente condurre, in uno scenario futuro di tensione geopolitica.

Il caso “Navalog”: Volt Typhoon contro la logistica navale just-in-time

Il cuore dell’intervento è stato dedicato a un caso più recente, su cui il team NetWitness è stato chiamato direttamente. Il nome dell’azienda è di fantasia (“Navalog Industries”), ma il contesto è netto: un operatore europeo specializzato nella logistica navale just-in-time, ovvero l’orchestrazione end-to-end delle spedizioni di componenti per grandi progetti industriali. Il cliente finale, in questo caso, era un cantiere impegnato nella costruzione di corvette per una Marina Militare europea, non italiana.

Il modello just-in-time è esso stesso il vero punto di leva. L’operatore logistico aggrega in una vista unica timeline di produzione, waypoint portuali, dipendenze tra fornitori, identità dei project manager e dei liaison di cantiere. Compromettere Navalog ha significato per Volt Typhoon ottenere ciò che il cantiere stesso non avrebbe potuto offrire altrettanto comodamente: una vista consolidata dei movimenti rilevanti del programma navale senza mai dover toccare un bacino di carenaggio.

Le fasi dell’attacco

La kill chain ricostruita da NetWitness ricalca con precisione il playbook tipico dell’attore.

1. Ricognizione mirata. L’attaccante ha studiato a lungo Navalog, mappandone persone, processi di sicurezza e tecnologie difensive prima di muovere il primo passo.
2. Phishing mirato a un contractor. Le mail sono state inviate separatamente alle tre persone del team di manutenzione del fornitore di Navalog, con contenuti credibili nella lingua locale, evidentemente raffinati con l’ausilio di strumenti di generazione automatica del testo.
3. Portale fasullo. L’infezione iniziale non è passata da un malware allegato, ma da un portale clonato a immagine e somiglianza di quello legittimo dell’azienda. Le credenziali, una volta inserite, hanno consentito l’esecuzione in memoria di un payload temporaneo per la raccolta delle credenziali stesse.
4. Pivot in Navalog con credenziali valide. Dal contractor, con credenziali ottenute, l’attaccante è entrato nell’intranet dell’operatore logistico.
5. Network scanning. L’unica vera “rumorosità” della catena: l’assenza, nell’azienda vittima, di un livello adeguato di visibilità di rete sul segmento locale ha permesso che gli scan non fossero rilevati.
6. Movimenti laterali in stile LOTL e tunnel via PowerShell. Da qui, accessi a sistemi adiacenti, configurazione di tunnel di rete con script PowerShell.
7. Persistenza con script AutoSSL. Un driver dedicato all’attivazione di un tunnel SSL, abbinato a chiavi di registro, ha rappresentato il meccanismo di persistenza chiave. Lo stesso oggetto era già stato osservato in precedenti investigazioni NetWitness e ha costituito la “pistola fumante” per l’attribuzione a Volt Typhoon.
8. Accesso al sistema ERP, cuore della logistica just-in-time.
9. Esfiltrazione in piccoli batch verso bucket AWS, con traffico modellato per assomigliare a normale comunicazione cloud e vendor.

Cosa cercava davvero

Una volta nell’ERP, Volt Typhoon non ha eseguito query massive né dump di interi database. Ha lavorato con interrogazioni mirate, ricostruite poi con certezza dai log applicativi, volte a estrarre informazioni circoscritte: tempistiche dei componenti destinati al prototipo navale e delle prove in mare, waypoint di porto e transito, mappe dei pattern di rifornimento just-in-time, responsabilità di filiera dei project manager e dei liaison di cantiere, struttura delle integrazioni tra l’ERP di Navalog e i sistemi di progetto del cantiere.

In sintesi, ha osservato Maccaglia, l’efficienza just-in-time di Navalog si era trasformata, agli occhi dell’avversario, in un just-in-time targeting dataset: una “vista a pannello unico” su tempi, esposizioni e dipendenze critiche del programma navale, utilizzabile per comprenderne e, se necessario, condizionarne il ritmo.

Significativamente, l’attore ha potuto in qualunque momento sabotare l’ERP, anche solo alterando poche righe, e bloccare per mesi il progetto. Non lo ha fatto. Ha scelto il silenzio.

L’investigazione: ricostruire a ritroso, talvolta al buio

Il modo in cui Maccaglia ha raccontato l’investigazione è forse il segmento più istruttivo per i CISO in sala. Il team è entrato a partire da un finding applicativo, accessi non autorizzati all’ERP, e da lì ha lavorato all’indietro lungo la catena.

Il percorso, ricostruito a ritroso a partire dai log di audit dell’ERP, è passato per:

• sessioni sospette ed elevazioni di ruolo su account ad alti privilegi;
• correlazione con i log di sicurezza Windows sui front-end dell’ERP e sui jump host, dove sono stati identificati nuovi profili locali, logon laterali con credenziali riusate e attività di service account fuori dagli orari attesi;
• sessioni SSL anomale verso AWS, mappate come canale di esfiltrazione;
• analisi dei log di firewall e perimetro, che ha condotto al team del contractor come punto di ingresso nell’intranet di Navalog;
• recupero (parziale) delle mail di phishing in casa del contractor. Il portale fasullo, nel frattempo, non era più attivo.

La scelta di non muovere niente

Un passaggio centrale, e non scontato, è la richiesta di NetWitness al cliente di mantenere l’ambiente in quiete operativa per circa 48 ore prima di avviare qualunque azione di containment. La logica, ha spiegato Maccaglia, è duplice: contro un attore come Volt Typhoon, agire troppo presto significa perdere visibilità senza eliminarlo davvero, e una remediation informata vale più di una remediation veloce. “Quando lo conosci, puoi prevedere quello che fa”, ha citato l’esempio classico di Sun Tzu, applicandolo al threat hunting.

Il vero ostacolo: il gap dei log di PowerShell

Il punto su cui Maccaglia è tornato più volte, anche con tono autocritico verso il settore, è la cronica mancanza di logging adeguato su PowerShell. Volt Typhoon ne è perfettamente consapevole: la sua persistenza si appoggia massicciamente a script PowerShell e a invocazioni di shellcode in memoria, sfruttando API come NtCreateSection, NtMapViewOfSection, UuidFromStringA e EnumSystemLocalesA per iniettare codice in processi legittimi quali dllhost.exe e per attivare i tunnel di esfiltrazione.

Nel caso Navalog, su parte dei sistemi adiacenti all’ERP, i log di esecuzione PowerShell erano presenti, ma il contenuto effettivo dei comandi mancava. Lo Script Block Logging non era stato abilitato ovunque, o lo era stato troppo tardi.

Per chi voglia colmare il gap, Maccaglia ha richiamato i canali e gli event ID rilevanti:

• canali Microsoft-Windows-PowerShell/Operational e Windows PowerShell in Event Viewer;
• 4103, Module Logging, su moduli e cmdlet invocati;
• 4104, Script Block Logging, che cattura il testo dei blocchi di script eseguiti;
• 4105 / 4106, comando avviato e completato;
• 4688, process creation nel log Security, con la command line quando configurata.

L’assenza di questi log ha costretto NetWitness, in alcuni passaggi della kill chain, a lavorare per ipotesi: TTP noti dell’attore, percorsi tipici di recon AD/ERP e sequenza degli artefatti pre e post-gap. È, ha riconosciuto Maccaglia, una delle ragioni per cui l’AI difensiva attuale, da sola, non è in grado di investigare un attore di questo profilo: senza visibilità e senza guida umana, semplicemente non vede.

Lezioni apprese: non si previene, si gestisce

La sintesi finale è netta: Volt Typhoon non si previene, si gestisce. Non perché sia invincibile, ma perché agisce in spazi, supply chain terze, provider commerciali, apparati di periferia, su cui l’organizzazione vittima non ha piena giurisdizione né potere di controllo. Anche con il supporto delle autorità, ottenere dati da un provider terzo nei tempi utili a una response efficace resta estremamente complesso, e quando ci si arriva l’attaccante si è già spostato.

Quello che si può, e si deve, fare è applicare in modo serio i controlli sulla propria infrastruttura. Maccaglia li ha riassunti in tre punti:

• Behavioral detection dove conta. Con Volt Typhoon non si cerca malware, si cerca il cambiamento inatteso: nuovi profili, attività di service account fuori orario, role change sospetti, esecuzioni PowerShell senza contesto.
• Segmentazione e visibilità OT. Ispezionare i protocolli ICS, applicare il principio del minimo privilegio, riconoscere quando un server di update o un fornitore terzo prova ad andare oltre il proprio perimetro logico.
• “Don’t trust, inspect.” La supply chain non è solo codice o firmware a monte: a volte entra dalla porta principale, con credenziali valide e in pieno orario d’ufficio.

Il filo conduttore è epistemico più che tecnologico: tanto meglio si conosce ciò che “dovrebbe esserci” nella propria rete, tanto prima si nota ciò che non dovrebbe. Quando la strategia dell’avversario è mimetizzarsi e aspettare, la chiarezza non è un lusso, è la condizione minima della difesa.

A questo, ha aggiunto Maccaglia, va affiancato qualcosa che in molte organizzazioni manca ancora: playbook mirati e specifici per scenari di advanced persistent threat su perimetri ibridi IT/OT. L’azienda vittima del caso Navalog, ha sottolineato, non era impreparata sul piano tecnologico, ma operava senza un playbook dedicato. Ed è precisamente questo, oggi, il delta che separa una difesa reattiva da una difesa governata.