Articolo Pubblicazioni
Analisi forense dopo un attacco ransomware: quali tracce preservare
di Vincenzo Calabrò · Pubblicato il 14 novembre 2026
Abstract
Dopo un attacco ransomware la priorità è tornare operativi, e il rischio è cancellare nella fretta le tracce che servono per capire che cosa è successo. L’articolo indica gli errori da evitare, le evidenze da preservare nelle prime ore e le domande a cui l’analisi forense deve rispondere, cioè da dove è entrato l’attaccante, che cosa ha fatto, se ha sottratto dati e se è ancora presente.
Perché serve l’analisi
Ripristinare i sistemi senza capire l’attacco significa spesso farlo ripartire. L’attaccante può avere lasciato account, accessi remoti o strumenti pronti all’uso, e la vulnerabilità che ha sfruttato è ancora lì. L’analisi forense serve anche per gli obblighi di legge, perché la notifica di una violazione di dati personali o di un incidente significativo richiede di sapere quali dati e quali sistemi sono stati coinvolti, e per l’eventuale azione giudiziaria o la richiesta all’assicurazione.
Che cosa non fare
- spegnere di colpo tutti i sistemi, perché la memoria RAM contiene processi, connessioni e a volte chiavi che allo spegnimento si perdono;
- reinstallare o ripristinare i server colpiti prima di averne fatto una copia;
- cancellare la nota di riscatto, i file cifrati o gli eseguibili sospetti;
- contattare gli attaccanti senza una strategia e senza documentare ogni scambio;
- lasciare che ogni reparto intervenga per conto proprio senza un coordinamento.
Le tracce da preservare
Il primo passo è isolare i sistemi dalla rete, scollegandoli o bloccando il traffico a livello di switch e firewall, senza spegnerli quando possibile. Poi si acquisiscono, in ordine di volatilità, la memoria dei sistemi chiave ancora accesi, le immagini dei dischi o almeno delle macchine più significative, i log di firewall, VPN, proxy, controller di dominio, server di posta ed EDR, le console dei servizi cloud con i relativi registri di audit e i dati del sistema di backup. Insieme si conservano la nota di riscatto, alcuni file cifrati con gli originali, se disponibili, e i campioni del malware. I log hanno una conservazione limitata, e alcuni attaccanti li cancellano, quindi conviene esportarli subito in un luogo sicuro.
Le domande dell’analisi
- Accesso iniziale. Una VPN o un servizio esposto senza autenticazione a più fattori, una vulnerabilità non corretta, un’email di phishing, credenziali comprate da un intermediario;
- Movimenti. Quali account sono stati usati, come sono stati ottenuti i privilegi amministrativi, quali sistemi sono stati raggiunti e con quali strumenti, spesso gli stessi usati dagli amministratori;
- Esfiltrazione. Se e quali dati sono usciti, ricostruendo archivi compressi, strumenti di sincronizzazione verso servizi cloud e volumi di traffico anomali nei giorni precedenti la cifratura;
- Cifratura. Quando è partita, da quale sistema, con quale meccanismo di distribuzione e su quali dati;
- Persistenza. Account creati, attività pianificate, servizi e accessi remoti lasciati per rientrare.
La risposta prende la forma di una timeline che unisce gli eventi dei diversi sistemi, normalizzati su un unico fuso orario. È il documento che permette di decidere che cosa ripristinare, che cosa ricostruire da zero e che cosa comunicare.
Identificare la variante
La nota di riscatto, l’estensione dei file e i campioni permettono spesso di identificare la famiglia di ransomware. Il progetto No More Ransom raccoglie strumenti di decifratura gratuiti per alcune varianti, e i report pubblici sulle tecniche dei gruppi più attivi indicano dove cercare le tracce. Prima di qualunque tentativo di decifratura bisogna lavorare su copie dei file, mai sugli originali.
Le tracce più utili
Tabella 1. Fonti di evidenza e informazioni che possono restituire.
| Fonte | Che cosa può mostrare |
|---|---|
| Log della VPN e dei servizi esposti | Accessi da indirizzi insoliti, orari anomali, account usati per entrare |
| Registri eventi di Windows e del controller di dominio | Accessi con account privilegiati, creazione di utenti, attività pianificate, servizi installati |
| EDR e antivirus | Esecuzione di strumenti di attacco, tentativi di disattivare le difese, sequenza dei processi |
| Firewall e proxy | Connessioni verso server di comando e controllo e volumi di dati in uscita |
| Memoria dei sistemi accesi | Processi in esecuzione, connessioni attive, a volte chiavi o comandi usati |
| Sistema di backup | Accessi alla console, cancellazioni o modifiche delle politiche di conservazione |
| Servizi cloud | Accessi alle console, creazione di chiavi, download massivi da archivi condivisi |
La relazione finale
Al termine dell’analisi serve una relazione che risponda alle domande in modo comprensibile anche ai non tecnici. Deve descrivere la cronologia dell’attacco, il vettore di accesso iniziale, i sistemi e i dati coinvolti, le prove dell’esfiltrazione o della sua assenza, il livello di certezza delle conclusioni e le raccomandazioni per chiudere le vulnerabilità sfruttate. Questa relazione serve alla direzione per le decisioni, all’assicurazione per la liquidazione, alle autorità per le relazioni finali di notifica e, se si arriva a un procedimento, al pubblico ministero o al giudice.
Prepararsi prima
Molte analisi falliscono perché i log non c’erano. Conservare per almeno sei mesi, meglio dodici, i registri dei sistemi critici in un archivio separato e protetto, attivare la registrazione degli eventi che contano sui controller di dominio e sugli endpoint, sincronizzare gli orologi di tutti i sistemi e sapere in anticipo chi chiamare per l’analisi sono le condizioni che trasformano un’indagine di settimane in una di giorni.
Un punto spesso trascurato è la sincronizzazione degli orari. I sistemi colpiti possono avere orologi sfasati, fusi orari diversi o registrare in UTC, e la timeline si costruisce solo dopo aver normalizzato tutti gli eventi sullo stesso riferimento. Un errore di un’ora può far sembrare successivo alla cifratura un accesso che l’aveva preceduta, e cambiare così la ricostruzione dell’attacco.
Vedi anche: l’articolo del 2022 Ransomware: ottimizzare detection e incident response e l’articolo del 2014 Incident response: le fasi della gestione di un incidente informatico e il ruolo della digital forensics.
Vincenzo Calabrò | Ingegnere informatico specializzato in sicurezza informatica e investigazioni digitali. Funzionario informatico del Ministero dell'Interno; su incarico autorizzato si occupa di sicurezza informatica e di perizie informatiche forensi. Autore di articoli e saggi. Lecturer, Speaker, Trainer.Profili: Google Scholar · ORCID · ResearchGate · Academia.edu · CyberSecurity360 · AgendaDigitale · ICT Security Magazine · LinkedIn