Ransomware agentico — il playbook di containment quando l'attaccante è un modello

Usa questo playbook quando hai evidenza — o forte sospetto — che una catena d'attacco sia guidata da un agente autonomo e non da un operatore hands-on-keyboard. Segnali che puntano qui:

• Fasi d'attacco che avanzano più veloci di quanto un operatore umano potrebbe digitarle a console, con transizioni sotto il minuto tra recon, uso credenziali e lateral movement.
• Azioni fallite ri-tentate con parametri raffinati in pochi secondi (JADEPUFFER ha corretto un login Nacos fallito in 31 secondi), invece dei minuti-ore che un umano impiega ad accorgersene e aggiustare.
• Initial access attraverso un servizio AI/LLM-adiacente — l'intrusione JADEPUFFER è partita da un endpoint di code-validation Langflow non autenticato (CVE-2025-3248, CVSS 9.8), ora nel catalogo CISA KEV.
• Ampiezza di attività parallela — sweep credenziali simultanei su servizi cloud, database e object storage — che un singolo umano sequenzierebbe.

NON usare questo playbook per ransomware classico human-operated (usa il tuo runbook IR standard), per worm commodity ad auto-propagazione (deterministici, non adattivi), o per una sospetta compromissione di agente senza obiettivo ransomware o distruttivo (quello è un incidente di agent-governance, non questo). La caratteristica distintiva qui è un avversario che ragiona e si adatta dentro la tua rete a velocità macchina.

Ogni piano IR orientato all'umano porta un'assunzione implicita: c'è dwell time. L'attaccante entra, poi si ferma — per orientarsi, tirare tool, decidere la mossa successiva. Quelle pause sono le tue finestre di interruzione. Contro un agente collassano.

L'operazione JADEPUFFER documentata da Sysdig ha eseguito l'intera catena — reconnaissance, harvesting credenziali, esfiltrazione, lateral movement verso un server MySQL di produzione e un servizio di config Nacos, privilege escalation, un account admin backdoor, un beacon crontab, e cifratura AES di 1.342 item di configurazione — senza umano nel loop (copertura indipendente, The Hacker News). L'indizio era la velocità: un login fallito diagnosticato e ritentato in 31 secondi.

Cosa cambia operativamente:

• Non esiste "contenuto entro fine turno". La finestra tra il primo segnale di rilevamento e la cifratura irreversibile è di minuti al massimo.
• I gate di approvazione manuale diventano il collo di bottiglia che perde. Se isolare un host o revocare un token richiede un ticket e un'approvazione di change, l'agente finisce prima.
• L'agente reagisce a te. Un containment parziale — bloccare un path — lo spinge a provarne un altro. Le mezze misure trapelano segnale e gli insegnano la tua difesa. Contieni completamente o per niente.

Non vinci alle 03:00 digitando più veloce di un modello. Il lavoro decisivo accade prima, rendendo una singola RCE incapace di diventare un evento database-wide. Fai questo ora:

• Inventaria la superficie d'attacco AI-adiacente. Ogni framework LLM, runtime di agenti, server MCP, tool di orchestrazione e builder AI no-code (Langflow, Nacos, MinIO ed equivalenti) è superficie di initial access. Patcha all'ultima versione, mettili dietro autenticazione, e toglili da qualsiasi path internet-raggiungibile di cui non hanno bisogno.
• Scopa ogni identità non-umana. Il service account dietro un agente o un'app deve raggiungere esattamente i dati che gli servono e nient'altro. Il danno di JADEPUFFER è venuto da un foothold le cui credenziali raggiungibili aprivano cloud, database e object storage. Il least-privilege per identità è il tetto al blast radius.
• Elimina credenziali di default e condivise. La catena ha pivotato via credenziali MinIO di default e un auth bypass Nacos. Enumera e rimuovi i default; secret unico per servizio.
• Pre-autorizza il kill. Decidi, in anticipo e per iscritto, chi può isolare un host, disabilitare un account e revocare un banco di token senza una riunione di change-approval. Automatizzalo dove puoi — la risposta deve muoversi a velocità macchina.
• Segmenta così la cifratura non può propagarsi. Le reti flat permettono a un host compromesso di raggiungere ogni share. La segmentazione trasforma una perdita totale in una contenuta.

Quando la catena è live, stai correndo contro l'agente. Priorità, in ordine:

1. Taglia la portata del foothold, non solo il foothold. Isola l'host compromesso a livello di rete E revoca immediatamente ogni credenziale che quell'host potrebbe aver letto — non quelle che hai confermato rubate, tutte. Assumi harvest completo.
2. Ruota in massa, non investigare prima. API key (cloud, e qualsiasi chiave di provider LLM che l'agente potrebbe rivendere o riusare), password database, chiavi object storage, service token. La rotazione costa meno della cifratura che stai cercando di prevenire.
3. Congela il piano identità. Disabilita il service account dietro il foothold e ogni account come cui si è autenticato. Se un admin backdoor è già stato iniettato, congelare il piano ne limita l'uso.
4. Blocca l'egress. Lo stesso evento esfiltra prima di cifrare. Taglia l'outbound verso destinazioni sconosciute per limitare la perdita dati anche se la cifratura è già in corso.

Una checklist da tenere alla console:

• [ ] Host compromesso isolato a livello di rete
• [ ] Tutte le credenziali raggiungibili da quell'host revocate/ruotate
• [ ] Chiavi API di provider LLM e cloud ruotate
• [ ] Service account disabilitato/i
• [ ] Egress in uscita verso ASN sconosciuti bloccato
• [ ] Integrità backup confermata e backup portati offline

Una volta fermata la catena, eradica assumendo che un avversario adattivo abbia piazzato più di una via di ritorno:

• Caccia la persistenza in stile agente, non solo file. JADEPUFFER ha iniettato un account admin backdoor direttamente in un database e installato un beacon crontab. Audita le tabelle di privilegi e le righe admin del database, i task schedulati (cron, timer systemd, scheduled task Windows), e le entry dei servizi di config — non solo il filesystem per binari droppati.
• Ricostruisci il foothold da base pulita. Non fare clean-in-place di un host su cui un agente ha avuto code execution. Ricostruisci da immagine known-good, patcha la vulnerabilità d'ingresso, e ripristina i dati da un backup precedente all'intrusione.
• Riconcilia ogni credenziale. Ogni secret raggiungibile durante l'incidente resta ruotato. Riemetti, non ripristinare, i token.
• Verifica il blast radius della cifratura. Enumera cosa è stato effettivamente cifrato o droppato (JADEPUFFER ha droppato le tabelle originali e distrutto database dopo la cifratura) e ripristina da backup offline, confermando l'integrità prima di tornare in produzione.

Preserva, con timestamp e chain-of-custody, prima di ricostruire qualsiasi cosa:

• La timeline compressa dell'attacco — dal primo segnale alla cifratura — con timestamp originali. La cadenza sotto il minuto è essa stessa evidenza di automazione e va nella notifica al regolatore.
• Storico completo dei comandi e delle chiamate API dall'host compromesso e dal servizio d'ingresso dell'agente.
• La lista di esposizione credenziali: ogni secret raggiungibile dal foothold, marcato come ruotato con l'ora.
• Artefatti di persistenza: la riga admin iniettata, il beacon crontab, ogni modifica ai servizi di config.
• Evidenza di esfiltrazione: sessioni in uscita, volumi, destinazioni.
• TTP mappate sia in MITRE ATT&CK sia in MITRE ATLAS — ATLAS è la matrice AI-avversariale che regolatori e assicuratori si aspetteranno sempre più per un incidente AI-driven.

Il punto difficile è che gran parte di questo è generato nei secondi in cui l'agente è attivo — non c'è tempo di assemblarlo a mano a metà incidente. È qui che la registrazione del traffico continua e a wire-speed si guadagna il posto: il modello AI Traffic Analysis on-appliance di Zero Hunt — quattro inference head paralleli (traffico sospetto, classificazione malware, identificazione tipo di attacco, application fingerprinting), addestrato su miliardi di sequenze PCAP e in esecuzione localmente sulla GPU dell'appliance — cattura il fan-out laterale, gli sweep di credenziali e l'egress mentre accadono, così la timeline e il set di IOC esistono già quando notifichi, invece di essere ricostruiti da un digest SIEM del mattino dopo.

Anti-pattern che fanno cifrare le organizzazioni, presi da una risposta tarata sull'umano che incontra un avversario macchina:

• Investiga-poi-contieni. L'istinto di scopare con precisione prima di agire è corretto contro un umano e fatale contro un agente. Contieni largo prima; restringi dopo.
• Risposta gated da approvazione. Un'azione di revoca-token che richiede un change ticket va più lenta dell'attacco. Pre-autorizza e automatizza le azioni distruttive di containment.
• Containment parziale. Bloccare un path insegna a un avversario adattivo a prenderne un altro. Isola completamente; non negoziare con un control loop.
• Rilevamento che riporta, non reagisce. Un SIEM che fa emergere l'incidente nel digest del mattino è uno strumento post-mortem, non un controllo di containment, contro un agente da 31 secondi. L'unico rilevamento abbastanza veloce è comportamentale e a wire-speed: la firma di traffico della cifratura in corso (burst di scritture SMB/NFS rapide, fan-out laterale prevedibile, preceduti da traffico di privilege escalation) è visibile durante la fase di cifratura, prima che i file siano completamente bloccati — esattamente la finestra che un agente comprime. Quel flag comportamentale a metà catena è ciò che permette a un kill automatico di scattare in tempo.
• Fidarsi dello stato di patch invece della raggiungibilità. Puoi patchare la CVE d'ingresso e perdere lo stesso, perché le credenziali harvestate sopravvivono alla vulnerabilità. Ruota assumendo compromissione completa.

Un attacco AI-driven non cambia i tuoi obblighi di notifica — cambia il contenuto. Punti chiave:

• Il clock è invariato. Sotto NIS2 (e la sua trasposizione italiana, d.lgs. 138/2024) l'early warning per incidente significativo è dovuto entro 24 ore e la notifica entro 72; sotto DORA i gate per incidente grave sono 4h / 72h / 1 mese. Vedi il playbook timeline incidenti NIS2 Title 13 per la cadenza.
• Classificalo come intenzionale e automatizzato. La notifica chiede se l'incidente fosse intenzionale; un attacco ad agente autonomo lo è, e l'automazione è materialmente rilevante per la valutazione d'impatto e per il quadro di minaccia del CSIRT di settore.
• Cita ATLAS, non solo ATT&CK. Regolatori, ENISA e assicuratori stanno costruendo le aspettative sugli incidenti AI attorno alla tassonomia AI-avversariale; mappare la catena in MITRE ATLAS accanto ad ATT&CK rende la notifica difendibile.
• Aspettati la domanda "c'era AI di mezzo" dagli assicuratori. I questionari di cyber-insurance stanno aggiungendo voci su attacchi autonomi ed esposizione AI; il pacchetto di evidenze che hai costruito sopra risponde direttamente.