Incident response forense e ransomware

Introduzione

Un incidente ransomware non coincide necessariamente con la comparsa di una schermata di riscatto o con l’improvvisa impossibilità di aprire i file.

La compromissione può essere iniziata:

• ore prima;
• giorni prima;
• settimane prima;
• attraverso una casella email;
• mediante un account VPN;
• sfruttando un servizio esposto;
• attraverso un fornitore;
• mediante credenziali sottratte;
• mediante una sessione cloud;
• mediante malware già presente su un endpoint.

Prima della cifratura, il soggetto ostile può aver:

- ottenuto un primo accesso;
- raccolto credenziali;
- enumerato utenti, server e domini;
- aumentato i privilegi;
- disabilitato strumenti di sicurezza;
- creato account o persistenze;
- raggiunto controller di dominio;
- individuato i backup;
- copiato dati;
- eliminato copie di ripristino;
- distribuito il componente di cifratura.

Il ransomware moderno può comprendere anche il furto di informazioni e la minaccia di pubblicazione. In alcuni casi l’organizzazione subisce soltanto l’estorsione basata sui dati sottratti, senza una cifratura significativa dei sistemi. La versione corrente del profilo NIST dedicato al ransomware, IR 8374 Rev. 1, pubblicata l’11 giugno 2026, considera l’intero rischio ransomware all’interno delle funzioni Govern, Identify, Protect, Detect, Respond e Recover del Cybersecurity Framework 2.0. NIST IR 8374 Rev. 1

La domanda iniziale dell’azienda è spesso:

La domanda tecnica corretta è più articolata:

Ripristinare rapidamente una macchina senza comprendere:

• credenziali compromesse;
• persistenze;
• servizi vulnerabili;
• sessioni attive;
• account privilegiati;
• infrastrutture di backup;
• possibile esfiltrazione;

può determinare una nuova compromissione.

Allo stesso tempo, attendere un’acquisizione forense completa mentre il ransomware continua a propagarsi può aumentare il danno.

L’incident response forense richiede quindi un equilibrio tra quattro esigenze:

1. proteggere persone e servizi essenziali;
2. contenere l’attacco;
3. conservare le prove;
4. ripristinare l’operatività in modo controllato.

La guida NIST SP 800-61 Rev. 3, pubblicata nell’aprile 2025, integra la risposta agli incidenti nella gestione complessiva del rischio, anziché trattarla come un’attività isolata da avviare soltanto dopo un allarme.

Sintesi operativa

1. attivare il responsabile dell’incidente e il gruppo decisionale;
2. verificare se vi siano rischi per persone, servizi essenziali o impianti;
3. identificare i sistemi manifestamente interessati;
4. isolare endpoint, server e segmenti compromessi;
5. evitare lo spegnimento indiscriminato;
6. usare canali di comunicazione esterni all’infrastruttura compromessa;
7. preservare nota di riscatto, file cifrati, log e alert;
8. registrare ogni azione con data, ora, operatore e motivazione;
9. acquisire memoria volatile quando utile e compatibile col contenimento;
10. preservare immagini o raccolte mirate degli endpoint prioritari;
11. esportare immediatamente log prossimi alla scadenza;
12. verificare account, sessioni, MFA, VPN e privilegi amministrativi;
13. individuare il possibile accesso iniziale;
14. ricostruire movimento laterale, persistenza ed eventuale esfiltrazione;
15. proteggere backup, hypervisor, storage e console amministrative;
16. verificare se l’ambiente di backup sia stato raggiunto;
17. calcolare l’hash degli elementi acquisiti;
18. costruire una timeline normalizzata;
19. delimitare il perimetro realmente compromesso;
20. eliminare vettori, persistenze e credenziali esposte;
21. predisporre un ambiente pulito per il ripristino;
22. ripristinare secondo priorità operative e dipendenze;
23. monitorare i sistemi prima e dopo la riconnessione;
24. valutare data breach, NIS2, DORA e altri obblighi applicabili;
25. coordinare legale, DPO, assicurazione, autorità e fornitori;
26. documentare decisioni, limiti e dati mancanti;
27. produrre una relazione tecnica riproducibile;
28. completare una revisione post-incidente.

1. Avvertenza preliminare

Le procedure descritte devono essere utilizzate esclusivamente:

• sui sistemi dell’organizzazione committente;
• su dispositivi e account amministrati legittimamente;
• con autorizzazione del titolare;
• nell’ambito di incarichi difensivi, aziendali o peritali;
• nel rispetto della riservatezza;
• secondo le procedure di sicurezza dell’organizzazione;
• con il coordinamento dei soggetti responsabili.

Non è lecito:

• accedere all’infrastruttura del presunto autore;
• utilizzare credenziali sottratte;
• entrare in server di comando e controllo;
• tentare di identificare soggetti mediante accessi non autorizzati;
• installare strumenti su dispositivi di terzi;
• intercettare traffico esterno al perimetro autorizzato;
• acquistare o utilizzare dati rubati;
• impiegare chiavi o token appartenenti a terzi;
• colpire, disabilitare o modificare sistemi ostili;
• effettuare attività di “hack back”.

Il perito informatico può:

• acquisire;
• conservare;
• analizzare;
• correlare;
• documentare;
• formulare ipotesi tecniche;
• indicare limiti;
• supportare la risposta.

Non sostituisce:

• direzione aziendale;
• avvocato;
• DPO;
• autorità giudiziaria;
• CSIRT;
• assicuratore;
• consulente del lavoro;
• revisore;
• responsabile della continuità operativa.

2. Che cos’è l’incident response forense

L’incident response è l’insieme coordinato di attività utilizzate per:

• prepararsi agli incidenti;
• rilevarli;
• valutarli;
• contenerli;
• analizzarli;
• eradicarne le cause;
• ripristinare i servizi;
• ridurre la probabilità di recidiva.

L’aggettivo forense indica che l’attività viene svolta preservando, per quanto possibile:

• integrità dei dati;
• tracciabilità;
• riproducibilità;
• catena di custodia;
• separazione tra dato e interpretazione;
• documentazione delle modifiche prodotte dagli operatori.

L’incident response non è identico alla digital forensics tradizionale.

Nel ransomware le due discipline devono procedere insieme.

3. Che cos’è un ransomware

Un ransomware è un insieme di strumenti o attività che limita la disponibilità di sistemi o dati e utilizza tale situazione per richiedere denaro o ottenere un altro vantaggio.

Può:

• cifrare file;
• cifrare dischi;
• cifrare macchine virtuali;
• rendere indisponibile un database;
• distruggere configurazioni;
• eliminare backup;
• bloccare account;
• sottrarre dati;
• minacciare la pubblicazione;
• contattare clienti o dipendenti;
• utilizzare i dati per ulteriori frodi.

MITRE ATT&CK classifica la cifratura a fini di impatto come tecnica T1486 — Data Encrypted for Impact e le attività volte a eliminare o disabilitare strumenti di recupero come T1490 — Inhibit System Recovery.

3.1 Ransomware a cifratura

Il soggetto ostile cifra:

• documenti;
• cartelle condivise;
• server;
• database;
• hypervisor;
• backup raggiungibili.

3.2 Doppia estorsione

Comprende:

cifratura
+
sottrazione di dati
+
minaccia di pubblicazione

3.3 Tripla estorsione

Può aggiungere:

• contatti ai clienti;
• attacchi DDoS;
• pressioni sui partner;
• minacce ai dipendenti;
• ulteriori richieste economiche.

3.4 Data extortion senza cifratura

Il soggetto ostile dichiara di aver sottratto dati e richiede denaro senza bloccare significativamente i sistemi.

3.5 Wiper mascherato da ransomware

Il malware può distruggere dati senza una reale possibilità di ripristino, pur mostrando una richiesta di riscatto.

La classificazione richiede analisi del codice, del comportamento e delle conseguenze. La sola nota di riscatto non basta.

4. Modello operativo aggiornato

Il modello NIST attuale integra l’incident response nel Cybersecurity Framework 2.0:

Govern
Identify
Protect
Detect
Respond
Recover

Preparazione, ruoli, inventario, gestione del rischio e protezione devono esistere prima dell’incidente. Le attività di rilevazione, risposta e recupero dipendono dalla maturità delle funzioni precedenti. NIST SP 800-61 Rev. 3

Per il presente capitolo utilizzeremo il seguente flusso operativo:

preparazione
→ rilevazione
→ qualificazione
→ contenimento
→ acquisizione forense
→ analisi
→ eradicazione
→ recupero
→ monitoraggio
→ lesson learned

Le fasi possono sovrapporsi.

Esempio:

• mentre un gruppo acquisisce la memoria;
• un secondo gruppo isola la rete;
• un terzo protegge i backup;
• il legale valuta gli obblighi;
• la direzione attiva la continuità operativa.

5. Obiettivi dell’intervento

L’intervento deve rispondere a domande concrete.

5.1 Obiettivi di sicurezza

- interrompere la propagazione;
- impedire ulteriori accessi;
- proteggere backup e credenziali;
- ridurre il danno;
- preservare servizi essenziali.

5.2 Obiettivi forensi

- identificare il primo accesso osservabile;
- individuare gli asset coinvolti;
- ricostruire la timeline;
- identificare account e sessioni;
- individuare persistenze;
- verificare eventuale esfiltrazione;
- identificare malware e strumenti;
- preservare reperti;
- documentare le lacune.

5.3 Obiettivi operativi

- determinare cosa ripristinare;
- stabilire l’ordine di recupero;
- verificare i backup;
- creare un ambiente pulito;
- evitare la reinfezione;
- riprendere i servizi controllando il rischio residuo.

5.4 Obiettivi organizzativi

- attivare le responsabilità;
- informare management;
- coordinare fornitori;
- rispettare obblighi;
- documentare decisioni;
- mantenere comunicazioni affidabili.

6. Evento, alert e incidente

Non ogni alert EDR è un incidente ransomware.

6.1 Evento

Un sistema registra un’attività.

Esempio:

esecuzione di powershell.exe

6.2 Alert

Una regola identifica un comportamento ritenuto sospetto.

Esempio:

PowerShell avviato con argomenti codificati

6.3 Incidente

L’organizzazione stabilisce che uno o più eventi hanno compromesso o minacciato:

• riservatezza;
• integrità;
• disponibilità;
• autenticità;
• continuità.

6.4 Ransomware confermato

Possibili elementi:

• file cifrati;
• nota di riscatto;
• processi di cifratura;
• alert coerenti;
• estensioni modificate;
• condivisioni indisponibili;
• attività su backup;
• comunicazione estorsiva;
• indicatori noti.

6.5 Ransomware sospetto

Esempi:

• numerosi file rinominati;
• picco di scritture;
• shadow copy eliminate;
• tool amministrativo inatteso;
• EDR disattivato;
• accesso anomalo ai backup.

La classificazione deve rimanere provvisoria finché non viene confermata.

7. Quando attivare formalmente l’incident response

L’attivazione può essere necessaria quando si rileva:

[ ] cifratura di file;
[ ] nota di riscatto;
[ ] perdita simultanea di più servizi;
[ ] account amministrativi anomali;
[ ] accesso ai backup;
[ ] esfiltrazione sospetta;
[ ] strumenti di sicurezza disattivati;
[ ] movimento laterale;
[ ] compromissione di un hypervisor;
[ ] compromissione del controller di dominio;
[ ] attività ostile ancora in corso;
[ ] impatto su dati personali;
[ ] impatto su servizi essenziali;
[ ] richiesta estorsiva.

L’attivazione deve indicare:

• chi ha dichiarato l’incidente;
• a quale ora;
• sulla base di quali elementi;
• quale gravità iniziale;
• quali team sono stati convocati;
• quali canali sono stati utilizzati.

8. Ruoli del gruppo di risposta

8.1 Incident commander

Coordina:

• priorità;
• decisioni;
• gruppi;
• aggiornamenti;
• escalation;
• passaggi tra fasi.

8.2 Responsabile tecnico

Coordina:

• isolamento;
• identità;
• reti;
• backup;
• ripristino;
• fornitori.

8.3 Responsabile forense

Coordina:

• acquisizioni;
• registri;
• catena di custodia;
• memoria;
• immagini;
• timeline;
• analisi.

8.4 Sicurezza e SOC

Gestiscono:

• EDR;
• SIEM;
• IOC;
• hunting;
• monitoraggio;
• contenimento remoto.

8.5 DPO e privacy

Valutano:

• dati personali;
• categorie;
• interessati;
• rischio;
• notifica;
• comunicazioni.

8.6 Legale

Valuta:

• obblighi;
• rapporti contrattuali;
• autorità;
• assicurazione;
• comunicazioni;
• eventuale interlocuzione estorsiva.

8.7 Continuità operativa

Gestisce:

• processi critici;
• modalità manuali;
• priorità;
• RTO;
• RPO;
• sedi alternative.

8.8 Comunicazione

Predispone:

• messaggi interni;
• comunicazioni ai clienti;
• rapporti con media;
• FAQ aziendali;
• aggiornamenti controllati.

9. Matrice decisionale iniziale

10. Sicurezza delle persone e dei servizi essenziali

Prima dell’acquisizione valutare:

• dispositivi medici;
• impianti;
• controllo accessi;
• videosorveglianza;
• sistemi antincendio;
• produzione;
• telecomunicazioni;
• trasporti;
• servizi sanitari;
• servizi pubblici.

In tali ambienti lo spegnimento può provocare conseguenze superiori all’attacco.

La decisione deve coinvolgere:

• responsabile impianto;
• sicurezza;
• ingegnere di processo;
• continuità;
• direzione;
• fornitore specializzato.

11. Protocollo dei primi quindici minuti

1. verificare la segnalazione;
2. annotare l’ora della rilevazione;
3. nominare un coordinatore;
4. aprire un registro dell’incidente;
5. utilizzare un canale di comunicazione affidabile;
6. identificare i sistemi manifestamente coinvolti;
7. scollegarli dalla rete quando possibile;
8. proteggere immediatamente backup e console amministrative;
9. preservare screenshot e note di riscatto;
10. non spegnere indiscriminatamente;
11. verificare account privilegiati;
12. informare direzione e responsabili tecnici;
13. impedire modifiche non coordinate;
14. assegnare un codice al caso;
15. registrare ogni azione.

CISA raccomanda di identificare e isolare immediatamente i sistemi interessati; quando non è possibile disconnetterli e la propagazione continua, lo spegnimento può essere utilizzato come misura estrema. CISA — I’ve Been Hit by Ransomware

12. Protocollo della prima ora

[ ] delimitare il primo perimetro;
[ ] esportare alert EDR;
[ ] esportare log SIEM;
[ ] acquisire eventi identity;
[ ] acquisire VPN e firewall;
[ ] bloccare account sospetti;
[ ] revocare sessioni;
[ ] proteggere hypervisor e backup;
[ ] acquisire memoria dagli host prioritari;
[ ] preservare campioni cifrati;
[ ] acquisire la nota di riscatto;
[ ] individuare server critici;
[ ] verificare cloud e SaaS;
[ ] verificare eventuale esfiltrazione;
[ ] contattare il fornitore IR, se previsto;
[ ] informare assicurazione secondo contratto;
[ ] attivare legale e DPO;
[ ] predisporre la continuità operativa;
[ ] evitare comunicazioni pubbliche premature;
[ ] aggiornare la gravità.

13. Protocollo delle prime ventiquattro ore

1. completare il censimento degli asset coinvolti;
2. preservare i log prima della scadenza;
3. acquisire endpoint rappresentativi;
4. acquisire controller di dominio e server prioritari;
5. ricostruire gli accessi iniziali;
6. verificare account, token, certificati e chiavi;
7. individuare persistenze;
8. identificare strumenti di movimento laterale;
9. ricostruire l’accesso ai backup;
10. verificare attività di staging ed esfiltrazione;
11. raccogliere indicatori di compromissione;
12. distribuire IOC validati al SOC;
13. verificare l’ambiente cloud;
14. predisporre il piano di reset delle identità;
15. verificare i restore point;
16. definire un ambiente di recupero pulito;
17. valutare data breach;
18. verificare NIS2, DORA e obblighi contrattuali;
19. coordinare eventuali autorità;
20. produrre un rapporto preliminare.

14. Cosa non fare

[ ] non riavviare tutti i sistemi;
[ ] non formattare immediatamente gli endpoint;
[ ] non cancellare il malware;
[ ] non eliminare la nota di riscatto;
[ ] non rinominare i file cifrati;
[ ] non eseguire decryptor sugli originali;
[ ] non collegare i backup alla rete compromessa;
[ ] non ripristinare prima di eliminare l’accesso iniziale;
[ ] non utilizzare account sospetti per acquisire;
[ ] non usare la posta compromessa per coordinarsi;
[ ] non caricare dati riservati su servizi pubblici;
[ ] non contattare autonomamente il soggetto estorsore;
[ ] non pagare senza un processo decisionale formalizzato;
[ ] non accusare un dipendente sulla base di un account;
[ ] non dichiarare che non vi è stata esfiltrazione per assenza di un singolo log;
[ ] non comunicare pubblicamente indicatori non verificati;
[ ] non modificare retention e policy senza registrarlo;
[ ] non eseguire scansioni pesanti sui sistemi instabili;
[ ] non affidarsi a una sola fonte;
[ ] non promettere il recupero completo.

15. Questionario iniziale

15.1 Rilevazione

1. Chi ha rilevato l’incidente?
2. A quale ora?
3. Su quale sistema?
4. Quale messaggio è comparso?
5. Quali file risultano cifrati?
6. Esiste una nota?
7. Quali servizi sono indisponibili?
8. È presente un alert EDR?
9. L’attività sembra ancora in corso?
10. Sono stati eseguiti riavvii?

15.2 Infrastruttura

1. Esiste Active Directory?
2. Quali hypervisor sono utilizzati?
3. Dove risiedono i backup?
4. Esistono copie offline o immutabili?
5. Quale EDR è installato?
6. Esiste un SIEM?
7. Quali cloud provider sono utilizzati?
8. Sono presenti VPN o RDP esposti?
9. Quali fornitori hanno accesso remoto?
10. Esiste un inventario aggiornato?

15.3 Identità

[ ] account amministrativi;
[ ] account di servizio;
[ ] account backup;
[ ] account cloud;
[ ] account VPN;
[ ] MFA;
[ ] certificati;
[ ] API key;
[ ] token;
[ ] utenze condivise.

15.4 Azioni già eseguite

Chiedere se l’organizzazione ha:

• spento sistemi;
• scollegato switch;
• disattivato account;
• eliminato file;
• riavviato server;
• ripristinato backup;
• modificato password;
• contattato l’attaccante;
• pubblicato comunicazioni;
• avviato antivirus;
• reinstallato agent;
• pagato somme.

16. Definire il quesito tecnico

Quesito improprio:

Quesiti tecnici corretti:

- individuare il primo evento di compromissione osservabile;
- delimitare i sistemi coinvolti;
- ricostruire gli account utilizzati;
- individuare il vettore iniziale;
- identificare persistenze e strumenti;
- verificare il movimento laterale;
- documentare accessi ai backup;
- verificare elementi compatibili con esfiltrazione;
- ricostruire la fase di cifratura;
- determinare quali dati e servizi fossero raggiungibili;
- indicare le condizioni tecniche per il recupero;
- descrivere i limiti dell’attribuzione.

17. Classificazione della gravità

La classificazione deve considerare:

• estensione;
• criticità;
• dati;
• durata;
• propagazione;
• identità;
• backup;
• sicurezza fisica;
• obblighi;
• dipendenze.

18. Delimitare il perimetro

Creare tre categorie.

18.1 Confermato compromesso

Elementi come:

• esecuzione malware;
• cifratura;
• persistenza;
• accesso ostile;
• IOC affidabile;
• attività EDR confermata.

18.2 Potenzialmente compromesso

Esempi:

• stessa subnet;
• stesse credenziali;
• sessione amministrativa;
• accesso da host compromesso;
• assenza di telemetria.

18.3 Nessuna evidenza di compromissione

Significa soltanto:

Non significa:

19. Mappa delle fonti

19.1 Endpoint

• memoria;
• disco;
• Windows Event Log;
• Sysmon;
• PowerShell;
• EDR;
• antivirus;
• browser;
• file system;
• registry;
• servizi;
• task;
• Prefetch;
• Amcache;
• SRUM;
• LNK;
• Jump List.

19.2 Linux e Unix

• journald;
• auditd;
• auth log;
• shell history;
• servizi;
• cron;
• SSH;
• processi;
• connessioni;
• file system.

19.3 Rete

• firewall;
• VPN;
• DNS;
• DHCP;
• proxy;
• NetFlow;
• packet capture;
• IDS/IPS;
• wireless;
• NAC.

19.4 Identità

• Active Directory;
• Entra ID;
• Google Workspace;
• MFA;
• RADIUS;
• PAM;
• SSO;
• token.

19.5 Cloud

• Microsoft 365;
• Azure;
• AWS;
• Google Cloud;
• SaaS;
• storage;
• backup;
• hypervisor.

19.6 Organizzazione

• inventario;
• ticket;
• turni;
• amministratori;
• fornitori;
• contratti;
• change management;
• continuità operativa.

Il metodo di acquisizione e correlazione dei registri è approfondito nel Capitolo 20 — Analisi di log aziendali, firewall, VPN e sistemi cloud.

20. Cartella del caso

CASO_RM_2026_021/
├── 00_incarico/
├── 01_verbali/
├── 02_registro_incidente/
├── 03_inventario/
├── 04_screenshot/
├── 05_note_riscatto/
├── 06_memoria/
├── 07_immagini_disco/
├── 08_raccolte_endpoint/
├── 09_windows/
├── 10_linux/
├── 11_edr_xdr/
├── 12_siem/
├── 13_firewall_vpn_dns/
├── 14_identita/
├── 15_cloud/
├── 16_backup/
├── 17_malware/
├── 18_file_cifrati/
├── 19_ioc/
├── 20_yara/
├── 21_pcap/
├── 22_hash/
├── 23_timeline/
├── 24_data_breach/
├── 25_notifiche/
├── 26_ripristino/
├── 27_report/
└── 28_relazione/

21. Registro dell’incidente

Ogni azione deve essere registrata.

Registrare anche:

• comandi;
• strumenti;
• errori;
• riavvii;
• reset;
• policy modificate;
• sistemi esclusi;
• decisioni.

22. Catena di custodia e hash

Per ogni reperto:

- identificativo;
- descrizione;
- origine;
- sistema;
- data;
- ora;
- fuso;
- operatore;
- metodo;
- strumento;
- versione;
- destinazione;
- dimensione;
- SHA-256;
- copie;
- trasferimenti;
- accessi.

La procedura completa è descritta nel Capitolo 2 — Catena di custodia, hash e verbale tecnico.

PowerShell

Get-FileHash -Algorithm SHA256 `
  -LiteralPath ".\HOST01-memory.raw"

Linux

sha256sum -- HOST01-memory.raw

macOS

shasum -a 256 -- HOST01-memory.raw

L’hash documenta l’identità binaria del file acquisito. Non dimostra che il dato fosse completo, autentico o non alterato prima dell’acquisizione.

23. Data, ora e sincronizzazione

Registrare:

- ora del sistema;
- ora UTC;
- timezone;
- sorgente NTP;
- scarto;
- ora EDR;
- ora SIEM;
- ora firewall;
- ora cloud;
- ora dell’acquisizione.

PowerShell

Get-Date -Format "yyyy-MM-ddTHH:mm:ss.fffK"
(Get-Date).ToUniversalTime().ToString("yyyy-MM-ddTHH:mm:ss.fffZ")
w32tm /query /status

Linux

date --iso-8601=ns
date -u --iso-8601=ns
timedatectl status

Non correggere silenziosamente gli eventi.

24. Contenimento e preservazione della prova

Il contenimento può modificare:

• sessioni;
• processi;
• memoria;
• connessioni;
• account;
• log;
• timestamp.

Queste modifiche non rendono l’attività scorretta quando sono necessarie.

Devono però essere documentate.

Esempio:

10:12 — processo ransomware osservato
10:14 — host isolato tramite EDR
10:15 — connessioni interrotte
10:18 — acquisizione RAM avviata

25. Isolamento dalla rete

Possibili modalità:

• isolamento EDR;
• rimozione cavo;
• disabilitazione porta switch;
• disconnessione Wi-Fi;
• VLAN di quarantena;
• blocco firewall;
• revoca VPN;
• network security group;
• blocco account.

25.1 Isolamento EDR

Vantaggi:

• rapido;
• centralizzato;
• mantiene il canale di gestione;
• preserva il sistema acceso.

Limiti:

• agent compromesso;
• console compromessa;
• host offline;
• comunicazione limitata;
• regole non applicate.

25.2 Rimozione del cavo

Può essere appropriata per un singolo endpoint.

Annotare:

• ora;
• porta;
• operatore;
• indirizzo;
• stato.

25.3 Segmentazione

Per ambienti estesi può essere necessario bloccare:

• SMB;
• RDP;
• WinRM;
• SSH;
• amministrazione remota;
• VPN;
• traffico east-west;
• accesso ai backup.

26. Spegnere o lasciare acceso?

Non esiste una regola universale.

26.1 Lasciare acceso quando

• la propagazione è contenuta;
• la memoria è rilevante;
• sono presenti chiavi o processi;
• il volume è cifrato ma montato;
• la sessione cloud è attiva;
• il sistema è stabile;
• l’acquisizione è immediatamente possibile.

26.2 Spegnere quando

• la cifratura continua;
• non è possibile isolare;
• l’host sta colpendo altri sistemi;
• vi è un rischio fisico;
• il danno aumenta rapidamente;
• non esiste capacità tecnica per un’acquisizione tempestiva.

26.3 Non eseguire un arresto ordinato senza valutarlo

Un arresto ordinato può:

• terminare processi;
• modificare log;
• scrivere sul disco;
• eliminare dati temporanei.

Uno spegnimento forzato può:

• corrompere file;
• perdere memoria;
• danneggiare database;
• perdere chiavi.

CISA considera lo spegnimento una misura estrema quando l’isolamento non è possibile e la diffusione continua. CISA

27. Contenimento degli endpoint

Per ogni endpoint:

[ ] isolare rete;
[ ] preservare stato;
[ ] acquisire ora;
[ ] identificare utente;
[ ] identificare processi;
[ ] identificare connessioni;
[ ] acquisire memoria;
[ ] acquisire raccolta mirata;
[ ] preservare EDR;
[ ] documentare cifratura;
[ ] calcolare hash;
[ ] etichettare.

Non applicare automaticamente la stessa procedura a:

• workstation;
• server;
• domain controller;
• hypervisor;
• dispositivo medico;
• sistema industriale.

28. Controller di dominio

La compromissione di un controller di dominio deve far presumere un rischio elevato per l’intera infrastruttura di identità.

Verificare:

• account Domain Admin;
• Enterprise Admin;
• servizi;
• ticket Kerberos;
• Golden Ticket o persistenze analoghe;
• GPO;
• account creati;
• reset password;
• deleghe;
• replica;
• certificati;
• AD CS;
• trust;
• backup del dominio.

Non è sufficiente:

- cambiare la password di un singolo amministratore;
- rimuovere il malware da un endpoint;
- ripristinare il file server.

Può essere necessario predisporre un piano di recupero dell’identità, con reset coordinato e verifica delle dipendenze.

29. Hypervisor e macchine virtuali

Possibili target:

• VMware ESXi;
• Hyper-V;
• Proxmox;
• console di gestione;
• storage;
• datastore;
• backup hypervisor.

Acquisire:

- audit amministrativo;
- accessi;
- task;
- eventi;
- shell;
- configurazioni;
- inventario VM;
- snapshot;
- file di log;
- account;
- API;
- attività del backup.

Non confondere snapshot e backup.

Uno snapshot:

• dipende dallo storage;
• può essere eliminato;
• può essere cifrato insieme al datastore;
• non sostituisce una copia separata.

30. NAS e storage

Verificare:

- account amministrativi;
- SMB/NFS;
- audit;
- snapshot;
- replica;
- cloud sync;
- app installate;
- servizi esposti;
- firmware;
- accessi;
- condivisioni.

Un NAS può risultare cifrato:

• da un client Windows;
• da credenziali SMB;
• da malware nativo;
• mediante console amministrativa;
• mediante exploit.

La presenza di file cifrati sul NAS non dimostra che il malware sia stato eseguito sul NAS.

31. Cloud e SaaS

Un ransomware può colpire il cloud attraverso:

• account compromessi;
• sincronizzazione;
• API;
• eliminazione di versioni;
• modifica retention;
• chiavi;
• service principal;
• token;
• account di servizio.

Verificare:

[ ] login;
[ ] sessioni;
[ ] ruoli;
[ ] app OAuth;
[ ] API key;
[ ] condivisioni;
[ ] eliminazioni;
[ ] versioning;
[ ] retention;
[ ] backup;
[ ] audit.

L’acquisizione approfondita sarà trattata nel Capitolo 23 — Cloud forensics: Google, Microsoft, Dropbox e backup.

32. Protezione immediata dei backup

I backup devono essere isolati prima che l’attaccante possa:

• cancellarli;
• cifrarli;
• modificarne la retention;
• compromettere le credenziali;
• distruggere i cataloghi;
• revocare chiavi;
• eliminare snapshot;
• alterare la replica.

Verificare:

- copie offline;
- copie immutabili;
- account backup;
- console;
- repository;
- credenziali;
- chiavi;
- cataloghi;
- restore point;
- copie fuori sede.

CISA e MITRE raccomandano backup separati e protetti dalla rete ordinaria, proprio per ridurre il rischio che vengano compromessi insieme ai sistemi di produzione. CISA StopRansomware Guide

32.1 Non collegare subito i backup

Prima verificare:

• ambiente pulito;
• identità pulita;
• console sicura;
• data del restore point;
• assenza di persistenza;
• validità del catalogo.

33. Ordine di volatilità

Una sequenza orientativa:

1. stato CPU e processi;
2. memoria RAM;
3. connessioni;
4. sessioni;
5. chiavi temporanee;
6. cache;
7. dati EDR prossimi alla scadenza;
8. log locali;
9. file system;
10. backup;
11. archivi storici.

L’ordine effettivo dipende da:

• rischio;
• stabilità;
• criticità;
• propagazione;
• capacità disponibile;
• tipo di sistema.

Il triage iniziale della prova digitale deve essere adattato al contesto operativo.

34. Live response

La live response raccoglie dati da un sistema acceso.

Può acquisire:

• ora;
• utenti;
• processi;
• connessioni;
• servizi;
• task;
• driver;
• mount;
• sessioni;
• memoria;
• configurazioni.

34.1 Vantaggi

• preserva dati volatili;
• supporta il contenimento;
• consente triage rapido;
• individua sistemi prioritari.

34.2 Limiti

• modifica il sistema;
• genera log;
• utilizza memoria;
• può essere osservata dall’attaccante;
• può causare instabilità;
• dipende dai privilegi;
• può essere ingannata da malware avanzato.

35. Acquisizione della memoria RAM

La memoria può contenere:

• processi;
• connessioni;
• moduli;
• comandi;
• chiavi;
• credenziali residue;
• configurazioni;
• malware fileless;
• sessioni;
• contenuti decifrati.

35.1 Procedura

1. identificare il sistema;
2. registrare ora e timezone;
3. scegliere uno strumento compatibile;
4. usare un supporto controllato;
5. registrare versione e hash dello strumento;
6. acquisire la memoria;
7. annotare errori e durata;
8. calcolare SHA-256 dell’immagine;
9. conservare l’originale;
10. analizzare una copia.

35.2 Strumenti possibili

• WinPmem;
• Magnet RAM Capture;
• FTK Imager;
• strumenti EDR;
• acquisizione hypervisor;
• strumenti Linux specifici.

La scelta dipende da:

• sistema operativo;
• versione;
• protezioni;
• stabilità;
• licenza;
• obiettivo.

35.3 Limite

L’acquisizione della RAM modifica inevitabilmente una parte della memoria.

36. Analisi della memoria con Volatility 3

Volatility 3 è un framework open source per l’analisi forense della memoria e dispone di plugin per processi, connessioni, servizi, registry e numerose altre strutture. Non acquisisce autonomamente la RAM: analizza un’immagine già prodotta. Documentazione Volatility 3

36.1 Informazioni generali

python3 vol.py \
  -f HOST01-memory.raw \
  windows.info

36.2 Processi

python3 vol.py \
  -f HOST01-memory.raw \
  windows.pslist

python3 vol.py \
  -f HOST01-memory.raw \
  windows.pstree

36.3 Command line

python3 vol.py \
  -f HOST01-memory.raw \
  windows.cmdline

36.4 Connessioni

python3 vol.py \
  -f HOST01-memory.raw \
  windows.netscan

36.5 Servizi

python3 vol.py \
  -f HOST01-memory.raw \
  windows.svcscan

36.6 Aree sospette

python3 vol.py \
  -f HOST01-memory.raw \
  windows.malfind

36.7 Hive del registro

python3 vol.py \
  -f HOST01-memory.raw \
  windows.registry.hivelist

Registrare:

• versione;
• comando;
• simboli;
• errori;
• output;
• hash;
• interpretazione.

Un risultato malfind non equivale automaticamente a malware.

37. Copia forense del disco

Quando possibile, produrre una copia forense del supporto.

La copia può preservare:

• file;
• dati cancellati;
• registry;
• log;
• Prefetch;
• MFT;
• USN Journal;
• shadow copy;
• file temporanei;
• artefatti utente;
• persistenze.

37.1 Priorità

Non sempre è possibile acquisire ogni dispositivo durante l’emergenza.

Selezionare:

- patient zero presunto;
- controller di dominio;
- server di gestione;
- server backup;
- jump server;
- endpoint amministratore;
- host con nota di riscatto;
- host con attività EDR rilevante.

37.2 Raccolta mirata

Quando l’immagine completa non è immediatamente possibile, acquisire:

• EVTX;
• registry;
• MFT;
• USN;
• Prefetch;
• Amcache;
• task;
• servizi;
• log applicativi;
• EDR;
• file sospetti.

La raccolta mirata non sostituisce sempre l’immagine completa.

38. KAPE

KAPE utilizza Targets per raccogliere artefatti e Modules per processarli. È adatto al triage rapido di fonti Windows, ma la selezione del target deve essere verificata rispetto alla versione e all’obiettivo. KAPE — Kroll

Sintassi concettuale:

kape.exe `
  --tsource C: `
  --tdest D:\CASO\KAPE\HOST01 `
  --target <TARGET_VALIDATO> `
  --tflush

Registrare:

- versione KAPE;
- licenza applicabile;
- target;
- moduli;
- sorgente;
- destinazione;
- log;
- errori;
- hash.

Non utilizzare un target generico senza comprenderne:

• contenuto;
• volume;
• impatto;
• artefatti esclusi.

39. Velociraptor

Velociraptor consente raccolte mirate, monitoraggio e hunting distribuito sugli endpoint. Può essere utile quando l’organizzazione deve interrogare rapidamente numerosi sistemi e confrontare processi, file, eventi e configurazioni. Documentazione Velociraptor

39.1 Possibili impieghi

• raccolta artefatti;
• ricerca file;
• acquisizione log;
• processi;
• connessioni;
• task;
• servizi;
• YARA;
• timeline;
• hunting di IOC.

39.2 Prima di avviare una hunt

Definire:

- domanda tecnica;
- gruppo endpoint;
- artifact;
- timeout;
- volume;
- privilegi;
- storage;
- retention;
- impatto.

39.3 Limiti

• agent non presente;
• endpoint offline;
• server compromesso;
• credenziali amministrative compromesse;
• query troppo ampia;
• raccolta che altera lo stato.

40. Sysinternals

Gli strumenti Sysinternals possono supportare il triage Windows.

40.1 Autoruns

Consente di esaminare punti di avvio automatico:

autorunsc64.exe `
  -accepteula `
  -a * `
  -c `
  -h `
  > autoruns.csv

40.2 TCPView/Tcpvcon

tcpvcon64.exe `
  -accepteula `
  -a `
  -n `
  -c `
  > tcpvcon.csv

40.3 Sigcheck

sigcheck64.exe `
  -accepteula `
  -h `
  -i `
  ".\sospetto.exe" `
  > sigcheck.txt

Verificare sempre l’help della versione installata.

Gli strumenti Sysinternals comprendono utility dedicate a processi, autorun, rete, firme e diagnostica Windows.

41. Triage Windows in sola lettura

I seguenti comandi producono attività e log sul sistema. Devono essere autorizzati e documentati.

41.1 Identità e sistema

Get-Date -Format "yyyy-MM-ddTHH:mm:ss.fffK"
hostname
whoami /all
systeminfo

41.2 Rete

ipconfig /all
route print
arp -a
netstat -ano

Get-NetTCPConnection |
  Sort-Object State,RemoteAddress |
  Export-Csv ".\tcp-connections.csv" `
    -NoTypeInformation `
    -Encoding UTF8

41.3 Processi

Get-Process |
  Sort-Object CPU -Descending |
  Select-Object `
    Id,ProcessName,Path,StartTime,CPU |
  Export-Csv ".\processes.csv" `
    -NoTypeInformation `
    -Encoding UTF8

41.4 Sessioni

quser
qwinsta

41.5 Servizi e task

Get-Service |
  Where-Object Status -eq "Running" |
  Export-Csv ".\running-services.csv" `
    -NoTypeInformation `
    -Encoding UTF8

Get-ScheduledTask |
  Export-Clixml ".\scheduled-tasks.xml"

41.6 Avvio automatico

Get-CimInstance Win32_StartupCommand |
  Export-Csv ".\startup-commands.csv" `
    -NoTypeInformation `
    -Encoding UTF8

41.7 Defender

Get-MpComputerStatus |
  Format-List |
  Out-File ".\defender-status.txt"

41.8 Shadow copy e backup

vssadmin list shadows
wbadmin get versions

Non eseguire comandi di eliminazione.

42. Esportazione dei log Windows

wevtutil epl Security `
  "D:\CASO\Security.evtx" `
  /ow:true

wevtutil epl System `
  "D:\CASO\System.evtx" `
  /ow:true

wevtutil epl `
  "Microsoft-Windows-Sysmon/Operational" `
  "D:\CASO\Sysmon.evtx" `
  /ow:true

wevtutil epl `
  "Microsoft-Windows-PowerShell/Operational" `
  "D:\CASO\PowerShell.evtx" `
  /ow:true

Acquisire anche:

• configurazione dei canali;
• dimensione massima;
• retention;
• stato del forwarding;
• eventuali gap.

43. Triage Linux in sola lettura

43.1 Sistema e ora

date --iso-8601=ns
date -u --iso-8601=ns
timedatectl status
hostnamectl

43.2 Utenti e sessioni

who -a
w
last -Faiw

43.3 Rete

ip addr show
ip route show
arp -an
ss -plant

43.4 Processi

ps auxwwf > processes.txt

43.5 Servizi

systemctl \
  --type=service \
  --state=running \
  --no-pager \
  > running-services.txt

43.6 File aperti

lsof -nP > open-files.txt

43.7 Journal

journalctl \
  --utc \
  --since "2026-07-01 00:00:00" \
  --output short-iso-precise \
  --no-pager \
  > journal-utc.txt

43.8 SSH e autenticazione

zgrep -h \
  -E "Accepted|Failed|sudo|session opened" \
  /var/log/auth.log* \
  > auth-events.txt

Limitare ricerche intensive sui sistemi instabili.

44. Packet capture e Wireshark

Una cattura di rete può documentare:

• comunicazioni attive;
• DNS;
• TLS;
• SMB;
• RDP;
• beaconing;
• trasferimenti;
• sistemi coinvolti.

44.1 Interfacce disponibili

tshark -D

44.2 Cattura autorizzata

tshark \
  -i <INTERFACCIA> \
  -f "host 203.0.113.10" \
  -w incident_capture.pcapng

44.3 Analisi del file

tshark \
  -r incident_capture.pcapng \
  -Y "dns or tls or smb2" \
  > filtered-events.txt

In TShark -f definisce un filtro di cattura, mentre -Y applica un filtro di visualizzazione. La cattura deve essere limitata alle reti autorizzate e protetta perché può contenere dati personali, credenziali o comunicazioni riservate.

45. EDR, XDR e SIEM

Acquisire:

- alert;
- raw events;
- process tree;
- command line;
- network events;
- file events;
- device timeline;
- incident;
- response actions;
- query;
- policy;
- esclusioni;
- stato agent;
- retention.

Distinguere:

evento:
telemetria registrata;

detection:
regola che interpreta eventi;

incident:
aggregazione gestita dalla piattaforma;

azione:
isolamento, kill, quarantena o blocco.

L’analisi dei log aziendali deve mantenere il collegamento tra vista normalizzata e record originario.

46. Nota di riscatto

La nota può essere:

• TXT;
• HTML;
• immagine;
• sfondo desktop;
• stampa;
• messaggio in console;
• email;
• chat;
• file presente in ogni cartella.

46.1 Acquisire

- file originale;
- percorso;
- nome;
- dimensione;
- hash;
- timestamp;
- contenuto;
- indirizzi;
- URL;
- identificativo vittima;
- email;
- wallet;
- screenshot.

46.2 Non concludere l’attribuzione dal nome

La nota può:

• copiare un gruppo noto;
• utilizzare un builder;
• essere modificata;
• derivare da un affiliato;
• essere falsa.

47. Campioni di file cifrati

Preservare:

• file di piccola dimensione;
• file di tipi diversi;
• file in cartelle diverse;
• estensione originaria;
• nuova estensione;
• un eventuale originale corrispondente;
• nota di riscatto associata.

Per ogni campione:

Nome originario:
Nome cifrato:
Percorso:
Dimensione:
SHA-256:
Tipo:
Header:
Data:

Non eseguire tentativi di decrypt sugli originali.

Produrre copie di lavoro.

48. Campione malware

Il campione può provenire da:

• quarantena EDR;
• memoria;
• download;
• directory temporanea;
• task;
• share;
• script;
• email.

48.1 Conservazione

- contenitore cifrato;
- password comunicata separatamente;
- accesso limitato;
- hash;
- nome neutralizzato;
- nessuna esecuzione nell’ambiente ordinario;
- laboratorio isolato.

48.2 Non caricare automaticamente su servizi pubblici

Un servizio esterno può:

• condividere il campione;
• rendere visibili metadati;
• notificare terzi;
• conservare il file;
• esporre documenti aziendali incorporati.

L’uso deve essere autorizzato e valutato rispetto a riservatezza e privacy.

49. YARA

YARA consente di descrivere e cercare pattern testuali o binari utili per classificare malware o individuare file compatibili con una regola. Un match è un indicatore, non una prova definitiva. Documentazione YARA

49.1 Scansione di copie di lavoro

yara \
  -r \
  -s \
  rules.yar \
  ./copie_lavoro \
  > yara_hits.txt

49.2 Procedura

1. verificare la fonte della regola;
2. registrare versione;
3. leggere la condizione;
4. verificare falsi positivi;
5. usare copie di lavoro;
6. registrare comando;
7. conservare output;
8. confermare manualmente i match.

50. Identificazione della famiglia e decryptor

Possibili elementi:

• nota;
• estensione;
• struttura del file;
• campione;
• mutex;
• configurazione;
• chiave;
• URL;
• wallet;
• stringhe;
• comportamento.

Il progetto No More Ransom mantiene un archivio di strumenti di decrittazione per specifiche famiglie. La disponibilità di un tool non significa che ogni variante o ogni file sia recuperabile.

50.1 Procedura prudente

1. identificare la variante;
2. verificare la fonte del decryptor;
3. preservare gli originali;
4. usare copie;
5. predisporre un ambiente isolato;
6. verificare hash e firma dello strumento;
7. testare su campioni;
8. confrontare output;
9. documentare errori;
10. non promettere il risultato.

51. Matrice degli indicatori di compromissione

Ogni IOC deve indicare:

• origine;
• prima osservazione;
• ultima osservazione;
• sistema;
• contesto;
• possibilità di falso positivo;
• stato del blocco.

52. Mappatura MITRE ATT&CK

Una matrice può includere:

MITRE ATT&CK è una base di conoscenza delle tecniche osservate negli attacchi. La mappatura descrive comportamenti compatibili e non identifica automaticamente un gruppo.

53. Individuare l’accesso iniziale

Possibili vettori:

• phishing;
• credenziale VPN;
• RDP esposto;
• vulnerabilità;
• fornitore;
• software remoto;
• account cloud;
• chiave API;
• dispositivo rubato;
• password riutilizzata.

Costruire una tabella:

Non scegliere l’ipotesi più intuitiva senza confrontare alternative.

54. Phishing

Acquisire:

• EML;
• header;
• allegato;
• URL;
• dominio;
• browser;
• download;
• process tree;
• login successivi;
• credenziali;
• token.

Collegamenti:

• Analisi forense di email e header
• Acquisizione di pagine web e contenuti online
• Accessi abusivi ad account

Un’email consegnata non dimostra che il destinatario abbia aperto l’allegato.

55. VPN, RDP e servizi esposti

Verificare:

- data accesso;
- account;
- IP;
- MFA;
- client;
- dispositivo;
- sessione;
- durata;
- traffico successivo;
- vulnerabilità;
- configurazione;
- aggiornamenti.

55.1 VPN

Un accesso VPN riuscito non dimostra:

• chi controllasse le credenziali;
• quali risorse siano state usate;
• che l’account fosse autorizzato in quel momento.

55.2 RDP

Correlare:

• Logon Type 10;
• TerminalServices;
• firewall;
• VPN;
• host origine;
• processi;
• session reconnect;
• file transfer.

55.3 Servizio vulnerabile

La presenza di una vulnerabilità non dimostra che sia stata sfruttata.

Servono:

• log;
• richieste;
• payload;
• processo;
• rete;
• file;
• timing;
• comportamento.

56. Compromissione delle credenziali

Verificare:

• password spraying;
• credential stuffing;
• phishing;
• infostealer;
• session hijacking;
• MFA fatigue;
• reset help desk;
• account condivisi;
• credenziali di servizio.

La procedura completa è trattata nel Capitolo 18 — Accessi abusivi ad account email, social e cloud.

57. Persistenza

Cercare:

- account;
- servizi;
- task;
- registry run key;
- WMI;
- startup;
- chiavi SSH;
- web shell;
- app OAuth;
- token;
- GPO;
- scheduled function;
- service principal;
- certificati.

Una persistenza può sopravvivere:

• al reset della password;
• al riavvio;
• al ripristino di un singolo server;
• alla reinstallazione di un endpoint;
• alla revoca di una sessione.

58. Privilege escalation

Possibili evidenze:

• aggiunta a gruppi;
• abuso di token;
• reset password;
• modifica sudoers;
• exploit locale;
• account amministrativo;
• delega cloud;
• service principal;
• modifica PAM.

Correlare:

account origine
→ azione
→ account privilegiato
→ host
→ attività successiva

59. Movimento laterale

Canali frequenti:

• RDP;
• SMB;
• WinRM;
• WMI;
• PsExec;
• SSH;
• strumenti RMM;
• software di distribuzione;
• GPO;
• hypervisor.

Cercare:

- autenticazioni;
- processi remoti;
- servizi;
- task;
- condivisioni;
- porte;
- account;
- sessioni;
- file copiati.

Una connessione SMB non dimostra automaticamente che sia stato distribuito il ransomware.

60. Disabilitazione delle difese

Verificare:

• EDR isolato;
• agent arrestato;
• policy modificata;
• esclusioni;
• antivirus disattivato;
• log cancellati;
• tamper protection;
• alert soppressi;
• account SOC compromesso.

Distinguere:

• azione ostile;
• manutenzione;
• errore;
• risposta autorizzata.

61. Inibizione del recupero

Possibili attività:

• shadow copy eliminate;
• servizi backup arrestati;
• cataloghi cancellati;
• repository raggiunti;
• snapshot eliminati;
• retention ridotta;
• chiavi compromesse;
• replica corrotta.

MITRE descrive tali attività nella tecnica T1490 — Inhibit System Recovery.

Non eseguire per prova comandi che eliminano:

• shadow copy;
• backup;
• cataloghi;
• snapshot.

Acquisire soltanto gli artefatti che documentano l’esecuzione.

62. Data staging ed esfiltrazione

Prima della cifratura possono essere creati:

• archivi ZIP;
• file RAR;
• file 7z;
• directory temporanee;
• copie su server;
• upload cloud;
• trasferimenti SFTP;
• strumenti di sincronizzazione.

Fonti:

• file system;
• EDR;
• Prefetch;
• command line;
• firewall;
• proxy;
• DNS;
• cloud audit;
• NetFlow.

62.1 Volume non equivale a contenuto

Un trasferimento di 20 GB non dimostra quali file siano stati trasferiti.

62.2 Assenza di log non equivale ad assenza di esfiltrazione

Possibili motivi:

• logging incompleto;
• traffico cifrato;
• canale non monitorato;
• retention scaduta;
• trasferimento tramite cloud;
• dispositivo rimovibile.

63. Fase di cifratura

Ricostruire:

- primo file cifrato osservato;
- processo;
- account;
- host;
- estensione;
- directory;
- file server;
- share;
- velocità;
- note;
- servizi arrestati;
- sistemi raggiunti.

63.1 File server

Determinare se la cifratura sia stata eseguita:

• localmente sul server;
• da un client mediante SMB;
• da un account amministrativo;
• da una GPO;
• da uno strumento remoto.

63.2 Datazione

La prima modifica osservata non coincide necessariamente con l’inizio dell’incidente.

64. Individuare il patient zero

Il “patient zero” dovrebbe essere definito come:

Non come:

Possibili fonti:

• email;
• browser;
• EDR;
• VPN;
• processi;
• logon;
• DNS;
• download;
• file;
• alert.

65. Determinare il blast radius

Creare una matrice:

Classificare:

- compromesso confermato;
- compromesso probabile;
- da verificare;
- nessuna evidenza;
- non osservabile.

66. Recupero dell’identità

Prima del ripristino valutare:

• account privilegiati;
• account servizio;
• MFA;
• token;
• certificati;
• password;
• API key;
• trust;
• federazione;
• recovery channel.

66.1 Sequenza orientativa

1. creare una workstation amministrativa pulita;
2. proteggere account break-glass;
3. revocare sessioni;
4. rimuovere account sconosciuti;
5. verificare gruppi e ruoli;
6. ruotare segreti privilegiati;
7. ruotare credenziali di servizio;
8. verificare certificati e chiavi;
9. ripristinare MFA;
10. monitorare nuovi accessi.

La sequenza deve essere adattata alle dipendenze: cambiare una password di servizio senza censire le applicazioni può interrompere ulteriori sistemi.

67. Validazione dei backup

Per ogni restore point:

- data;
- origine;
- tipo;
- repository;
- immutabilità;
- cifratura;
- catalogo;
- hash;
- esito test;
- malware rilevato;
- dipendenze.

67.1 Domande

1. Il backup precede l’accesso iniziale?
2. Contiene una persistenza?
3. Le credenziali erano già compromesse?
4. È stato verificato?
5. È leggibile?
6. È completo?
7. Contiene configurazioni?
8. Esistono versioni multiple?

Un backup precedente alla cifratura può essere successivo alla compromissione iniziale.

68. Ambiente pulito di recupero

Predisporre:

• rete separata;
• identità controllate;
• DNS sicuro;
• gestione aggiornata;
• EDR;
• logging;
• patch;
• account minimi;
• controllo dei flussi;
• repository verificato.

68.1 Clean room

Può essere:

• infrastruttura separata;
• tenant dedicato;
• subnet isolata;
• laboratorio;
• cloud temporaneo.

68.2 Obiettivo

Verificare il sistema prima della riconnessione all’ambiente produttivo.

69. Eradicazione o reinstallazione?

69.1 Eradicazione mirata

Può essere valutata quando:

• compromissione limitata;
• malware identificato;
• telemetria completa;
• integrità verificabile;
• sistema ricostruibile difficilmente.

69.2 Reinstallazione

È spesso preferibile quando:

• privilegi elevati;
• rootkit;
• domain compromise;
• persistenza incerta;
• log incompleti;
• sistema standardizzabile;
• fiducia non recuperabile.

69.3 Limite

Reinstallare un endpoint non elimina:

• account compromessi;
• token;
• OAuth;
• persistenza cloud;
• vulnerabilità;
• credenziali di servizio;
• accesso del fornitore.

70. Ordine di ripristino

Un ordine orientativo:

1. identità essenziale;
2. DNS e servizi infrastrutturali;
3. logging e sicurezza;
4. backup management;
5. sistemi amministrativi;
6. applicazioni critiche;
7. file server;
8. servizi secondari;
9. endpoint;
10. archivi.

L’ordine reale dipende dalle dipendenze.

Esempio:

l’applicazione gestionale dipende da:
- Active Directory;
- DNS;
- database;
- storage;
- certificato;
- servizio email.

Ripristinare soltanto l’applicazione non basta.

71. Criteri di riconnessione

Un sistema può essere riconnesso quando:

[ ] è stato reinstallato o bonificato;
[ ] le vulnerabilità sono state corrette;
[ ] le credenziali sono state ruotate;
[ ] l’EDR è attivo;
[ ] il logging funziona;
[ ] gli IOC sono stati verificati;
[ ] le persistenze sono state rimosse;
[ ] le dipendenze sono sicure;
[ ] il backup è stato validato;
[ ] esiste un piano di rollback;
[ ] il responsabile ha approvato.

72. Monitoraggio dopo il recupero

Prevedere:

• hunting IOC;
• alert rafforzati;
• controllo accessi;
• DNS;
• firewall;
• EDR;
• account;
• backup;
• nuove persistenze;
• esfiltrazione;
• errori applicativi.

Durata e intensità dipendono dal rischio residuo.

73. Decisione sul pagamento del riscatto

Il perito informatico non decide autonomamente se pagare.

La decisione può coinvolgere:

• direzione;
• legale;
• autorità;
• assicurazione;
• consulenti finanziari;
• compliance;
• DPO;
• soggetti competenti per eventuali sanzioni.

Le autorità statunitensi, tra cui l’FBI, dichiarano di non sostenere il pagamento perché non garantisce il recupero dei dati, può incentivare ulteriori attacchi e non assicura che le informazioni sottratte non vengano pubblicate. FBI — Ransomware

73.1 Elementi tecnici da fornire ai decisori

- stato dei backup;
- percentuale di sistemi cifrati;
- presenza di decryptor;
- criticità dei dati;
- possibile esfiltrazione;
- attendibilità del soggetto;
- tempi di recupero;
- rischi di reinfezione;
- dati ancora disponibili.

73.2 Nessuna garanzia

Anche dopo un pagamento:

• la chiave può non arrivare;
• il decryptor può essere difettoso;
• il recupero può essere lento;
• i dati possono restare corrotti;
• i dati sottratti possono essere pubblicati;
• l’organizzazione può essere colpita di nuovo.

74. Comunicazioni con il soggetto estorsore

Non improvvisare.

Le eventuali comunicazioni devono essere coordinate con:

• legale;
• autorità;
• assicurazione;
• specialisti autorizzati;
• direzione.

74.1 Conservare

- messaggi;
- orari;
- username;
- URL;
- identificativi;
- wallet;
- file;
- allegati;
- screenshot;
- trascrizioni;
- hash.

74.2 Non utilizzare

• account personali;
• rete compromessa;
• dispositivi produttivi;
• canali non autorizzati.

74.3 Limite

Un soggetto che mostra un file aziendale dimostra di disporre di quella copia o rappresentazione, non necessariamente dell’intero dataset dichiarato.

75. Autorità e CSIRT

In Italia l’organizzazione può dover coordinarsi, secondo il caso, con:

• Polizia Postale;
• autorità giudiziaria;
• CSIRT Italia;
• Agenzia per la cybersicurezza nazionale;
• Garante;
• autorità di settore.

Conservare:

- numero pratica;
- data;
- soggetto contattato;
- informazioni trasmesse;
- allegati;
- ricevute;
- aggiornamenti.

La guida ACN raccoglie istruzioni per i soggetti pubblici e privati tenuti alle notifiche degli incidenti informatici.

76. Ransomware e data breach

Un ransomware può comportare:

• indisponibilità;
• perdita;
• alterazione;
• accesso non autorizzato;
• divulgazione;
• distruzione di dati personali.

L’evento deve essere valutato dal titolare con DPO e legale.

76.1 Informazioni tecniche utili

- categorie di dati;
- sistemi;
- numero approssimativo di interessati;
- intervallo;
- account;
- esfiltrazione;
- cifratura;
- chiavi;
- backup;
- conseguenze;
- misure adottate.

76.2 GDPR

L’articolo 33 del GDPR prevede, quando la violazione può presentare un rischio per i diritti e le libertà, la notifica all’autorità senza ingiustificato ritardo e, ove possibile, entro 72 ore dalla conoscenza. Tutte le violazioni devono essere documentate. L’articolo 34 richiede la comunicazione agli interessati senza ingiustificato ritardo quando il rischio è elevato, salvo le eccezioni previste. Testo GDPR

77. Obblighi NIS2 in Italia

Gli obblighi NIS non si applicano indistintamente a ogni azienda.

Per i soggetti essenziali e importanti rientranti nel decreto legislativo n. 138/2024, gli incidenti con impatto significativo devono essere notificati al CSIRT Italia secondo il processo previsto.

La disciplina prevede, in sintesi:

- pre-notifica entro 24 ore;
- notifica entro 72 ore;
- relazione finale entro un mese;

con ulteriori aggiornamenti nei casi previsti. I termini decorrono dalla conoscenza qualificata dell’incidente secondo le regole applicabili. D.lgs. 138/2024, art. 25

77.1 Dati tecnici da predisporre

• data e ora;
• impatto;
• servizi;
• origine sospetta;
• indicatori;
• dimensione;
• effetti transfrontalieri;
• contenimento;
• aggiornamenti;
• causa;
• misure correttive.

78. DORA per le entità finanziarie

Il regolamento DORA disciplina la resilienza operativa digitale delle entità finanziarie rientranti nel proprio ambito.

Per gli incidenti ICT classificati come maggiori, il regolamento delegato UE 2025/301 prevede:

• notifica iniziale entro quattro ore dalla classificazione e, in ogni caso, non oltre 24 ore dalla conoscenza dell’incidente;
• rapporto intermedio entro 72 ore dalla notifica iniziale;
• rapporto finale entro un mese dal rapporto intermedio o dall’ultimo aggiornamento intermedio.

L’applicabilità, la classificazione e l’autorità competente devono essere verificate con compliance e legale. Regolamento delegato UE 2025/301

79. Assicurazione cyber

Verificare il contratto prima di:

• incaricare fornitori;
• contattare il soggetto estorsore;
• sostenere costi;
• comunicare pubblicamente;
• avviare un ripristino esteso.

Possibili clausole:

• notifica immediata;
• panel di fornitori;
• consenso preventivo;
• forensic retainer;
• legale incaricato;
• business interruption;
• costi di recupero;
• esclusioni.

Conservare:

• numero sinistro;
• comunicazioni;
• autorizzazioni;
• preventivi;
• fatture;
• decisioni.

80. Fornitori e supply chain

Un incidente può derivare da:

• MSP;
• software gestionale;
• RMM;
• account manutentore;
• aggiornamento;
• integrazione;
• API;
• VPN fornitore.

Verificare:

- account;
- accessi;
- contratti;
- log;
- orari;
- sistemi gestiti;
- strumenti remoti;
- notifiche del fornitore;
- altri clienti coinvolti.

Non attribuire l’incidente al fornitore soltanto perché possedeva un accesso.

81. Comunicazioni interne

Predisporre un messaggio controllato.

Esempio:

È in corso un incidente informatico.
Non accendere dispositivi spenti senza indicazione.
Non collegare supporti USB.
Non utilizzare la posta aziendale per comunicazioni sul caso.
Non cancellare messaggi o file.
Segnalare anomalie al canale indicato.
Non rilasciare dichiarazioni esterne.

Evitare di comunicare:

• dettagli tecnici inutili;
• indicatori non validati;
• nomi di sospetti;
• importi;
• dati personali;
• credenziali;
• piani di risposta.

82. Comunicazioni a clienti e interessati

Le comunicazioni devono essere:

• accurate;
• comprensibili;
• non speculative;
• coerenti;
• aggiornabili;
• approvate.

Distinguere:

fatto confermato:
alcuni sistemi sono indisponibili;

ipotesi:
potrebbe esserci stata esfiltrazione;

dato non disponibile:
non è ancora noto il numero dei file.

Non dichiarare:

quando l’analisi non consente di escluderlo.

83. Continuità operativa

Attivare procedure alternative:

• lavorazione manuale;
• telefono;
• modulistica;
• sistemi secondari;
• sedi alternative;
• comunicazioni esterne;
• priorità clienti;
• procedure emergenza.

83.1 Separazione

Le modalità temporanee non devono:

• riutilizzare password compromesse;
• collegarsi alla rete infetta;
• introdurre dispositivi personali non controllati;
• trasferire dati senza protezione.

84. Root cause analysis

La causa radice non coincide necessariamente con il primo malware rilevato.

Esempio:

evento visibile:
ransomware.exe eseguito;

causa tecnica:
account amministrativo compromesso;

causa organizzativa:
MFA non applicata;

causa strutturale:
accesso VPN non dismesso;

causa gestionale:
offboarding incompleto.

84.1 Metodo dei livelli

1. cosa è accaduto;
2. come è stato possibile;
3. quale controllo mancava;
4. perché il controllo mancava;
5. quale intervento riduce il rischio.

La root cause deve essere supportata dalle fonti, non adattata a una conclusione già decisa.

85. Lesson learned

La revisione deve coinvolgere:

• direzione;
• IT;
• sicurezza;
• legale;
• DPO;
• continuità;
• fornitori;
• utenti coinvolti.

Domande:

- cosa ha funzionato;
- cosa non ha funzionato;
- quali dati mancavano;
- quali decisioni sono state lente;
- quali ruoli erano ambigui;
- quali backup erano inutilizzabili;
- quali strumenti non erano disponibili;
- quali comunicazioni hanno creato problemi;
- quali controlli devono essere aggiornati.

NIST SP 800-61 Rev. 3 considera il miglioramento continuo parte integrante della risposta e della gestione del rischio. NIST SP 800-61 Rev. 3

86. Conservazione delle evidenze dopo il recupero

Non eliminare automaticamente:

• immagini;
• memoria;
• log;
• note;
• malware;
• file cifrati;
• comunicazioni;
• report;
• timeline;
• ticket.

Definire:

• durata;
• fondamento;
• custode;
• accessi;
• cifratura;
• distruzione;
• copie;
• eventuali procedimenti.

Il periodo deve considerare:

• contenzioso;
• assicurazione;
• data breach;
• autorità;
• obblighi contrattuali;
• minimizzazione.

87. Caso pratico 1 — VPN compromessa in un’azienda di Roma

Scenario

Un’azienda con sede nel quartiere EUR rileva file cifrati su due server.

Risultati

- account VPN attivo di un ex collaboratore;
- MFA non abilitata;
- accesso notturno;
- RDP verso un server;
- creazione di un servizio;
- accesso al repository backup;
- cifratura avviata due giorni dopo.

Conclusione prudente

88. Caso pratico 2 — Studio legale di Roma e doppia estorsione

Scenario

Uno studio legale di Prati riceve una nota che dichiara la sottrazione di fascicoli.

Risultati

• file server cifrato;
• archivio 7z creato;
• traffico verso storage cloud;
• dati di rete parziali;
• nota con elenco di clienti;
• nessun elenco completo dei file.

Conclusione

89. Caso pratico 3 — Clinica romana

Scenario

Una clinica privata rileva indisponibilità del gestionale e della diagnostica.

Priorità

1. sicurezza dei pazienti;
2. continuità delle prestazioni;
3. isolamento controllato;
4. protezione dei backup;
5. acquisizione dei sistemi prioritari;
6. valutazione dei dati sanitari;
7. comunicazioni.

Conclusione

90. Caso pratico 4 — Hypervisor cifrato

Scenario

Un’impresa romana trova datastore virtuali indisponibili.

Risultati

- accesso alla console con account amministrativo;
- autenticazione da IP VPN;
- shell abilitata;
- backup delle VM raggiungibili;
- host riavviato prima dell’intervento;
- memoria volatile non disponibile.

Conclusione

91. Caso pratico 5 — NAS cifrato da un client

Scenario

Uno studio professionale di Roma presume che il ransomware sia stato eseguito sul NAS.

Risultati

• nessun processo anomalo sul NAS;
• accessi SMB dall’endpoint PC17;
• PC17 compromesso;
• numerose scritture mediante account utente;
• snapshot NAS disponibili.

Conclusione

92. Caso pratico 6 — Sincronizzazione cloud

Scenario

Un ransomware cifra una cartella locale sincronizzata con OneDrive.

Risultati

• file locali cifrati;
• sincronizzazione delle nuove versioni;
• version history disponibile;
• account cloud non compromesso;
• nessuna eliminazione amministrativa.

Conclusione

93. Caso pratico 7 — Backup compromesso

Scenario

Un’azienda romana dispone di backup recenti ma non riesce a ripristinarli.

Risultati

- account backup appartenente al dominio;
- password compromessa;
- cataloghi eliminati;
- repository ancora presente;
- copia offline di una settimana prima;
- test restore mai eseguito.

Conclusione

94. Caso pratico 8 — Falso positivo

Scenario

Un file server romano mostra migliaia di file rinominati.

Risultati

• nessuna nota;
• nessun processo ostile;
• attività di migrazione autorizzata;
• account di servizio;
• ticket presente;
• hash dei contenuti invariati.

Conclusione

95. Caso pratico 9 — Data extortion senza cifratura

Scenario

Un’azienda riceve una richiesta di pagamento e alcuni file campione, ma i sistemi sono operativi.

Risultati

• account cloud compromesso;
• numerosi download;
• nessuna cifratura;
• token OAuth;
• dati campione autentici;
• sessioni revocate.

Conclusione

96. Caso pratico 10 — Compromissione del fornitore

Scenario

Più clienti romani dello stesso fornitore IT rilevano attività anomale.

Risultati

- strumento RMM comune;
- account tecnico;
- accessi nello stesso intervallo;
- malware distribuito da console;
- log parziali;
- fornitore in fase di analisi.

Conclusione

97. Errori da evitare

1. Spegnere tutto automaticamente. Si perdono dati volatili e si possono interrompere servizi essenziali.
2. Non isolare i sistemi. La cifratura può continuare.
3. Ripristinare subito. Il vettore iniziale può essere ancora attivo.
4. Collegare i backup alla rete compromessa. Possono essere cifrati o eliminati.
5. Confondere snapshot e backup. Lo snapshot dipende dalla stessa infrastruttura.
6. Eliminare la nota di riscatto. Si perde un reperto.
7. Eseguire decryptor sugli originali. Si rischia un’ulteriore alterazione.
8. Caricare campioni riservati online. Si possono diffondere dati aziendali.
9. Formattare il patient zero. Si distrugge la fonte principale.
10. Non acquisire la memoria. Si perdono processi, connessioni e chiavi.
11. Acquisire la memoria mentre la cifratura continua ovunque. Il contenimento può essere più urgente.
12. Non registrare i comandi. L’attività non è riproducibile.
13. Usare l’account compromesso per acquisire. Si confondono eventi investigativi e ostili.
14. Cambiare una sola password. Possono restare token, sessioni e app.
15. Dimenticare account di servizio. Possono mantenere la compromissione.
16. Non proteggere gli hypervisor. Un singolo accesso può compromettere molte VM.
17. Non proteggere la console backup. Il repository può diventare inutilizzabile.
18. Confondere file cifrato e malware eseguito localmente. La cifratura può provenire da un client remoto.
19. Attribuire il gruppo dalla nota. La nota può essere copiata.
20. Attribuire una persona dall’account. Le credenziali possono essere sottratte.
21. Fidarsi della geolocalizzazione IP. È una stima.
22. Considerare l’assenza di log come assenza di attività. I dati possono essere mancanti.
23. Dichiarare assenza di esfiltrazione troppo presto. I canali possono non essere osservabili.
24. Non acquisire DNS e proxy. Si perdono collegamenti importanti.
25. Non verificare l’orologio. La timeline può essere errata.
26. Normalizzare le date senza conservare gli originali. Si perde trasparenza.
27. Confondere alert e incidente. L’alert può essere falso positivo.
28. Usare una sola regola YARA. Può produrre falsi positivi o negativi.
29. Considerare il decryptor una garanzia. La variante può non essere compatibile.
30. Considerare il pagamento una garanzia. Chiave e cancellazione dei dati non sono assicurate.
31. Comunicare dettagli non confermati. Si aumenta il rischio reputazionale e legale.
32. Non coinvolgere il DPO. Può esistere un data breach.
33. Non verificare NIS2 o DORA. Possono applicarsi termini specifici.
34. Contattare l’assicurazione troppo tardi. Il contratto può richiedere una notifica immediata.
35. Non acquisire le azioni del SOC. Anche il contenimento modifica l’ambiente.
36. Non distinguere patient zero osservato e assoluto. Le fonti possono iniziare tardi.
37. Ripristinare credenziali già compromesse. Si consente un nuovo accesso.
38. Riutilizzare immagini di sistema non verificate. Possono contenere persistenze.
39. Riconnettere tutti i sistemi contemporaneamente. Si perde la capacità di isolare una recidiva.
40. Concludere senza indicare le lacune. La relazione diventa fuorviante.

98. Procedura operativa completa

Fase 1 — Attivazione

[ ] dichiarazione incidente;
[ ] coordinatore;
[ ] codice caso;
[ ] canale sicuro;
[ ] ruoli;
[ ] direzione;
[ ] legale;
[ ] DPO;
[ ] assicurazione.

Fase 2 — Sicurezza

[ ] persone;
[ ] impianti;
[ ] servizi essenziali;
[ ] continuità;
[ ] priorità.

Fase 3 — Contenimento

[ ] endpoint;
[ ] server;
[ ] rete;
[ ] account;
[ ] VPN;
[ ] cloud;
[ ] hypervisor;
[ ] backup.

Fase 4 — Preservazione

[ ] nota;
[ ] file cifrati;
[ ] malware;
[ ] memoria;
[ ] log;
[ ] screenshot;
[ ] comunicazioni;
[ ] hash.

Fase 5 — Acquisizione

[ ] RAM;
[ ] dischi;
[ ] raccolte mirate;
[ ] EDR;
[ ] SIEM;
[ ] identità;
[ ] firewall;
[ ] cloud;
[ ] backup.

Fase 6 — Analisi

[ ] accesso iniziale;
[ ] esecuzione;
[ ] persistenza;
[ ] privilegi;
[ ] movimento laterale;
[ ] staging;
[ ] esfiltrazione;
[ ] cifratura.

Fase 7 — Perimetro

[ ] compromessi;
[ ] probabili;
[ ] da verificare;
[ ] non osservabili;
[ ] puliti provvisoriamente.

Fase 8 — Eradicazione

[ ] vettore iniziale;
[ ] vulnerabilità;
[ ] account;
[ ] token;
[ ] persistenze;
[ ] malware;
[ ] servizi;
[ ] policy.

Fase 9 — Recupero

[ ] backup validati;
[ ] clean room;
[ ] identità;
[ ] infrastruttura;
[ ] applicazioni;
[ ] endpoint;
[ ] riconnessione;
[ ] monitoraggio.

Fase 10 — Obblighi

[ ] GDPR;
[ ] NIS2;
[ ] DORA;
[ ] autorità;
[ ] assicurazione;
[ ] contratti;
[ ] comunicazioni.

Fase 11 — Chiusura

[ ] timeline;
[ ] root cause;
[ ] impatto;
[ ] evidenze;
[ ] relazione;
[ ] lesson learned;
[ ] piano correttivo;
[ ] conservazione.

99. Checklist finale

Gestione

[ ] incidente formalmente aperto;
[ ] ruoli assegnati;
[ ] registro aggiornato;
[ ] canale sicuro;
[ ] decisioni documentate.

Contenimento

[ ] sistemi isolati;
[ ] account revocati;
[ ] backup protetti;
[ ] cloud verificato;
[ ] fornitori controllati.

Forensics

[ ] memoria;
[ ] immagini;
[ ] raccolte mirate;
[ ] log;
[ ] note;
[ ] file cifrati;
[ ] malware;
[ ] hash.

Analisi

[ ] initial access;
[ ] patient zero;
[ ] persistenza;
[ ] privilegi;
[ ] lateral movement;
[ ] esfiltrazione;
[ ] cifratura;
[ ] blast radius.

Recupero

[ ] identità pulita;
[ ] backup testati;
[ ] vulnerabilità corrette;
[ ] EDR attivo;
[ ] logging attivo;
[ ] sistemi monitorati;
[ ] riconnessione approvata.

Compliance

[ ] DPO;
[ ] GDPR;
[ ] NIS2;
[ ] DORA;
[ ] assicurazione;
[ ] autorità;
[ ] clienti;
[ ] fornitori.

Relazione

[ ] fatti separati dalle ipotesi;
[ ] timestamp originali;
[ ] lacune documentate;
[ ] conclusioni prudenti;
[ ] allegati verificabili;
[ ] hash degli output.

100. Output minimo dell’accertamento

1. incarico;
2. verbale di attivazione;
3. registro dell’incidente;
4. inventario degli asset;
5. matrice della gravità;
6. registro delle evidenze;
7. note di riscatto;
8. campioni cifrati;
9. campioni malware;
10. hash SHA-256;
11. immagini di memoria;
12. immagini disco;
13. raccolte KAPE;
14. raccolte Velociraptor;
15. output Volatility;
16. output Sysinternals;
17. log Windows;
18. log Linux;
19. EDR/XDR;
20. SIEM;
21. firewall;
22. VPN;
23. DNS;
24. DHCP;
25. packet capture;
26. Active Directory;
27. Entra ID;
28. Microsoft 365;
29. Google Workspace;
30. cloud audit;
31. backup audit;
32. matrice IOC;
33. regole YARA;
34. risultati hunting;
35. mappatura ATT&CK;
36. timeline;
37. matrice del blast radius;
38. analisi del possibile accesso iniziale;
39. analisi dell’esfiltrazione;
40. registro del contenimento;
41. piano di eradicazione;
42. piano di ripristino;
43. test dei backup;
44. valutazione dati personali;
45. notifiche e comunicazioni;
46. relazione preliminare;
47. relazione finale;
48. rapporto lesson learned;
49. piano correttivo;
50. hash degli allegati.

101. Struttura della relazione tecnica

101.1 Incarico

• committente;
• quesito;
• autorizzazione;
• perimetro;
• periodo;
• limiti.

101.2 Contesto

• organizzazione;
• architettura;
• sistemi;
• reti;
• cloud;
• identità;
• backup.

101.3 Rilevazione

• segnalazione;
• data;
• ora;
• alert;
• sintomi;
• gravità.

101.4 Contenimento

• sistemi isolati;
• account;
• rete;
• cloud;
• backup;
• modifiche.

101.5 Materiale

• memoria;
• dischi;
• log;
• malware;
• file;
• hash.

101.6 Metodo

• strumenti;
• versioni;
• comandi;
• acquisizione;
• normalizzazione;
• correlazione.

101.7 Risultati

• initial access;
• persistenza;
• movimento laterale;
• dati;
• cifratura;
• account;
• sistemi.

101.8 Timeline

• eventi;
• fonti;
• UTC;
• attendibilità;
• gap.

101.9 Impatto

• servizi;
• dati;
• indisponibilità;
• esfiltrazione;
• backup;
• soggetti.

101.10 Recupero

• eradicazione;
• restore;
• test;
• riconnessione;
• monitoraggio.

101.11 Limiti

• retention;
• sistemi spenti;
• log mancanti;
• fonti non disponibili;
• cifratura;
• fornitori;
• attribuzione.

101.12 Conclusioni

Risposte tecniche proporzionate al quesito.

102. Modelli di frasi tecniche

102.1 Ransomware confermato

102.2 Attività in corso

102.3 Spegnimento

102.4 Memoria non acquisita

102.5 Patient zero

102.6 Vettore iniziale

102.7 Account

102.8 Esfiltrazione

102.9 Nessuna evidenza di esfiltrazione

102.10 Nota di riscatto

102.11 File cifrati

102.12 Decryptor

102.13 Backup

102.14 Snapshot

102.15 Ripristino

102.16 Data breach

102.17 Pagamento

102.18 Attribuzione

102.19 Gap

102.20 Conclusione generale

103. Immagini e figure suggerite

104. Riferimenti tecnici e normativi esterni

1. NIST SP 800-61 Rev. 3 — Incident Response Recommendations and Considerations, versione finale dell’aprile 2025.
2. NIST IR 8374 Rev. 1 — Ransomware Risk Management, versione finale dell’11 giugno 2026.
3. CISA — StopRansomware Guide, prevenzione, contenimento, raccolta delle prove e recupero.
4. CISA — I’ve Been Hit by Ransomware, isolamento e spegnimento come misura estrema.
5. FBI — Ransomware, rischi e limiti del pagamento del riscatto.
6. MITRE ATT&CK — Data Encrypted for Impact, T1486.
7. MITRE ATT&CK — Inhibit System Recovery, T1490.
8. MITRE ATT&CK — Data Backup, M1053.
9. No More Ransom — Repository di strumenti di decrittazione.
10. Volatility 3 — Documentazione ufficiale e plugin Windows.
11. Velociraptor — Documentazione ufficiale DFIR.
12. KAPE — Kroll Artifact Parser and Extractor.
13. YARA — Regole e scansione da riga di comando.
14. GDPR, articoli 33 e 34 — Notifica e comunicazione delle violazioni.
15. Garante per la protezione dei dati personali — Data breach.
16. Decreto legislativo n. 138/2024 — Disciplina NIS2 italiana.
17. ACN — Linee guida e processo di notifica degli incidenti NIS.
18. Regolamento UE 2022/2554 — DORA.
19. Regolamento delegato UE 2025/301 — Tempi di notifica degli incidenti DORA.
20. Regolamento di esecuzione UE 2025/302 — Modelli e procedure DORA.

105. Collegamenti interni consigliati

Capitolo precedente

• Analisi di log aziendali, firewall, VPN e sistemi cloud

Capitolo successivo

• Dipendente infedele, sottrazione dati e uso di USB

Capitoli correlati

• Triage iniziale della prova digitale a Roma
• Catena di custodia, hash e verbale tecnico
• Copia forense di hard disk, SSD, pendrive e NAS
• Analisi forense di computer Windows
• Analisi forense di macOS e Linux
• Acquisizione forense di smartphone Android
• Acquisizione forense di iPhone e iPad iOS
• Perizia WhatsApp: messaggi, vocali e allegati
• Recupero dati cancellati per fini probatori
• Analisi forense di email e header
• PEC, ricevute, allegati e prova digitale
• PDF, firme digitali e marche temporali
• Metadati, EXIF, XMP, C2PA e provenienza dei file
• Verifica forense di screenshot e schermate
• Acquisizione di pagine web, social e contenuti online
• Accessi abusivi ad account email, social e cloud
• Truffe online, bonifici fraudolenti e financial cybercrime
• Cloud forensics: Google, Microsoft, Dropbox e backup
• Timeline forense e ricostruzione cronologica degli eventi
• Relazione tecnica, CTP informatico e contestazione delle prove digitali

106. Pagine servizio consigliate

/servizi/incident-response-forense/
/servizi/perizia-informatica-forense-roma/
/servizi/analisi-smartphone-computer/
/servizi/analisi-email-pec-documenti-digitali/
/servizi/consulente-tecnico-parte-informatico-roma/
/contatti/

Anchor text consigliati

incident response forense a Roma
analisi tecnica di un ransomware
acquisizione forense durante un incidente
analisi memoria RAM ransomware
analisi di file cifrati
ricostruzione dell’accesso iniziale
analisi EDR e SIEM
verifica di esfiltrazione dati
recupero controllato dopo ransomware
analisi forense dei backup
timeline di un incidente ransomware
perizia informatica per data breach
consulente informatico forense per aziende a Roma

107. Box commerciale finale

La tua azienda ha subito un ransomware o un incidente informatico a Roma?

Lo Studio Quaranta Digital Forensics può supportare aziende, studi professionali, responsabili IT, legali, DPO e assicuratori nelle attività di:

[ ] triage dell’incidente;
[ ] contenimento tecnico;
[ ] acquisizione della memoria;
[ ] acquisizione di server ed endpoint;
[ ] raccolta EDR e SIEM;
[ ] analisi Windows e Linux;
[ ] analisi firewall, VPN e cloud;
[ ] identificazione degli indicatori;
[ ] analisi di note e file cifrati;
[ ] ricostruzione dell’accesso iniziale;
[ ] verifica del movimento laterale;
[ ] analisi dell’eventuale esfiltrazione;
[ ] verifica tecnica dei backup;
[ ] timeline forense;
[ ] supporto al data breach;
[ ] relazione tecnica;
[ ] assistenza al legale e al CTP.

CTA principale: Richiedi una valutazione preliminare urgente
CTA secondaria: Descrivi i sistemi coinvolti e il momento della rilevazione

Lo Studio non garantisce:

• decifratura;
• recupero integrale;
• assenza di esfiltrazione;
• identificazione dell’autore;
• pagamento o rimborso assicurativo;
• ripristino entro tempi predeterminati.

108. Conclusione del capitolo

La risposta a un ransomware non è una semplice attività antivirus.

Richiede il coordinamento di:

sicurezza
→ contenimento
→ forensics
→ identità
→ backup
→ continuità
→ compliance
→ recupero

La priorità iniziale è impedire che il danno aumenti.

La priorità forense è preservare ciò che può spiegare:

• come l’attaccante sia entrato;
• quali account abbia utilizzato;
• quali sistemi abbia raggiunto;
• quali dati possa aver consultato;
• quali persistenze abbia lasciato;
• come sia avvenuta la cifratura.

La priorità del recupero è evitare che i sistemi ripristinati tornino a dipendere da:

• credenziali compromesse;
• vulnerabilità non corrette;
• infrastrutture contaminate;
• backup non verificati;
• account ostili;
• token ancora validi.

Una relazione tecnicamente corretta deve indicare:

- cosa è stato osservato;
- cosa è stato acquisito;
- cosa è stato modificato durante la risposta;
- quali fonti erano disponibili;
- quali fonti mancavano;
- quali conclusioni sono supportate;
- quali restano ipotesi;
- quali limiti impediscono ulteriori affermazioni.

Il pagamento di un riscatto, il diritto al rimborso, la qualificazione penale, la notifica e la comunicazione pubblica non sono decisioni del solo perito informatico.

Il ruolo dell’informatica forense è fornire ai decisori una ricostruzione tecnica:

• ordinata;
• verificabile;
• prudente;
• proporzionata;
• utile al recupero e alle successive valutazioni.

109. Anticipazione del capitolo successivo

Capitolo 22 — Dipendente infedele, sottrazione dati e uso di USB

Il prossimo capitolo tratterà:

• definizione del quesito nelle indagini aziendali;
• autorizzazioni, privacy e rapporti di lavoro;
• acquisizione del computer aziendale;
• account condivisi e individuali;
• dispositivi USB;
• registro Windows;
• SetupAPI;
• USBSTOR;
• seriali e tempi di collegamento;
• copie di file;
• archivi ZIP e 7z;
• email personali;
• cloud storage;
• servizi di file sharing;
• browser;
• stampa;
• cancellazione;
• formattazione;
• antiforensics;
• Microsoft Purview;
• SharePoint e OneDrive;
• timeline;
• attribuzione prudente;
• relazione tecnica;
• limiti nel collegare un’attività digitale a una persona fisica.

Continua con il Capitolo 22 — Dipendente infedele, sottrazione dati e uso di USB →