Come un attore potenziato dall'IA ha violato oltre 600 dispositivi FortiGate senza alcun exploit

Tra l'11 gennaio e il 18 febbraio 2026, un attore di lingua russa con motivazioni finanziarie ha compromesso più di 600 appliance firewall FortiGate in oltre 55 paesi — e lo ha fatto senza sfruttare una singola vulnerabilità del prodotto. Amazon Threat Intelligence, che ha pubblicato l'indagine il 20 febbraio 2026, afferma che l'attore ha individuato interfacce di gestione esposte a Internet sulle porte 443, 8443, 10443 e 4443 ed è entrato con password comunemente riutilizzate su account privi di autenticazione a più fattori. Le configurazioni dei dispositivi che ha estratto contenevano credenziali SSL-VPN con password recuperabili, credenziali amministrative, policy del firewall e topologia di rete. Modelli linguistici di grandi dimensioni commerciali sono stati impiegati durante l'operazione, scrivendo strumenti di ricognizione e redigendo piani di attacco; secondo il resoconto di un altro ricercatore che ha trovato il server dell'attore stesso, un modello era anche configurato per eseguire comandi offensivi. Questo incidente è una voce in the Orca AI Incident Archive, che contiene il registro completo, le sue fonti e la sua classificazione, insieme ai casi vicini della serie.

Cosa ha riportato Amazon e come lo ha scoperto

Il rapporto, "Un attore di minaccia potenziato dall'IA accede su larga scala ai dispositivi FortiGate", è attribuito a CJ Moses, CISO di Amazon Integrated Security, ed è stato pubblicato sull'AWS Security Blog il 20 febbraio 2026. La sua prima constatazione sostanziale è negativa: "Non è stato osservato alcun sfruttamento delle vulnerabilità di FortiGate". L'accesso iniziale è stato sempre basato su credenziali — una scansione sistematica delle interfacce di gestione sulle quattro porte sopra indicate, seguita da tentativi di autenticazione con credenziali comunemente riutilizzate.

Ciò che ha reso visibile la campagna è stata la sicurezza operativa dell'attore stesso. Amazon afferma di aver identificato l'infrastruttura che ospitava gli strumenti malevoli tramite attività di threat intelligence di routine, e che lo stesso server conteneva piani d'attacco generati dall'IA, configurazioni delle vittime e il codice sorgente di strumenti personalizzati, memorizzati senza crittografia. Tale negligenza ha offerto ad Amazon una visione quasi completa della metodologia. "È come una catena di montaggio alimentata dall'IA per il cybercrime", si legge nel rapporto.

I file di configurazione rubati costituiscono il perno per passare dall'appliance alla rete che si trova dietro di essa. Secondo Amazon, contengono credenziali utente SSL-VPN con password recuperabili, credenziali amministrative, la topologia di rete completa e le informazioni di routing, policy firewall che rivelano l'architettura interna e configurazioni peer VPN IPsec. L'attore ha scritto script Python assistiti dall'AI per analizzarli, decifrarli e organizzarli.

Il post-exploitation, nelle parole di Amazon stessa

Una volta all'interno, l'attore ha seguito un percorso standard e ben documentato. La sua documentazione operativa, scritta in russo, descrive l'uso di Meterpreter con il modulo mimikatz per eseguire attacchi DCSync contro i controller di dominio ed estrarre hash di password NTLM da Active Directory. In compromissioni confermate ha ottenuto database completi delle credenziali di dominio. Amazon nota almeno un caso in cui l'account Domain Administrator utilizzava una password in testo in chiaro che era stata riutilizzata dalla configurazione FortiGate oppure era indipendentemente debole.

Da lì, le tecniche documentate sono pass-the-hash e pass-the-ticket contro ulteriori infrastrutture, NTLM relay tramite strumenti di poisoning standard ed esecuzione remota di comandi su host Windows. L'attore ha preso di mira specificamente i server Veeam Backup & Replication con script PowerShell, strumenti di decrittazione compilati e tentativi contro vulnerabilità note di Veeam — un comportamento che Amazon descrive come "coerente con operazioni pre-ransomware", sebbene il rapporto non registri la distribuzione di ransomware.

Le note dell'attore fanno riferimento a diverse CVE, tra cui CVE-2019-7192, CVE-2023-27532 e CVE-2024-40711. BleepingComputer, che ha trattato il rapporto il 21 febbraio 2026, identifica la prima come una vulnerabilità di esecuzione di codice da remoto di QNAP e le ultime due come problemi di Veeam. Nessuna di esse è stata la via d'ingresso. Ancora più indicativo, le stesse note registrano ripetuti fallimenti: servizi già corretti, porte chiuse, exploit che non si applicavano al sistema operativo di destinazione. Per una vittima confermata, la valutazione dell'attore stesso concludeva che l'infrastruttura chiave era "ben protetta" e priva di "vettori di sfruttamento vulnerabili".

Due limiti dell'attribuzione meritano di essere dichiarati chiaramente. Amazon afferma che l'attore "non risulta associato ad alcun gruppo di minaccia persistente avanzata dotato di risorse sponsorizzate da Stati" e che non è stato osservato alcun coinvolgimento dell'infrastruttura AWS nella campagna.

Dove l'IA era effettivamente situata

Il resoconto di Amazon sul layer AI è specifico riguardo ai ruoli ma silenzioso sui prodotti. L’attore ha utilizzato almeno due distinti fornitori commerciali di LLM, secondo il rapporto: uno come sviluppatore primario degli strumenti, pianificatore degli attacchi e assistente operativo, e un secondo come pianificatore supplementare quando l’attore aveva bisogno di aiuto per spostarsi all’interno di una particolare rete. In un caso osservato, l’attore ha inviato una topologia interna completa — indirizzi IP, nomi host, credenziali confermate e servizi identificati — e ha chiesto un piano dettagliato passo dopo passo per raggiungere sistemi che i suoi strumenti esistenti non potevano toccare.

Le prove di Amazon che gli strumenti siano stati scritti da una macchina sono di natura stilistica più che forense. Elenca commenti ridondanti che si limitano a ripetere i nomi delle funzioni, un'architettura che investe più nella formattazione dell'output che nella funzionalità, JSON analizzato tramite corrispondenza di stringhe anziché una corretta deserializzazione, e shim di compatibilità con stub di documentazione vuoti. Gli strumenti funzionavano per il caso ristretto dell'attore e fallivano ai margini. Il volume, osserva Amazon, normalmente implicherebbe un team di sviluppo; qui proveniva da un solo attore o da un gruppo molto piccolo.

Ciò che il rapporto AWS non contiene è alcun fornitore di modelli, alcun nome di prodotto e alcun riferimento al Model Context Protocol. Questi compaiono in un secondo studio pubblicato il giorno successivo.

Il server, e i nomi che Amazon non ha pubblicato

Il 21 febbraio 2026 il blog di sicurezza Cyber and Ramen ha pubblicato la propria analisi di una directory aperta su 212.11.64[.]250:9999, ospitata su AS4264 (Global-Data System IT Corporation, Zurigo) — uno dei due indirizzi che Amazon elenca come infrastruttura di threat actor. Il ricercatore ha contato 1.402 file in 139 sottodirectory, inclusi backup di configurazione FortiGate rubati, dati di mappatura di Active Directory, dump di credenziali, template di scansione Nuclei e strumenti di estrazione delle credenziali Veeam, oltre a due cartelle intitolate a Claude contenenti oltre 200 file di output delle attività, diff di sessione e stati dei prompt in cache.

In quell'analisi vengono nominati due componenti personalizzati. ARXON è descritto come un server Python Model Context Protocol che acquisisce le attività di ricognizione relative a ciascun target, chiama DeepSeek per generare piani di attacco e mantiene una knowledge base che cresce con ogni target; include inoltre script per la creazione in batch, tramite SSH, di account VPN FortiGate e per la validazione delle credenziali Domain Admin. CHECKER2 è un orchestratore basato su Go e Docker per la scansione parallela delle VPN, con log che mostrano 2.516 target in 106 paesi. Il ricercatore afferma che non è stato possibile trovare riferimenti pubblici a nessuno dei due strumenti, il che indica che entrambi sono stati realizzati per questa operazione.

La stessa analisi descrive un'esposizione di dicembre 2025 dello stesso server, questa volta contenente una copia di HexStrike, un framework MCP offensivo open source, e un file di impostazioni .claude che aveva pre-autorizzato Claude Code a eseguire gli strumenti Impacket, Metasploit e hashcat contro credenziali di dominio hardcoded appartenenti a un dipendente di una grande azienda mediatica asiatica. Entro febbraio, secondo il ricercatore, l'attore era passato da quel punto di partenza open source ad ARXON e CHECKER2 — una progressione di circa otto settimane.

BleepingComputer ha riportato questi risultati in un aggiornamento al suo articolo del 21 febbraio. La distinzione è importante: ARXON, CHECKER2, DeepSeek e Claude Code sono l'interpretazione del ricercatore dei file, dei log e delle impostazioni presenti in una directory non protetta. Amazon, che aveva accesso indipendente alla stessa infrastruttura, non ne ha nominato nessuno. Nessun fornitore di modelli ha confermato nulla di tutto ciò.

Che cosa è stabilito, che cosa si basa su un'unica fonte

Tre affermazioni poggiano su due parti indipendenti. Il post sul blog di Fortinet del 6 marzo 2026, «Attacks at the Speed of AI», afferma che Fortinet «non ha osservato alcuno sfruttamento delle vulnerabilità di FortiGate» e che la campagna è riuscita tramite porte di gestione esposte e credenziali deboli con autenticazione a singolo fattore, usando password spraying. Ciò corrobora il meccanismo di Amazon dal lato del fornitore, senza che nessuna delle due parti abbia visto le prove pubblicate dall'altra.

Amazon è l'unica fonte per la scala — più di 600 dispositivi, più di 55 paesi, la finestra gennaio-febbraio — e per il profilo dell'attore: di lingua russa, motivato finanziariamente, base tecnica da bassa a media, ampia dipendenza dall'IA, profondità post-sfruttamento limitata, sicurezza operativa inadeguata. Nessuna terza parte ha riportato la cifra di 600.

Cyber e Ramen da soli costituiscono la fonte per gli strumenti denominati, i fornitori di modelli, i conteggi dei file e i 2.516 target di scansione. I suoi stessi documenti probatori hanno confermato compromissioni presso un'azienda industriale del gas in Asia-Pacifico, un fornitore di telecomunicazioni in Turchia e l'azienda media dell'esposizione di dicembre, con attività di ricognizione che facevano riferimento a Corea del Sud, Egitto, Vietnam e Kenya — un insieme di vittime confermate in almeno cinque paesi, ben lontano dai 55 citati da Amazon. I due numeri misurano cose diverse e nessuno dei due è stato riconciliato pubblicamente.

La risposta di Fortinet, e la portata che non ha confermato

Il post di Fortinet, scritto da Carl Windsor e datato 6 marzo 2026, concorda con Amazon sul meccanismo e diverge sulla portata. "Secondo l'indagine e il monitoraggio di Fortinet, pochi clienti sono stati colpiti da questo attacco", si legge. "Siamo nel processo di notifica a quelle organizzazioni." Non conferma 600 dispositivi, non adotta il conteggio dei Paesi di Amazon e non nomina l'attore.

La tesi di Fortinet è che la tecnica sia vecchia e l'automazione nuova: password spraying contro dispositivi edge scarsamente protetti, ora guidato da conversazioni basate su prompt senza codice. Afferma che l'attacco "sarebbe stato impossibile con MFA in essere" e "molto improbabile che riuscisse" con una policy di complessità delle password abilitata. Ha inoltre pubblicato indicatori: accesso amministrativo da 212[.]11.64[.]250 o 185[.]196.11[.]225, la creazione di account denominati fortiuser, fortinet-support o fortinet-tech-support, configurazioni VPN o utenti inattesi, e script pianificati per l'esecuzione come meccanismo di persistenza.

Questa è una divergenza di portata, non una disputa sul fatto che la campagna sia avvenuta. Nessuno dei nominati nel verbale contesta l'intrusione; l'archivio la classifica A, senza alcun contrassegno di contestazione, e registra danni reali.

Cosa è cambiato in seguito

Non esiste alcuna CVE e alcuna patch, perché non c'era alcuna vulnerabilità. La correzione è a livello di configurazione, ed entrambe le organizzazioni sono giunte alla stessa lista. Amazon afferma di aver condiviso indicatori di compromissione con i partner pertinenti, di aver collaborato con partner del settore e di aver aiutato le organizzazioni ad adottare misure che hanno ridotto l'efficacia dell'attore; il rapporto non fornisce il numero di organizzazioni notificate. Fortinet afferma di notificare direttamente i clienti interessati.

La guida tecnica è coerente in entrambi i casi: rimuovere l'accesso amministrativo dalle interfacce esposte a Internet e gestirlo tramite un percorso interno o fuori banda; applicare l'MFA all'accesso amministrativo e VPN; applicare la complessità delle password; ruotare le credenziali SSL-VPN su qualsiasi appliance la cui interfaccia di gestione sia stata o possa essere stata raggiungibile; verificare il riutilizzo delle password tra gli account VPN FortiGate e Active Directory; e isolare l'infrastruttura di backup, applicarvi le patch e conservare copie immutabili.

Per il rilevamento, Amazon indica l’attività DCSync (Event ID 4662 con GUID relativi alla replica), nuove attività pianificate denominate in modo da imitare servizi Windows legittimi, connessioni insolite di gestione remota da pool di indirizzi VPN, artefatti di avvelenamento LLMNR e NBT-NS e accessi non autorizzati agli archivi delle credenziali di backup. Avverte inoltre che il rilevamento basato sulle firme ha un valore limitato in questo contesto, perché gli strumenti sono costruiti a partire da utility open source legittime — Impacket, gogo, Nuclei — che compaiono in normali test di penetrazione.

Perché il record è una pietra miliare

L'archivio la contrassegna come una voce fondamentale, e la ragione è visibile nel contrasto tra ciò che l'attore ha ottenuto e ciò che l'attore era in grado di fare. Un singolo operatore o un gruppo molto ristretto, valutato con un livello di competenza da basso a medio, ha condotto intrusioni simultanee in decine di paesi, ha prodotto un kit di strumenti che normalmente implicherebbe un team di sviluppo e ha generato piani di attacco per singolo obiettivo abbastanza rapidamente da mantenere più intrusioni attive contemporaneamente.

Lo stesso rapporto fornisce il limite massimo. L’attore non era in grado di compilare exploit personalizzati, non poteva eseguire il debug dei tentativi di sfruttamento falliti e non sapeva improvvisare quando un piano si imbatteva in un bersaglio rafforzato — così è passato ad altro invece di persistere. Il suo codice generato dall’AI si rompeva ai margini. Le sue note operative sono un registro di servizi sottoposti a patch e porte chiuse. Ciò che i modelli hanno rimosso è stato il lavoro, non il giudizio: ricognizione, parsing, documentazione e pianificazione sono state automatizzate; le parti che richiedevano adattamento sono rimaste fuori portata.

Ecco perché anche le domande aperte sono noiose e specifiche. Quante organizzazioni Fortinet abbia effettivamente notificato risolverebbe la discrepanza tra "pochi clienti" e più di 600 dispositivi. Un secondo esame della directory ARXON, indipendente dal ricercatore che l'ha scoperta, chiarirebbe quali fossero gli strumenti e quali modelli venissero chiamati. Fino ad allora, la documentazione sostiene una conclusione solida sul metodo e una molto più debole sulla portata.