Esfiltrazione dati: cos'è e come si rileva in azienda

L'esfiltrazione dei dati (data exfiltration) è il trasferimento non autorizzato di dati da un'organizzazione verso un luogo controllato da altri: il server di un attaccante, un cloud storage, una chiavetta USB. Si rileva dal comportamento: file sensibili letti e subito inviati verso destinazioni insolite, volumi in uscita anomali, strumenti di compressione o sincronizzazione usati fuori dalla norma.

Di seguito: come la descrive MITRE ATT&CK, per quali strade escono i dati, quali segnali guardare nei log, cosa riduce il rischio e quali obblighi scattano quando i dati sono usciti davvero.

Cos'è l'esfiltrazione dei dati

Il riferimento comune per chi lavora in un SOC è MITRE ATT&CK, la base di conoscenza pubblica delle tecniche osservate negli attacchi reali. Lì l'esfiltrazione è una tattica a sé, la TA0010 (Exfiltration): raccoglie le tecniche con cui un avversario porta fuori i dati dalla rete della vittima. MITRE aggiunge che, dopo averli raccolti, gli attaccanti spesso li impacchettano per non farsi notare durante il trasferimento, comprimendoli e cifrandoli, e che li fanno uscire di solito sul canale di comando e controllo o su un canale alternativo, a volte limitando la dimensione dei singoli invii.

Esfiltrazione e data breach non sono sinonimi

Il GDPR (art. 4, punto 12) definisce la violazione dei dati personali come «la violazione di sicurezza che comporta accidentalmente o in modo illecito la distruzione, la perdita, la modifica, la divulgazione non autorizzata o l'accesso ai dati personali trasmessi, conservati o comunque trattati». Il data breach è quindi la categoria larga, che comprende anche la perdita accidentale o un ransomware che cifra senza copiare. L'esfiltrazione è un modo specifico di arrivarci: un trasferimento deliberato verso l'esterno. Riguarda anche dati non personali, come progetti, offerte o codice sorgente, che il GDPR non copre.

Cosa succede prima che i dati escano

Due passaggi precedono quasi sempre l'uscita, e MITRE li classifica nella tattica di raccolta (Collection), non in quella di esfiltrazione:

• Staging (T1074, Data Staged): i dati raccolti vengono concentrati in una cartella o in un sistema, anche in un'istanza cloud creata apposta, per ridurre le connessioni verso il server di controllo e farsi notare meno.
• Archiviazione (T1560, Archive Collected Data): i dati vengono compressi per inviarne meno e cifrati per nasconderne il contenuto a chi ispeziona il traffico.

Avvengono ancora dentro la rete: chi se ne accorge qui ferma l'attacco prima della perdita.

Come escono i dati: le tecniche principali

Nella versione attuale di ATT&CK (v20) la tattica Exfiltration elenca dieci tecniche. Queste sono le più utili da conoscere per chi gestisce una rete aziendale:

• Sul canale di comando e controllo (T1041, Exfiltration Over C2 Channel): i dati rubati viaggiano dentro le comunicazioni che il malware ha già aperto con l'attaccante, con lo stesso protocollo.
• Su un protocollo alternativo (T1048, Exfiltration Over Alternative Protocol): FTP, SMTP, HTTP/S, DNS, SMB o qualsiasi altro protocollo diverso da quello di controllo, eventualmente cifrato o offuscato, e a volte verso una destinazione diversa dal server principale.
• Su un servizio web legittimo (T1567, Exfiltration Over Web Service): cloud storage, repository di codice, siti di testo condiviso, webhook. Funziona perché, spiega MITRE, i computer dell'azienda parlano già con quei servizi, il firewall può già lasciarli passare e il traffico è cifrato in TLS.
• Verso un altro account cloud (T1537, Transfer Data to Cloud Account): i dati passano a un account dell'attaccante sullo stesso provider, anche tramite condivisioni, sincronizzazioni o backup. Chi guarda solo i grandi trasferimenti verso l'esterno può non vederlo.
• Su un supporto fisico (T1052, Exfiltration Over Physical Medium): disco esterno, chiavetta USB, telefono. MITRE la cita in particolare per le reti isolate da Internet.
• A pezzi e a orari scelti (T1030, Data Transfer Size Limits, e T1029, Scheduled Transfer): i dati escono in blocchi di dimensione fissa, sotto le soglie che farebbero scattare un alert, oppure solo in certe fasce orarie, per confondersi con il traffico normale.

L'ultima tecnica aggiunta è la T1700 (AI-Enabled Exfiltration), creata da MITRE il 22 settembre 2026: un attaccante usa la prompt injection, diretta o indiretta, per indurre un assistente o un agente AI aziendale a usare i propri collegamenti a strumenti e dati per portare informazioni all'esterno.

Esfiltrazione e ransomware: prima copiano, poi cifrano

In molti attacchi ransomware i dati vengono copiati fuori prima della cifratura, così l'attaccante può minacciare di pubblicarli anche se l'azienda ripristina tutto dai backup: è il meccanismo della cosiddetta doppia estorsione.

Le schede MITRE lo documentano con casi concreti. Per la tecnica di esfiltrazione verso il cloud storage (T1567.002) riportano che Indrik Spider ha esfiltrato dati con Rclone o MEGASync prima di distribuire il ransomware, e che i gruppi Akira e Medusa hanno usato Rclone per portare i dati delle vittime su servizi cloud. Rclone è un programma legittimo di sincronizzazione che, secondo MITRE, può inviare dati verso servizi come Dropbox, Google Drive, Amazon S3 e MEGA. Lo strumento è pulito: è l'uso che non lo è.

Per chi subisce un ransomware la conseguenza è pratica: la domanda sono usciti dei dati? decide gli obblighi di notifica, e ci torniamo più sotto. L'abbiamo analizzata nel dettaglio in ransomware e GDPR: notifica al Garante e sanzioni.

Quando l'esfiltrazione arriva da dentro

Non serve un attaccante esterno. Le linee guida EDPB 01/2021 sugli esempi di notifica (versione 2.0 del 14 dicembre 2021) descrivono il caso di un dipendente che, durante il periodo di preavviso, copia i contatti dei clienti dal database aziendale, a cui aveva accesso legittimo per lavoro, e mesi dopo li usa per la propria nuova attività.

L'EDPB riconosce che possono essere i casi più difficili da prevenire, perché l'accesso è autorizzato, e indica alcune misure: valutare la revoca di alcuni accessi a chi ha comunicato le dimissioni, tenere log degli accessi che permettano di registrare e segnalare quelli indesiderati, impedire la copia o il download dei dati su supporti rimovibili. Nel caso descritto la conclusione è la notifica all'autorità di controllo, senza obbligo di comunicazione ai clienti, oltre alla documentazione interna.

Come si rileva un'esfiltrazione

Il punto di partenza è accettare che una soglia sul traffico in uscita non basta: le tecniche T1030 e T1029 esistono proprio per restarci sotto. Le strategie di rilevamento che MITRE associa alle tecniche di esfiltrazione guardano invece le sequenze di eventi e le deviazioni dalla normalità. I segnali principali:

1. Lettura di file sensibili seguita da una connessione insolita. Un processo apre documenti riservati e subito dopo avvia un trasferimento verso una destinazione rara, magari con traffico cifrato o con un rapporto anomalo tra byte inviati e ricevuti.
2. Processi che non dovrebbero parlare con l'esterno. Programmi che normalmente non generano traffico di rete e che all'improvviso inviano volumi rilevanti, anche su HTTPS o DNS.
3. Compressione e poi caricamento. Uno strumento di archiviazione (per esempio tar o gzip) seguito da invii verso servizi di cloud storage, oppure curl, wget, rclone o script che caricano file su quei servizi.
4. Applicazioni d'ufficio che caricano dati. Excel o PowerShell che leggono file grandi e poi fanno richieste HTTPS di caricamento verso domini di cloud storage.
5. Protocolli, orari e volumi fuori profilo. Trasferimenti su FTP, SMB, SMTP o DNS da processi non standard, fuori orario o con volumi insolitamente alti, compreso il tunneling DNS.
6. Movimenti nel cloud. Chiamate alle API o alla riga di comando del provider che spostano o sincronizzano file da bucket sensibili verso destinazioni esterne.

Nessuno di questi segnali, da solo, prova un attacco: un amministratore che fa un backup su un cloud esterno produce eventi simili. Servono log di endpoint, rete, proxy, DNS e cloud raccolti in un unico punto, per esempio un SIEM, una baseline di cosa è normale per quell'utente, quel server, quell'orario, e qualcuno che legga gli alert in tempi brevi.

La centralizzazione conta anche per un motivo meno ovvio. Nel caso 1 delle linee guida EDPB, l'azienda ha potuto escludere con certezza l'esfiltrazione perché aveva log di tutti i flussi di dati in uscita, posta compresa, e quei log non mostravano trasferimenti nel periodo dell'attacco. Nel caso 5, invece, il kit installato sul server web permetteva all'attaccante di cancellare ogni traccia dell'esfiltrazione, ed è stato scoperto solo un mese dopo l'installazione. Log conservati solo sulla macchina compromessa non dimostrano niente, e un mese di permanenza è esattamente il problema del dwell time.

Come si riduce il rischio

Le mitigazioni che MITRE associa a queste tecniche:

• Data loss prevention (M1057): strumenti che riconoscono i dati sensibili e possono bloccarne l'invio su protocolli non cifrati o il caricamento dal browser.
• Filtro del traffico (M1037): proxy obbligatori, server DNS dedicati e solo quei sistemi autorizzati a uscire sulle rispettive porte, invece di tutti i computer della rete.
• Segmentazione (M1030): regole del firewall che lasciano entrare e uscire solo le porte e il traffico necessari.
• Contenuti web (M1021): un proxy web che applica una politica sui servizi esterni ammessi e blocca quelli non autorizzati, cloud storage personali compresi.
• Accessi al cloud storage (M1018, M1022): permessi per gruppi e ruoli, liste di controllo sugli oggetti, token di accesso temporanei invece di credenziali permanenti, soprattutto per chi sta fuori dall'azienda.
• Agenti AI con permessi minimi: per la T1700 MITRE indica di limitare i permessi su file e cartelle a cui gli agenti AI accedono e di isolarli dall'esterno quando possibile.

Prima di tutto questo va saputo dove stanno i dati che contano: una policy DLP scritta senza un inventario dei dati sensibili blocca a caso.

Se i dati sono usciti: cosa dicono GDPR e NIS2

Quando l'esfiltrazione riguarda dati personali, l'art. 33 del GDPR chiede al titolare di notificare la violazione al Garante senza ingiustificato ritardo e, ove possibile, entro 72 ore dal momento in cui ne è venuto a conoscenza, a meno che sia improbabile un rischio per i diritti e le libertà delle persone. Se la notifica arriva dopo le 72 ore, va accompagnata dai motivi del ritardo. Le informazioni non ancora disponibili si possono fornire in fasi successive.

L'art. 34 aggiunge la comunicazione alle persone interessate quando il rischio è elevato. Non è richiesta, fra gli altri casi, se i dati violati erano resi incomprensibili a chi non è autorizzato, per esempio con la cifratura. Nel caso 5 dell'EDPB, un codice malevolo sul sito di un'agenzia per il lavoro ha esposto fino a 213 moduli di candidatura: il rischio è elevato, quindi servono notifica al Garante e comunicazione ai candidati. In ogni caso, notificata o no, la violazione va documentata nel registro interno (art. 33, par. 5). La procedura completa è in procedura data breach e registro delle violazioni.

Per i soggetti NIS2 c'è un secondo canale, indipendente dal primo (per chi è entrato nell'elenco NIS nel corso del 2026 l'obbligo di notifica decorre dal 1° gennaio 2027). L'art. 25 del D.Lgs. 138/2024 prevede, per gli incidenti significativi, una pre-notifica al CSIRT Italia entro 24 ore e una notifica entro 72 ore da quando se ne è venuti a conoscenza, con gli indicatori di compromissione se disponibili, e una relazione finale entro un mese dalla notifica. Come capire se l'incidente è significativo e cosa scrivere lo trovi in notifica degli incidenti NIS2.

In sintesi: l'esfiltrazione è il trasferimento non autorizzato di dati fuori dall'organizzazione, ed è la fase in cui un'intrusione diventa una perdita. Passa da canali che sembrano normali (cloud storage, HTTPS, DNS, strumenti di sincronizzazione legittimi) e può precedere un ransomware. Si rileva correlando accesso ai dati e traffico in uscita su log centralizzati, rispetto a una baseline. Quando escono dati personali scattano gli artt. 33 e 34 del GDPR, e per i soggetti NIS2 anche la notifica al CSIRT Italia.

Una domanda utile per partire: se stanotte un server caricasse decine di gigabyte su un cloud storage, chi se ne accorgerebbe, e quando? Il quadro più ampio è nella panoramica sulle minacce informatiche. Se vuoi capire quanto del traffico in uscita della tua rete è visibile oggi, trovi come lavoriamo nella pagina cybersecurity.