Ransomware a sola esfiltrazione — il playbook di data extortion

Questo playbook si attiva quando l’organizzazione riceve una richiesta di riscatto o di estorsione fondata su dati rubati, senza cifratura dei file — o quando la cifratura, se presente, è incidentale e il ripristino non è il problema. Il segno distintivo è un messaggio che minaccia di pubblicare, vendere o avvisare i tuoi clienti e i regolatori se non paghi, spesso con un campione di file esfiltrati come prova e un countdown su un leak site.

Nell’ambito: il flusso di rilevazione, delimitazione, notifica e decisione sull’estorsione per un evento di data extortion. Fuori ambito: il ransomware cifrante classico in cui la priorità è ripristinare il servizio — per la meccanica della decisione pagare-o-ricostruire vedi il playbook di negoziazione ransomware, e per una catena guidata da un agente vedi contenimento del ransomware AI agentica. Il contesto giornalistico sullo spostamento del 2026 è nell’articolo sul ransomware a sola esfiltrazione.

Perché oggi è il modello prevalente: gruppi come Hunters International hanno spento il loro cifratore e si sono rilanciati come l’operazione di sola estorsione World Leaks, con uno strumento di esfiltrazione dedicato invece di un locker, e il mercato si è spostato dalla cifratura alla pura estorsione con il crollo dei tassi di pagamento.

Non c’è una chiave da attendere, quindi le scadenze sono esterne. Conta due clock dal momento in cui vieni a conoscenza:

• Il clock del leak site. L’attaccante fissa un countdown di pubblicazione, di solito pochi giorni, dopo il quale i campioni diventano una pubblicazione completa. È controllato dall’avversario e può essere spostato: non trattarlo come fisso.
• I clock di legge. Se sono usciti dati personali, l’art. 33 GDPR concede 72 ore per notificare all’autorità garante dalla conoscenza. L’art. 23 NIS2 (early warning 24h / 72h / 1 mese) e, per i soggetti finanziari, la notifica degli incidenti gravi DORA possono scattare sugli stessi fatti. Sono scadenze legali e non si spostano.

La trappola è spendere il primo giorno sul contenimento e rimandare la notifica. In un evento a sola esfiltrazione i dati sono già usciti al giorno zero, quindi il clock di notifica è spesso il vincolo più urgente. Avvia la timeline regolatoria in parallelo al lavoro tecnico, non dopo.

Obiettivo: stabilire se i dati stanno ancora uscendo e tagliare il canale, poi preservare le evidenze.

• Conferma che l’esfiltrazione sia reale e delimita la finestra: estrai la telemetria di egress (firewall, proxy, NetFlow, DNS) per il periodo sospetto e i 7-30 giorni precedenti — lo staging spesso precede la richiesta di settimane.
• Individua il canale di egress (upload su cloud storage, host controllato dall’attaccante, DNS tunneling, un SaaS legittimo usato come condotto) e bloccalo senza allertare un attore ancora attivo prima di aver delimitato gli accessi.
• Preserva prima di rimediare: snapshot degli host colpiti, esporta i log rilevanti e registra i timestamp — lo spegnimento stesso può distruggere le evidenze volatili che ti serviranno per la notifica.
• Ruota le credenziali e revoca sessioni e token per ogni identità nel percorso di accesso; gli attori di data theft mantengono spesso un secondo punto d’appoggio.
• Apri il log della timeline interna e avvisa il DPO e il referente legale in parallelo al SOC: i loro clock sono già partiti.

Checklist: finestra di egress delimitata; canale individuato e bloccato; snapshot forensi acquisiti; credenziali e token ruotati; log della timeline aperto; DPO e legale coinvolti.

Obiettivo: trasformare ‘dicono di aver preso dei dati’ in un inventario difendibile di ciò che è uscito davvero, perché sia l’obbligo di notifica sia l’esposizione all’estorsione dipendono dai dettagli.

• Ricostruisci l’insieme esfiltrato da volume di egress, file share e database consultati e dai campioni di prova dell’attaccante. Confronta i campioni dichiarati con i record reali: bluff e gonfiature sono comuni.
• Classifica i dati: dati personali (che fanno scattare il GDPR), categorie particolari o dati sanitari, record finanziari regolati, segreti industriali, dati di terzi che tratti per altri (che spostano l’obbligo di notifica lungo la catena — vedi notifica violazione SaaS di terze parti).
• Mappa ogni categoria di dati al suo regime di notifica e alla scadenza prima che scada il termine GDPR di 72 ore. Sotto-delimitare per evitare di notificare è l’errore che trasforma un incidente in una sanzione.
• Decidi ora la posizione di comunicazione verso clienti e partner, non dopo che la pubblicazione te la impone.

Checklist: inventario esfiltrato ricostruito; campioni dell’attaccante verificati sui dati reali; categorie di dati classificate; mappa di notifica per regime costruita; posizione di comunicazione redatta.

Obiettivo: prendere la decisione di pagamento sulle evidenze, poi chiudere il cerchio. Nei casi a sola esfiltrazione il pagamento non ripristina nulla: compra una promessa di cancellare dati che non puoi verificare siano stati cancellati, e gli attaccanti spesso ri-estorcono o vendono comunque.

• Verifica prima l’esposizione alle sanzioni. Un pagamento a un soggetto sanzionato comporta un rischio sanzionatorio a responsabilità oggettiva; vale per i pagamenti da data extortion, non solo per quelli di decifratura. Non pagare senza screening OFAC o del regime pertinente e via libera del legale.
• Pesa il tasso di base reale. I dati Coveware del Q3 2026 mostrano che quasi l’80% degli incidenti si risolve ormai senza riscatto, e il tasso di pagamento per la sola esfiltrazione è sceso al minimo storico del 15%: pagare è l’eccezione, non la regola.
• Assumi comunque la pubblicazione. Costruisci il piano che presume che i dati diventino pubblici: persone notificate, reset delle credenziali, monitoraggio frodi, legal hold. Una promessa di cancellazione non è un controllo.
• Chiudi con una relazione finale: ambito verificato, notifiche inviate e quando, stato della remediation e la causa radice del divario di rilevazione (come lo staging e l’egress sono passati inosservati).

Checklist: screening sanzioni eseguito; decisione registrata con motivazione e approvatore; piano assumi-pubblicazione eseguito; notifiche inviate; relazione finale con analisi del divario di rilevazione.

Lungo rilevazione, delimitazione ed eventuale notifica, tieni pronto (firmato, con timestamp e catena di custodia):

• Export della telemetria di egress sulla finestra dell’incidente più 7-30 giorni di baseline.
• L’analisi di individuazione del canale (come e dove sono usciti i dati).
• L’inventario esfiltrato ricostruito, con i campioni dell’attaccante confrontati ai record reali.
• La mappatura di classificazione dei dati verso ciascun regime di notifica.
• I log di contenimento e di rotazione credenziali con timestamp.
• Il record dello screening sanzioni e il memo di decisione sul pagamento.
• Le notifiche inviate, per regime, con timestamp.

La parte difficile di un caso a sola esfiltrazione è provare cosa è uscito e quando — e la maggior parte dei team non ci riesce, perché nulla sul filo veniva osservato in modo comportamentale. È il divario che un livello di analisi del traffico con AI on-premise è costruito per colmare: un modello di deep learning con quattro teste di inferenza parallele (traffico sospetto, classificazione malware, identificazione del tipo di attacco, fingerprinting applicativo) che gira sulla GPU dell’apparato a velocità di linea multi-gigabit, segnalando lo staging e l’egress anomalo — ASN di destinazione mai visti, volume in uscita sostenuto da un host che di norma solo riceve, picchi di DNS-over-HTTPS — mentre accade, non nel digest del SIEM del mattino dopo. Poiché gira on-premise su modelli privati, il traffico e le evidenze non lasciano mai il perimetro. Il lato offensivo chiude il cerchio: un red team AI autonomo che prova in anticipo il percorso di esfiltrazione trasforma ‘i dati possono uscire inosservati’ in un rilievo testato con una prova firmata, invece di una domanda a cui rispondi per la prima volta durante l’incidente.

Schemi osservati in organizzazioni analoghe:

• Trattarlo come un incidente di ripristino. Ripristinare dal backup e dichiarare vittoria, mentre l’attaccante detiene ancora i dati e il clock di notifica scorre non gestito.
• Aspettare la certezza prima di notificare. I clock GDPR (72 ore) e NIS2 partono dalla conoscenza; una notifica preliminare è attesa, e sotto-dichiarare per guadagnare tempo è l’errore più costoso.
• Fidarsi della promessa di cancellazione. Pagare e chiudere il fascicolo, senza un piano assumi-pubblicazione — e poi trovarsi mesi dopo con una pubblicazione o una ri-estorsione e nessuna risposta pronta.
• Delimitare a partire dalle dichiarazioni dell’attaccante. Accettare l’inventario della richiesta invece di ricostruire cosa è uscito davvero; porta sia a sovra-notificare sia a mancare categorie.
• Nessuna visibilità sull’egress. Scoprire il furto solo dalla richiesta di riscatto, perché nulla osservava il comportamento in uscita — la causa radice più comune, e quella che decide se avevi qualche possibilità di fermarlo.

Un singolo evento di furto dati fa scattare di solito più regimi, ciascuno con il suo clock e la sua autorità, sulla stessa base di evidenze:

• Art. 33 GDPR — 72 ore all’autorità garante quando sono usciti dati personali; l’art. 34 aggiunge la notifica alle persone interessate quando il rischio è elevato (una pubblicazione lo qualifica di regola).
• Art. 23 NIS2 — early warning 24h / notifica 72h / relazione finale 1 mese per soggetti essenziali e importanti.
• DORA, notifica degli incidenti gravi per i soggetti finanziari, con scadenze proprie.
• Catene di responsabile del trattamento — se i dati rubati appartengono ai tuoi clienti, scatta anche il dovere di notificarli lungo la catena; vedi notifica violazione SaaS di terze parti.

In ogni caso il record sottostante è lo stesso; le notifiche sono sintesi diverse di un’unica base di evidenze. Costruiscila una volta ed esporta per regime, invece di gestire percorsi di evidenze paralleli sotto clock simultanei.