Introduzione
Nel contesto della sicurezza nazionale, l’acquisizione forense delle evidenze digitali riveste un ruolo cruciale nella gestione degli incidenti informatici. Un CSIRT/SOC (Computer Security Incident Response Team/Security Operations Center) deve assicurare che ogni fase – dalla profilazione del sistema e triage iniziale, fino alla copia forense dei dati – sia condotta in modo rigoroso e conforme agli standard. Tali pratiche garantiscono sia la continuità operativa degli enti coinvolti che la valorizzazione probatoria delle informazioni raccolte, permettendo eventuali azioni legali. In questo articolo esamineremo le principali metodologie di acquisizione forense, distinguendo tra scenari live e post-mortem, le tecniche di copia bitstream di dischi e dump di RAM, gli artefatti tipici dei sistemi Windows e Linux, nonché gli strumenti hardware/software disponibili. Faremo riferimento ai principali standard internazionali (ad es. ISO/IEC 27037, NIST SP 800-86, RFC 3227) e con esempi concreti in contesto italiano.
System Profiling e Triage
La fase di triage forense consiste nel valutare rapidamente uno scenario compromesso e dare priorità alle evidenze digitali in base alla loro rilevanza e urgenza. In pratica, significa eseguire una profilazione del sistema coinvolto nell’incidente: identificare il tipo di host (es. server, workstation), il sistema operativo e versione, i servizi attivi, gli utenti connessi e altri elementi chiave, ancor prima di procedere all’acquisizione completa. Lo scopo del triage è individuare subito i dati più critici – ad esempio processi sospetti in esecuzione, connessioni di rete attive verso IP anomali, file di log che mostrano segni di manomissione – che richiedono azione immediata o conservazione urgente. Questa rapida valutazione permette al responsabile di decidere i passi successivi: ad esempio, se isolare il sistema dalla rete per contenere una minaccia in corso, oppure se mantenere la macchina accesa per acquisire dati volatili (RAM, processi, ecc.) prima che vadano persi.
Durante il triage, è fondamentale rispettare il principio dell’ordine di volatilità indicato dall’RFC 3227: occorre procedere raccogliendo prima i dati più volatili e soggetti a cambiamento, per poi passare a quelli meno volatili. Ciò significa, ad esempio, che su un sistema attivo si dovrebbero salvare immediatamente informazioni come il contenuto della memoria RAM, la tabella dei processi e le connessioni di rete, prima di acquisire i dati persistenti su disco. Allo stesso tempo, bisogna evitare manovre che possano alterare o distruggere le evidenze: non spegnere il sistema prematuramente (l’attaccante potrebbe aver impostato script di wipe all’arresto), e utilizzare strumenti “puliti” (da supporti esterni) invece di quelli presenti sul sistema compromesso, che potrebbero essere stati modificati dall’attaccante. Il responsabile forense deve istruire i primi soccorritori digitali (first responder) a seguire procedure codificate – spesso definite in playbook di incidente – per effettuare un triage metodico. Ad esempio, può essere prevista una checklist: identificare e fotografare la schermata attiva, annotare o esportare rapidamente la lista dei processi e delle connessioni (usando tool come netstat o PowerShell in modalità forense), verificare la presenza di dispositivi USB collegati, e controllare il clock di sistema (per future correlazioni temporali). Queste attività di profilazione iniziale forniscono un quadro dello stato del sistema utile per orientare l’indagine e decidere quali evidenze raccogliere con priorità. In sintesi, system profiling e triage rappresentano la prima linea di azione di un responsabile CSIRT nella fase di Preparation/Identification di un incidente, gettando le basi per un’acquisizione forense mirata ed efficace.
Processo di acquisizione: modalità live vs post-mortem
Una volta completato il triage, si passa al processo di acquisizione delle evidenze digitali vero e proprio, che può avvenire in due modalità principali: live (a sistema acceso) o post-mortem (a sistema spento). La scelta dipende dalla situazione: in molti casi di risposta a incidenti, è necessario operare live forensics per catturare dati volatili critici; altre volte, soprattutto in scenari di analisi forense tradizionale (es. sequestro di un computer in un’indagine giudiziaria), si opta per spegnere il sistema e lavorare su copie a freddo per minimizzare modifiche.
Acquisizione live
In questa modalità si raccolgono evidenze a sistema funzionante. I vantaggi sono evidenti: si possono preservare informazioni che altrimenti andrebbero perse con lo spegnimento – ad esempio il contenuto della RAM, le chiavi di cifratura in uso, processi e connessioni attive, ecc. Tuttavia, l’acquisizione live comporta inevitabilmente qualche alterazione dello stato del sistema (ogni comando eseguito può modificare dati, come i timestamp di ultimo accesso) e va quindi condotta con strumenti e metodologie che riducano al minimo tale impatto. Best practice in questo ambito (formalizzate in ISO 27037 e RFC 3227) includono: usare tool forensi dedicati eseguendoli da supporti in sola lettura (per non introdurre nuovi file sul disco target) e documentare ogni operazione compiuta. Un esempio tipico di acquisizione live è il dump della memoria RAM (vedi sezione dedicata) oppure l’estrazione di informazioni volatili tramite script di risposta all’incidente. In situazioni dove si sospetta la presenza di malware avanzati o tecniche anti-forensi (come il timestomping o la cancellazione dei log di evento), l’analisi live può rivelare indizi (processi anomali in esecuzione, moduli kernel caricati in memoria) che un’analisi post-mortem potrebbe non evidenziare. È importante anche valutare i rischi: ad esempio, scollegare la rete di una macchina compromessa può essere opportuno per isolarla, ma va fatto in modo controllato (un malware potrebbe monitorare la connettività e reagire cancellando tracce se “perde” la rete ). Il responsabile deve quindi decidere, caso per caso, quali step eseguire live e in che sequenza, bilanciando la conservazione massima delle prove con la stabilizzazione dell’incidente (es. evitare che l’attacco prosegua).
Acquisizione post-mortem
Consiste nell’acquisire le evidenze a sistema spento, tipicamente tramite la rimozione dei supporti di memoria (hard disk, SSD) e la successiva copia forense bitstream in laboratorio. Questo approccio ha il vantaggio di assicurare che il supporto originale non venga modificato ulteriormente dal momento del sequestro in poi. Nel momento in cui si spegne un computer, però, si perde tutto il contenuto volatile: memoria RAM, stato dei processi, informazioni non salvate su disco, ecc. Pertanto, la decisione di spegnere dovrebbe essere ponderata: ad esempio, se si ritiene che le informazioni critiche risiedano su disco (non volatile) e non vi sia particolare interesse per lo stato attuale della RAM, può essere preferibile rimuovere l’alimentazione immediatamente per congelare la situazione. Al contrario, se si sospetta che informazioni vitali (come chiavi di cifratura, malware in RAM o volumi cifrati aperti) siano presenti in memoria, è fondamentale lasciare il sistema acceso finché non si sia effettuato un dump della memoria e di eventuali dati volatili. L’ISO/IEC 27037 fornisce linee guida proprio per decidere queste priorità: “se dati volatili di rilievo sono presenti, raccoglierli prima di rimuovere l’alimentazione; se invece il focus è sui dati non volatili su disco, si può procedere allo spegnimento in sicurezza”. In modalità post-mortem, l’operatore può impiegare tecniche come il “pull the plug” (scollegare brutalmente l’alimentazione anziché seguire la normale procedura di shutdown, per evitare che eventuali routine di spegnimento dell’attaccante distruggano dati). Naturalmente ciò potrebbe generare qualche inconsistenza nei file (es. journal non “puliti”), ma si preferisce questo rischio piuttosto che perdere prove volatili preziose. Una volta spento e messo in sicurezza il sistema, si passa all’imaging forense dei supporti (illustrato nella sezione successiva). L’acquisizione post-mortem è tipica nelle operazioni di polizia giudiziaria (sequestri) e nelle analisi che non richiedono intervento immediato sul campo. Un responsabile CSIRT deve saper indicare quando è appropriato seguire l’una o l’altra modalità, spesso anche combinandole (es.: acquisizione ibrida, dove prima si esegue un dump di RAM live e poi si spegne per copiare il disco). In ogni caso, che l’acquisizione sia live o a freddo, vanno seguiti i protocolli di documentazione e catena di custodia per garantire integrità e autenticità delle evidenze raccolte.
Acquisizione bitstream di memorie di massa
La copia forense bitstream di un supporto di memoria di massa (dischi fissi, SSD, memorie esterne) è un processo centrale nell’informatica forense. A differenza di una normale copia file-per-file, l’imaging bitstream duplica bit a bit l’intero contenuto del supporto – includendo settori non allocati, spazio slack, aree nascoste – in modo da ottenere un clone esatto dell’originale . Questo è fondamentale perché file cancellati o metadata residuali, non visibili al file system attivo, possono contenere informazioni cruciali in un’indagine.
Procedura di imaging: il processo standard prevede di collegare il supporto originale a una workstation forense (o a un dispositivo duplicatore) in modalità read-only e creare un file immagine o una copia clonata su un supporto di destinazione pulito. Una misura imprescindibile è l’uso di un write-blocker, un dispositivo hardware (o software) che si interpone tra il drive di origine e il sistema di acquisizione, e impedisce qualsiasi comando di scrittura verso il dispositivo sorgente. In questo modo, si può leggere ogni settore del disco senza rischiare modifiche accidentali (ad esempio aggiornamenti di timestamp di accesso, incrementi di contatori SMART, ecc.). I write-blocker hardware sono tipicamente connessi via USB/SATA o tramite dock, e devono essere verificati prima dell’uso; molti modelli forniscono indicatori che confermano lo stato di sola lettura. È importante che il personale ricontrolli che il blocco in scrittura sia attivo per tutti i dispositivi connessi e che i blocker siano periodicamente testati (come raccomandato anche dai laboratori NIST). In alternativa o in aggiunta, su sistemi nix si può montare il supporto in modo da non scrivere journal (opzione ro,noload* per NTFS, ad es.), ma il dispositivo hardware è preferibile perché più affidabile.
Durante l’imaging, si genera di solito un hash crittografico (tipicamente MD5 e/o SHA-1/SHA-256) sia del contenuto originale che della copia, per poter verificare in ogni momento la corrispondenza (integrità) tra i due. Un responsabile deve esigere che al termine dell’acquisizione questi hash combacino e che vengano registrati nei verbali. Come sottolineato da NIST, se si prevede un possibile uso probatorio, è opportuno conservare l’originale intatto come evidenza (ad esempio sigillando il disco originale) ed effettuare tutte le analisi successive sulla copia. L’ISO 27037 e le best practice internazionali insistono molto su questo punto: l’originale diventa evidence master conservato a fini legali, mentre la copia forense (opportunamente verificata) è quella su cui gli analisti lavorano, eventualmente potendone fare ulteriori copie di lavoro. Ogni passo eseguito deve essere documentato dettagliatamente: oltre ai comandi o software utilizzati per l’imaging, vanno annotati ad esempio il modello e seriale del disco originale, la capacità, il nome e versione dello strumento impiegato (software o duplicatore hardware), l’ora di inizio e fine copia, il nome del tecnico operatore e qualsiasi anomalia riscontrata. Queste informazioni supportano la catena di custodia e servono a dimostrare che la procedura è stata eseguita correttamente e senza contaminare le prove.
Formati di output: l’acquisizione bitstream può produrre sia copie fisiche (disk-to-disk, clonazione diretta su un altro drive) che immagini logiche in un file (disk-to-image). La scelta dipende dalle esigenze e dalle risorse: una copia disk-to-disk permette, ad esempio, di montare immediatamente il clone su un’altra macchina per un’analisi rapida, ma richiede un secondo dispositivo di capacità uguale o maggiore. La copia in un file immagine (spesso con estensione .dd se raw o .E01 se compressa con formato EnCase) è più flessibile: il file può essere trasferito, copiato e montato tramite software appositi; di contro, per accedervi occorre utilizzare applicativi forensi o montarlo in un ambiente che supporti tale formato. Molti strumenti consentono anche di comprimere al volo l’immagine, salvando spazio, e di segmentarla in più file (utile per gestire file system che non supportano file di grandi dimensioni). In contesti operativi, il responsabile deve definire uno schema di nomenclatura per le immagini e un sistema di storage sicuro: ad esempio, archiviare le immagini su NAS forense isolato, con controlli di integrità periodici (ricalcolo hash) e accesso ristretto.
In conclusione, l’acquisizione bitstream è un processo dispendioso in termini di tempo e risorse (copiare centinaia di GB può richiedere ore), ma è indispensabile per garantire un’analisi completa e la validità delle prove in tribunale. Organizzazioni ben preparate adottano linee guida interne per quando e come eseguire imaging completo (ad esempio, può non essere realistico fermare immediatamente un server critico per copiarlo; vanno stabiliti criteri di impatto). Il responsabile CSIRT bilancia quindi anche l’esigenza di continuità operativa con quella probatoria, pianificando acquisizioni a freddo in orari e modi che riducano il danno, ma senza compromettere la raccolta delle prove necessarie.
Acquisizione di dump di memoria (RAM)
Le informazioni contenute nella memoria volatile (RAM) di un sistema spesso non hanno equivalenti sul disco e possono rivelare dettagli cruciali di un attacco informatico. La RAM ospita infatti lo stato vivo del sistema: processi in esecuzione, moduli di kernel e driver caricati, connessioni di rete aperte, file aperti (che magari non sono mai stati salvati su disco), chiavi di cifratura in uso, password in chiaro temporaneamente in memoria, e molto altro. Tutto questo viene perso definitivamente non appena il sistema viene spento, data la natura volatile della RAM. Per tale ragione, acquisire un dump di memoria è una fase fondamentale nella risposta agli incidenti live: consente di “congelare” lo stato runtime del sistema al momento dell’incidente per analizzarlo successivamente in laboratorio.
Dal punto di vista pratico, un dump di RAM si ottiene tramite appositi strumenti che copiano byte per byte tutto il contenuto della memoria in un file (spesso chiamato memory.dmp con estensione .raw/.bin). Su sistemi Windows, esistono utilità consolidate come Magnet RAM Capture (fornito da Magnet Forensics) o Belkasoft Live RAM Capturer, nonché tool open-source come WinPmem (facente parte del progetto Rekall) e DumpIt. Questi programmi, tipicamente eseguiti dal tecnico sul sistema target (idealmente da una chiavetta USB, per ridurre scritture su disco), producono un file immagine della RAM che può poi essere scaricato per l’analisi. Su Linux, l’operazione richiede spesso il caricamento di un modulo kernel dedicato come LiME (Linux Memory Extractor) o l’utilizzo di interfacce /dev/mem (se abilitate) e utility dd. L’immagine di memoria così ottenuta viene poi analizzata con framework di memory forensics quali Volatility o Rekall, che permettono di estrarre dalle strutture binarie informazioni intelligibili: ad esempio la lista dei processi e dei relativi segmenti di memoria, le connessioni di rete attive, le DLL/caricate nei processi, eventuale codice iniettato, e persino di ricostruire contenuti testuali (come chat, email, cronologia web) presenti in memoria. Un’analisi approfondita della RAM può rivelare malware fileless (cioè che risiedono solo in memoria), evidenze di attacchi “pass the hash” o credenziali rubate in cleartext, e tante altre informazioni essenziali per capire come è avvenuta la compromissione e cosa sta facendo l’attaccante.
Vale la pena evidenziare due aspetti: temporalità e integrità. La RAM è estremamente dinamica: anche in pochi secondi lo stato può cambiare (processi che terminano, nuovi che si avviano, allocazioni che si spostano). Pertanto, l’operatore deve eseguire il dump il prima possibile durante il triage, minimizzando ritardi. Inoltre, va considerato che il processo di dumping stesso consuma un po’ di RAM e altera alcuni contenuti (ad esempio, parte della RAM viene occupata dal buffer di copia); questo è inevitabile, ma accettabile se si utilizzano strumenti progettati per minimizzare l’impatto. Si documenta in ogni caso quale tool è stato usato e in che orario. Sul fronte integrità, benché non sia possibile calcolare un hash prima (dato che la RAM è mutevole), si calcola almeno l’hash del file di dump generato e lo si conserva per verifiche future, trattandolo poi con la stessa cura di un’immagine disco.
Un altro motivo critico per effettuare il dump di RAM è la presenza di chiavi di cifratura o altri segreti volatili. Se un sistema impiega dischi cifrati (es. BitLocker su Windows, LUKS su Linux) o connessioni VPN cifrate attive, spesso la chiave di decrittazione risiede in RAM mentre il volume è montato o la sessione attiva. Estrarre la RAM può consentire di recuperare tali chiavi – tramite specifici plugin di Volatility – e quindi di accedere a dati altrimenti indecifrabili. ISO 27037 infatti avverte di considerare l’acquisizione di dati volatili prima dello shutdown proprio perché “chiavi di cifratura e altri dati cruciali potrebbero risiedere in memoria attiva”. Un caso concreto è quello dei ransomware: alcuni memorizzano la chiave di cifratura in RAM; se si interviene rapidamente e si cattura la memoria, si potrebbe estrarre la key e decriptare i file senza pagare riscatti.
In sintesi, l’acquisizione della memoria volatile è un tassello irrinunciabile nelle indagini su incidenti moderni. Un responsabile SOC deve prevedere nel piano di risposta la raccolta di dump di RAM per ogni server o endpoint compromesso (quando fattibile in sicurezza) e garantire che il personale sia addestrato all’uso degli strumenti di memory dump. Solamente catturando questa dimensione “effimera” dell’attacco si ottiene una visione completa dell’accaduto, che combini stato dinamico e dati statici.
Artefatti di sistemi operativi Microsoft Windows
I sistemi Windows conservano una vasta gamma di artefatti forensi – file di log, voci di registro, cache di sistema – che possono fornire preziose evidenze sulle attività avvenute prima, durante e dopo un incidente informatico. Un responsabile forense deve conoscere questi artefatti e includerne la raccolta nel processo di acquisizione. Ecco i principali artefatti Windows da considerare e il loro significato:
- Event Logs (registri eventi): Windows registra eventi di sistema, sicurezza e applicazione nei file di log (.evtx) situati in C:\Windows\System32\winevt\Logs\. Questi log, consultabili tramite Event Viewer, sono fondamentali per ricostruire la sequenza di eventi di un sistema. Ad esempio, il Security Log documenta tentativi di accesso (Event ID 4625 per login falliti, 4624 per login riusciti) e cambi di privilegi, permettendo di identificare eventuali accessi non autorizzati o escalation di privilegi avvenute. Il log System registra informazioni su avvii/arresti di sistema, crash, o errori di driver; il log Application contiene eventi dalle applicazioni (es. errori applicativi, servizi custom). Durante un’incidente, copiare e mettere in sicurezza questi file di log è prioritario, in quanto potrebbero venire cancellati dall’attaccante per nascondere le tracce. Un esempio concreto: grazie ai Security Log si può scoprire l’ora esatta in cui un account amministrativo sospetto ha effettuato login, o se vi sono stati tentativi massivi di password guessing.
- Registry (registro di configurazione): Il registro di Windows è una banca dati centralizzata che memorizza configurazioni di sistema, applicazioni, informazioni sugli utenti, dispositivi hardware e molto altro. È suddiviso in hive principali (SAM, SYSTEM, SOFTWARE, SECURITY, oltre ai NTUSER.DAT per ogni utente) che risiedono sul disco. Dal punto di vista forense, il registry è una miniera di informazioni: ad esempio, consente di identificare periferiche USB collegate in passato (chiavi di registro USBSTOR che elencano device ID, date e serial number dei dispositivi – utile per investigare esfiltrazioni tramite chiavette); permette di vedere programmi impostati per l’esecuzione automatica (Run keys) – spesso usati da malware per persistere; contiene gli MRU (Most Recently Used), liste di file o percorsi recentemente aperti da ciascun utente, che aiutano a capire quali documenti sono stati acceduti; tracce di installazione software, configurazioni di rete, e così via. Due artefatti peculiari meritano menzione: ShimCache e AmCache. Lo ShimCache (Application Compatibility Cache) è una cache mantenuta da Windows per compatibilità applicativa, che registra ogni eseguibile avviato sul sistema con timestamp (talora anche se l’eseguibile non esiste più); fornisce quindi una storia delle esecuzioni utile a rintracciare malware eseguiti e poi cancellati. L’AmCache è un file (Amcache.hve) introdotto dalle versioni moderne di Windows, che conserva dettagli sugli eseguibili lanciati, come nome, path, hash e primo timestamp di esecuzione. Analizzando AmCache si può determinare ad esempio la prima volta in cui un malware è stato eseguito, anche se non ci sono log di altro tipo. Durante l’acquisizione forense, è buona pratica estrarre copie dei file di registro (
C:\Windows\System32\Config\*eC:\Users\{utente}\NTUSER.DATper ogni profilo) per analizzarli con strumenti forensi (Registry viewers, RegRipper, etc.). - Prefetch files: Windows utilizza la funzionalità Prefetch per velocizzare il caricamento dei programmi usati di frequente. Ogni volta che un eseguibile viene lanciato, il sistema crea/ aggiorna un file prefetch (estensione
.pf) in C:\Windows\Prefetch\ contenente il nome del programma, un hash del percorso e riferimenti ai file caricati. Dal punto di vista forense, i prefetch file tracciano l’esecuzione dei programmi e ne registrano il timestamp di ultimo avvio . Ciò è prezioso per stabilire una timeline di esecuzione: ad esempio, se un malware è stato eseguito alle 3:00 AM e poi cancellato, rimarrà comunque un file .pf (es.MALWARE.EXE-3AD3B2.pf) con ultimo esecuzione a quell’ora. I prefetch indicano anche il numero di volte di esecuzione e quali librerie o file ha caricato il processo, dando indizi su cosa abbia fatto. È importante notare che il Prefetch è abilitato di default su desktop Windows, ma su Windows Server potrebbe essere disabilitato per impostazione predefinita. Nelle analisi di incidenti su client, i prefetch sono spesso tra le prime cose da controllare per vedere quali programmi anomali sono stati eseguiti di recente. Vanno quindi raccolti durante l’acquisizione (copiando l’intera cartella Prefetch). Un caso d’uso tipico: rilevare un tool di hacking (es. mimikatz.exe) dal prefetch, anche se l’eseguibile non è più presente – evidenza che qualcuno lo ha lanciato sul sistema. - LNK (Link) files: i file di collegamento
.lnksono scorciatoie Windows che si creano quando un utente accede a file o cartelle (ad es. i collegamenti nei “Recent Items”). Ogni LNK conserva metadati dettagliati sull’elemento target: percorso completo del file/cartella, dispositivo di origine (incluso il numero di serie di volume – utile per identificare unità USB), timestamp dell’ultimo accesso, dimensione del file target, e a volte coordinate della finestra o icona. In un’indagine, analizzare i LNK consente di scoprire attività utente come aperture di documenti o esecuzione di strumenti, anche se tali file non esistono più. Ad esempio, se un dipendente ha aperto un file riservato e copiato su USB, potrebbe restare un link in%APPDATA%\Microsoft\Windows\Recent\che svela nome e percorso di quel file, nonché identifica la pennetta USB usata (dal seriale riportato nel LNK). I LNK possono anche indicare programmi lanciati da percorsi insoliti (es.C:\Temp\hacker_tool.exe), dando tracce di esecuzioni sospette. È quindi prassi acquisire la cartella Recent di ciascun profilo utente e altri percorsi dove possono annidarsi LNK (es. collegamenti sul desktop, nel menu Start, etc.). - Altri artefatti rilevanti: ce ne sono numerosi; tra i principali citiamo: i Jump Lists (liste dei file aperti di recente per applicazioni “pinned” sulla taskbar, memorizzate in
%APPDATA\Microsoft\Windows\Recent\AutomaticDestinations\), utili per vedere cronologia di utilizzo di specifici programmi; i file di paging e ibernazione (C:\pagefile.syseC:\hiberfil.sys), che contengono porzioni di RAM e stato del sistema scritti su disco – analizzandoli si possono estrarre password o frammenti di documenti presenti in memoria; i dump di crash (MEMORY.DMPgenerati da Blue Screen) che talvolta sopravvivono e contengono un’istantanea della RAM al momento del crash; il MFT (Master File Table) nei volumi NTFS, che elenca tutti i file con i loro timestamp e può essere estratto per analisi timeline; i log di sistema quali Firewall di Windows (p.e.pfirewall.logse attivato) e Windows Defender (eventi antimalware) che potrebbero rivelare tentativi di connessione o malware rilevati; infine, i file di configurazione e cache applicative (ad esempio i log di navigazione web, la cache DNS, i file di Outlook PST/OST per le email, etc.) da acquisire se pertinenti al caso.
In fase di risposta a un incidente, il responsabile CSIRT deve stilare un elenco di questi artefatti Windows e assicurarsi che la squadra li raccolga sistematicamente. Spesso si utilizzano strumenti di live response (come KAPE – Kroll Artifact Parser and Extractor, di Eric Zimmerman) che automaticamente collezionano copie di molti di questi artefatti chiave per una rapida analisi. La ricchezza di informazioni fornite dagli artefatti Windows consente, una volta in laboratorio, di ricostruire la linea temporale degli eventi (tramite analisi timeline correlando log, MFT e timestamp vari) e di attribuire azioni ad account utente specifici, distinguendo attività lecite da quelle malevole. Ad esempio, combinando i dati di registro (es. chiave USBSTOR) con i LNK file, si può provare che un certo file è stato copiato su una chiavetta a una certa ora da un determinato utente. Per garantire ciò, la fase di acquisizione deve aver preservato intatti tali artefatti.
Artefatti di sistemi operativi Linux
Anche in ambienti Linux/Unix esistono artefatti forensi fondamentali per un’analisi post-incident. Sebbene Linux non abbia un Registro unificato come Windows, mantiene moltissime informazioni in file di log testuali e file di configurazione, che se raccolti e analizzati correttamente permettono di ricostruire intrusioni e attività anomale. Ecco alcuni elementi chiave che un responsabile dovrebbe includere nel piano di acquisizione da sistemi Linux compromessi:
- Log di sistema e di sicurezza: la gran parte delle distribuzioni Linux registra gli eventi in
/var/log/. In particolare, il syslog o log generale di sistema (tipicamente/var/log/syslogsu Debian/Ubuntu o/var/log/messagessu Red Hat/CentOS) contiene messaggi su una vasta gamma di attività: avvio di servizi, messaggi del kernel, connessioni di rete, errori generici. Esaminare il syslog consente di individuare quando sono stati avviati o fermati servizi (utile per vedere ad esempio se un servizio critico è andato in crash in concomitanza con l’attacco) e messaggi anomali del kernel che potrebbero indicare exploit (es. oops o segfault sospetti). Ancora più importanti spesso sono i log di autenticazione, come/var/log/auth.log(su sistemi Debian-like) o/var/log/secure(Red Hat-like), dove vengono tracciati tutti i tentativi di login, sia locali che remoti, con indicazione di utente, origine e successo/fallimento. In questi file si trovano anche i log di uso del comando sudo (elevazione di privilegi), gli accessi via SSH, eventuali cambi di password, ecc. Durante un’incidente, analizzare auth.log può rivelare ad esempio un attacco brute-force in atto (molti tentativi di login falliti in sequenza) o se un utente in particolare ha ottenuto accesso root via sudo in orari non autorizzati. Altri log utili sono quelli di servizi specifici: ad esempio, log di Apache/Nginx in/var/log/apache2/o/var/log/nginx/(per investigare compromissioni di web server), log di database (MySQL, PostgreSQL) se si sospetta un SQL injection, log di firewall/iptables, ecc. Il responsabile deve stilare una lista dei percorsi di log da prelevare in base ai servizi in esecuzione sul sistema bersaglio. È buona pratica includere sempre i log lastlog, wtmp, btmp: sono file binari (tipicamente in/var/log/che registrano rispettivamente l’ultimo login di ogni utente, la cronologia di tutti i login (wtmp) e quella dei login falliti (btmp). Questi file, analizzabili con comandi comelastelastb, possono integrare le informazioni di auth.log riguardo gli accessi utente nel tempo. - Cronologia dei comandi e configurazioni utente: su Linux, ogni utente shell tipicamente ha un file di history (es.
~/.bash_historyper Bash) in cui vengono salvati i comandi digitati in passato. Questa cronologia, se non cancellata dall’attaccante, è un artefatto estremamente prezioso: consente di vedere quali comandi sono stati eseguiti – ad esempio, un aggressore che abbia ottenuto accesso shell potrebbe aver lanciato comandi per creare nuovi utenti, modificare configurazioni o estrarre dati, e spesso tali comandi rimangono nella bash_history. Va notato che la history di solito si salva solo alla chiusura della sessione; se l’attaccante non ha terminato la sessione o ha disabilitato la logging della history, il file potrebbe non contenere tutto. In ogni caso, acquisire i file di history di tutti gli utenti (bash, zsh, etc.) è doveroso. Oltre ai comandi, le configurazioni utente come~/.ssh/authorized_keysdevono essere raccolte: questo file indica eventuali chiavi pubbliche autorizzate per login SSH senza password – spesso gli attaccanti ne aggiungono una per garantirsi l’accesso persistente. Anche i file~/.ssh/known_hostspossono dare indizi su da quali macchine ci si è collegati. Il filesystem home degli utenti, in generale, può contenere script di persistenza (es. aggiunte in~/.bashrco~/.profileche eseguono malware all’avvio della shell). Durante l’acquisizione forense, se non si effettua un’immagine completa del disco, almeno le home directory rilevanti dovrebbero essere copiate integralmente per preservare questi artefatti. - Configurazioni di sistema e job pianificati: un vettore comune di persistenza su Linux è l’uso di cron job maligni. I cron job si trovano in
/etc/crontab,/etc/cron.hourly/cron.daily/...o nelle crontab per utente (/var/spool/cron/crontabs/). Analizzandoli, si potrebbe scoprire, ad esempio, che è stato inserito un job che esegue periodicamente un certo script (magari per ricollegarsi a una botnet o mantenere l’accesso). Durante l’incidente, si estraggono quindi tutte le configurazioni di cron. Un altro punto chiave sono le configurazioni di SSH in/etc/ssh/sshd_config: se un attaccante ha abilitato opzioni deboli o cambiato la porta del servizio potrebbe aver modificato questo file. Inoltre, i log di SSH (che in realtà confluiscono in auth.log) dovrebbero essere già considerati, ma è bene filtrarli per evidenziare, ad esempio, da quali IP sono avvenuti accessi SSH riusciti. Anche la configurazione di altri servizi (VPN, servizi cloud, Docker containers in/var/lib/docker/etc.) può essere rilevante se l’incidente li coinvolge – la regola generale è collezionare tutto ciò che potrebbe aver registrato attività dell’attaccante. - Log di pacchetti e sistema: un aspetto peculiare di Linux è la presenza dei package management logs. Su Debian/Ubuntu c’è
/var/log/dpkg.logche tiene traccia di ogni installazione/aggiornamento/rimozione di pacchetti, con timestamp. Su RedHat/CentOS analoghi sono i log di yum o dnf. Questi log sono utilissimi per vedere se durante l’intrusione l’attaccante ha installato nuovi software (es. un server web, uno strumento di hacking) oppure se il sistema ha aggiornato qualcosa di critico di recente. Ad esempio, se dpkg.log mostra l’installazione di netcat o nmap, è un red flag di attività sospetta. Altri log degni di nota:/var/log/lastlog(ultimi accessi utenti),/var/log/faillog(errori di login),/var/log/mail.log(attività del server mail, se presente, per vedere possibili esfiltrazioni via email) e i log di eventuali IDS/IPS installati. Se il sistema utilizza systemd, molti log tradizionali potrebbero essere nel journal binario (/var/log/journal/) accessibile conjournalctl: in tal caso, è opportuno esportare l’intero journal (usandojournalctl --sincecon un range temporale, oppure copiando i file journal) per l’analisi.
In fase di acquisizione, spesso la via più semplice è eseguire un package di raccolta (ad esempio uno script che copia tutto /var/log e alcune directory chiave di /etc e home utenti). Tuttavia, un responsabile attento specificherà quali sono gli “essential artifacts” Linux da non tralasciare. Magnet Forensics elenca 7 artefatti essenziali: history bash, syslog, auth.log, sudo logs, cron, SSH, package logs tutti punti che abbiamo toccato. Raccogliendo questi, un analista potrà: ricostruire la timeline di un attacco (dall’intrusione iniziale visibile in auth.log, alle azioni compiute visibili nella history e nei log di sistema, fino alla persistenza via cron), attribuire azioni a utenti/ip (log di autenticazione), e scoprire eventuali manomissioni (servizi disabilitati, configurazioni cambiate). Un esempio: tramite auth.log si individua che l’attaccante ha ottenuto accesso con l’utente “webadmin” via SSH; guardando nella bash_history di webadmin si vede che ha eseguito un certo script e aperto una connessione reverse shell; controllando crontab si trova un job aggiunto da webadmin che ogni ora tentava di riconnettersi ad un certo host (persistenza). Inoltre dpkg.log rivela che l’attaccante ha installato un pacchetto socat per facilitare le proxy. Tutto ciò costruisce una narrazione completa dell’incidente. È compito del responsabile assicurare che tali tasselli informativi non vadano perduti: ad esempio, evitando la rotazione o cancellazione dei log (in casi estremi, potrebbe decidere di spegnere subito un server Linux se teme che l’attaccante possa “ripulire” i log tramite rootkit, e acquisire a freddo).
In conclusione, gli artefatti Linux, sebbene sparsi in file diversi, coprono molti aspetti dell’attività di sistema e, se acquisiti integralmente, forniscono un quadro molto dettagliato agli investigatori. La sfida è sapere dove guardare: per questo esistono anche cheat-sheet e liste preparate (ad esempio Seven Linux Artefacts to Collect di SANS) che guidano i primi responder su cosa prendere. Un responsabile dovrebbe prevedere tali linee guida e aggiornarsi continuamente, dato che i percorsi e formati dei log possono variare con le versioni (es. il passaggio a systemd-journald). Garantire la raccolta coerente e completa di questi artefatti in ogni incidente significa accelerare l’analisi forense e migliorare l’efficacia della risposta.
Strumenti hardware e software per l’acquisizione forense
Per eseguire le operazioni sopra descritte, il responsabile deve assicurarsi che il team disponga dei giusti strumenti hardware e software di acquisizione forense, nonché delle competenze per usarli correttamente. Vediamo i principali.
Strumenti hardware
- Write-blocker: come già menzionato, sono dispositivi (talora in forma di piccoli box USB/SATA o bay da laboratorio) che assicurano l’accesso in sola lettura ai supporti di memoria originali . Sono uno standard de-facto in qualsiasi acquisizione di dischi: marchi noti includono Tableau (ad es. Tableau T8u USB 3.0 Forensic Bridge), Logicube, Digital Intelligence UltraBlock, ecc. Esistono write-blocker per diverse interfacce: SATA/PATA, USB, NVMe, SCSI, ecc. Il loro impiego consente di collegare un hard disk sequestrato alla macchina forense senza rischio di contaminare i dati – condizione essenziale per mantenere l’integrità probatoria. Alcuni modelli hanno funzionalità avanzate come il logging interno delle operazioni o la possibilità di attivare/disattivare il blocco (ma in forense deve restare attivo!). Il NIST CFTT (Computer Forensic Tool Testing) conduce test periodici sui write-blocker per certificarne l’affidabilità; un responsabile può consultare tali risultati per scegliere dispositivi adeguati.
- Duplicatori e unità di imaging hardware: si tratta di apparecchi dedicati che possono copiare un disco di origine verso uno o più dischi di destinazione senza bisogno di un computer intermedio. Spesso sono dispositivi portatili, alimentati a parte, con schermo integrato, usati sul campo dalle forze dell’ordine. Esempi: Tableau Forensic Duplicator, Logicube Falcon, Atola Insight. Questi strumenti eseguono copie bitstream con verifica hash incorporata e spesso supportano il cloning multi-target (una sorgente verso due copie identiche contemporaneamente). Il vantaggio è la velocità e il fatto che sono costruiti per non alterare l’originale (incorporano essi stessi funzioni di write-block). Inoltre, supportano formati di output multipli (raw, E01, ecc.) e generano report dettagliati. Secondo NIST SP 800-86, i tool hardware di imaging forniscono in genere log di audit trail e funzioni per garantire consistenza e ripetibilità dei risultati. L’uso di duplicatori è frequente nelle acquisizioni di numerosi supporti in poco tempo (es. per copiare velocemente decine di hard disk durante un sequestro contemporaneo).
- Altri tool hardware: include adattatori e accessori, ad esempio: kit di cavi e adattatori per collegare dischi di laptop, telefoni o dispositivi proprietari; dispositivi per estrarre chip di memoria (nell’ambito mobile forensics, eMMC reader); strumenti per acquisire SIM card o smart card, ecc. Nel contesto specifico di incidenti informatici in enti, alcuni di questi sono meno rilevanti, ma un responsabile dovrebbe avere pronte soluzioni per connettere qualsiasi supporto si trovi (dai vecchi dischi IDE agli ultimi M.2 NVMe). Da citare anche i blocchi di rete (sebbene non hardware in senso stretto): quando si prende un computer acceso come evidenza, un’opzione è inserirlo in una “faraday bag” o scollegarlo da rete e Wi-Fi per isolarlo – questo più per preservare da modifiche remote che per acquisizione, ma fa parte dell’equipaggiamento di scena.
Strumenti software
- Utility di imaging forense: sul lato software, un arsenale classico comprende tool come dd (il tool Unix per copie bitstream), con varianti forensi quali dcfldd o Guymager (GUI Linux) che aggiungono funzioni di hashing e log. Questi consentono di creare immagini raw bit-a-bit. In ambiente Windows, il popolare FTK Imager permette di acquisire dischi, cartelle o anche singoli file di memoria e di rete, generando immagini in diversi formati (incluso il compresso E01) e calcolando hash in automatico. Software commerciali come EnCase e X-Ways integrano funzioni di imaging: ad esempio EnCase permette di creare direttamente un case con immagini E01 e verifica integrità. Molti di questi software supportano sia l’acquisizione fisica (del disco intero) che logica (ad es. solo una partizione o solo certi file). La scelta dello strumento dipende dallo scenario: dd e affini sono ottimi per ambienti Linux e situazioni scriptabili; FTK Imager è spesso usato su postazioni Windows per copie “ad hoc” (ad esempio di pendrive o di piccoli volumi) grazie alla sua semplicità d’uso grafica. È importante che i tecnici verifichino i checksum generati e alleghino i log prodotti dallo strumento (ad es. FTK Imager produce un file di output con tutti i dettagli dell’operazione). Da ricordare: prima dell’imaging, il disco di destinazione va azzerato o comunque pulito, per evitare contaminazione (principio del “forensically clean media”).
- Strumenti per acquisizione live e triage: in contesti di incidente, esistono suite pensate per automatizzare la raccolta di evidenze volatili e semi-volatili. Ad esempio, KAPE (Kroll Artifact Parser and Extractor) consente di definire “target” (artefatti noti di Windows) e raccoglierli rapidamente da un sistema live in un output centralizzato. Volatility (framework di memory forensics) ha moduli per dumping live memory su Windows (WinPmem) e ora anche su Linux. Belkasoft Evidence Center e Magnet AXIOM dispongono di agent da deployare su macchine live per estrarre dati chiave (RAM, registro eventi, ecc.) con un minimo impatto. Un altro strumento pratico è CyLR (Cyber Logos Rapid Response) – un leggero collector open source – o lo script Livessp (SANS SIFT). Questi tool aiutano il first responder a non dimenticare elementi importanti durante la concitazione di un incidente. Per il triage rapido di supporti spenti (es. decine di PC da controllare), esistono anche soluzioni come Paladin (distro live basata su Ubuntu con toolkit forense) o CAINE (Computer Aided Investigative Environment), che permettono di bootare la macchina da USB/DVD in un ambiente forense e copiare selettivamente evidenze (con write-block software attivo sul disco originale).
- Tool per acquisizione della memoria: già evidenziati in parte, meritano un focus. Oltre a DumpIt e Magnet RAM Capture citati, c’è Microsoft LiveKd (Sysinternals) che consente di ottenere dump di memoria di macchine Windows partendo da un kernel debug; LiME su Linux è ormai standard per memdump su Android e server headless; AVML (Acquire Volatile Memory for Linux) è uno strumento più recente di Microsoft per estrarre RAM da VM Linux (utile in cloud). Qualunque strumento si usi, deve essere testato e validato prima in laboratorio. Ad esempio, si può verificare che il dump prodotto sia apribile in Volatility e che corrisponda (nel caso Windows) alla versione OS corretta. Il responsabile dovrebbe predisporre procedure e ambienti di prova per garantire la familiarità del team con tali strumenti: un errore nell’uso (es. dimenticare di eseguire come Administrator un RAM capture tool) potrebbe rendere nullo il dump.
In generale, la dotazione strumentale di un responsabile SOC/CSIRT deve essere allineata alle best practice internazionali. Gli standard NIST elencano dozzine di tool sia commerciali che open source, e raccomandano di avere politiche per l’uso corretto degli strumenti (ad esempio, mantenere una copia di ciascun software usato, con versioni, hash, in modo da poter dimostrare in tribunale esattamente cosa è stato usato e che non contiene backdoor). È inoltre importante monitorare il panorama: strumenti nuovi emergono (ad es. per acquisire dati da cloud, o dall’IoT), e un responsabile deve valutarne l’adozione. Nel kit non dovrebbero mancare anche strumenti di verifica: ad esempio, software per calcolare hash (md5deep, sha256sum), per confrontare file, per estrarre metadata. Anche se non direttamente di “acquisizione”, essi supportano la fase di accertamento dell’integrità dei dati acquisiti.
In conclusione, strumenti hardware e software ben selezionati sono il braccio armato dell’analista forense. La loro efficacia dipende dalla competenza d’uso e da procedure appropriate. Un responsabile deve assicurare formazione continua e magari predisporre ambienti di simulazione dove testare periodicamente l’intera catena (ad esempio, simulare un attacco e far eseguire ai tecnici l’acquisizione con i loro tool, verificando poi che tutto – hash, log, tempi – sia conforme). Questa preparazione fa la differenza tra un’acquisizione improvvisata e una condotta professionalmente, come richiesto in un contesto di sicurezza nazionale.
Standard e linee guida internazionali
Nel campo della digital forensics applicata agli incidenti informatici esistono standard e linee guida internazionali che definiscono principi, terminologie e procedure riconosciute. Un candidato al ruolo di responsabile CSIRT deve non solo conoscerli, ma saperli mettere in pratica e farvi aderire le operazioni del team. Di seguito, i riferimenti principali.
- ISO/IEC 27037:2012 – “Information technology – Security techniques – Guidelines for identification, collection, acquisition and preservation of digital evidence”. È lo standard ISO specifico per la prima fase della gestione delle evidenze digitali. Esso stabilisce le linee guida per l’identificazione delle potenziali fonti di prova, la raccolta (intesa come acquisizione sul campo dei dispositivi/ evidenze), l’acquisizione forense vera e propria (creazione di copie bitstream) e la preservazione delle stesse. Vengono definiti i principi generali (ad es. minimizzare la contaminazione, assicurare la documentazione completa, mantenere la chain of custody) e identificati i ruoli chiave, in particolare il Digital Evidence First Responder (DEFR), ossia l’operatore iniziale che interviene sulla scena. L’ISO 27037 fornisce indicazioni su come valutare la volatilità delle evidenze e come dare priorità in base ad essa (ad esempio, suggerendo di acquisire per prima i dati che “scomparirebbero” se il dispositivo fosse spento). Inoltre, dedica sezioni alla corretta custodia, etichettatura e trasporto delle evidenze digitali, sottolineando l’uso di contenitori appropriati (es. buste antistatiche, custodie sigillabili) e precauzioni contro fattori ambientali che possano danneggiare i dispositivi raccolti. Questo standard – pur non essendo una procedura operativa dettagliata – costituisce un framework di riferimento ampiamente adottato da forze di polizia e team di risposta in tutto il mondo per garantire che fin dai primi istanti le evidenze siano trattate “as ISO compliant as possible”. In Italia, i principi di ISO 27037 sono stati recepiti in molte linee guida interne di Forze dell’Ordine e CERT aziendali.
- NIST Special Publication 800-86 – “Guide to Integrating Forensic Techniques into Incident Response”. Pubblicata dal National Institute of Standards and Technology (USA), questa guida colma il gap tra digital forensics tradizionale e incident response. Il suo scopo è fornire un processo strutturato per utilizzare tecniche forensi durante la risposta a incidenti di sicurezza . NIST 800-86 descrive un modello di processo forense composto da quattro fasi: Collection (raccolta) – dove si acquisiscono i dati rilevanti dall’ambiente target (dischi, memorie, log di rete, ecc); Examination (esame) – che implica il filtro e l’estrazione preliminare di informazioni dai dati grezzi (ad es. parsing di log, carving di file dalla memoria); Analysis (analisi) – la fase interpretativa in cui gli analisti traggono conclusioni su cosa è successo, correlando le evidenze; Reporting (reportistica) – documentare i risultati e magari fornire raccomandazioni. Questa struttura viene integrata nel ciclo di vita di incident response (Preparation, Detection & Analysis, Containment, Eradication & Recovery, Lessons Learned) delineato da un altro noto documento NIST (SP 800-61). La SP 800-86 fornisce anche practical tips: ad esempio suggerisce fonti di evidenze per vari tipi di incidenti, tecniche di collezione specifiche (come fare imaging, come raccogliere dati di rete), considerazioni legali da tenere presenti (negli USA, aspetti di privacy, Fourth Amendment, ecc.), e importanza di policy e procedure interne per la forensics. In sostanza, questo documento aiuta un responsabile a capire come inserire le attività forensi in un piano di risposta senza improvvisarle. Ad esempio, se c’è un sospetto worm in rete, la guida consiglia di raccogliere non solo i sistemi infetti ma anche traffico di rete, memory dump per analizzare il malware, e di farlo in tempi rapidi dati i dati volatili. Fornisce quindi un utile complemento operativo agli standard ISO.
- RFC 3227 – “Guidelines for Evidence Collection and Archiving” (IETF). Questo RFC (Request for Comments) del 2002, pur datato, è ancora citatissimo per il concetto di order of volatility che introduce. In poche pagine, fornisce una serie di raccomandazioni pratiche per chi raccoglie evidenze digitali in ambiente live. Oltre a ribadire l’importanza di partire dai dati più volatili (CPU, cache, RAM, processi) per poi passare a quelli meno volatili come dischi e infine backup e media esterni, include una lista di cose da non fare: ad esempio non spegnere il sistema prematuramente, pena perdita di dati importanti; non fidarsi dei tool presenti sul sistema compromesso, ma usare software di raccolta su supporti protetti; non usare comandi che possano alterare massivamente i file (come tool che cambiano tutti gli ultimi accessi); attenzione a “trappole” di rete (disconnecting la rete può attivare meccanismi distruttivi se il malware li prevede). Il documento tratta anche aspetti di privacy (invita a rispettare le policy aziendali e leggi durante la raccolta, minimizzando dati non necessari) e considerazioni legali generali sulla validità delle prove (ad esempio, ricorda che le prove devono essere autentiche, affidabili, complete e ottenute in modo lecito per essere ammissibili). Un altro punto fondamentale è la definizione di Chain of Custody (catena di custodia): RFC 3227 specifica che bisogna poter descrivere chiaramente quando, dove, da chi ogni evidenza è stata scoperta, raccolta, maneggiata, trasferita. Suggerisce di documentare tutti i passaggi, includendo date, nomi e persino numeri di tracking delle spedizioni se un supporto viene trasferito. Questo è pienamente in linea con le prassi forensi e in Italia corrisponde all’obbligo di verbale di sequestro e custodia delle copie forensi. In sintesi, l’RFC 3227 è una lettura obbligata per i first responder e rimane attuale: i suoi consigli vengono spesso citati nei corsi forensi e implementati nei manuali operativi.
- Altri standard e guide rilevanti: oltre ai sopra citati, possiamo menzionare il NIST SP 800-101 (Guide to Mobile Forensics) per la parte di dispositivi mobili – utile se l’incidente coinvolge smartphone aziendali; lo standard ISO/IEC 27035 per la gestione degli incidenti di sicurezza, che include la fase di Incident Response e accenna alla preservazione delle evidenze come parte del processo di mitigazione; la serie ISO/IEC 27041, 27042, 27043 che forniscono rispettivamente guide sulla gestione delle attività forensi (assicurazione di processo), sull’analisi di evidenze digitali e sugli step per investigazioni digitali – evoluzioni post-27037 che entrano più nel dettaglio delle fasi successive all’acquisizione. In ambito law enforcement europeo, il Manuale di Valencia (European cybercrime training manual) e le linee guida dell’ENFSI (European Network of Forensic Science Institutes) replicano concetti simili per armonizzare le pratiche. Nel Regno Unito, la famosa ACPO Good Practice Guide for Digital Evidence enuncia 4 principi, tra cui il principio 1: non alterare i dati su un dispositivo a meno che non sia inevitabile; principio 2: chiunque acceda a dati digitali deve essere competente e tenere traccia di tutto; principio 3: va tenuta documentazione completa di tutti i processi; principio 4: la persona responsabile dell’indagine ha la responsabilità generale di assicurare conformità legale. Questi rispecchiano molto quanto detto in ISO 27037 e RFC 3227, enfatizzando integrità e documentazione. Infine, val la pena ricordare che in Italia anche la giurisprudenza ha affrontato il tema: la Corte di Cassazione (Sez. VI, sentenza n. 26887/2019) ha delineato un vero e proprio vademecum su come devono essere eseguiti i sequestri di dati informatici, richiamando la necessità di adottare cautele tecniche per garantire che la copia forense sia fedele e che gli originali siano conservati senza alterazioni, pena l’inutilizzabilità degli elementi raccolti. Ciò rafforza l’importanza per un responsabile di seguire standard riconosciuti, così che l’operato del team sia non solo efficace tecnicamente ma anche solido a livello legale.
In sintesi, standard e linee guida forniscono il quadro teorico e pratico entro cui muoversi: adottarli garantisce consistenza delle operazioni forensi e facilita la cooperazione con altri team (nazionali e internazionali) parlando lo stesso “linguaggio” procedurale. Un responsabile informato farà riferimento a questi documenti nella stesura delle procedure interne, nell’addestramento del personale e nella giustificazione delle scelte operative durante un incidente.
Casi d’uso in contesto nazionale
Per contestualizzare quanto esposto, consideriamo alcuni scenari nel panorama italiano dove le pratiche di acquisizione forense sono state – o potrebbero essere – determinanti. L’obiettivo è mostrare come un responsabile CSIRT/SOC applica tali conoscenze in situazioni reali, spesso in collaborazione con enti pubblici e forze dell’ordine.
1. Attacco ransomware a un ente pubblico (Regione Lazio, 2021): un caso emblematico è l’attacco ransomware che ha colpito la Regione Lazio nell’agosto 2021, paralizzando il portale vaccinale COVID-19 e numerosi servizi online per giorni. In un evento del genere, il responsabile della risposta (in sinergia con l’ACN/CERT nazionale e i tecnici regionali) ha dovuto immediatamente predisporre un triage su decine di server e sistemi: identificare quali erano criptati e fuori uso, isolare la rete per prevenire ulteriore propagazione, ma anche acquisire copie forensi dei sistemi colpiti per analizzare il malware e verificarne l’impatto. Nel caso Lazio, ad esempio, è stata effettuata l’acquisizione bitstream dei server critici, inclusi i controller di dominio e i server di gestione del portale sanitario, al fine di consegnare tali immagini agli esperti (anche stranieri) per l’analisi del ransomware e la ricerca di eventuali decryptor. Parallelamente, è probabile sia stato eseguito il dump della memoria su almeno uno dei server infetti ancora in esecuzione, per catturare la chiave di cifratura o tracce dell’attaccante in RAM. Questo incidente ha evidenziato l’importanza di avere procedure pronte: nonostante la gravità, il team forense doveva agire tempestivamente senza compromettere i servizi di ripristino. La raccolta dei log di sicurezza Windows e dei domain controller logs è stata fondamentale per ricostruire la dinamica: ad esempio, capire quale account iniziale è stato compromesso (si parlò di credenziali VPN rubate) e quando il malware ha iniziato a diffondersi. L’analisi forense, condotta sulle immagini acquisite, ha permesso di individuare i file di persistence creati dal ransomware e i movimenti laterali effettuati, dati con cui il responsabile ha potuto informare gli amministratori su come bonificare completamente la rete prima di rimetterla in produzione. Inoltre, queste evidenze sono state girate alla Polizia Postale per le indagini penali. Il lesson learned di Lazio 2021 ha probabilmente portato a migliorare ancora le pratiche di incident response italiane, ad esempio enfatizzando la necessità di separare le reti di backup e verificare che le copie di sicurezza non fossero cifrate (in quell’occasione, fortunatamente i backup erano salvi, ma in altri casi non è stato così). Un responsabile, da questo esempio, trae l’indicazione che avere un piano di acquisizione forense predefinito per scenari di ransomware massivi è essenziale: chi fa cosa, quali sistemi si copiano per primi, dove si stoccano le immagini in sicurezza, come coordinare più squadre sul territorio (nel Lazio intervenne anche il CNAIPIC e team di sicurezza privati). In definitiva, il caso Regione Lazio ha mostrato come l’acquisizione forense non sia una fase “postuma”, ma integrata nella gestione della crisi: mentre si lavora al ripristino, in parallelo si portano avanti imaging e raccolta evidenze, poiché attendere la fine dell’emergenza per iniziare l’acquisizione significherebbe perdere dati chiave o trovare sistemi completamente ripristinati (quindi privati delle tracce dell’attacco).
2. Compromissione di account email governativi: immaginiamo uno scenario in cui un Ministero o un’agenzia governativa rileva accessi sospetti a caselle di posta istituzionali (PEC o email interne). Questo potrebbe derivare da un attacco mirato (es. phishing avanzato) volto a carpire informazioni sensibili. Il responsabile CSIRT nazionale verrebbe allertato per supportare l’ente nell’indagine. In un caso del genere, una delle prime mosse sarebbe raccogliere in maniera forense i log del server di posta (ad esempio i log IMAP/POP/SMTP, o i log di accesso alla Webmail) per identificare da quali IP e quando si sono verificati gli accessi abusivi. Poi, si procederebbe all’acquisizione delle caselle di posta compromesse – ad esempio esportando i file .pst/.ost nel caso di Exchange/Outlook, o effettuando un dump delle caselle dal server – per analizzare quali email sono state lette o esfiltrate dall’attaccante. Se si sospetta che l’attaccante abbia usato una postazione interna compromessa, quel PC verrebbe sequestrato per un’analisi: in tal caso la squadra forense eseguirebbe un’acquisizione post-mortem completa del disco e della RAM (se la macchina è accesa) di tale computer. Dall’immagine del PC si cercherebbero artefatti come browser history (per vedere se l’attaccante ha navigato la webmail), eventuali keylogger o malware installati, e tracce di movimenti laterali. Un esempio reale simile è accaduto con attacchi APT a Ministeri esteri: in passato, malware come Remote Control System o Ursnif hanno infettato PC di dipendenti pubblici per rubare credenziali PEC e documenti riservati. In queste indagini, la collaborazione con Polizia Postale è stretta: il responsabile deve garantire che ogni acquisizione segua procedure ineccepibili così che le prove (log di accesso, immagini dei PC) siano valide per identificare gli autori e perseguirli. Un aspetto critico qui è la catena di custodia condivisa: ad esempio, i log del server mail potrebbero essere forniti dall’ente al CSIRT e poi da questo alla Polizia; bisogna documentare ogni passaggio, magari apponendo firme digitali ai file per garantirne l’immodificabilità durante il trasferimento. Questo scenario evidenzia l’importanza della normativa nazionale (es. obblighi di notifica incidenti secondo NIS/DORA) che impone tempi stretti: entro 24 ore l’ente deve informare l’ACN, e nei giorni seguenti fornire risultati preliminari. Un responsabile quindi attiverebbe subito le procedure di acquisizione forense parallelamente alla mitigazione (es. reset password account, blocco di IoC a firewall), per poter fornire rapidamente un quadro d’impatto. Il risultato tangibile sarebbe un rapporto forense con elenco delle caselle violate, l’analisi di come (es. malware su PC X che ha fatto da pivot), e le azioni raccomandate per evitare futuri attacchi (es. 2FA obbligatoria sulle caselle, campagne anti-phishing).
3. Indagine su dipendente infedele in un ente pubblico: un contesto diverso, ma non raro, è quello di un abuso interno – ad esempio un funzionario di un’amministrazione che sottrae dati riservati (liste di cittadini, documenti interni) per fini personali o per rivenderli. In tal caso, l’incidente può non essere un “attacco esterno” ma una violazione di policy interna. Tuttavia, le tecniche di acquisizione forense sono analoghe: supponiamo che si sospetti che il dipendente abbia copiato file su una USB personale. Il responsabile della sicurezza dell’ente, con supporto forense) disporrà il sequestro del PC aziendale dell’individuo e di eventuali supporti nel suo ufficio. Su quel PC si effettuerà un imaging completo del disco. Dall’analisi emergeranno ad esempio artefatti USB nel registro di Windows con l’identificativo di una pen drive non autorizzata e date di utilizzo. I log di accesso potrebbero mostrare che il soggetto ha lavorato fuori orario su quei file (Event Log con login serali, oppure timeline di $MFT che indica accessi in orari anomali). Anche i LNK files e la shellbag del registro potrebbero confermare che ha aperto cartelle contenenti i dati riservati e magari copiato file su un percorso esterno. Tutte queste prove, opportunamente raccolte e documentate, costituiranno materiale per un eventuale procedimento disciplinare o penale. In un caso simile è fondamentale che la copia forense del disco del dipendente sia effettuata in maniera impeccabile e che l’originale venga custodito in cassaforte: la difesa potrebbe contestare la manomissione dei dati, quindi poter esibire hash corrispondenti e documentazione di catena di custodia completa tutela l’ente e la validità probatoria. Inoltre, se coinvolto un sindacato o autorità, sapere di aver seguito standard ISO/NIST (dunque di non aver violato la privacy di altri dati se non quelli pertinenti, ecc.) mette al riparo da contestazioni sulla metodologia. Un esempio reale avvenne qualche anno fa in un comune italiano, dove un amministratore di sistema fu scoperto a curiosare nei dati anagrafici senza motivo: grazie alla analisi forense dei log applicativi e del suo computer, si individuò l’illecito. Il responsabile deve essere sensibile anche a questi scenari “interni”, predisponendo magari procedure semplificate di acquisizione (non sempre servirà un intervento della Polizia, a volte è un audit interno) ma ugualmente rigorose.
4. Coordinamento multi-ente in incidenti su infrastrutture critiche: In ambito nazionale, il responsabile per la prevenzione incidenti potrebbe trovarsi a gestire situazioni che coinvolgono più enti contemporaneamente – ad esempio una campagna di attacchi ransomware a vari ospedali o comuni. In queste situazioni, l’acquisizione forense deve scalare su più fronti: occorre inviare squadre locali (o guidare da remoto i tecnici sul posto) per raccogliere evidenze in ciascun luogo. Un caso ipotetico: una variante di ransomware colpisce simultaneamente 5 ospedali italiani. Il CSIRT nazionale emette allerta e invia digital forensics kits alle squadre IT locali con istruzioni su cosa fare: eseguire subito dump di RAM delle macchine critiche (server di cartelle cliniche) e poi spegnerle per imaging, raccogliere log di sicurezza e una copia dei malware trovati su disco. Ogni squadra segue lo stesso protocollo (magari fornito sotto forma di checklist derivata da ISO 27037). I dati raccolti vengono poi centralizzati al CSIRT per l’analisi aggregata – questo ha senso perché confrontando i dump di memoria o gli artefatti del malware, si può capire se gli attacchi sono correlati (stessa variante) e quindi fornire early warning agli altri. Un responsabile deve quindi saper orchestrare acquisizioni forensi in parallelo, mantenendo la qualità. Ciò comporta anche aspetti logistici, come assicurarsi che ogni ente abbia almeno un personale formato DEFR o che possa dare accesso rapido alle stanze server per le copie. La cooperazione con forze di polizia qui è doppiamente importante: incidenti su infrastrutture critiche vengono seguiti anche dall’autorità giudiziaria, quindi polizia scientifica e Postale lavoreranno con il CSIRT. Uniformare gli standard (ad es. concordare l’uso di determinate tipologie di supporti di custodia sigillati, condividere gli hash via canali sicuri) è qualcosa che va preparato prima dell’incidente, tramite accordi e protocolli tra ACN e forze dell’ordine. In Italia, il modello di intervento cooperativo è in evoluzione, ma eventi come quelli di Luglio 2023 (attacco ransomware a vari comuni toscani) hanno visto CERT-AgID e CNAIPIC lavorare fianco a fianco. Il risultato è duplice: mitigare l’incidente e raccogliere prove per perseguire i criminali. Il responsabile deve assicurarsi che nessuno dei due obiettivi comprometta l’altro (ad es. non ripristinare macchine senza prima averle acquisite, a costo di tenere giù un servizio un’ora in più – decisione spesso difficile ma necessaria in ottica strategica).
Questi esempi mostrano che, nel contesto italiano, l’acquisizione forense è ormai parte integrante della gestione degli incidenti informatici, sia che essi siano causati da hacker esterni sia da minacce interne. Adottare standard internazionali offre un linguaggio comune e una qualità garantita delle operazioni, mentre declinare tali standard nelle procedure specifiche nazionali (considerando normative locali e struttura organizzativa italiana) è il compito del responsabile. In ogni caso, le evidenze digitali raccolte – dai log di Windows alle memorie RAM – si sono rivelate l’elemento chiave per chiarire gli incidenti e trarne lezioni: ad esempio, l’analisi forense post-mortem dei sistemi di un comune colpito da ransomware può evidenziare come l’attaccante è entrato (RDP esposto, credenziali deboli), fornendo indicazioni per mettere in sicurezza tutti gli altri enti con configurazioni simili. Così, il ciclo prevenzione-incidenti-miglioramento si chiude, con la forensica digitale a fare da ponte tra reazione all’emergenza e strategia di sicurezza proattiva.
Conclusioni
L’acquisizione forense di sistemi informatici – con tutte le sue sfaccettature di triage, imaging e raccolta artefatti – rappresenta una pietra angolare della moderna risposta agli incidenti. Nel ruolo di responsabile per la prevenzione e gestione di incidenti informatici, queste competenze non sono solo tecniche, ma strategiche: bisogna saper orientare il team verso le azioni giuste nei momenti critici, garantendo che nessuna prova vada perduta e che l’integrità delle evidenze rimanga intatta. Come evidenziato dai principali standard (ISO/IEC 27037, NIST 800-86) e linee guida (RFC 3227), seguire metodologie strutturate assicura che l’indagine digitale sia condotta con rigore scientifico e validità legale.
Un buon responsabile CSIRT deve quindi agire su più fronti: prevenire – formando il personale e predisponendo procedure e toolkit per essere pronti all’acquisizione; gestire – durante l’incidente decidere rapidamente cosa acquisire live e cosa post-mortem, bilanciando la necessità di contenere la minaccia con quella di conservare le prove; analizzare – assicurarsi che i dati raccolti vengano esaminati a fondo (se non dal proprio team, passando il testimone a team forensi dedicati), traendo conclusioni solide; e comunicare – redigendo report post-incidente chiari che documentino l’accaduto e reggano a eventuali scrutini giudiziari.
In ambito nazionale, queste responsabilità si amplificano: il responsabile diventa l’anello di congiunzione tra diverse entità (enti colpiti, agenzie di sicurezza, forze dell’ordine, talvolta partner internazionali per attacchi globali), dovendo garantire un approccio unificato e conforme agli standard. Solo un processo di acquisizione forense ben gestito può fornire le risposte alle domande chiave dopo un incidente: come è successo? cosa è stato colpito? c’è ancora presenza dell’attaccante? quali dati sono stati compromessi? – e queste risposte informano tanto le azioni di recovery immediato quanto le strategie di miglioramento a lungo termine.
Concludendo, l’acquisizione forense non è una mera operazione tecnica ma un’attività dal forte impatto organizzativo e legale. Operare secondo le best practice internazionali, mantenere un alto livello di professionalità e documentazione, e sapersi adattare ai contesti concreti (tecnologici e normativi) italiani, sono caratteristiche imprescindibili per il responsabile CSIRT/SOC. Così facendo, ogni incidente informatico, per quanto grave, diventa anche un’opportunità di apprendimento e di rafforzamento della postura di sicurezza nazionale, trasformando l’esperienza sul campo in nuove misure preventive e in una resilienza cyber sempre maggiore. La sfida è elevata, ma come recita un principio forense: “le prove digitali non mentono” – sta a noi saperle preservare e interpretare correttamente, a tutela della sicurezza collettiva e della giustizia.
