Fast16 sabotava simulazioni nucleari prima di Stuxnet con hook su LS-DYNA e AUTODYN

Fast16 emerge come uno dei più sofisticati strumenti di sabotaggio informatico pre-Stuxnet progettati per alterare simulazioni di armi nucleari senza distruggere file, bloccare sistemi o generare segnali evidenti di compromissione. Il malware prendeva di mira software specialistici come LS-DYNA e AUTODYN, intervenendo sulle simulazioni di detonazioni ad alto esplosivo e sul comportamento dell’uranio sotto compressione estrema. L’analisi tecnica mostra un framework sviluppato già dal 2005, circa due anni prima dell’attivazione di Stuxnet, con una logica operativa molto diversa dai malware distruttivi tradizionali. Fast16 incorporava un binario di servizio con macchina virtuale Lua 5.0, un driver di filesystem avviato al boot e un motore di hook basato su regole capace di riscrivere sequenze di istruzioni estremamente specifiche dentro una singola applicazione target. Il sabotaggio non si attivava in modo generico ma solo quando la simulazione raggiungeva condizioni compatibili con una detonazione nucleare a implosione. Il malware controllava infatti la densità del materiale simulato e attivava il tampering solo oltre 30 grammi per centimetro cubo, soglia che l’uranio raggiunge sotto compressione d’urto. Questa selettività mostra un livello di conoscenza profondo dei processi di progettazione nucleare e trasforma Fast16 in un’arma informatica concepita per corrompere la fiducia nei risultati scientifici.

La scoperta del framework Fast16 conferma un sabotaggio pre-Stuxnet

SentinelOne ha pubblicato la prima analisi pubblica di Fast16 nell’aprile 2026 mentre il team Threat Hunter di Symantec ha esaminato il motore di hook confermando i target applicativi e la natura del sabotaggio. Il framework consisteva in un service binary, una macchina virtuale Lua 5.0 incorporata, un driver di filesystem boot-start e un hook engine guidato da regole. Il driver creava un filtro kernel del file system capace di monitorare tutti gli accessi ai file e intercettare in modo selettivo gli eseguibili caricati dal disco. Il malware attendeva il lancio di EXPLORER.EXE e poi analizzava file con estensione .EXE compilati con il compilatore Intel, riconosciuti attraverso la stringa “Intel” nell’header PE. Quando il file veniva letto in memoria, il motore applicava patch on-the-fly solo se trovava sequenze di opcode corrispondenti ai pattern previsti. La tabella interna conteneva 101 regole di byte-pattern, ciascuna progettata per riconoscere una sequenza di istruzioni precisa e inserire hook verso codice malevolo in una sezione .xdata iniettata.

LS-DYNA e AUTODYN diventano i bersagli delle simulazioni alterate

I principali bersagli di Fast16 erano LS-DYNA e AUTODYN, due software utilizzati per simulazioni fisiche complesse, impatti, modellazione dei materiali, esplosioni e fenomeni ad alta pressione. Questi programmi vengono impiegati in molti ambiti legittimi, dalla sicurezza automobilistica alla progettazione industriale, ma possono anche essere usati per simulazioni avanzate di detonazioni e comportamento dei materiali sotto shock. Fast16 non colpiva ogni solver di dinamica esplicita compilato con Intel Fortran a precisione singola. Le regole individuate corrispondevano invece a versioni specifiche di LS-DYNA e AUTODYN, segno di un targeting molto ristretto. Il malware inseriva hook solo in sequenze di istruzioni collegate alle simulazioni di shock ad alta pressione e non interferiva con calcoli generici, crash test o modellazione ordinaria. Gli attaccanti avevano creato gruppi di regole differenti per build diverse del software, dimostrando un monitoraggio continuo degli aggiornamenti dei target. Questa manutenzione costante indica un’operazione sostenuta nel tempo, progettata per mantenere efficacia anche dopo modifiche e nuove release dei programmi scientifici usati dai laboratori colpiti.

Il motore di hook applica patch selettive durante la lettura dal disco

Il driver di Fast16 funzionava come filtro SCSI e monitorava l’accesso ai file prima che gli eseguibili venissero caricati definitivamente in memoria. Quando rilevava un file .EXE compilato con strumenti Intel, l’hook engine confrontava il contenuto con le 101 regole di byte-pattern integrate nel malware. Alcune regole, come la 46 e la 47, catturavano sequenze floating-point x87 molto specifiche e le sostituivano con chiamate verso un gestore iniettato. Le sequenze individuate includevano operazioni come salvataggi e caricamenti di valori floating-point, moltiplicazioni e riferimenti a indirizzi assoluti. Questo livello di precisione impediva l’attivazione casuale del malware su applicazioni non desiderate. Fast16 applicava il patching solo durante la lettura del file dal disco e manteneva l’intercettazione in memoria, evitando modifiche permanenti facilmente rilevabili sull’eseguibile originale. Il codice malevolo veniva collocato in sezioni dati iniettate e utilizzato soltanto quando la simulazione attraversava condizioni fisiche compatibili con detonazioni high-explosive. Tutte le evidenze indicano che il tool fosse progettato per manipolare simulazioni nucleari e non per eseguire spionaggio generico.

Fast16 attiva il tampering solo oltre 30 grammi per centimetro cubo

Il tratto più rivelatore di Fast16 riguarda il controllo sulla densità del materiale simulato. Il malware attivava il tampering solo quando il valore superava 30 g/cm³, una soglia estremamente significativa nelle simulazioni di uranio sottoposto a compressione d’urto. In condizioni ordinarie l’uranio non raggiunge quel valore, ma durante un dispositivo nucleare a implosione gli esplosivi ad alto potenziale generano una pressione tale da comprimere il nucleo verso densità molto superiori a quelle normali. La compressione riduce la fuga di neutroni e aumenta la probabilità di fissione a catena, rendendo critico il calcolo della supercriticalità. Fast16 interveniva proprio su questi valori, alterando output legati alla pressione, allo stress tensoriale e al comportamento sotto shock. Il malware ignorava simulazioni ordinarie e si attivava esclusivamente durante run complete di blast transitorio e detonazione. Questa condizione selettiva dimostra che gli attaccanti conoscevano non solo il software ma anche il significato fisico dei parametri manipolati. Il risultato era un sabotaggio invisibile che falsava i modelli senza interrompere l’esecuzione delle simulazioni.

Il Meccanismo A altera gli output nelle simulazioni ad alta pressione

Fast16 utilizzava tre strategie di sabotaggio distinte, indicate come Meccanismo A, Meccanismo B e Meccanismo C. Il Meccanismo A si attivava al primo e al sedicesimo raggiungimento del punto di hook restituendo semplicemente il controllo al programma, probabilmente per mantenere una fase iniziale di calibrazione o evitare anomalie immediate. Nelle esecuzioni successive, se il valore di input della simulazione si collocava tra 30 e 65, il malware riduceva gli output al 10 per cento del valore normale e manteneva la riduzione nel tempo. Questa manipolazione non produceva un errore evidente o un crash dell’applicazione ma generava risultati scientificamente alterati. Gli utenti del software vedevano simulazioni apparentemente valide, ma i dati prodotti descrivevano un comportamento fisico non corrispondente alla realtà. La scelta di intervenire solo in una finestra di valori così precisa rafforza l’ipotesi di un targeting contro scenari nucleari specifici. Il malware non cercava rumore operativo ma un effetto strategico: indurre progettisti e ricercatori a fidarsi di dati sbagliati.

Il Meccanismo B colpisce LS-DYNA e riduce il tensore di stress

Il Meccanismo B era progettato specificamente per LS-DYNA e controllava la selezione dell’Equation of State utilizzata nella simulazione. Il codice verificava condizioni associate ai modelli Jones-Wilkins-Lee e ad altri modelli impiegati per esplosivi ad alto potenziale, tra cui valori di selezione 2, 3 e 7. Se la condizione risultava soddisfatta e alcuni attributi della simulazione raggiungevano cinque volte il valore iniziale, Fast16 modificava i valori del tensore di Cauchy stress, intervenendo su componenti come sig_xx, sig_yy e sig_zz. La riduzione arrivava fino all’1 per cento del valore reale quando la densità del materiale raggiungeva 30 g/cm³. Il malware non applicava però una caduta improvvisa, ma calcolava una pendenza graduale per arrivare all’1 per cento nel momento in cui la densità raggiungeva 60 g/cm³. Questa progressività rendeva l’alterazione meno evidente durante l’analisi dei risultati. Il modello prodotto indicava una compressione del materiale maggiore di quella reale, distorcendo la valutazione della risposta dell’uranio alla detonazione.

Il Meccanismo C prende di mira AUTODYN con scale diverse di pressione

Il Meccanismo C era invece orientato verso AUTODYN e controllava la presenza di valori associati a modelli come EOS Ideal Gas, JWL e Lee-Tarver, rispettivamente indicati nei dati come 3, 5 e 11. Il codice verificava anche la presenza della stringa “$Loading co” in memoria, ulteriore indicatore di una simulazione coerente con il target previsto. Anche in questo caso l’azione partiva solo quando un attributo della simulazione raggiungeva cinque volte il valore iniziale.

A seconda della variante e della versione del software, Fast16 scalava valori di output come la pressione a tassi differenti. In una build la riduzione portava i valori al 42 per cento del reale quando la densità arrivava a 60 g/cm³. In un’altra versione il valore scendeva al 10 per cento verso 40 g/cm³, mentre altre build applicavano riduzioni al 10 per cento verso 47 g/cm³ e all’8 per cento verso 48 g/cm³. La simulazione non doveva necessariamente raggiungere la densità finale, perché la pendenza veniva calcolata in anticipo. Questo schema mostra un adattamento continuo del malware alle versioni di AUTODYN utilizzate dalle vittime.

Le build multiple mostrano un’operazione sostenuta per anni

Gli esperti hanno identificato fino a dieci build distinte di Fast16, con gruppi di regole dedicate a versioni differenti di LS-DYNA e AUTODYN. Le 101 regole di hook risultano suddivise in circa 9-10 gruppi, ciascuno compatibile con una specifica build del software target. Questo dato è cruciale perché indica un’operazione mantenuta nel tempo, non un singolo esperimento isolato. Gli attaccanti seguivano gli aggiornamenti dei programmi di simulazione e modificavano il framework per conservare la capacità di sabotaggio dopo cambiamenti nel codice compilato. Una simile attività richiedeva accesso a versioni aggiornate dei software, competenze di reverse engineering, conoscenze fisiche sulle simulazioni high-explosive e capacità di sviluppo kernel-level su Windows. Fast16 appare quindi come un’arma informatica strategica costruita per interferire con processi scientifici altamente specializzati. La sua esistenza anticipa molti elementi concettuali poi associati a Stuxnet, ma con un obiettivo diverso: non distruggere centrifughe o impianti industriali, bensì corrompere silenziosamente il processo decisionale basato su simulazioni.

Fast16 si propaga nella rete target ma resta confinato all’ambiente interno

Fast16 si installava attraverso un file denominato svcmgmt.exe capace di supportare diverse modalità operative. Il malware creava un servizio chiamato SvcMgmt e un driver denominato fast16.sys configurato come componente boot-start. Prima di propagarsi, controllava l’assenza di 18 chiavi associate ad antivirus o soluzioni EDR nel registro di sistema. La diffusione avveniva all’interno della rete target tramite enumerazione di share e tecniche di impersonazione, ma senza tentativi di uscire verso Internet o reti esterne. Questa scelta operativa è molto significativa perché suggerisce un ambiente bersaglio isolato, probabilmente compatibile con reti di laboratorio o infrastrutture di ricerca sensibili. Il malware non puntava a massimizzare infezioni globali ma a raggiungere e mantenere una presenza in un perimetro specifico. La persistenza derivava dalla combinazione tra driver avviato al boot e servizio automatico, mentre il sabotaggio rimaneva dormiente fino alla comparsa delle condizioni applicative e fisiche previste. Fast16 era quindi progettato per operare in silenzio, evitare esposizione esterna e modificare soltanto calcoli critici nel momento esatto in cui diventavano rilevanti.

Il targeting nucleare emerge dalla fisica della compressione dell’uranio

Il targeting di Fast16 emerge con forza dalla scelta della soglia di 30 g/cm³ e dalla manipolazione di pressione e stress durante simulazioni di detonazione. Nelle armi nucleari a implosione, gli esplosivi ad alto potenziale disposti attorno al nucleo generano un’onda di pressione che comprime l’uranio. Questa compressione riduce la dispersione neutronica e aumenta la probabilità che il materiale raggiunga condizioni supercritiche. Fast16 altera proprio i valori usati per valutare questa transizione, modificando pressione termodinamica, tensori di stress e comportamento sotto shock. I ricercatori che utilizzavano software compromessi potevano quindi ottenere stime errate sulla compressione necessaria per innescare una reazione nucleare. La manipolazione non produceva risultati casuali ma una distorsione coerente, orientata a far apparire il materiale più comprimibile o più vicino a determinate condizioni operative di quanto fosse nella realtà. Questa precisione rende il malware un esempio raro di sabotaggio computazionale applicato alla fisica delle armi, in cui il dato alterato diventa l’arma principale.

Il sabotaggio delle simulazioni può ritardare o deviare la ricerca nucleare

Le conseguenze operative di Fast16 riguardavano la fiducia nei risultati delle simulazioni. Il tampering produceva output falsati che indicavano una compressione maggiore del reale a parità di densità, con effetti particolarmente critici quando il materiale simulato raggiungeva circa 33 g/cm³. I progettisti nucleari che si affidavano a quei modelli potevano ricevere dati inaccurati sulla pressione, sulla comprimibilità e sulla supercriticalità del materiale. In uno scenario di ricerca avanzata, errori di questo tipo possono ritardare programmi, indirizzare test verso configurazioni sbagliate o indurre conclusioni tecniche fuorvianti. Fast16 non cancellava documenti, non cifrava sistemi e non mostrava messaggi. Operava invece sul livello più delicato: l’affidabilità del risultato scientifico. Questa caratteristica lo rende molto più difficile da scoprire rispetto a un malware distruttivo tradizionale. Gli attaccanti hanno aggiornato il framework nel tempo per mantenere efficacia contro nuove versioni di LS-DYNA e AUTODYN, costruendo un sabotaggio persistente e difficile da attribuire.

Fast16 anticipa la guerra informatica contro i processi fisici critici

Fast16 rappresenta uno dei primi esempi noti di tool progettato per corrompere simulazioni fisiche critiche in ambito nucleare. Prima ancora che Stuxnet mostrasse al mondo la possibilità di sabotare impianti industriali attraverso codice malevolo, questo framework dimostrava già una logica di guerra informatica orientata ai processi fisici. Il bersaglio non era l’infrastruttura visibile ma la rappresentazione computazionale della realtà. Alterando i parametri delle simulazioni, il malware poteva compromettere decisioni scientifiche, valutazioni progettuali e risultati sperimentali senza lasciare segni immediati. La presenza di componenti sviluppati dal 2005, la macchina virtuale Lua 5.0, il driver kernel, le build multiple e il targeting selettivo contro LS-DYNA e AUTODYN delineano un’operazione di altissima specializzazione. Fast16 non fu soltanto un malware avanzato ma un prototipo di sabotaggio strategico contro la conoscenza tecnica. La sua analisi mostra che la cybersecurity dei sistemi scientifici non riguarda soltanto la protezione dei dati ma anche l’integrità dei modelli, dei risultati e delle simulazioni su cui si fondano decisioni tecnologiche e militari.