L’agente AI ha scelto la vulnerabilità e tentato l’exploit da solo. Le violazioni riuscite erano manuali
8 min di lettura
Il 30 luglio 2026 Unit 42, il centro di threat intelligence di Palo Alto Networks, pubblica un rapporto a firma di Andy Piazza che documenta un ciclo d’attacco condotto da un’intelligenza artificiale: enumera bersagli, sceglie una vulnerabilità, scarica l’exploit e tenta lo sfruttamento senza che un operatore intervenga passo per passo. Titolo testuale: «Chinese-Speaking Threat Actor Harnesses AI Models for Autonomous Cyberattacks».
Chi, con cosa, comandato come
L’attore, di lingua cinese, opera sotto gli alias knaithe e KnYuan. Unit 42 lo colloca a Zhuhai, in Cina, sulla base della sua attività pubblica su GitHub — in particolare 1DayNews, una pipeline che aggrega segnalazioni di vulnerabilità da 17 fonti, le filtra con DeepSeek e distribuisce gli avvisi via Telegram. Il rapporto lo descrive come «opportunistic exploit operator and self-described binary security researcher».
Per la campagna offensiva ha usato DeepSeek come motore di ragionamento, orchestrato dal framework open-source Hermes Agent di NousResearch: terminale, comando e controllo via Telegram, e “skill” personalizzate — tra cui godmode, per il jailbreak dell’LLM, già integrata nel framework. Completava l’impianto un server open-source (FofaMap) collegato a FOFA, la piattaforma di enumerazione degli asset esposti su internet, con un traduttore da linguaggio naturale a query FOFA. L’attore ha testato marginalmente anche Claude Code e Codex, ma solo per verifiche di connettività o proxy, mai come motore d’attacco — «consistent with evaluating the AI-market to identify their preferred tool set», secondo Unit 42.
Quello che l’AI ha fatto da sola — e dove si è fermata
Da un’unica sessione recuperata, del 7 maggio 2026 (Unit 42 precisa di non aver recuperato altro input dell’operatore oltre al compito iniziale), il rapporto ricostruisce il ciclo passo per passo. DeepSeek ha scaricato da GitHub un exploit pubblico per CVE-2026-33017 (Langflow, CVSS 9.8), enumerato 84 istanze via FOFA e trovato un bersaglio vulnerabile — ma l’attacco non è partito: mancava una precondizione di configurazione. Il modello lo ha scritto da solo: «All three Langflow need public flow ID but no auto_login — stuck. […] Search for larger-scale vulns.» Senza che nessuno glielo chiedesse, ha cercato un bersaglio più promettente: rassegna di dieci famiglie di prodotti, ricerca su GitHub dei PoC più popolari, scelta di n8n — «looks extremely promising!» —, con FOFA che confermava 647.017 istanze nel mondo, 25.209 in Cina. Ha incatenato due CVE (CVE-2026-21858, lettura file arbitraria, CVSS 10.0, e CVE-2025-68613, bypass sandbox a esecuzione di codice, CVSS 9.9), campionato un centinaio di IP cinesi, trovato tre bersagli vulnerabili — e si è fermato di nuovo: i moduli richiedevano un’autenticazione che l’exploit non prevedeva. «These forms have auth enabled. Let me check other targets», ha scritto, prima di scandagliare altri cinquanta bersagli senza risultato.
È una distinzione che il rapporto tiene separata, ed è bene tenerla tale anche qui: gli attacchi riusciti — esfiltrazione da tre organizzazioni via Citrix NetScaler (CVE-2026-3055, CVSS 9.8), comandi eseguiti su 11 istanze Marimo Notebook (CVE-2026-39987), reverse shell tentati su 9 server Apache Tomcat e 3 endpoint VPN IKE — sono catalogati come campagna manuale, con «conventional workflows», non come prodotto dell’agente autonomo. Fra i bersagli manuali, un ente governativo malese colpito «over multiple days with memory grooming parameters». In tutto, fra autonomo e manuale, l’attore ha tentato di colpire oltre 460 bersagli — Unit 42 avverte inoltre di aver trovato tracce di sfruttamento su un numero imprecisato di altri host, elencati in un file che l’attore ha cancellato prima dell’analisi: i numeri confermati sono un pavimento, non un tetto.
Sulla conclusione, Unit 42 è netta: «Although these autonomous campaigns did not achieve full compromise of any of their intended targets» — il ciclo autonomo non ha violato nulla, nella sessione osservata — «the margin of failure was narrow»: a fermarlo sono state precondizioni di configurazione del bersaglio, non un limite del modello. «Targets with weaker default configurations would have been susceptible». La capacità era piena e funzionante da capo a fondo; il bersaglio, per una volta, era configurato meglio dell’aggressore.
Il modello più permissivo, e chi invece ha retto
Sul perché la scelta sia caduta su DeepSeek, Unit 42 resta nella valutazione, non nel fatto accertato: «the actor selected a model with minimal safety controls (DeepSeek) accessed through an open-source framework with no client-side restrictions. The actor attempted to use Western models, but their provider-side controls likely limited their effectiveness for autonomous attacks. This likely led the actor to select the most permissive model for their campaign.»
Sul lato opposto, la parte che completa il quadro e che non va lasciata fuori: «Our colleagues at OpenAI were able to confirm that their provider-side safeguards refused requests that violated their policies. They also confirmed that continued attempts led their safety systems to flag and disable an account they believe is linked to this campaign prior to our intelligence sharing with their team.»
Due fornitori, due esiti opposti, sulla stessa intenzione d’uso. È la lezione che una settimana fa avevamo isolato in laboratorio, quando CAISI aveva misurato GLM-5.2: rifiuti quasi totali sulla richiesta diretta in chat, zero su dieci nella stessa richiesta scomposta in un compito agentico. Qui non è più un banco di prova: è un attore reale che ha scelto lo strumento in base a quale gli opponesse meno resistenza. Le protezioni non sono una proprietà dei pesi del modello: sono uno strato del sistema che lo esegue. Un modello raggiunto via API porta con sé lo strato del fornitore — qui ha funzionato, ha rifiutato, ha fatto disattivare un account. Ma quello strato sta nella pila che si assembla, non nel modello: qui l’accesso era l’API del fornitore stesso — la tabella di Unit 42 riporta «Direct API: api.deepseek[.]com» —, e a mancare era lo strato del framework, «no built-in safety layer», con per giunta una skill godmode per il jailbreak già a disposizione. Chi mette insieme modello, framework e strumenti quello strato se lo costruisce, oppure non ce l’ha affatto. Vale nelle due direzioni: è ciò che ha permesso a questo attore di scegliere il più permissivo, ed è ciò che permette a un’organizzazione seria di costruire controlli propri, verificabili e registrati, invece di dipendere da quelli di un fornitore che li può cambiare con un aggiornamento che non vedete arrivare. Resta comunque una misura diversa dalla capacità: i numeri su Langflow ed n8n dicono quanto l’agente sappia fare, «no built-in safety layer» dice quanto sia stato lasciato libero di farlo — confonderle è l’errore che un capitolato deve escludere a monte.
Cosa fare, in pratica
- Se valutate un modello a pesi aperti per un caso d’uso con strumenti in mano, non fermatevi alla scheda del produttore: verificate cosa succede quando il compito è scomposto in passi, non posto come domanda diretta.
- Trattate FOFA, Shodan e i motori di enumerazione degli asset come la superficie che un aggressore automatizzato userà per primo: sapere cosa è visibile dall’esterno prima che lo scopra un agente è la differenza fra 84 istanze trovate e zero.
- Documentate per iscritto quale protezione accompagna ogni modello messo in esercizio — di fabbrica o costruita da voi — prima che un default troppo permissivo diventi la porta che un agente apre da solo.
Come lo risolviamo noi
Il controllo mancato all’attaccante — reso dal fornitore nel caso OpenAI, da nessuno nel caso DeepSeek/Hermes Agent — è quello che mettiamo alla prova per i clienti: uno strato di sicurezza misurato in configurazione agentica, non in chat, che gira prima della messa in esercizio di ogni modello o agente e a cadenza dopo, con la traccia da esibire a un’ispezione. Vale già oggi per chi rientra nel perimetro di sicurezza nazionale cibernetica: il DPCM sulle categorie ICT soggette a valutazione del CVCN include i sistemi AI/ML per la gestione di reti e sistemi; per gli altri resta l’obbligo di valutazione documentata dei fornitori del D.lgs. 138/2024.
Lo stesso impianto tiene insieme, in un modello operativo unico, i dati sparsi dell’organizzazione — archivi, gestionali, sensori, log — su cui agenti AI eseguono compiti tecnici con un operatore al comando, esattamente nel punto che questo rapporto mostra più fragile: non la richiesta, l’esecuzione. Vale per i modelli cinesi a pesi aperti che sempre più aziende italiane valutano quanto per quelli americani o europei: la provenienza del modello conta meno di chi controlla quel punto. Per grandi imprese, difesa, pubblica amministrazione e sanità, lo facciamo in entrambe le modalità — on-premise su macchine autonome del cliente o su cloud dedicato con data center in Italia — con la gestione tenuta insieme a voi, senza che dobbiate già avere in casa chi amministra questi sistemi.
State per mettere in produzione un agente con strumenti in mano — non un chatbot — costruito su un modello a pesi aperti? Parliamone in una sessione di trenta minuti: verifichiamo lo strato di protezione nella vostra configurazione reale, in agentico, prima che lo faccia qualcun altro al posto vostro.