Fast16 e la guerra della percezione

Fast16 – Cyberwar • Sorveglianza • Infrastrutture di controllo

Fast16 interveniva in memoria durante l’esecuzione, non sui file su disco. L’alterazione era invisibile agli strumenti di verifica standard.

Fast16 – come funziona il malware?

Fast16 non modificava i file su disco. È la prima cosa da capire, e la più controintuitiva: un codice che non tocca il programma che infetta. Aspettava che il software venisse caricato in memoria, poi interveniva in tempo reale durante l’esecuzione, usando un motore di hook con 101 regole a livello di byte per riscrivere i calcoli mentre avvenivano. Il risultato sullo schermo mostrava pressioni insufficienti. La simulazione indicava che la reazione a catena non si sarebbe innescata. Il test sembrava fallire.

La fisica reale, nel frattempo, poteva raccontare tutt’altra storia.

Il framework risale al 2005. La scoperta è del 2026, vent’anni dopo. Per quasi due decenni ha dormito in un file su VirusTotal, catalogato senza essere compreso. Juan Andrés Guerrero-Saade di SentinelOne lo trovò nel 2019; ci volle l’intelligenza artificiale per decifrare cosa fosse progettato a fare. Il codice era costruito per resistere alla comprensione umana: la macchina virtuale Lua integrata predatava i primi campioni di Flame di tre anni, anticipava Stuxnet di almeno cinque. Quello che consideriamo l’alba della cyberwar offensiva era già in corso, silenziosamente, metodicamente, mentre il dibattito accademico cercava ancora di definire cosa fosse un’arma informatica.

Cos’è Fast16? Due architetture di inganno

Il parallelismo con Stuxnet è illuminante nelle differenze. Stuxnet accelerava le centrifughe iraniane oltre i limiti di sicurezza e alimentava agli operatori dati che mostravano tutto normale: distruzione fisica camuffata da funzionamento regolare. Fast16 invertiva la direzione del trucco — lasciava i dispositivi intatti e convinceva gli ingegneri che stessero fallendo quando forse stavano riuscendo.

Kim Zetter, nel reportage definitivo su Stuxnet, ricostruisce come l’operazione richiedesse un livello di conoscenza dell’impianto di Natanz che poteva provenire solo da intelligence umana sul campo. Fast16 aggiunge un ulteriore strato: chi scrisse il codice conosceva abbastanza della fisica delle testate da calibrare una soglia di attivazione sulla densità dell’uranio sotto implosione. I domini usati come server di comando e controllo per Stuxnet furono registrati nel novembre 2005; all’inizio del 2006 un test di prova fu condotto negli Stati Uniti e i risultati presentati al Presidente Bush. Se Fast16 era già attivo nella stessa finestra temporale — e i dati suggeriscono di sì — le due operazioni non erano parallele: erano componenti della stessa campagna.

Il filo verso la NSA

Nel 2016 e nel 2017, il collettivo Shadow Brokers pubblicò archivi sottratti all’Equation Group, un attore di minacce persistenti avanzate con connessioni documentate alla NSA. Tra i file divulgati, un documento chiamato “drv_list.txt” — quasi 250 KB di driver progettati per attacchi APT. Dentro quella lista: la stringa “fast16”. Il percorso PDB collega la fuga del 2017 con un modulo vettore Lua multi-modale compilato nel 2005 e, in ultima analisi, con il suo payload stealth: un driver kernel progettato per sabotaggio di precisione.

Fast16 arrivava con tre payload distinti: bytecode Lua per gestire configurazione, propagazione e logica di coordinamento; una ConnotifyDLL ausiliaria; il driver kernel fast16.sys. Progettato per elevarsi come servizio, distribuire l’impianto kernel, e propagarsi attraverso il Service Control Manager verso server di rete con credenziali deboli o predefinite, nell’ambiente Windows 2000/XP dell’epoca.

«Sbalorditivo», secondo Vikram Thakur di Symantec, il livello di competenza richiesto per costruire qualcosa di simile nel 2005. La parola è corretta ma incompleta. Il vero sbalordimento non è tecnico: è che un impianto di questa sofisticazione abbia dormito in un archivio pubblico per vent’anni prima che qualcuno capisse cosa fosse.

Architettura a tre strati: Lua per la logica, DLL ausiliaria, driver kernel per il sabotaggio in-memory. Fonte: SentinelOne Research.

Fast16 – Il mimetismo computazionale

Le orchidee del genere Ophrys non producono nettare. Imitano chimicamente i feromoni delle femmine di alcune specie di api, inducendo i maschi ad atterrare sul fiore nel tentativo di accoppiarsi. Il polline viene trasferito. L’ape non ottiene nulla. Il sistema funziona perché il segnale falso è indistinguibile dal segnale reale: non per qualità del segnale, ma perché il sistema ricevente non ha accesso alla fonte originale con cui confrontarlo.

Fast16 operava sulla stessa logica. Il codice non hackerava l’uranio. Produceva un segnale falso a livello di dato, costruito per essere indistinguibile dal segnale reale all’interno del sistema percettivo a cui era destinato: un ingegnere di fronte a uno schermo, con accesso alle simulazioni ma non alla fisica che quelle simulazioni erano tenute a rappresentare.

Baudrillard scriveva nel 1981 che la mappa precede il territorio, che la rappresentazione sostituisce il reale fino al punto in cui il reale stesso smette di essere il riferimento. Fast16 è la dimostrazione tecnica di questa tesi. Paul Virilio, negli stessi anni, teorizzava il trasferimento del controllo militare moderno dalla gestione dello spazio fisico alla gestione della percezione — «logistics of perception»: la capacità di controllare ciò che il nemico vede determina l’esito del conflitto prima che il conflitto abbia luogo. Fast16 è questa teoria applicata a un laboratorio di fisica nucleare. Non cyberwar nel senso corrente del termine — blackout, interruzione di sistemi, distruzione di infrastrutture — ma logistica della percezione applicata alla scienza.

L’anatomia del controllo invisibile

Natanz era un sistema chiuso, fisicamente isolato, con operatori specializzati, protocolli rigidi, ridondanze multiple. Eppure Fast16 l’ha attraversata e ha manipolato la percezione dei suoi ingegneri per anni, perché la complessità del sistema era al tempo stesso la sua forza operativa e la sua vulnerabilità epistemica: nessun ingegnere poteva tenere in testa l’intero stato del sistema, e tutti dovevano fidarsi degli strumenti di misurazione. Alterare la percezione della realtà di operatori competenti, dall’interno di sistemi di cui si fidano completamente, senza che se ne accorgano, è la forma di controllo più sofisticata disponibile.

I grandi aggregatori di dati contemporanei — Google, Meta, Amazon AWS, Microsoft Azure, Palantir, le piattaforme biometriche, i modelli linguistici di larga scala — sono sistemi di complessità ordini di grandezza superiori a una centrale nucleare. Nessun essere umano ne comprende l’intero stato, inclusi i loro stessi ingegneri. Tutti gli operatori devono fidarsi dei dashboard, delle metriche interne, degli strumenti di misurazione che il sistema stesso produce. Un sistema abbastanza complesso non può essere verificato dall’interno; la domanda che rimane sospesa è chi controlla i controllori quando i controllori sono già parte del sistema controllato.

Clearview AI ha costruito un database di oltre 50 miliardi di immagini facciali estratte senza consenso esplicito da piattaforme pubbliche; sistemi analoghi operano in Cina attraverso la rete di sorveglianza urbana, negli Emirati attraverso i sistemi aeroportuali. Il punto di vulnerabilità specifico non è il furto dei dati: è la corruzione dei modelli di addestramento. Un attore che introducesse sistematicamente associazioni errate nel dataset di training potrebbe produrre misidentificazioni mirate, invisibili agli operatori perché coerenti con la logica interna del modello. E questo non è un rischio ipotetico: i sistemi di riconoscimento facciale documentano già tassi di errore significativamente più alti su donne con pelle scura rispetto a uomini con pelle chiara. Nessuno ha programmato quella discriminazione. È emersa dai dati.

Quando un algoritmo di raccomandazione decide quali notizie vedi, quali contatti raggiungi più spesso, quali post arrivano alla tua rete e quali no, sta modificando la tua percezione della realtà con la stessa struttura operativa con cui Fast16 modificava i dati di pressione dell’uranio. L’operatore crede di avere accesso diretto al sistema. In realtà opera su una rappresentazione costruita per massimizzare metriche che non gli sono state comunicate, da un attore che non vede, per obiettivi che non coincidono con i suoi. Il 70% circa del cloud computing globale è concentrato in tre aziende private soggette alla giurisdizione statunitense e alle richieste delle agenzie di sicurezza tramite il CLOUD Act. Un governo che voglia accedere ai dati di un’organizzazione straniera che usa AWS non ha bisogno di hackerare AWS. Il parallelo con Fast16 è diretto: la compromissione non è visibile dall’esterno, il sistema funziona normalmente, i dati sembrano intatti. La differenza è che non si tratta di un attacco: quella è l’architettura.

Fast16 – La normalizzazione dell’invisibile

I visori di realtà aumentata — Apple Vision Pro, Meta Quest, le piattaforme enterprise di Microsoft — e i sistemi di interfaccia cervello-computer come Neuralink rappresentano un piano ulteriore di mediazione: non tra l’utente e l’informazione, ma tra l’utente e la realtà fisica percepita. Fast16 modificava la simulazione. Questi sistemi modificano ciò che vedi attraverso il visore che indossi. La logica è identica; la prossimità al corpo è radicalmente diversa.

Il problema che accomuna tutti questi piani è che nessuno di essi, preso singolarmente, appare come un sistema di controllo. Ognuno ha una giustificazione funzionale che suona ragionevole: la biometria semplifica l’accesso, la curazione algoritmica migliora la rilevanza, i modelli AI automatizzano decisioni complesse, il cloud riduce i costi infrastrutturali. La logica di Fast16 applicata alle infrastrutture di dati non è intuitivamente pericolosa: sembra normale, quotidiana, inevitabile. Ed è esattamente questa normalizzazione dell’invisibile che rende il controllo occulto attraverso le macro-infrastrutture di dati strutturalmente diverso da qualsiasi altra forma di potere che abbiamo imparato a riconoscere.

Vent’anni di silenzio

Fast16 è stato scoperto nel 2026. Per quasi vent’anni ha dormito in un archivio pubblico, accessibile a chiunque avesse saputo cosa cercare. Per anni prima della scoperta, un gruppo di ingegneri lavorava su simulazioni i cui output erano silenziosamente falsi. Non sapevano. Non potevano sapere: il codice modificava i dati in memoria senza toccare i file su disco, e verificarlo avrebbe richiesto eseguire calcoli indipendenti su un sistema completamente separato e non infetto, in un’epoca in cui nessuno sapeva che ci fosse qualcosa da verificare.

Se un sistema di sabotaggio progettato nel 2005 può dormire vent’anni in un archivio pubblico prima di essere identificato per quello che è, la domanda che rimane aperta riguarda i sistemi attivi adesso: i modelli su cui costruiamo diagnosi, valutazioni di rischio, identità digitali, decisioni finanziarie, relazioni sociali mediate. Quanti di questi sistemi elaborano dati che qualcuno, da qualche parte, ha già modificato in memoria — senza toccare i file su disco — in attesa che la densità superi la soglia giusta?

Post scriptum

Fast16 è stato identificato da Juan Andrés Guerrero-Saade di SentinelOne nel 2019, ma la sua natura e il suo scopo sono stati compresi solo nel 2026, con il supporto di strumenti di analisi assistita dall’intelligenza artificiale. Per quasi due decenni il file era rimasto su VirusTotal — una piattaforma pubblica — catalogato ma non decifrato. La scoperta ha richiesto la combinazione di competenza umana specializzata e capacità computazionale che nel 2005, quando il codice fu scritto, non esisteva.

Il codice anticipava Flame di tre anni e Stuxnet di almeno cinque. Questo significa che l’architettura della cyberwar offensiva moderna non è nata con Stuxnet, come spesso si racconta: era già operativa, e nessuno lo sapeva.

Guarda su YouTube ↗