L'attaccante da 31 secondi: cosa significa per il ripristino il primo attacco ransomware autonomo

Quando l'attaccante ha smesso di aver bisogno di un essere umano

Il 1° luglio 2026 il Sysdig Threat Research Team ha pubblicato la sua analisi di un'operazione ransomware a cui ha dato il nome JADEPUFFER. Nelle parole di Sysdig, si tratta di "what we assess to be the first documented case of agentic ransomware: a complete extortion operation driven end-to-end by a large language model (LLM)" (ovvero, secondo la valutazione di Sysdig, il primo caso documentato di ransomware agentico: un'operazione di estorsione completa condotta dall'inizio alla fine da un large language model).

Non è l'ennesima storia di email di phishing scritte dall'AI o di chiamate vocali deepfake. Nei payload catturati da Sysdig, l'agente ha sfruttato un'applicazione esposta su Internet, ha raccolto credenziali, si è spostato su un secondo server, ne ha preso il controllo del servizio di configurazione, ha cifrato e cancellato dati e ha lasciato una richiesta di riscatto. Quando un passaggio falliva, diagnosticava l'errore e riprovava senza attendere istruzioni.

In BackupSec pensiamo che JADEPUFFER conti meno come singolo incidente che come anteprima. È un primo dato concreto su una domanda a cui ogni architettura di backup e ripristino prima o poi dovrà rispondere: cosa succede quando il ciclo decisionale dall'altra parte si riduce da ore a secondi?

Dentro la catena d'attacco di JADEPUFFER

Nelle linee generali si tratta di una kill chain da cui i team di sicurezza si difendono da anni. Lo dice anche Sysdig: "None of the individual techniques were novel or sophisticated" (nessuna delle singole tecniche era nuova o sofisticata). La novità è ciò che le ha eseguite. La sequenza che segue riprende il report di Sysdig:

1. Accesso iniziale. L'agente ha sfruttato la CVE-2025-3248 in Langflow, un framework open source per costruire applicazioni LLM. La NVD la descrive come una code injection nell'endpoint /api/v1/validate/code che consente a "a remote and unauthenticated attacker" (un attaccante remoto e non autenticato) di eseguire codice arbitrario, e le assegna un punteggio CVSS di 9,8. La correzione è stata rilasciata in Langflow 1.3.0 il 31 marzo 2025 e la CISA ha aggiunto la vulnerabilità al suo catalogo Known Exploited Vulnerabilities il 5 maggio 2025. La patch esisteva, ma non era stata applicata.
2. Raccolta di credenziali. Sull'host Langflow l'agente ha enumerato il sistema e ha passato al setaccio l'ambiente alla ricerca di API key di provider LLM, credenziali cloud, wallet di criptovalute e credenziali di database, poi ha fatto il dump del database Postgres di Langflow stesso. Ha trovato un object store MinIO raggiungibile dall'host, vi ha effettuato l'accesso con le credenziali predefinite di MinIO (minioadmin:minioadmin) e ha elencato bucket che, secondo Sysdig, includevano "application data, backups, ML artifacts, and a terraform-state bucket" (dati applicativi, backup, artefatti di ML e un bucket con lo stato di Terraform). Da uno di questi ha prelevato un file credentials.json contenente una coppia access key/secret.
3. Persistenza. Ha installato sull'host Langflow una voce crontab che contatta l'infrastruttura dell'attaccante ogni 30 minuti.
4. Spostamento verso il vero obiettivo. Secondo Sysdig, il vero obiettivo dell'operazione era un server di produzione separato, esposto su Internet, con MySQL e un servizio di configurazione Alibaba Nacos. L'agente si è connesso come root alla porta MySQL esposta. Sysdig non ha osservato da dove provenissero quelle credenziali di root: "Their origin is unknown" (la loro origine è sconosciuta).
5. Presa di controllo di Nacos. L'agente ha attaccato Nacos su più fronti contemporaneamente: la famiglia di bypass dell'autenticazione della CVE-2021-29441 (secondo la NVD, in Nacos prima della 1.4.1 il filtro di autenticazione può essere aggirato con un header user-agent falsificato), un JSON Web Token forgiato con la chiave di firma predefinita di Nacos, documentata pubblicamente, e un account amministratore backdoor scritto direttamente nel database di Nacos grazie all'accesso root. Il tentativo con il JWT è fallito ("custom secret in use", cioè era in uso un secret personalizzato) ed è stato abbandonato. L'account backdoor ha funzionato, dopo la correzione in 31 secondi descritta più avanti.
6. Impatto. L'agente ha cifrato tutti i 1.342 elementi di configurazione di Nacos con la funzione AES_ENCRYPT() di MySQL, ha eliminato le tabelle originali di configurazione e di cronologia e ha poi eliminato interi schemi di database. La nota di riscatto dichiara AES-256; Sysdig fa notare che AES_ENCRYPT() usa per impostazione predefinita AES-128-ECB, a meno che il server non sia stato riconfigurato. Il dettaglio che conta di più per il ripristino: la chiave è stata stampata una sola volta e mai salvata né inviata, per cui, nelle parole di Sysdig, "The victim cannot recover the encrypted configurations even with payment" (la vittima non può recuperare le configurazioni cifrate nemmeno pagando). Solo una copia creata prima dell'attacco, e tenuta fuori dalla portata dell'attaccante, avrebbe potuto riportare indietro quei dati.
7. Estorsione. Ha creato una tabella README_RANSOM contenente la richiesta, un indirizzo Bitcoin e un contatto Proton Mail.

L'avvertenza onesta

Vogliamo essere precisi su cosa significhi qui "autonomo", perché esagerarlo indebolirebbe l'argomentazione che stiamo per fare.

Sysdig indica due cose che non può vedere. Non ha osservato come l'agente abbia ottenuto le credenziali root di MySQL usate nel quarto passaggio. E dichiara "no visibility into JADEPUFFER's system prompt or agent configuration" (nessuna visibilità sul system prompt o sulla configurazione dell'agente di JADEPUFFER), per cui non può dire quale obiettivo o quali risorse un essere umano abbia fornito all'agente prima dell'esecuzione. Qualcuno lo ha costruito, configurato e avviato.

Ciò che Sysdig documenta è il comportamento all'interno delle sessioni catturate: più di 600 payload distinti, codice che racconta il proprio ragionamento ed errori diagnosticati e corretti in pochi secondi. Sulla base di queste evidenze conclude che "the evidence points to an autonomous agent driving the operation rather than a human operator or a fixed toolkit" (le evidenze indicano che a condurre l'operazione era un agente autonomo, non un operatore umano o un toolkit predefinito).

Questa distinzione conta, e secondo noi rafforza l'argomentazione invece di indebolirla. Anche una catena in cui un essere umano fissa l'obiettivo e l'agente si occupa dell'esecuzione elimina la principale fonte di latenza di un'operazione ransomware tradizionale: il tempo che un operatore umano passa a riflettere, a confrontarsi con un referente e a decidere cosa provare dopo.

Perché 31 secondi contano più di quanto sembri

I 31 secondi non sono la durata complessiva dell'attacco. Sysdig non pubblica una durata end-to-end della catena, e noi deliberatamente non ne inventeremo una. Pubblica invece una sequenza con timestamp relativa alla presa di controllo di Nacos. L'agente ha inserito il suo account amministratore backdoor, ha tentato l'accesso alle 19:34:36 UTC e ha fallito. Ha verificato in parallelo due possibili cause, poi alle 19:35:07 ha inviato un payload correttivo di 15 righe che ha ricostruito l'account nel modo giusto. L'accesso è riuscito alle 19:35:18. Nelle parole di Sysdig: "The window between the failed login and the correct multi-step fix is 31 seconds" (l'intervallo tra l'accesso fallito e la correzione corretta in più passaggi è di 31 secondi). Sysdig riporta lo stesso schema in altri punti della sessione. Quando una richiesta ha restituito XML invece di JSON, il payload successivo analizzava XML. Quando un DROP DATABASE è fallito per un vincolo di chiave esterna, quello successivo ha prima disattivato il controllo.

Confrontiamolo con il comportamento di un operatore umano quando un passaggio fallisce. Si ferma. Rivaluta. In un'operazione ransomware-as-a-service strutturata, può scrivere a un referente e attendere indicazioni. Riprova con tempi misurati in minuti o in ore, a volte a cavallo di un cambio turno. Questa latenza, l'intervallo tra un fallimento e il tentativo successivo, è sempre stata una delle poche cose a favore dei difensori. È il motivo per cui un alert delle 2 di notte può ancora essere analizzato da una persona alle 8 del mattino senza che l'incidente sia necessariamente peggiorato in modo drammatico nel frattempo.

Un agente che riduce quell'intervallo a 31 secondi non è solo più veloce. Elimina il presupposto implicito in quasi ogni runbook di incident response: che tra il primo tentativo fallito di un attaccante e il successivo ci sia una finestra su scala umana, e che un processo di detection and response che opera su una scala temporale umana simile possa ragionevolmente aspettarsi di intervenire al suo interno.

I numeri che erano già veri prima dell'arrivo dell'AI

L'infrastruttura di backup non è diventata un bersaglio a causa dell'AI agentica. Lo era già, e i dati in merito precedono JADEPUFFER di due anni.

• Il 2024 Ransomware Trends Report di Veeam, un'indagine su 1.200 rispondenti di organizzazioni che avevano subito almeno un attacco ransomware nel 2023, ha rilevato che "backup repositories are targeted in 96% of attacks, with bad actors successfully affecting the backup repositories in 76% of cases" (i repository di backup sono presi di mira nel 96% degli attacchi, e gli attaccanti riescono a comprometterli nel 76% dei casi). Veeam ripete il dato del 96% sul proprio blog.
• La ricerca di Sophos del 2024 sui backup compromessi, basata su 2.974 professionisti IT e di cybersecurity le cui organizzazioni erano state colpite da ransomware nell'anno precedente, ha rilevato che "The median overall ransomware recovery costs for organizations whose backups were compromised ($3M) came in eight times higher than that of organizations whose backups were not impacted ($375K)" (il costo mediano complessivo di ripristino da ransomware per le organizzazioni con backup compromessi, 3 milioni di dollari, è risultato otto volte superiore a quello delle organizzazioni i cui backup non erano stati colpiti, 375.000 dollari).

Questi numeri descrivono un mondo di attaccanti umani che avevano già capito che distruggere o cifrare il livello di backup è la mossa con il massimo effetto leva disponibile una volta che un'operazione ransomware ha messo piede nell'ambiente. L'AI agentica non cambia nulla di questo calcolo. Cambia chi, o che cosa, può metterlo in pratica su larga scala, a ogni ora, senza bisogno di dormire, di fare una pausa di turno o di attendere l'approvazione di un referente prima di provare la credenziale successiva.

L'IBM 2026 X-Force Threat Intelligence Index aggiunge la linea di tendenza. IBM X-Force ha osservato un aumento del 44% degli attacchi iniziati con lo sfruttamento di applicazioni esposte pubblicamente, esattamente il vettore d'ingresso usato da JADEPUFFER, e i gruppi attivi di ransomware ed estorsione sono cresciuti del 49% su base annua. La superficie d'attacco cresceva già prima che servisse un operatore autonomo.

Dalle finestre di rilevamento alla certezza del ripristino

Sfruttare una vulnerabilità nota è già la via d'ingresso più comune. Lo stesso report IBM afferma che lo sfruttamento delle vulnerabilità "became the leading cause of attacks, accounting for 40% of incidents observed by X-Force in 2025" (è diventato la principale causa degli attacchi, pari al 40% degli incidenti osservati da X-Force nel 2025). Il divario tra vulnerabilità note e vulnerabilità chiuse è troppo ampio, e si rinnova troppo di continuo, perché una prevenzione perfetta sia realistica. JADEPUFFER rientra nello schema: Sysdig osserva che l'attacco al vero obiettivo "leaned on years-old issues, a 2021 Nacos auth-bypass and an unchanged default signing key" (si è appoggiato a problemi vecchi di anni, un bypass dell'autenticazione di Nacos del 2021 e una chiave di firma predefinita mai cambiata). JADEPUFFER non cambia questa argomentazione. La rende più netta.

Se il presupposto di lavoro del settore è stato che un processo di detection and response a ritmo umano possa ragionevolmente aspettarsi di intercettare un'intrusione in qualche punto tra l'accesso iniziale e l'impatto irreversibile, un agente che si autocorregge in 31 secondi mette direttamente in discussione quel presupposto. La risposta non può essere "rilevare e rispondere più in fretta di una macchina", perché non è una gara che i difensori possano aspettarsi di continuare a vincere all'infinito. La risposta deve essere architetturale: rendere sopportabile l'esito di un'intrusione rapida e adattiva, indipendentemente da quanto l'attaccante diventi più veloce.

In concreto, le proprietà che contano per l'infrastruttura di backup e ripristino non cambiano perché l'attaccante è un agente AI anziché un essere umano. Diventano irrinunciabili invece che auspicabili:

• Separazione delle credenziali e delle identità che non dipenda dal fatto che una persona noti in tempo un'attività insolita. Se le credenziali che raggiungono l'ambiente di backup sono le stesse che un agente può raccogliere in pochi secondi da un host compromesso, l'isolamento deve essere strutturale, non procedurale.
• Immutabilità validata, non solo configurata. Un blocco di retention che una credenziale con privilegi sufficienti può disattivare in silenzio è un controllo che presuppone un attaccante umano che esiterà. Un agente non esiterà.
• Test di ripristino che presuppongono che l'attaccante conosca già l'ambiente. L'agente di JADEPUFFER si è adattato in tempo reale ai passaggi falliti. Un piano di ripristino testato solo contro un singolo scenario di guasto atteso è un piano costruito per un avversario più lento e più prevedibile di quello che ora si è dimostrato possibile.

Cosa significa per i responsabili del rischio aziendale

JADEPUFFER è una campagna documentata, non la prova che ogni operazione ransomware sia ormai autonoma. Ma se la valutazione di Sysdig regge, qualcosa che finora era teorico è stato ora osservato: un agente LLM che esegue una vera catena d'attacco contro un vero obiettivo, con un ciclo di autocorrezione misurato in secondi.

Per i responsabili del rischio, la domanda pratica non è più se il ransomware agentico diventerà più diffuso. Sysdig afferma che i difensori "should expect the volume and breadth of such campaigns to rise as agentic tooling matures" (dovrebbero aspettarsi che il volume e l'ampiezza di queste campagne crescano con la maturazione degli strumenti agentici), e IBM X-Force "expects adversaries to automate complex tasks like reconnaissance and advanced ransomware attacks" (si aspetta che gli avversari automatizzino attività complesse come la ricognizione e gli attacchi ransomware avanzati). La domanda pratica è se i presupposti della vostra architettura di ripristino siano stati costruiti per un avversario a ritmo umano o per uno che non ne ha più bisogno.

Il ruolo di BackupSec

In BackupSec abbiamo costruito il nostro approccio attorno a una premessa che JADEPUFFER rende più urgente: la prevenzione fallirà, e il livello che decide l'esito è quello costruito per sopravvivere al fallimento, per quanto veloce fosse ciò che lo ha causato.

• ZeroMON monitora Veeam Backup & Replication. Si installa on-premises come OVA, si connette con un account in sola lettura e non invia nulla a BackupSec né a terze parti. Tiene traccia dello stato di salute dei job di backup, registra le modifiche di configurazione in Veeam (chi ha cambiato cosa e quando), mostra lo stato di immutabilità così come lo riportano le impostazioni dei repository di Veeam stesso e tiene in vista la checklist del Security Analyzer di Veeam. Le sue regole di alert coprono le mosse che un intruso compie lato Veeam contro i backup, come modifiche alle credenziali, modifiche a retention e pianificazioni, job disattivati e sessioni di eliminazione. Gli alert vengono inviati via email e tramite notifica in-app. ZeroMON osserva Veeam: non vede la raccolta di credenziali su altri host e legge le impostazioni di immutabilità di Veeam invece di verificare i lock sullo storage stesso.
• ZeroTAM mette a disposizione del vostro team un advisor dedicato alla sicurezza dei backup: revisione dell'architettura, pianificazione del ripristino da ransomware, capacità e supporto prioritario in caso di crisi. È il contesto in cui verificare sotto pressione se la separazione delle identità, l'immutabilità e l'isolamento sono stati progettati per un attaccante a ritmo umano.
• ZeroPEN è un penetration test guidato dalle minacce su Veeam Backup & Replication, Veeam ONE ed Enterprise Manager. Simula una kill chain ransomware in otto fasi mappate su MITRE ATT&CK, dall'accesso iniziale e dall'abuso di credenziali, passando per l'accesso ai repository e la neutralizzazione dei backup, fino a una prova della capacità di cifratura. L'engagement include la verifica dell'integrità del ripristino e dell'immutabilità e fornisce evidenze pronte per l'audit, con un retest per le criticità gravi. Non è distruttivo: ZeroPEN "never deletes real backups, performs real encryption, or stops production or backup services" (non elimina mai backup reali, non esegue cifrature reali e non arresta servizi di produzione o di backup).

La domanda che JADEPUFFER solleva non è se le vostre difese siano veloci. È se la vostra architettura di ripristino sia stata costruita in modo da non dipendere dalla loro velocità.

Parlate con BackupSec della validazione della vostra architettura di ripristino →

Questa analisi si basa sulla ricerca di Sysdig di luglio 2026 su JADEPUFFER, sull'IBM 2026 X-Force Threat Intelligence Index, sul 2024 Ransomware Trends Report di Veeam e sulla ricerca di Sophos del 2024 sui backup compromessi, con i dettagli sulle vulnerabilità tratti da NVD e CISA. L'interpretazione e il framework qui presentati sono di BackupSec. Per capire come questa analisi si applica al vostro ambiente specifico, contattate il nostro team →