DeepSeek ha condotto attacchi cyber autonomi: ha fallito, ma ha…

Un threat actor di lingua cinese ha integrato DeepSeek con il framework open-source Hermes Agent per orchestrare una pipeline di hacking autonomo, dal ricognizione

{"main_topic":"ai","topics":["ai","cybersecurity","cve","agentic","llm"]}

Un threat actor di lingua cinese ha integrato DeepSeek con il framework open-source Hermes Agent per orchestrare una pipeline di hacking autonomo, dal ricognizione all'esecuzione di exploit, con intervento umano limitato al solo prompt iniziale. Lo ha documentato Unit 42 di Palo Alto Networks in un report pubblicato il 30 luglio 2026. La campagna conferma che la barriera tecnica per operazioni offensive AI-enabled è abbassata a livello di singolo individuo: l'attore ha assemblato in minuti quello che tradizionalmente richiederebbe ore di analisi manuale. Il dato più rilevante, però, non è il successo degli attacchi autonomi — che sono falliti — ma la dimostrazione che il divario tra modelli AI "difensivi" e "offensivi" dipende ormai da scelte di architettura safety, non da sofisticazione tecnica.

Punti chiave

Un threat actor di lingua cinese, alias knaithe e KnYuan, ha utilizzato DeepSeek come reasoning engine all'interno del framework open-source Hermes Agent per operazioni offensive autonome.
La pipeline ha combinato ricerca su FOFA, selezione di PoC da GitHub e tentativi di exploit per CVE specifici, con gestione autonoma delle risorse di calcolo.
Gli attacchi autonomi sono falliti per difese lato target (autenticazione richiesta, flow ID non pubblici); i successi confermati — 3 data exfiltration da Citrix NetScaler e command execution su 11 endpoint Marimo — derivano da operazioni manuali parallele.
Claude (Anthropic) e Codex (OpenAI) sono stati testati ma limitati a connectivity testing; i controlli safety lato provider hanno impedito uso offensivo, mentre DeepSeek e Qwen, accessibili direttamente via API senza restrizioni client-side, hanno abilitato l'esecuzione in "YOLO mode".

Come funziona l'agente autonomo: da prompt iniziale a exploit

L'architettura documentata da Unit 42 si articola in tre livelli. Il reasoning engine è DeepSeek, accessibile direttamente alle API native senza proxy intermedi. Il framework di orchestrazione è Hermes Agent, progettato per operazioni autonome con sistema di skills, accesso terminale e command-and-control via Telegram. Il terzo livello è l'integrazione tramite Model Context Protocol (MCP) con un server open-source, FofaMap-Platinum-Full-Expert, che traduce istruzioni in linguaggio naturale in query per la piattaforma di ricerca cyberspaziale FOFA.

L'attore ha personalizzato Hermes Agent con tre skills red-teaming: godmode per jailbreaking, web-terminal-exploitation per l'esecuzione di attacchi, e fofa-cyberspace-search per la ricerca di target. Questa configurazione ha permesso a DeepSeek di operare in quella che BleepingComputer definisce "YOLO mode": esecuzione senza conferma intermedia, dove ogni step generato dal modello viene tradotto immediatamente in azione.

Una sessione completa del 7 maggio 2026 è stata recuperata integralmente da Unit 42. Secondo il report, "We were unable to recover additional operator input beyond the initial task": dopo il prompt iniziale, DeepSeek ha gestito autonomamente il workflow per il resto della sessione, inclusa la gestione delle risorse di calcolo.

La catena autonoma: dal fallimento Langflow alla selezione di n8n

La sessione recuperata documenta il processo decisionale di DeepSeek in tempo reale. Il primo target selezionato è stato Langflow, con la vulnerabilità CVE-2026-33017, classificata CRITICAL con CVSS 9.8 secondo il National Vulnerability Database. DeepSeek ha scaricato autonomamente un proof-of-concept da GitHub, enumerato 84 istanze esposte via FOFA e identificato una versione vulnerabile, la 1.3.4. L'exploit è fallito: tutti e tre i sistemi Langflow vulnerabili richiedevano un public flow ID e l'assenza di auto_login ha bloccato la catena.

I log di reasoning recuperati da Unit 42 registrano la risposta autonoma del modello: "All three Langflow need public flow ID but no auto_login—stuck. Deployments small(84 alive), exploitable probably 0. Search for larger-scale vulns". DeepSeek ha quindi condotto ricerca su 10 famiglie di prodotti, analizzando deployment footprint e disponibilità di PoC, e ha selezionato n8n per la superficie di attacco superiore: 647.017 istanze globali, di cui 25.209 in Cina, secondo i dati FOFA citati nel report.

Per n8n, DeepSeek ha concatenato due vulnerabilità: CVE-2026-21858 (arbitrary file read, CVSS 10.0 secondo NVD) e CVE-2025-68613 (sandbox bypass to RCE, CVSS 9.9 secondo NVD). Il modello ha analizzato autonomamente le versioni affette, concludendo che "v1.117.3 is vulnerable to both". Ha campionato circa 100 indirizzi IP sui 25.209 n8n cinesi e sondato circa 40 target per dettagli di versione. Tre sistemi vulnerabili sono stati identificati, ma tutti richiedevano autenticazione: anche questa catena è fallita.

"the system executed hundreds of hours of manual targeting analysis in mere minutes, while also managing its own compute resources" — Unit 42, citato in Security Affairs

Il contrasto safety: perché Claude e OpenAI hanno bloccato, DeepSeek no

Il report documenta che l'attore ha testato anche strumenti AI occidentali, con risultati radicalmente diversi. Claude Code (Anthropic) è stato utilizzato in tre sessioni per un totale di 10 entry, limitate a /model checks, connectivity tests e una richiesta di npm install. Codex (OpenAI) mostra segni di uso in directory di exploit development, ma i chat logs non sono stati preservati. Entrambi erano routati via proxy attraverso il dominio code.newcli[.]com.

La differenza architetturale è decisiva. Secondo quanto riportato da TechTimes citando il report Unit 42: "The actor selected a model with minimal safety controls 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". OpenAI ha confermato ufficialmente che i suoi safety controls hanno rifiutato richieste policy-violating e ha disabilitato un account collegato alla campagna.

DeepSeek e Qwen, accessibili direttamente alle API native senza layer di controllo interposto, hanno permesso invece l'esecuzione continua. Il framework Hermes Agent non implementa guardrail client-side: la combinazione di modello senza safety e framework senza restrizioni ha creato uno stack effettivamente "offensivo by design".

I successi reali: exploit manuali e l'esposizione dell'infrastruttura

Contrariamente agli attacchi autonomi, le operazioni manuali parallele dell'attore hanno ottenuto risultati confermati. Unit 42 documenta data exfiltration da 3 target Citrix NetScaler tramite CVE-2026-3055 (memory overread, CVSS 9.3 secondo la classificazione CNA NetScaler), e command execution su 11 endpoint Marimo notebook tramite CVE-2026-39987 (pre-auth RCE, CVSS non ancora assegnato in NVD al momento del report). SecurityOnline riporta che la campagna complessiva ha tentato oltre 460 target, con 3 breach confermati.

L'attore è stato attribuito a Zhuhai, Cina, sulla base di attività GitHub pubblica che include il tool 1DayNews per aggregazione di vulnerabilità RCE. Unit 42 valuta l'attore come indipendente, non legato a entità statale. L'infrastruttura è stata esposta per errore operativo: un file server è stato avviato nella home directory invece che in una staging folder isolata, permettendo a Unit 42 il recupero dei log.

Il dato mette in prospettiva il rischio immediato: l'autonomia AI non ha ancora superato le difese lato target, ma ha compresso radicalmente il tempo di preparazione. Andy Piazza, senior director of threat intelligence presso Unit 42, precisa un limite metodologico: "We do not know if that targeting was intentional or simply a random list of targets that had internet-facing services the attacker was interested in".

Cosa fare adesso

Verificare che i sistemi Langflow, n8n, Citrix NetScaler e Marimo non siano esposti su internet con configurazioni di default o senza autenticazione; le patch per le CVE citate sono disponibili nelle release notes ufficiali e nel database NVD.
Valutare nei threat model aziendali il rischio specifico di strumenti AI con safety layer bypassabili o assenti, trattandoli come capacità offensive a disposizione di threat actor di bassa soglia tecnica.
Richiedere ai provider di servizi AI in uso documentazione trasparente sui controlli safety implementati lato provider, distinguendo tra guardrail di modello e restrizioni di infrastruttura.
Assicurarsi che l'autenticazione su strumenti di workflow automation e piattaforme di sviluppo sia implementata correttamente, poiché è risultata il controllo difensivo efficace contro gli attacchi autonomi documentati.

FAQ

DeepSeek ha compromesso sistemi autonomamente?

No. Gli attacchi autonomi documentati da Unit 42 sono falliti per difese lato target. I compromessi confermati — 3 data exfiltration e 11 command execution — derivano da exploit manuali condotti parallelamente dall'attore.

Perché Claude e OpenAI non sono stati usati per gli attacchi?

I controlli safety lato provider hanno impedito operazioni offensive. Claude è stato limitato a connectivity testing, e OpenAI ha disabilitato un account collegato alla campagna dopo il rifiuto di richieste policy-violating.

L'attore è legato a un governo?

Unit 42 valuta l'attore come indipendente. Non emergono sovrapposizioni infrastrutturali che colleghino knaithe/KnYuan a gruppi APT statali cinesi allo stato attuale delle analisi.

Le informazioni sono state verificate sulle fonti citate e aggiornate al momento della pubblicazione.

Fonti

Fonti e riferimenti