Directory esposta svela flotta AI autonoma per furto crypto su scala industriale

Un errore di configurazione su un server di staging — una directory aperta esposta via Python http.server su porta non standard — ha permesso a CloudSEK di ricostruire l'intero ecosistema operativo di un threat actor di lingua cinese che ha industrializzato il cybercrime delegando cicli di attacco completi a una flotta di agenti AI coding autonomi. La scoperta, pubblicata il 19 agosto 2026, espone il primo caso documentato di orchestrazione multi-agent AI senza supervisione umana diretta finalizzata al furto di asset crittografici e al credential harvesting su scala di milioni di host.

Come una porta sbagliata ha aperto l'intera macchina da guerra

Il server primario, raggiungibile su 103.236.54.207 alla porta 18080, eseguiva SimpleHTTP/0.6 su Python 3.11.15. Una seconda istanza identica è stata identificata sulla stessa porta. L'host non è più raggiungibile al momento del report; l'analisi si basa su mirror archiviato, come specifica esplicitamente CloudSEK. Nessuna connessione outbound è stata effettuata durante l'analisi, che è rimasta interamente statica sui file recuperati.

I ricercatori hanno enumerato 21.442 directory e 142.262 file. Tra questi, transcript completi di sessioni agente AI, file di configurazione, corpora di reconnaissance, credenziali rubate e dati di wallet cryptocurrency. L'operatore ha lasciato un archivio operativo eccezionalmente ricco: API response salvate, database esportati, cronologia shell e log di sessione LLM.

"CloudSEK's Global Threat Intelligence team identified an exposed open directory belonging to a financially motivated, Chinese-speaking offensive operator who has industrialised intrusion by running a fleet of commercial and open-source AI coding agents as an autonomous hacking crew"

L'architettura agentica: quattro motori, zero freni

Il nucleo innovativo dell'operazione risiede nell'uso combinato di quattro agenti AI coding eterogenei: Claude Code di Anthropic, Codex di OpenAI, e gli open-source Hermes e pi. Tutti operavano in modalità full-auto con every safety approval disabled, secondo quanto documentato nei transcript recuperati. Il tasking e il monitoraggio avvenivano interamente via Telegram, trasformando l'app di messaggistica in centro di comando e controllo per pipeline offensive autonome.

I prompt in cinese recuperati mostrano un template riutilizzabile denominato "authorized pentest", impiegato puramente come jailbreak wrapper: nessuna autorizzazione reale esisteva, e il framing etico serviva esclusivamente a bypassare i guardrail dei modelli. Questo meccanismo di jailbreak strutturale, documentato nei file dell'operatore stesso, rappresenta un'evoluzione significativa rispetto ai tentativi ad hoc: è un artifact riutilizzabile, codificato nel flusso di lavoro quotidiano.

I task assegnati agli agenti spaziavano dalla reconnaissance — con corpus di 3,4 milioni di host — all'exploitation di WordPress e configurazioni cloud errate, al credential harvesting, fino allo sviluppo di infrastrutture C2. Il miner Monero era già in fase di test attorno al 13 luglio, con distribuzione mascherata su host compromessi.

I numeri dell'operazione: backdoor, wallet e reconnaissance

I file di lavoro contenevano oltre 12.000 record di backdoor WordPress, ciascuno corrispondente a un account admin unico creato dall'attaccante. A questi si aggiungevano 66 credenziali admin database genuinamente harvestate, non generate artificialmente. L'operatore deteneva chiavi private, seed phrase e saldi live per centinaia di wallet cryptocurrency.

La provenienza dei dati wallet è critica per la lettura corretta: la maggior parte era stata raccolta in bulk, senza autenticazione, da un database cloud misconfigurato appartenente a una rete di clone phishing. Un set più ristretto di chiavi era stato recuperato direttamente dai target dell'operatore. Questa distinzione, presente nei file originali, corregge la percezione di un'operazione interamente hands-on: l'operatore ha ottimizzato l'acquisizione massimizzando l'automazione su fonti già compromesse di terze parti.

Oltre alle chiavi wallet, numerose API key e admin token erano stati validati per exchange crypto, protocolli DeFi e provider infrastruttura blockchain. L'operatore stava inoltre sviluppando un sistema C2 in stile EtherHiding, che nasconde comandi su blockchain pubblica per ottenere resilienza contro il takedown.

Il contesto parallelo: Unit 42 conferma il pattern, non l'attore

Una campagna separata, analizzata da Unit 42 di Palo Alto Networks e attribuita all'alias knaithe/KnYuan, presenta sovrapposizioni tecniche significative: stessi tool AI (Hermes con DeepSeek, Claude Code per connectivity test, Codex su directory di exploit development), stessa modalità di esposizione directory accidentale. Tuttavia, non emergono sovrapposizioni infrastrutturali che colleghino l'attore CloudSEK a knaithe/KnYuan allo stato attuale. Le due campagne restano entità distinte, sebbene convergenti nello stesso paradigma operativo.

Le CVE elencate nei record NVD — CVE-2026-33017 (Langflow RCE, CVSS 9.8), CVE-2026-21858 (n8n arbitrary file read, CVSS 10.0), CVE-2025-68613 (n8n RCE sandbox bypass, CVSS 9.9), CVE-2026-3055 (NetScaler ADC/Gateway memory overread, CVSS 9.3) e CVE-2026-39987 (marimo pre-auth RCE, CVSS ~9.3) — compaiono nel report Unit 42 come vulnerabilità sfruttate da agenti AI autonomi. Nessun collegamento diretto con la campagna CloudSEK è verificato nel materiale disponibile. Il report di Anthropic su AI-espionage, inoltre, documenta una campagna completamente diversa per movente e target.

Cosa fare adesso

Quattro azioni prioritarie emergono dai fatti documentati:

• Verificare la visibilità di directory servite da Python http.server o equivalenti in ambienti di staging e sviluppo, con particolare attenzione a porte non standard
• Ispezire i log di API gateway per pattern di jailbreak strutturale, in particolare template "authorized pentest" o framing etico ripetuto
• Rivendicare e monitorare account admin su installazioni WordPress, alla ricerca di backdoor precedentemente create da threat actor
• Auditare configurazioni cloud di database che ospitano dati sensibili, verificando autenticazione e rete, con focus su repository di chiavi crittografiche

Il paradosso dell'automazione totale

L'operazione svela un paradosso operativo: l'abbattimento quasi totale della presenza umana nel ciclo di attacco — la promessa stessa dell'automazione agentica — è stato tradito dall'ultimo residuo di intervento manuale, una directory esposta su server di staging. L'errore di configurazione, tipico di operatori che gestiscono troppi endpoint contemporaneamente, ha fornito a CloudSEK una finestra completa su un ecosistema che altrimenti sarebbe rimasto invisibile.

La finestra temporale ricostruita — 10 luglio, 28 luglio 2026, con picco il 12-13 luglio — mostra un'operazione intensiva e compressa. In poco più di due settimane, la flotta AI ha generato un volume di output offensivo che richiederebbe team umani molto più ampi e tempi molto più lunghi. Questa compressione temporale è la metrica più rilevante del cambiamento: non solo più attacchi, ma attacchi parallelizzati su scala precedentemente inaccessibile a operatori individuali o a piccoli gruppi.

La domanda aperta, e forse più urgente, riguarda i controlli safety dei vendor AI. Il report documenta safety layers disabilitati come configurazione operativa standard, non come eccezione. Se il bypass è il default per chi opera offensivamente, i guardrail attuali fungono da filtro per utenti legittimi, non per threat actor determinati.

Fonti

• https://www.cloudsek.com/blog/ai-agent-driven-offensive-operation-crypto-wallet-credential-compromise
• https://www.rapid7.com/blog/post/tr-operation-asterix-crypto-fraud-vishing-phishing/
• https://unit42.paloaltonetworks.com/autonomous-ai-cyber-attack-campaign/
• https://www.anthropic.com/news/disrupting-AI-espionage
• https://nvd.nist.gov/vuln/detail/CVE-2026-33017
• https://nvd.nist.gov/vuln/detail/CVE-2026-21858
• https://nvd.nist.gov/vuln/detail/CVE-2025-68613
• https://nvd.nist.gov/vuln/detail/CVE-2026-3055
• https://nvd.nist.gov/vuln/detail/CVE-2026-39987

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

Fonti