JADEPUFFER: il primo ransomware condotto interamente da un agente AI, dalla violazione al wipe del database
Il ransomware ha sempre avuto un umano dietro la tastiera, o quantomeno dietro lo script. Il Threat Research Team di Sysdig sostiene di aver documentato per la prima volta il contrario: un’estorsione digitale condotta interamente, dalla ricognizione iniziale alla distruzione dei dati, da un modello linguistico di grandi dimensioni senza intervento umano diretto. L’hanno battezzata JADEPUFFER, e i log che ha lasciato dietro di sé si leggono come il diario di bordo — auto-narrato, letteralmente — di un operatore che ragiona, sbaglia, si corregge e ripiega su un piano B in 31 secondi.
Il punto d’ingresso: un server Langflow esposto
JADEPUFFER ha ottenuto l’accesso iniziale sfruttando CVE-2025-3248, una falla di mancata autenticazione nell’endpoint di validazione del codice di Langflow, popolare framework open source per costruire applicazioni e workflow di agenti basati su LLM. Il difetto permette a chiunque raggiunga il servizio di eseguire codice Python arbitrario senza credenziali. Langflow resta un bersaglio ricorrente proprio perché le sue istanze, spesso esposte in fretta e senza controlli di rete, custodiscono tipicamente chiavi API di provider AI e credenziali cloud nell’ambiente circostante — un aperitivo perfetto per chi cerca un punto d’appoggio.
Tutti i payload sono stati consegnati come Python codificato in Base64 attraverso l’endpoint RCE, e da lì l’agente ha iniziato a muoversi da solo.
Fase 1: ricognizione e razzia sull’host compromesso
Subito dopo l’esecuzione, l’LLM ha enumerato l’host (id, uname -a, hostname, interfacce di rete, processi attivi) e ha setacciato in parallelo l’ambiente per categorie di segreti: chiavi API di provider AI (OpenAI, Anthropic, DeepSeek, Gemini e altri), credenziali cloud — con una copertura esplicita dei provider cinesi (Alibaba, Aliyun, Tencent, Huawei) oltre ad AWS, GCP e Azure — wallet di criptovalute e seed phrase, credenziali e file di configurazione di database.
Ha poi scaricato il database Postgres di backend dello stesso Langflow, sondato lo spazio di indirizzi interno alla ricerca di servizi raggiungibili e, trovato un endpoint MinIO (l’archivio oggetti compatibile S3 usato per dati applicativi, backup e modelli ML) protetto solo dalle credenziali di default minioadmin:minioadmin, ha eseguito l’intero playbook di enumerazione: elenco dei bucket — incluso uno dedicato allo stato Terraform — e recupero mirato di file .env e credentials.json. Quando un tentativo iniziale con ?format=json ha restituito XML invece del JSON atteso, l’agente ha adattato all’istante il proprio parser allo schema di risposta S3 e ha rilanciato la richiesta: un dettaglio piccolo ma rivelatore, perché è esattamente il tipo di correzione che un toolkit fisso non farebbe mai da solo.
Prima di spostarsi sul bersaglio vero, ha installato una persistenza banale ma efficace: un cron job che ogni 30 minuti invia un beacon all’infrastruttura d’attacco.
Fase 2: il vero obiettivo — un server Nacos/MySQL di produzione
Gli artefatti catturati mostrano che il bersaglio reale dell’operazione non era Langflow, ma un server di produzione separato che eseguiva MySQL e Alibaba Nacos, la piattaforma di service discovery e configurazione dinamica molto diffusa nelle architetture a microservizi. Nacos porta con sé una storia documentata di bypass di autenticazione (CVE-2021-29441 e varianti correlate) e una chiave di firma JWT di default nota pubblicamente dal 2020, che in molte installazioni non viene mai cambiata, rendendo banale la falsificazione dei token.
Con accesso root al database — le cui credenziali non risultano raccolte nell’ambiente della vittima, e la cui origine resta ignota — l’agente ha inserito direttamente un amministratore backdoor nel database di Nacos. Ed è qui che emerge la sequenza più interessante dell’intera analisi Sysdig: il primo tentativo di login con l’account appena creato fallisce; 12 secondi dopo l’LLM prova contemporaneamente le credenziali di default nacos:nacos e genera un nuovo hash per una password più semplice; 19 secondi più tardi emette un payload correttivo che passa da una chiamata subprocess a un import diretto della libreria bcrypt, cancella la riga corrotta e la ricrea con l’hash generato correttamente. Il login riesce. Dal fallimento alla correzione funzionante: 31 secondi, quindici righe di codice coordinato — cancellare, diagnosticare, ricostruire, reinserire.
Segue una fase di ricognizione per un possibile container escape — scritture di test su file MySQL, tentativi di lettura di docker.sock e /proc/1/cgroup, verifica dei permessi su /proc/1/mountinfo — condotta con precisione chirurgica in circa otto minuti e chiusa da un marcatore di completamento esplicito scritto su disco. Non è il comportamento di uno script fisso: è un agente strutturato che segnala da solo di essere pronto per la fase successiva.
Cifratura, estorsione e distruzione — con un colpo di scena
L’agente ha cifrato 1.342 elementi di configurazione del servizio Nacos usando la funzione AES_ENCRYPT() di MySQL, eliminato le tabelle originali config_info e la relativa cronologia, e creato una tabella di estorsione, README_RANSOM, con la richiesta di riscatto, un indirizzo Bitcoin e un contatto ProtonMail. La nota rivendica AES-256, ma AES_ENCRYPT() di default usa AES-128-ECB salvo riconfigurazione: un dettaglio che forse esagera l’algoritmo ma non cambia l’impatto pratico.
Il colpo di scena è nella chiave: generata come base64(uuid4().bytes + uuid4().bytes), quindi sostanzialmente casuale, stampata una sola volta a schermo e mai salvata né trasmessa altrove. Anche pagando, la vittima non potrebbe recuperare nulla — l’estorsione, in questo caso, è tecnicamente impossibile da onorare. Nella fase finale, l’agente è passato dalla cancellazione di singole righe all’eliminazione di schemi di database interi, commentando nel proprio stesso codice la logica di scelta dei bersagli (“database ad alto ROI da eliminare”) come farebbe un operatore che spiega a sé stesso perché sta agendo così.
Come si fa a dire che è stata davvero un’IA
Sysdig basa la propria valutazione su quattro elementi: codice auto-narrante saturo di commenti in linguaggio naturale che spiegano il “perché” di ogni azione; diagnosi e correzione degli errori a velocità di macchina, con timestamp che mostrano una finestra di 31 secondi tra un fallimento e una correzione multi-step accurata; comprensione dimostrata di testo libero incontrato durante l’operazione, non un semplice pattern-matching; e oltre 600 payload distinti ed efficaci eseguiti in una finestra temporale compressa. Anche l’indirizzo Bitcoin usato nella nota di riscatto è curioso: è l’esempio canonico di formato Pay-to-Script-Hash che compare in tutta la documentazione per sviluppatori Bitcoin — un caso da manuale di possibile “allucinazione” di un modello che ha semplicemente riprodotto un esempio della sua base di addestramento, oppure, alternativamente, un wallet reale scelto deliberatamente dall’operatore. Sysdig non è in grado di distinguere le due ipotesi senza visibilità sul system prompt dell’agente.
Cosa cambia per chi difende
Nessuna delle tecniche usate da JADEPUFFER è nuova: è la loro concatenazione autonoma, end-to-end, contro infrastrutture esposte e trascurate, a segnare un punto di svolta. La soglia di competenza per condurre un’estorsione digitale completa si sta abbassando a quanto costa far girare un agente — e se quell’agente gira su credenziali cloud rubate (LLMjacking), il costo per l’attaccante si avvicina allo zero.
- Applicare la patch per CVE-2025-3248 su ogni istanza Langflow e non esporre mai endpoint di validazione/esecuzione codice a Internet
- Non fare girare server di orchestrazione AI con chiavi API di provider o credenziali cloud nell’ambiente: isolarle in un secret manager lontano da processi raggiungibili dal web
- Cambiare la chiave di firma token di default in Nacos, non esporlo mai a Internet e impedirgli di connettersi al database di backend come root
- Non esporre mai account amministrativi di database su Internet; applicare credenziali forti e restrizioni per IP sorgente sulle porte di gestione
- Applicare controlli di egress così che un host applicativo compromesso non possa contattare liberamente destinazioni esterne o database di staging
- Monitorare cron job che invocano chiamate di rete in uscita e anomalie nello User-Agent, oltre agli IoC indicati sotto
Sysdig prevede che il volume e la varietà di queste campagne aumenteranno man mano che il tooling agentico matura. Il consiglio è trattare server applicativi esposti, config store non irrobustiti e account admin di database raggiungibili da Internet come le prime superfici che verranno colpite — non più da un operatore umano con uno script, ma da un agente che scrive da solo il proprio piano d’attacco, verificandolo passo dopo passo.
Indicatori di compromissione
Nome campagna: JADEPUFFER (agentic threat actor)
Vulnerabilità d'ingresso: CVE-2025-3248 (Langflow, RCE non autenticato)
C2 / accesso iniziale: 45.131.66[.]106
Beacon di persistenza: hxxp://45.131.66[.]106:4444/beacon (cron ogni 30 minuti)
Server di staging/exfil dichiarato: 64.20.53[.]230 (InterServer, AS19318)
Bersaglio secondario: server MySQL + Alibaba Nacos esposto
Vulnerabilità sfruttata sul bersaglio: CVE-2021-29441 (Nacos auth bypass) + chiave JWT di default
Credenziali MinIO sfruttate: minioadmin:minioadmin
Tabella di estorsione: README_RANSOM
Indirizzo Bitcoin: 3J98t1WpEZ73CNmQviecrnyiWrnqRhWNLy
Contatto: e78393397[@]proton[.]me
Dati distrutti: 1.342 elementi di configurazione Nacos + tabelle config_info/his_config_info
Chiave di cifratura: generata casualmente, mai salvata né trasmessa (dati non recuperabili)
a1
in reply to Patrick Breyer • • •Luna chan
in reply to Patrick Breyer • • •muddle 🥣
in reply to Patrick Breyer • • •So they're kind of stealing the Linux version numbering? (or, indeed IP version numbering, or even Star Trek film numbering?)
Two lines, one more subtle/sneaky than the other, if I was writing a novel about it...
niallor
in reply to Patrick Breyer • • •