Attore IA buca 600 FortiGate senza zero-day: l’errore è agghiacciante

Tra l’11 gennaio e il 18 febbraio 2026 un attore della minaccia potenziato dall’IA ha compromesso oltre 600 appliance FortiGate in più di 55 paesi, secondo quanto osservato da Amazon Threat Intelligence. La parte più inquietante non è il volume, né il fatto che l’operatore sia descritto come di lingua russa e motivato finanziariamente. Il punto vero è un altro: la campagna non si basa su una vulnerabilità “nuova” o su un exploit sofisticato. È un’operazione che vive di configurazioni di base, di interfacce di gestione esposte su Internet, di autenticazione a fattore singolo e di credenziali deboli o riutilizzate. L’IA, qui, non inventa un’arma inedita. Trasforma una serie di errori banali in una capacità industriale. Il risultato è un modello di cybercrime che nel 2026 diventa sempre più prevedibile: attori con skill “basse” riescono a produrre output da team strutturati, perché delegano a più provider di large language model la scrittura di script, la generazione di checklist operative e persino la costruzione di toolkit di ricognizione. È un salto di scala, non necessariamente un salto di qualità. Ma per le vittime conta soprattutto la scala.

Una campagna “senza CVE” che funziona perché l’igiene non regge

Amazon descrive un attore opportunistico che cerca bersagli fragili. Quando trova ambienti rinforzati, fallisce e passa oltre. Questo dettaglio è cruciale perché sposta la discussione dal mito dell’attaccante “geniale” alla realtà statistica: nel 2026 molti incidenti non accadono perché l’attore è straordinario, ma perché qualcuno ha lasciato aperta la porta principale. L’accesso iniziale avviene tramite porte di gestione esposte e autenticazione a singolo fattore, con scansioni su endpoint tipici come 443, 8443, 10443 e 4443. L’attore tenta credenziali riutilizzate e combina l’accesso con l’esfiltrazione di configurazioni FortiGate, che spesso contengono materiale di valore spropositato: credenziali, peer di VPN, topologie, regole firewall, indizi sulla segmentazione reale e su come un’organizzazione “pensa” la propria rete. È un attacco che non ha bisogno di bucare un firewall “con un exploit”. Gli basta sfruttare l’abitudine organizzativa più comune: trattare la gestione remota come un requisito operativo e non come un asset critico da isolare, hardenizzare e monitorare come un domain controller.

L’errore dell’attore: opsec pessima e infrastruttura lasciata “a vista”

Uno dei dettagli più utili, nella ricostruzione, è che Amazon trova infrastrutture dell’attore con file operativi accessibili: piani d’attacco generati da IA, configurazioni delle vittime, strumenti, codice sorgente e note di lavoro. È un fallimento di sicurezza operativa che, paradossalmente, aumenta la visibilità difensiva. In pratica, l’attore scala grazie all’IA ma si espone perché non sa gestire disciplina e compartmentalization. Questo aspetto è coerente con la valutazione complessiva: abilità di base bassa-media, capacità di problem solving creativo limitata, dipendenza elevata da “sequenze corrette” generate dai modelli. Funziona finché l’ambiente è standard e fragile; collassa quando serve debug, adattamento e pivot non banali.

L’IA come “sviluppatore principale” e il toolkit che rivela la mano dei LLM

Nel materiale analizzato emergono strumenti in Go e Python con segnali tipici di generazione assistita: commenti ridondanti, funzioni ripetitive, parsing ingenuo, stub e shim incompleti. Non sono framework eleganti. Sono strumenti “sufficienti” a fare quello che serve in massa. L’attore usa più LLM provider per compiti diversi: uno per scrivere script e parser, uno per produrre piani operativi e checklist, uno per adattare comandi a contesti specifici. Il passaggio più delicato è che l’attore, secondo la ricostruzione, invia anche topologie e dati delle vittime ai modelli per ottenere piani personalizzati. Questo introduce un tema laterale ma pesante: la sicurezza non è solo “non farsi bucare”, è anche evitare che le proprie configurazioni finiscano in workflow esterni, anche quando a farlo è l’attaccante. Nel flusso operativo, i tool automatizzano discovery e post-accesso: ingestiscono reti da tabelle di routing, classificano per dimensione, enumerano servizi, cercano host SMB, identificano domain controller, integrano scanner come Nuclei e producono liste prioritarie. È un modello di lavoro che assomiglia a una pipeline: acquisisci un foothold, raccogli contesto, generi target list, poi esegui un playbook di post-exploitation quasi standardizzato.

Dal FortiGate ad Active Directory, la catena che porta al ransomware passa dai backup

Il punto d’arrivo della campagna non è “il firewall” in sé. FortiGate è il ponte verso l’interno. Una volta ottenute configurazioni e accessi, l’attore conduce post-exploitation su Active Directory, estrae credenziali, tenta DCSync tramite moduli come mimikatz e passa a tecniche di movimento laterale come pass-the-hash, pass-the-ticket e relay NTLM con poisoning. Questa è la parte che, in molti incidenti moderni, precede il momento in cui la vittima “vede” l’attacco. L’attenzione verso l’infrastruttura di backup è un altro indicatore importante. Vengono citati target su Veeam Backup & Replication, con script PowerShell e tentativi di sfruttamento di vulnerabilità note, inclusi riferimenti a CVE come CVE-2019-7192, CVE-2023-27532 e menzioni di CVE-2024-40711. Ma la ricostruzione parla anche di fallimenti ripetuti contro servizi patchati o non applicabili, confermando il pattern: quando non entra con le scorciatoie, l’attore spesso non ha profondità tecnica per inventarsi un’alternativa. Si sposta su un altro bersaglio. Qui la logica è quella tipica del pre-ransomware: se controlli Active Directory e i backup, controlli la possibilità di ripristino. Anche senza “firmare” l’evento con un ransomware specifico, il comportamento è quello di chi prepara una monetizzazione.

Perché l’IA cambia il gioco anche quando l’attacco è “banale”

Questa campagna è un esempio perfetto di come l’IA abbassi le barriere per attori non sofisticati. Non rende improvvisamente tutti capaci di scrivere exploit kernel o bypassare hardening avanzato. Rende invece economico fare tre cose che prima richiedevano tempo e competenza: documentare il playbook, automatizzare la pipeline e replicare l’operazione su centinaia di target senza bruciarsi subito. La conseguenza è che la difesa “di base” torna a essere decisiva. Se un ambiente rinforzato respinge l’attore e lo costringe a spostarsi, allora la sicurezza non è più una gara a chi ha la migliore threat intel, ma a chi applica davvero le misure fondamentali in modo coerente.

Le difese che spezzano la scalabilità, non la singola intrusione

La lista delle contromisure citate nel testo ha un valore preciso: sono misure che non “fermano l’hacker”, ma interrompono la scalabilità. Se l’attore vive di MFA assente e gestione esposta, la priorità diventa togliere l’ossigeno a quel modello. Significa eliminare l’esposizione diretta delle interfacce di gestione, forzare autenticazione multi-fattore, imporre igiene credenziali e ridurre il riuso, applicare patch e configurazioni hardening sui dispositivi perimetrali, segmentare la rete per impedire che un accesso al perimetro diventi immediatamente un accesso al dominio, e soprattutto proteggere i backup come se fossero un obiettivo primario, non un “servizio interno”. Amazon, nella ricostruzione, parla anche di condivisione di indicatori e azioni di disruption. Ma l’elemento più utile resta l’osservazione empirica: l’attore fallisce contro ambienti rinforzati. È un dato che riduce l’ansia e aumenta la responsabilità, perché dimostra che le difese “noiose” funzionano ancora, proprio nel momento in cui l’IA rende l’attacco più veloce e più replicabile. Nel 2026, questa è probabilmente la lezione più concreta: l’IA sta facendo crescere l’offensiva in ampiezza, ma non sta cancellando il valore dell’hardening. Sta solo punendo più duramente chi non lo fa.