Un agente AI ha condotto da solo un attacco ransomware, dall'accesso iniziale all'estorsione

Il team di ricerca sulle minacce di Sysdig ha documentato quello che valuta essere il primo attacco ransomware eseguito interamente da un agente AI, senza intervento operativo umano. L'operatore, denominato JADEPUFFER, ha sfruttato la CVE-2025-3248 su Langflow, framework open-source per la creazione di app LLM e workflow agentici, per accedere a un server di produzione, cifrare 1.342 configurazioni Nacos e distruggere interi database schema, senza che la vittima possa recuperare i dati.

Sysdig classifica JADEPUFFER come un "agentic threat actor" (ATA): un operatore la cui capacità offensiva è erogata da un agente AI anziché da un toolkit guidato da un umano. La vulnerabilità sfruttata per l'accesso iniziale è un'autenticazione mancante nell'endpoint di validazione del codice di Langflow, che consente a un attaccante non autenticato di eseguire codice Python arbitrario sull'host. Tutti i payload sono stati consegnati come Python codificato in Base64 tramite questo endpoint.

Ricognizione e raccolta di credenziali

Dopo l'accesso iniziale, l'agente ha eseguito ricognizione e raccolta di segreti in parallelo: chiavi API di provider LLM (OpenAI, Anthropic, DeepSeek, Gemini), credenziali cloud con copertura esplicita di provider cinesi (Alibaba, Aliyun, Tencent, Huawei) oltre a AWS, GCP e Azure, wallet e seed phrase di criptovalute, credenziali e file di configurazione di database. Ha eseguito il dump del database Postgres di Langflow, salvando i risultati in file locali, revisionandoli e poi cancellando i file di staging.

L'agente ha inoltre enumerato un object store MinIO interno usando le credenziali di default minioadmin:minioadmin, listando tutti i bucket (dati applicativi, backup, artefatti ML, stato Terraform) ed estraendo file di credenziali; quando il parser della risposta ha fallito perché impostato per il formato JSON anziché XML, l'agente ha corretto autonomamente l'errore. Per mantenere la persistenza ha installato un crontab con un beacon verso l'infrastruttura dell'attaccante ogni 30 minuti.

L'attacco al server Nacos

Il bersaglio finale era un server di produzione separato, esposto su internet, che eseguiva un database MySQL e il servizio di configurazione Alibaba Nacos, piattaforma open-source per service discovery e configurazione dinamica usata nelle architetture a microservizi. L'agente si è connesso alla porta MySQL esposta con credenziali root; Sysdig non sa come siano state ottenute e afferma che non risultano rubate dall'ambiente della vittima.

JADEPUFFER ha attaccato Nacos con più vettori simultanei: lo sfruttamento dell'auth-bypass CVE-2021-29441, la forgiatura di un JWT valido usando la chiave di firma di default di Nacos, documentata pubblicamente dal 2020 e rimasta invariata in molti deployment, e l'iniezione di un amministratore backdoor direttamente nel database di supporto tramite l'accesso root ottenuto in precedenza. Dopo un primo tentativo fallito, causato da un hash bcrypt generato via subprocess con PATH vuoto, l'agente ha diagnosticato in parallelo due possibili cause e 31 secondi dopo ha emesso un payload correttivo che cancellava l'account rotto e lo ricreava con importazione diretta di bcrypt, verificando la versione prima di procedere. Ha poi condotto un'indagine sistematica per un tentativo di container escape via primitive di file MySQL, prima di emettere un marker esplicito di completamento e passare alla fase ransomware.

Cifratura e riscatto impossibile da onorare

L'agente ha cifrato tutti i 1.342 elementi di configurazione Nacos con la funzione AES_ENCRYPT() di MySQL, eliminato le tabelle originali config_info e his_config_info, e creato una tabella di estorsione README_RANSOM con richiesta di riscatto, indirizzo Bitcoin e contatto Proton Mail: "YOUR DATA HAS BEEN ENCRYPTED. All NACOS configurations, REDACTED customer data, and REDACTED PII have been encrypted with AES-256."

La chiave usata per la cifratura era però effimera, generata da due UUID4 concatenati e codificata in base64: è stata stampata su stdout ma mai persistita né trasmessa, per cui la vittima non può recuperare i dati nemmeno pagando. Il claim "AES-256" nella nota è inoltre probabilmente impreciso, dato che MySQL AES_ENCRYPT() usa AES-128-ECB per default salvo riconfigurazione esplicita del server. L'agente è poi passato dalla cancellazione a livello di riga al dropping di interi database schema, commentando nei payload il proprio "rationale di targeting" e indicando, senza verifica esterna, che i dati erano già stati copiati su un server di staging.

Secondo Sysdig, i payload dell'operazione erano autoesplicativi: "conteneva ragionamento in linguaggio naturale, prioritizzazione degli obiettivi e il tipo di annotazioni dettagliate che gli operatori umani spesso non scrivono ma che il codice generato da LLM produce in modo riflessivo". L'operazione ha prodotto oltre 600 payload distinti e mirati in una finestra temporale compressa, adattando i tentativi falliti in tempo reale.

Fra gli indicatori di compromissione raccolti, Sysdig segnala che l'indirizzo Bitcoin usato nella nota di riscatto corrisponde all'esempio canonico Pay-to-Script-Hash presente in tutta la documentazione per sviluppatori Bitcoin e nei corpora di training degli LLM. I dati blockchain mostrano 737 transazioni confermate e circa 46 BTC ricevuti storicamente, con saldo attuale pari a zero perché ogni deposito viene trasferito immediatamente: resta impossibile stabilire se l'indirizzo sia effettivamente reale e presidiato e, soprattutto, da chi.

Cosa cambia per la difesa

"Il livello di competenza richiesto per gestire un ransomware si è ridotto al solo costo di esecuzione di un agente, e se tale agente viene eseguito con credenziali rubate tramite LLMjacking, il costo per un attaccante è praticamente nullo", scrive Sysdig. L'abilità tecnica necessaria per condurre un attacco ransomware si è così ridotta al costo di eseguire un agente AI.

Fra le raccomandazioni difensive: aggiornare Langflow per correggere la CVE-2025-3248 e non esporre endpoint di code-execution su internet, cambiare la chiave di default di Nacos e non esporlo su internet, non eseguire server AI con API key o credenziali cloud nell'ambiente, non esporre la porta di amministrazione del database su internet e applicare controlli di egress per impedire beacon arbitrari.