Il sabotaggio cyber-fisico non è nato a Natanz nel 2010. SentinelOne Labs ha svelato FAST16, un sofisticato framework del 2005 (collegato ai leak della NSA di ShadowBrokers) capace di alterare silenziosamente i calcoli scientifici in tempo reale. Utilizzando un driver kernel (fast16.sys) e un motore alimentato da Lua, il malware non distruggeva i sistemi, ma iniettava errori infinitesimali nelle simulazioni di ingegneria nucleare e strutturale. Questa scoperta anticipa di anni le tecniche di Stuxnet e rivela un livello di maturità offensiva finora insospettabile per la metà degli anni Duemila.
Cosa leggere
SentinelOne Labs scopre FAST16 e collega il malware ai leak ShadowBrokers
SentinelOne Labs analizza due file compilati nel 2005: svcmgmt.exe, datato 30 agosto 2005, e fast16.sys, datato 19 luglio 2005. Il campione era stato caricato su VirusTotal già intorno al 2005 ma, ancora nel 2025, riceveva solo una rilevazione a bassa confidenza. Il dettaglio decisivo arriva dal percorso PDB contenuto nel carrier: C:\buildy\driver\fd\i386\fast16.pdb. Questo riferimento consente agli analisti di collegare il malware al nome fast16 comparso nei leak ShadowBrokers del 2017. Il collegamento trasforma un campione apparentemente isolato in una possibile componente di un toolkit offensivo statale. Nei leak di ShadowBrokers, il nome fast16 appare nella lista drv_list.txt dei componenti TeDi legati a Territorial Dispute, accompagnato dalla stringa di evasione Nothing to see here – carry on. Questa coincidenza tecnica e nominale permette di collocare il framework in un contesto operativo molto più ampio. FAST16 non era un malware generico, ma un sistema modulare pensato per operazioni di sabotaggio silenzioso.
FAST16 usa svcmgmt.exe e fast16.sys per operare a livello kernel
Il framework FAST16 era composto da più componenti con funzioni distinte. Il carrier svcmgmt.exe agiva come wrapper, servizio Windows e loader di bytecode Lua 5.0, mentre il driver fast16.sys operava come filesystem driver boot-start di classe SCSI. Il sistema includeva anche svcmgmt.dll, utilizzata per funzioni di reporting utente. Questa architettura mostra un livello di ingegneria molto avanzato per il 2005, soprattutto considerando l’uso di una macchina virtuale Lua crittografata all’interno del payload.
Il carrier supportava diverse modalità operative. Senza argomenti funzionava come servizio Windows, con il parametro -p gestiva l’installazione, mentre con -i o -r eseguiva bytecode Lua. Poteva inoltre agire come wrapper per generare processi child. Il driver fast16.sys esponeva i device object \Device\fast16 e ??\fast16, usava DeviceType 0xA57C e disabilitava Windows Prefetcher per ridurre le tracce. Le stringhe API erano offuscate tramite XOR e risolte dinamicamente in ntoskrnl.exe.
FAST16 sfrutta Lua e condivisioni Windows per diffondersi nelle reti
La propagazione di FAST16 avveniva tramite un piccolo wormlet basato su SCM, il Service Control Manager di Windows. Il malware copiava payload su condivisioni di rete sfruttando API di controllo servizi e password amministrative deboli, in particolare su sistemi Windows 2000 e Windows XP. Questa capacità wormabile consentiva al framework di diffondersi in ambienti aziendali e laboratori senza richiedere exploit sofisticati, sfruttando piuttosto configurazioni deboli e credenziali riutilizzate. Il sistema includeva anche un kill-switch denominato ok_to_install, progettato per verificare la presenza di prodotti antivirus noti. Il controllo analizzava chiavi di registro associate a soluzioni come Symantec, Sygate e ZoneAlarm, interrompendo l’installazione se rilevava protezioni incompatibili o rischiose. Questa logica dimostra attenzione operativa e capacità di deconfliction. FAST16 non cercava la massima diffusione indiscriminata, ma un’infezione controllata e compatibile con obiettivi specifici.
Driver fast16.sys intercetta NTFS FAT e MRxSMB per alterare eseguibili
Il cuore tecnico di FAST16 risiedeva nel driver fast16.sys, capace di agganciare funzioni filesystem critiche. Il driver intercettava IRP_MJ_CREATE, IRP_MJ_READ, IRP_MJ_CLOSE e Fast I/O su dispositivi NTFS, FAT e MRxSMB. In questo modo poteva osservare e modificare dinamicamente l’accesso ai file, incluso il caricamento di eseguibili specifici. L’intervento avveniva a livello kernel, rendendo il comportamento estremamente difficile da rilevare con strumenti di sicurezza tradizionali dell’epoca.
Il patching si attivava solo dopo l’avvio di explorer.exe, un dettaglio che riduceva il rischio di instabilità durante il boot e permetteva al malware di operare in una fase più prevedibile del ciclo di sistema. Il driver cercava esclusivamente file .EXE contenenti metadati del compilatore Intel C/C++ subito dopo l’ultimo section header. Questa selettività rivela una conoscenza profonda dei toolchain scientifici e ingegneristici utilizzati nei target previsti.
FAST16 applica 101 regole di patching per sabotare calcoli scientifici
Il meccanismo di sabotaggio di FAST16 si basava su un motore di patching con 101 regole di pattern matching. Il codice iniettava sezioni .xdata e .pdata copiate dall’originale e applicava sostituzioni tramite wildcard e flag di stato. Un dispatch array da 256 byte ottimizzava il processo, permettendo al driver di individuare pattern specifici negli eseguibili target e modificarli in memoria. L’obiettivo non era bloccare i programmi, ma alterarne il comportamento matematico.
Una regola particolarmente rilevante iniettava una sequenza FPU capace di scalare valori in tre array interni. Questo introduceva errori sistematici nei calcoli in virgola mobile, con effetti potenzialmente devastanti su simulazioni scientifiche, modellazione fisica e analisi ingegneristiche. Il sabotaggio non causava crash evidenti e non modificava in modo permanente i file su disco. Le applicazioni continuavano a funzionare, ma producevano risultati alterati. Questa è la caratteristica che rende FAST16 un precursore diretto dei cyber-physical attack moderni.
LS-DYNA PKPM e MOHID emergono come possibili target del sabotaggio
SentinelOne Labs identifica tre probabili target del framework FAST16 nel contesto del 2005: LS-DYNA 970, PKPM e MOHID. LS-DYNA era utilizzato per simulazioni complesse, incluse modellazioni legate ad armi e fisica nucleare. PKPM era una suite CAD impiegata nell’ingegneria strutturale cinese. MOHID era invece utilizzato per modellazione idrodinamica in ambito portoghese. La scelta di questi target suggerisce un’operazione orientata a settori scientifici, militari e infrastrutturali. Il sabotaggio di questi strumenti poteva generare conseguenze molto diverse da un’infezione tradizionale. Errori silenziosi nei calcoli potevano ritardare programmi di ricerca, compromettere verifiche di sicurezza, alterare simulazioni ingegneristiche o produrre decisioni tecniche basate su dati falsati. Il danno non sarebbe stato immediatamente riconducibile a un malware. Questo modello offensivo dimostra una strategia più sofisticata del semplice furto di informazioni: manipolare la fiducia nei risultati computazionali.
FAST16 anticipa Stuxnet e Flame nella storia delle armi cibernetiche
La cronologia di FAST16 è uno degli elementi più rilevanti della ricerca. Il framework risale a luglio-agosto 2005, quindi precede Stuxnet di almeno cinque anni. Inoltre, l’uso di una VM Lua 5.0 embedded anticipa di circa tre anni i primi campioni noti di Flame, altro malware sofisticato associato a operazioni statali. Questo colloca FAST16 in una fase molto precoce dello sviluppo di strumenti cyber offensivi avanzati. La presenza di marcatori SCCS/RCS suggerisce sviluppatori con background Unix o militare, mentre l’architettura modulare richiama pratiche mature di ingegneria software. FAST16 mostra che già a metà degli anni Duemila esistevano strumenti capaci di combinare propagazione, evasione, patching kernel-level e sabotaggio fisico indiretto. La scoperta ridimensiona l’idea secondo cui Stuxnet avrebbe rappresentato l’inizio assoluto del sabotaggio cyber-fisico. Più probabilmente, Stuxnet rese visibile una capacità già esistente.
ShadowBrokers permette di ricostruire il ruolo storico di fast16
Il riferimento a fast16 nei leak ShadowBrokers del 2017 è decisivo perché offre una traccia esterna al campione analizzato. Nei file trapelati, il nome compare all’interno della documentazione di componenti driver, indicando che il tool era noto, catalogato e probabilmente integrato in un arsenale più ampio. La stringa di evasione associata al nome suggerisce anche un intento operativo: nascondere, minimizzare o mascherare la presenza del componente durante attività di deconfliction. La corrispondenza tra il percorso PDB del malware e la voce nei leak consente a SentinelOne Labs di contestualizzare FAST16 come parte di un programma strutturato di sviluppo offensivo. Questo non significa necessariamente ricostruire ogni operazione in cui il framework sia stato usato, ma fornisce una base tecnica forte per collegarlo a un ecosistema statale. Il valore della scoperta sta proprio nella convergenza tra reverse engineering, campioni storici e riferimenti emersi da leak successivi.
FAST16 dimostra il rischio del sabotaggio software invisibile
La caratteristica più inquietante di FAST16 è la sua capacità di produrre sabotaggio invisibile. Il malware non puntava a cifrare file, rubare dati o distruggere sistemi in modo evidente. Interveniva invece sui calcoli, modificando risultati scientifici e ingegneristici in modo silenzioso. In un ambiente di simulazione, questo può essere più pericoloso di una compromissione manifesta, perché l’utente continua a fidarsi dell’output prodotto dal software. Questa logica offensiva colpisce il cuore della sicurezza dei sistemi cyber-fisici. Le decisioni su strutture, modelli idrodinamici, componenti industriali o scenari nucleari dipendono dalla correttezza delle simulazioni. Se il software genera risultati falsati ma plausibili, l’errore può propagarsi lungo tutta la catena decisionale. FAST16 mostra che la manipolazione dell’integrità computazionale era già una priorità offensiva nel 2005, ben prima della piena consapevolezza pubblica del problema.
Regole YARA e analisi retroattiva aiutano a rilevare FAST16
La ricerca di SentinelOne Labs include regole YARA per individuare carrier, driver e binari target potenzialmente patchati. Questo consente attività di rilevamento retroattivo su archivi malware, repository storici e collezioni di software scientifici dell’epoca. L’analisi retrospettiva è fondamentale perché tool come FAST16 possono restare invisibili per decenni, soprattutto se progettati per operare senza generare crash o indicatori evidenti di compromissione. Le organizzazioni che usano o conservano software di simulazione storici dovrebbero verificare integrità binaria, hash, sezioni anomale e possibili modifiche in memoria. Particolare attenzione va posta a driver filesystem non documentati, hook kernel e alterazioni nei flussi di caricamento degli eseguibili. Il caso FAST16 dimostra l’importanza di preservare campioni vecchi e rianalizzarli con strumenti moderni. Molte operazioni avanzate possono emergere solo anni dopo, quando nuovi leak o nuove tecniche forensi permettono di leggere segnali rimasti nascosti.
FAST16 riscrive la cronologia dei cyber-physical attack
FAST16 obbliga a rivedere la storia delle armi cibernetiche. Prima di Stuxnet, prima della piena esposizione di Duqu e prima dell’attenzione pubblica sui sabotaggi industriali, esisteva già un framework capace di alterare software scientifici a livello kernel. La combinazione di Lua, driver filesystem, patching selettivo e target ingegneristici mostra una maturità tecnica sorprendente per il 2005. Non si trattava di esperimento grezzo, ma di una capacità operativa avanzata. La scoperta suggerisce che la storia nota dei cyber-physical attack sia solo la parte visibile di un percorso più lungo. Gli strumenti pubblicamente emersi negli anni successivi potrebbero essere stati preceduti da framework meno noti, usati in operazioni mirate e rimasti sepolti in archivi malware. FAST16 non è soltanto un reperto tecnico, ma una prova storica del fatto che il sabotaggio software di precisione era già una realtà a metà degli anni Duemila.
SentinelOne Labs apre nuove domande sulle operazioni rimaste nascoste
Le conclusioni di SentinelOne Labs descrivono FAST16 come un precursore silenzioso dello statecraft cibernetico moderno. Il framework era modulare, wormabile e chirurgicamente preciso. La capacità di alterare calcoli in virgola mobile senza provocare crash immediati dimostra una conoscenza profonda dei toolchain Intel, dei sistemi Windows e degli ambienti scientifici target. È una forma di sabotaggio pensata non per farsi notare, ma per contaminare risultati e decisioni. La ricerca invita la comunità a contribuire con binari target patchati, campioni storici e ulteriori evidenze per ricostruire l’impatto completo del framework. FAST16 chiude un capitolo sconosciuto della storia cibernetica, ma apre una domanda ancora più ampia: quante operazioni simili restano nascoste in archivi dimenticati, repository privati o collezioni malware non rianalizzate? Il caso dimostra che il passato della cybersecurity è ancora incompleto e che nuove scoperte possono modificare radicalmente la comprensione delle minacce moderne.
Iscriviti alla Newsletter
Non perdere le analisi settimanali: Entra nella Matrice Digitale.
Matrice Digitale partecipa al Programma Affiliazione Amazon EU. In qualità di Affiliato Amazon, ricevo un guadagno dagli acquisti idonei. Questo non influenza i prezzi per te.
