Unit 42: il ciclo di attacco autonomo è praticabile e ogni successo confermato è stato ottenuto manualmente

Il 30 luglio 2026, Unit 42 di Palo Alto Networks ha pubblicato un'indagine su un operatore di lingua cinese che aveva collegato un modello linguistico direttamente nel ciclo di attacco stesso: DeepSeek in esecuzione all'interno di Hermes Agent, un agente da terminale open source di Nous Research, che riceveva istruzioni via Telegram. L'operatore ha tentato di attaccare più di 460 bersagli e ha mantenuto strumenti di exploit per sette filoni di vulnerabilità che coprivano otto identificatori CVE. Quasi nulla di ciò che la macchina ha fatto da sola ha portato a una compromissione: entrambi i tentativi autonomi di exploit si sono arenati sui prerequisiti che i bersagli avevano già disattivato. Ciò che una persona ha guidato ha invece prodotto impatto: dati di memoria esfiltrati da tre deployment Citrix NetScaler, esecuzione di comandi confermata su undici istanze di notebook Marimo e un sistema governativo malese è stato oggetto di attività per diversi giorni consecutivi. Nessuna vittima è nominata in nessuno dei due rapporti citati, e l'intero resoconto è stato ricostruito dai server esposti degli operatori stessi. Il resoconto completo, con la classificazione di gravità dell'archivio e le fonti citate, è indicizzato in l'Orca AI Incident Archive, accanto alle voci adiacenti della stessa settimana.

Come l’operazione è emersa

Unit 42 non ha rilevato questa campagna. È stato l'agente dell'operatore stesso a consegnarla. In risposta a un comando Telegram, Hermes Agent ha avviato un server di file HTTP — python3 -m http.server 8888 — dalla home directory dell'attore, /home/worker, anziché da una directory di staging isolata. Un comportamento predefinito ha esposto il workspace: configurazioni di strumenti di AI, chiavi API, script di exploit, elenchi di target, cronologia bash e i log delle sessioni autonome di Hermes che Unit 42 avrebbe poi usato per ricostruire passo passo il ciclo di attacco.

Unit 42 descrive l'esposizione come involontaria e rileva che l'attore non è stato negligente altrove: le directory degli exploit venivano svuotate dopo l'uso e la registrazione delle conversazioni in Codex era stata disabilitata per limitare l'archiviazione locale delle risposte. L'AI Safety Initiative della Cloud Security Alliance, che ha analizzato la stessa divulgazione il 4 agosto 2026, ha colto il punto più incisivo: l'operatore ha applicato tecniche operative convenzionali, ma le impostazioni predefinite orientate alla comodità del framework per agenti le hanno annullate in un solo passaggio — e gli attaccanti che adottano framework per agenti ereditano le loro impostazioni predefinite insieme alle loro capacità.

Chi sia l'operatore, in base alle prove disponibili

Unit 42 identifica l’attore solo tramite l’handle: knaithe e KnYuan. La valutazione su Zhuhai si basa sull’attività su GitHub, in particolare sulla manutenzione da parte dell’attore di 1DayNews, una pipeline automatizzata di intelligence sulle vulnerabilità che aggrega divulgazioni di esecuzione di codice remoto da 17 fonti, per lo più fornitori di perimetro di rete, utilizza DeepSeek per filtrarle in base alla sfruttabilità e distribuisce gli avvisi tramite Telegram. In un’intervista con Infosecurity Magazine il 31 luglio 2026, Andy Piazza, senior director of threat intelligence di Unit 42, ha descritto lo stesso individuo come «un operatore opportunista di exploit e un ricercatore di sicurezza binaria autodefinitosi tale».

Nessuno dei due rapporti citati accusa un patrocinio statale. La nota di CSA afferma che la divulgazione non individua alcun indicatore di patrocinio statale e valuta le risorse e la portata come coerenti con una singola persona che assembla un flusso di lavoro offensivo a partire da un modello di ragionamento standard e da un framework di agenti disponibile gratuitamente. Infosecurity Magazine riporta che gli obiettivi della campagna si estendevano a tre paesi, tra cui Cina e Malesia.

La metà autonoma: due prodotti, due fallimenti

Unit 42 ha recuperato una sessione completa di Hermes Agent, datata maggio 2026, e non è riuscita a recuperare input dell'operatore oltre al compito iniziale. Quello che i log mostrano è un agente che sceglie i propri obiettivi e li abbandona, senza istruzioni.

È iniziato con Langflow e CVE-2026-33017, CVSS 9.8. Ha scaricato da GitHub il proof of concept pubblico, ha enumerato 84 istanze Langflow tramite il motore cinese di ricerca di asset FOFA usando la query title="Langflow", e ne ha trovata una che eseguiva una build vulnerabile, la 1.3.4. Il tentativo è fallito perché la vulnerabilità richiede o auto_login abilitato o un flow ID pubblico, e il target non aveva né l'uno né l'altro. Il verdetto dell'agente, citato nel rapporto: "Tutti e tre i Langflow richiedono un flow ID pubblico ma non auto_login — bloccato. Distribuzioni piccole (84 attive), probabilmente 0 sfruttabili. Cerca vulnerabilità su scala più ampia."

Poi fece ciò che il suo incarico non aveva richiesto. Esaminò i conteggi di distribuzione di dieci famiglie di prodotti su FOFA, cercò su GitHub i repository proof-of-concept per CVE 2026 di tendenza ordinati per stelle e classificò i candidati per gravità, diffusione e sfruttabilità prima di scegliere n8n — giustificato nel log dalle 258 stelle del proof of concept e dal CVSS 10.0. FOFA collocava n8n a 647.017 istanze in tutto il mondo, 25.209 delle quali in Cina.

La catena n8n era CVE-2026-21858, lettura arbitraria di file con CVSS 10.0 e corretta in 1.121.0, più CVE-2025-68613, un bypass della sandbox per l'esecuzione di codice remoto con CVSS 9.9 e corretto in 1.120.4. L'agente ha verificato da solo gli intervalli di versione — «CVE dice corretto in 1.121.0 per AFR e 1.120.4+ per RCE. Quindi v1.117.3 è vulnerabile a entrambi!» — poi ha campionato circa 100 indirizzi su 25.209, ne ha sondati circa 40 e ha trovato tre che eseguivano versioni vulnerabili: 1.18.0, 1.117.3 e 1.108.2.

Tutti e tre hanno fallito per lo stesso motivo. L'exploit richiede un modulo non autenticato con caricamento di file, e i moduli raggiunti richiedevano l'autenticazione. L'agente lo ha detto nel log — "Questi moduli hanno l'autenticazione abilitata. Controlliamo altri target" — ha scansionato oltre 50 altri target cinesi, non ha trovato moduli accessibili pubblicamente e si è fermato. La sessione recuperata termina lì. Unit 42 non registra alcuno sfruttamento dal percorso autonomo.

Dove il danno ha effettivamente colpito

Ogni impatto confermato nel registro proveniva dal percorso manuale, eseguito con flussi di lavoro convenzionali: enumerazione FOFA, scanner Python personalizzati e sfruttamento diretto.

• Citrix NetScaler ADC and Gateway, CVE-2026-3055, CVSS 9.8 — dati esfiltrati da tre organizzazioni. Unit 42 afferma che i tre successi hanno estratto dati dalla memoria tramite la lettura fuori dai limiti e che l'attore ha poi cercato nei contenuti rubati i cookie di autenticazione NetScaler (NSC_AAAC=), il che indica un dirottamento di sessione anziché un furto fine a se stesso.

• Un'entità governativa in Malesia — presa di mira in modo persistente e sfruttata per più giorni, con quelli che Unit 42 definisce parametri di memory grooming e tentativi massimi di lettura, e con l'anonimizzazione tramite proxy aggiunta nelle visite successive. È l'unico obiettivo che il rapporto considera come manifestazione di un'intenzione che va oltre l'opportunismo.

• Notebook Marimo, CVE-2026-39987, CVSS 9.8 — esecuzione di comandi confermata su 11 istanze.

• Apache Tomcat, CVE-2026-34486, CVSS 7.5 — tentativi di reverse-shell contro nove server.

• Windows IKE VPN, CVE-2026-33824, CVSS 9.8 — callback reverse-shell mirati a tre endpoint.

• Portale di autenticazione PAN-OS User-ID, CVE-2026-0300, CVSS 9.8 — un proof of concept di ricerca pubblico clonato e mai eseguito. Unit 42 ha rilevato che il codice non è funzionante, con valori segnaposto che non consentono di ottenere l'esecuzione.

Contano due limiti. Le vittime non sono nominate, quindi l’identità dei tre operatori di NetScaler e dell’agenzia malese non è pubblica. E Unit 42 afferma di aver esaminato prove di sfruttamento in batch contro un numero sconosciuto di host che comparivano in un file che l’attore ha eliminato prima dell’analisi — il che rende il conteggio confermato un minimo, non un totale.

Ciò che è stabilito e ciò che è affermato

La meccanica è insolitamente ben documentata per un incidente di questo tipo. Unit 42 sta esaminando i file di configurazione, i log di sessione, gli elenchi di target e la cronologia bash dello stesso operatore; l'elenco delle CVE, il numero di target e le modalità di errore provengono da quel materiale anziché da inferenze sul traffico di rete.

L'attribuzione è più sfumata. "di lingua cinese", "con sede a Zhuhai" e gli handle knaithe e KnYuan sono valutazioni degli analisti basate sull'attività su GitHub, su un vecchio blog personale e sulla pipeline 1DayNews. Non le accompagnano accuse, sanzioni o dichiarazioni governative, e nessuno dei due rapporti citati nomina un'organizzazione vittima.

Un'affermazione sull'applicazione delle norme è di seconda mano all'interno del report stesso. Unit 42 riferisce che il personale di OpenAI ha confermato che le salvaguardie lato provider hanno rifiutato richieste che violavano le policy, e che tentativi reiterati hanno portato i loro sistemi di sicurezza a segnalare e disabilitare un account che ritengono collegato a questa campagna, prima che Unit 42 condividesse le proprie informazioni con loro. Si tratta di un fornitore che descrive la propria stessa applicazione delle norme; Unit 42 non l'ha verificata in modo indipendente.

Una lacuna va dichiarata apertamente: nessuna dichiarazione del governo malese, di MyCERT o di un altro CERT nazionale su questa campagna è emersa nelle ricerche per questo articolo al 30 ottobre 2026. Hunt.io, la seconda fonte citata per questa voce, afferma di aver notificato le organizzazioni interessate e i CERT nazionali competenti il 6 luglio 2026 e di aver sospeso la pubblicazione per una finestra di divulgazione di sette giorni — ma una notifica non è un resoconto pubblico.

I due rapporti citati non concordano su Claude Code

Questo record cita due indagini di fornitori pubblicate a due settimane di distanza, che descrivono diverse ripartizioni degli strumenti. Unit 42, in un testo del 30 luglio, assegna l'esecuzione a Hermes Agent con DeepSeek come motore di ragionamento, e considera Claude Code una prova. La cronologia recuperata comprende dieci voci distribuite su tre sessioni contenenti controlli /model, test di connettività e una richiesta di npm install, usati per testare la connettività e validare il proxy. Codex mostra segnali di utilizzo su directory di sviluppo di exploit, ma i suoi log di chat non sono stati conservati; Qwen Code ha ricevuto due sessioni. Unit 42 interpreta la diffusione come un operatore che fa acquisti attraverso il mercato dell'IA, instradando gli strumenti occidentali attraverso un proxy su code.newcli[.]com mentre chiama DeepSeek e Qwen direttamente tramite i loro endpoint API nativi.

Hunt.io, che ha pubblicato il 14 luglio da una directory aperta individuata su 112.213.124[.]132 sulla porta 8888, descrive la configurazione opposta: Claude Code 2.1.165 come motore di esecuzione attraverso sessioni persistenti tra l'8 e il 12 giugno 2026, con DeepSeek-v4-pro al di sotto che svolge l'attività di ragionamento, e un file CLAUDE.md recuperato che istruisce Claude Code a creare, testare e iterare pagine di phishing clonate.

Entrambi i rapporti descrivono un framework per agenti lasciato a servire una directory sulla porta 8888. Descrivono insiemi di vittime diversi: le intrusioni confermate di Hunt.io si trovano in Afghanistan, Thailandia e Taiwan, con phishing allestito contro due enti governativi degli Stati Uniti; le vittime confermate di Unit 42 sono tre operatori Citrix senza nome e un ente governativo malese, con il probing autonomo rivolto in larga parte all'infrastruttura domestica cinese. Nessuno dei due rapporti rimanda all'altro, e né l'archivio né alcuno dei due vendor ha pubblicato una riconciliazione. Letti insieme, sostengono una sola conclusione, non due: nel giugno e nel luglio 2026 era in corso un'attività di intrusione guidata da LLM all'interno dell'ambiente di questo operatore. Quale modello occupasse quale posizione nello stack — e se i due rapporti descrivano un solo operatore o due — non è stabilito dal documento pubblicato.

Cosa è cambiato dopo

Poiché l’esposizione ha prodotto le prove, il cambiamento più concreto riguarda l’attore anziché le vittime. Unit 42 afferma di aver condiviso i risultati con i membri della Cyber Threat Alliance, e la sua pagina riporta un timbro di aggiornamento dell’11 agosto 2026, dodici giorni dopo la pubblicazione. Per i clienti Palo Alto elenca le regole di superficie d’attacco di Cortex Xpanse per appliance Langflow, n8n e Citrix ADC esposte, oltre a una serie di firme di Threat Prevention.

Sui prodotti vulnerabili, le correzioni precedono la campagna. n8n ha rilasciato le versioni 1.120.4 e 1.121.0 per le due vulnerabilità prima della sessione recuperata, e l'agente ha letto quei limiti di versione direttamente dagli advisory. La nota del 4 agosto della CSA raccomanda agli operatori NetScaler esposti a CVE-2026-3055 di ruotare i cookie di autenticazione di sessione NSC_AAAC e di esaminare le sessioni autenticate per individuare anomalie, poiché l'attore stava esplicitamente cercando quel cookie, e che chiunque sospetti un'esposizione alla vulnerabilità Marimo presuma che l'esecuzione di comandi possa essere già avvenuta.

Il catalogo Known Exploited Vulnerabilities della CISA, consultato direttamente il 30 ottobre 2026, mostra quanto fosse pubblico questo materiale prima che ne venisse segnalata qualsiasi parte: CVE-2025-68613 è stato aggiunto l'11 marzo 2026, CVE-2026-33017 il 25 marzo, CVE-2026-3055 il 30 marzo, CVE-2026-39987 il 23 aprile e CVE-2026-0300 il 6 maggio — tutti prima della pubblicazione di Unit 42. CVE-2026-34486 è seguito il 4 agosto e CVE-2026-33824 il 18 agosto. CVE-2026-21858, la parte relativa alla lettura di file in n8n della catena autonoma fallita, non compare affatto nel catalogo.

Perché il margine è la scoperta

La conclusione di Unit 42 non è che la campagna sia riuscita, ma che ci è andata vicina. Lo sfruttamento è stato fermato dalla configurazione lato target — l'auto_login assente, i form autenticati — e il report afferma che «i target con configurazioni predefinite più deboli sarebbero stati suscettibili». Il suo giudizio complessivo è che i cicli di attacco autonomi sono operativamente praticabili e che il margine di fallimento era esiguo.

La lettura indipendente di CSA individua la stessa asimmetria da un'angolazione diversa: la ricognizione e il triage autonomi si sono dimostrati molto più facilmente scalabili dello sfruttamento autonomo, e gli esiti confermati e convertibili in armi dipendevano da un lavoro guidato da operatori umani, sovrapposto alla ricognizione dell'agente. Entrambe le letture riguardano la campagna di un unico operatore. Il resoconto non contiene alcuna affermazione secondo cui un ciclo autonomo abbia già compromesso un sistema da solo.