Ottobre 2025 – IlMioBlog

Memoria volatile in Windows. Analisi del dump di memoria

Procedure di acquisizione e precauzioni operative

L’acquisizione live della memoria RAM su sistemi Windows richiede una strategia che minimizzi l’alterazione dello stato del sistema, dato che il tool di acquisizione stesso deve essere eseguito sul sistema target e inevitabilmente ne modifica in parte i dati. È fondamentale non spegnere né riavviare la macchina (per evitare la perdita completa dei dati volatili) e procedere piuttosto a isolare il sistema dalla rete (es. scollegando il cavo o disabilitando il Wi-Fi) per prevenire interazioni esterne durante la raccolta. Prima di iniziare, è buona prassi preparare un supporto esterno (come una chiavetta USB) contenente l’eseguibile di acquisizione, in modo da eseguire il tool da un supporto rimovibile e salvare il dump di memoria su un’unità esterna o share di rete. Ciò riduce le scritture sul disco locale del sistema in esame e limita la possibilità che malware o altri processi notino l’operazione, oltre a diminuire il rischio di sovrascrivere dati volatili critici. Ad esempio, è comune avviare WinPmem da USB e salvare l’immagine di memoria direttamente su un server remoto. Durante l’acquisizione, i tool tentano spesso di mettere in pausa altri processi o utilizzano driver kernel per accedere direttamente alla RAM, mitigando problemi di consistenza (il cosiddetto memory smear, cioè piccole discrepanze dovute al continuo cambiamento dei dati in RAM). In ogni caso, è consigliato avviare la cattura il prima possibile, prima che ulteriori attività del sistema sovrascrivano informazioni potenzialmente importanti. Nel processo di acquisizione bisogna anche documentare orario e modalità di cattura (utile per correlare in seguito gli eventi di memoria con log di sistema) e, completata l’operazione, calcolare hash crittografici (MD5/SHA) del file di dump ottenuto. Ciò garantisce l’integrità dell’evidenza e permette di attestare che l’immagine di memoria analizzata corrisponda esattamente a quella acquisita sul sistema live. L’originale va conservato in modo sicuro e l’analisi va eseguita su copie, mantenendo una chiara chain of custody qualora l’evidenza dovesse essere presentata in sede legale.

Strumenti principali per l’acquisizione di memoria volatile

In ambiente Windows esistono diversi strumenti specializzati per acquisire il contenuto della memoria fisica in modo forense. Tutti questi caricano un driver kernel per accedere alla RAM a basso livello e producono un file (tipicamente in formato raw o mem) contenente l’intera memoria volatile. Di seguito alcuni dei tool comunemente impiegati.

WinPmem – strumento open source (parte del progetto Rekall) che permette il dump completo della RAM; utilizza un driver kernel dedicato e salva l’immagine in formato raw. È un tool a riga di comando ed è apprezzato per la sua affidabilità.
FTK Imager (Memory Capture) – il noto tool di imaging forense FTK Imager include una funzione “Capture Memory” per acquisire la RAM live; tramite un’interfaccia grafica consente di specificare destinazione del file di output e offre l’opzione di includere automaticamente il pagefile di Windows.
DumpIt – utility stand-alone a riga di comando (originariamente di MoonSols, ora disponibile tramite Magnet Forensics) che esegue un dump completo con un semplice doppio click. Genera per default un file .dmp (formato crash dump di Windows) contenente la memoria fisica, opzionalmente anche in formato raw; è popolare per la sua facilità d’uso one-click, sebbene introduca un footprint in memoria molto ridotto (carica pochissimi DLL).
Mandiant Redline – strumento freeware di FireEye con interfaccia GUI che include funzionalità sia di acquisizione live (tramite un driver kernel) sia di analisi basica. Redline può essere eseguito da USB e consente di collezionare la RAM in un file di dump; internamente utilizza la componente Memoryze per l’accesso raw alla memoria.
Belkasoft Live RAM Capturer – tool gratuito orientato all’acquisizione rapida anche in presenza di tecniche anti-debug/anti-dump. Ha un’interfaccia semplice (“Capture” button) e produce un file raw; supporta sia x86 che x64 e cerca di bypassare eventuali protezioni del malware durante la lettura della RAM.
F-Response – soluzione commerciale che permette di acquisire memoria da macchine live da remoto. Consiste in un driver e connettore di rete che espone la RAM del sistema target come una periferica accessibile dall’analista, consentendo il dump anche via LAN/WAN. È usato in contesti enterprise per incident response distribuito.

Nota: Indipendentemente dallo strumento scelto per l’acquisizione, il file grezzo ottenuto (immagine di memoria) è generalmente analizzabile con i principali framework di memory forensics (Volatility, Rekall, etc.), a prescindere dal tool che lo ha generato.

L’importante è assicurarsi che il tool supporti il sistema operativo target (versione e architettura) e sia testato in anticipo, per evitare incompatibilità al momento critico.

Principali artefatti estratti da un dump di memoria

Una volta ottenuta un’immagine di memoria, l’analisi forense si concentra sull’estrazione degli artefatti volatili, ossia tutte le informazioni significative sullo stato del sistema al momento della cattura. La memoria RAM conserva tracce di quasi ogni attività del sistema; infatti, qualsiasi operazione software passa in RAM e molti dati possono persistere anche dopo la cessazione di un processo. Tra i principali artefatti estraibili da un dump di memoria (e le relative strutture di dati che li contengono) vi sono i seguenti.

Processi e thread in esecuzione: l’elenco dei processi attivi al momento della cattura può essere ricostruito attraversando la doubly-linked list dei processi in kernel mode. In Windows il kernel mantiene una lista concatenata di strutture _EPROCESS (puntata da PsActiveProcessHead), ciascuna rappresentante un processo attivo. Ogni record EPROCESS contiene vari metadata (PID, nome eseguibile, stato, ecc.) e un puntatore al PEB (Process Environment Block) in user mode, dove sono presenti ulteriori info come i parametri di avvio, le variabili d’ambiente e i moduli caricati del processo. Dal PEB si può risalire anche al tree VAD (Virtual Address Descriptors) che descrive le regioni di memoria allocate dal processo. L’analisi dell’elenco dei processi (ad es. tramite plugin Volatility pslist/pstree) consente di identificare processi sospetti – ad esempio nomi anomali o processi senza parent legittimo. Un esempio tipico: individuare un svchost.exe il cui parent process non è services.exe può indicare un processo spoofed o iniettato. Si controllano anche indicatori come processi con numero di thread/handle pari a zero o timestamp inconsueti, che suggeriscono processi terminati o nascosti (in questi casi si può incrociare con una scansione di strutture non collegate tramite plugin psscan per trovare eventuali EPROCESS orfani). In sintesi, la lista dei processi attivi fornisce una “fotografia” dello stato di esecuzione del sistema, analoga a ciò che mostrerebbe un Task Manager al momento del dump.
Moduli e DLL caricati nei processi: per ogni processo, la memoria contiene l’elenco delle DLL e librerie caricate nello spazio di indirizzamento di quel processo. Questa informazione è ottenuta leggendo le strutture di loader del PEB (lista dei moduli in memoria) o tramite scanning delle pagine di memoria alla ricerca di intestazioni PE in uso. Un’analisi dei moduli caricati (dlllist in Volatility) permette di rilevare DLL sospette, ad esempio librerie con percorsi insoliti o iniettate in modo riflessivo (presenti in RAM ma non sul disco). Un modulo in memoria senza un corrispettivo file su disco è un forte indicatore di code injection. Analogamente, driver e moduli del kernel caricati possono essere elencati tramite la struttura globale PsLoadedModuleList(o plugin Volatility modules/modscan): eventuali driver non firmati o posizionati fuori dalle directory di sistema standard potrebbero indicare rootkit in kernel space.
Connessioni di rete e socket: le informazioni sulle connessioni di rete attive (socket aperti TCP/ UDP) sono dati volatili tipicamente persi allo shutdown, ma restano presenti nel dump di RAM. Tramite strutture del driver di rete (ad es. oggetti _TCPT_OBJECT per connessioni TCP in Windows Vista+), è possibile elencare connessioni con relativi endpoint locali/remoti e processo associato. I tool forensi (es. plugin netscan di Volatility) effettuano una scansione della memoria kernel alla ricerca di queste strutture per recuperare connessioni di rete live e anche recentemente chiuse. Ciò consente di scoprire eventuali comunicazioni con server esterni (es. indirizzi IP di C2 malware, porte sospette aperte da processi che normalmente non dovrebbero avere traffico di rete). Ad esempio, se un malware era connesso a un IP esterno al momento del dump, l’analisi della memoria ne rivelerà l’IP e la porta, informazione preziosa per comprendere canali di command-and-control o esfiltrazione dati. Anche socket in ascolto (porte aperte in listening) possono essere identificate attraverso le strutture di socket in memoria (es. plugin sockets). Le connessioni individuate in RAM offrono evidenze che spesso non lasciano altre tracce persistenti (una volta chiusa la connessione, solo la memoria ne serba traccia).
File e handle aperti: la tabella degli handle di ogni processo (puntata dalla struttura EPROCESS) elenca riferimenti a risorse aperte, tra cui file, registry key, pipe, ecc., in uso da quel processo. Analizzando gli handle aperti (plugin Volatility handles o files) si possono scoprire file temporanei o nascosti utilizzati da malware. Ad esempio, se un processo malware ha aperto un file in una directory insolita o con un nome random, o ha una handle verso un file già cancellato sul disco, tali informazioni emergono dalla memoria (poiché l’handle resta in vita finché il file è aperto, anche se è stato cancellato dal filesystem). Questo tipo di analisi aiuta a identificare quali file un malware stava leggendo/scrivendo in quel momento, fornendo indizi su componenti aggiuntivi o dati esfiltrati.
Informazioni di registro e configurazione: parte del Registro di Windows risiede in memoria quando il sistema è acceso, in particolare le hive principali e le chiavi recentemente accedute. Tramite un dump di memoria è possibile estrarre intere hive di registro o singole chiavi/pair valore che erano caricate in RAM. Ad esempio, la Volatility con plugin come hivelist individua le basi di registro in memoria, e printkey può leggerne il contenuto. Ciò consente di rilevare modifiche al registro effettuate da malware solo in memoria (che non siano state ancora scaricate su disco) oppure configurazioni di persistenza: chiavi di Run/RunOnce, chiavi di servizi, ecc., che malware ha modificato per auto-avviarsi. Anche informazioni di configurazione volatile, come le chiavi di registro che mantengono le connessioni di rete recenti le ultime chiavi aperte, possono essere recuperate. In sintesi, il dump di RAM può rivelare l’ultimo stato noto di alcune parti del registro di sistema, anche meglio di un’analisi post-mortem sul disco.
Dati sensibili in memoria (credenziali, input utente): la memoria può contenere frammenti di dati in chiaro che non sono salvati altrove. Un esempio notevole sono le credenziali utente e hash conservati nei processi di sistema come lsass.exe: un dump di LSASS dal file di memoria permette spesso di estrarre hash NTLM o persino password in chiaro delle sessioni di login attive. Strumenti come Mimikatz sfruttano proprio questo. In ambito forense, analizzando la memoria si possono individuare anche testi in chiaro digitati o copiati: ad esempio, la clipboard utente (appunti) può contenere l’ultimo testo copiato, e ciò risiede in RAM; oppure buffer di console che rivelano comandi PowerShell o CLI eseguiti (spesso in Unicode/ASCII facilmente cercabile). Gli analisti utilizzano spesso il string carving sulla memoria per trovare indicatori (es. URL, indirizzi IP, chiavi di registro, nomi di file sospetti, porzioni di codice malicioso, ecc.). Inoltre, malware complessi che usano crittografia possono lasciare in memoria le chiavi di cifratura durante l’esecuzione: se catturate in tempo, queste chiavi (ad es. di ransomware) possono essere recuperate e utilizzate per decifrare i dati colpiti. Qualsiasi informazione volatile, dalle conversazioni in chat non salvate su disco fino alla cronologia dei comandi di shell, rientra tra gli artefatti analizzabili nella RAM.
Strutture del kernel e segni di rootkit: un’analisi approfondita del dump include l’esame di strutture del kernel per individuare manipolazioni malevole. Ad esempio, un rootkit in kernel mode potrebbe nascondere un processo rimuovendolo dalla lista dei processi (modificando i link ActiveProcessLinks in EPROCESS). Un analista, tuttavia, può eseguire scansioni grezze della memoria alla ricerca di pattern di EPROCESS non collegati (Volatility psscan) e scoprire così processi “nascosti” nonostante non appaiano nella lista attiva. Analogamente, si controllano le SSDT e IDT (tabelle di system call e interrupt) per rilevare eventuali hook, oppure si esaminano i puntatori a funzioni di driver per vedere se puntano a regioni non standard (segno di hooking in memoria). La presenza di moduli anomali nel kernel, di sezioni di memoria marcate come eseguibili ma non appartenenti a moduli noti (malfind plugin per individuare codice iniettato in processi), o di driver nascosti, sono tutti artefatti rilevabili solo tramite memory forensics. Queste strutture di basso livello forniscono indizi su tecniche di occultamento utilizzate da malware avanzati (DKOM – Direct Kernel Object Manipulation, hooking di funzioni, patch in-line in memoria, ecc.) e completano il quadro evidenziale individuando anche minacce che non lasciano tracce nei file system.

In sintesi, dall’analisi di un dump di memoria si possono estrarre moltissime evidenze: processi attivi e terminati, moduli e codice iniettato, connessioni di rete, attività utente recente, credenziali, chiavi crittografiche, stato di configurazioni volatili, ecc. Queste informazioni, incrociate tra loro (ad es. correlando un processo malware con le sue connessioni di rete e i file che ha aperto), permettono di ricostruire le azioni svolte da un attaccante o da un malware in un intervallo temporale vicino all’incidente, offrendo una visibilità unica che integra l’analisi dei dischi e di altri log persistenti. La memory forensics fornisce dunque uno snapshot puntuale dello stato di un sistema compromesso, fondamentale per comprendere attività altrimenti inaccessibili dopo lo shutdown.

Ruolo complementare di pagefile.sys e hiberfil.sys nell’arricchimento delle evidenze

Nel contesto Windows, oltre alla RAM fisica, esistono file di sistema su disco che catturano porzioni della memoria volatile e possono fornire evidenze aggiuntive durante un’indagine forense. In particolare pagefile.sys (file di paging) e hiberfil.sys (file di ibernazione) svolgono un ruolo complementare nell’arricchire i dati acquisiti dalla RAM.

Pagefile.sys: è il file di paging usato da Windows come estensione della RAM sul disco. Quando la memoria fisica si riempie, parti dei dati meno usati in RAM vengono “swappati” nel pagefile, per poi essere ricaricati in memoria al bisogno. Dal punto di vista forense, il pagefile.sys spesso contiene frammenti di dati che erano presenti in RAM in precedenza e che potrebbero non trovarsi nell’istantanea della memoria acquisita (perché paginati su disco al momento del dump) . Ad esempio, nel pagefile possono emergere porzioni di documenti, contenuti di pagine web, stringhe di testo, codici malevoli caricati in memoria e poi rimossi, cronologie di navigazione, immagini o altri artefatti di attività utente che non risiedono più nella RAM attiva. In un caso pratico, l’analisi del pagefile ha permesso di estrarre centinaia di URL di siti visitati dall’utente e immagini relative alla navigazione web, informazioni non presenti altrove poiché la cronologia del browser era stata cancellata ma rimasta in pagine di memoria virtuale. Tuttavia, va notato che il pagefile non mantiene la struttura allocativa della RAM bensì solo pagine isolate: di conseguenza, non è direttamente “montabile” con tool come Volatility per estrarre processi o socket. L’analisi forense del pagefile si basa su techiche di carving e ricerca stringhe nei suoi contenuti non strutturati. Ad esempio, si possono estrarre stringhe Unicode/ASCII dal pagefile alla ricerca di indicatori (URL, nomi di file, chiavi di registro, ecc.) oppure utilizzare strumenti di carving per ricostruire file o immagini frammentate al suo interno. In sintesi, il pagefile.sys funge da miniera di dati residuali: qualsiasi informazione che sia passata per la RAM potrebbe aver lasciato traccia in questo file di swap, rendendolo una fonte preziosa di evidenze supplementari (sebbene la sua interpretazione richieda più lavoro manuale e possa produrre anche falsi positivi, dato che include frammenti di pagine appartenenti anche a software di sicurezza, sistema operativo, ecc.).
Hiberfil.sys: è il file in cui Windows salva il contenuto completo della RAM quando il sistema entra in modalità ibernazione (sospensione su disco). In pratica, hiberfil.sys rappresenta un’istantanea byte-per-byte della memoria al momento in cui il sistema è stato ibernato. Questo significa che, dal punto di vista forense, esso equivale a un dump di memoria effettuato dal sistema stesso durante il processo di ibernazione. Se un computer sospetto viene trovato spento in modalità ibernata (o se si dispone del file hiberfil.sys da un’immagine disco), analizzarlo consente di recuperare uno stato della memoria di interesse. L’hiberfil.sys conserva lo stato completo del sistema al momento dell’ibernazione, inclusi tutti i processi attivi, le loro memorie, le connessioni di rete aperte, le impostazioni correnti e così via. È dunque una miniera d’oro forense che permette di sbirciare “l’ultimo respiro” del sistema prima dello stop. In termini pratici, esistono strumenti per convertire hiberfil.sys in un’immagine di RAM standard: ad esempio Volatility (v2 o v3) offre plugin imagecopy/hiberfile per trasformare il file di ibernazione in un file raw analizzabile e tool dedicati come Hibernation Recon supportano i vari formati di hiberfil (che differiscono tra Windows 7 e Windows 8+ a causa di compressione). Una volta convertito, l’analista può trattarlo come un normale dump di memoria e applicare gli stessi plugin per estrarre processi, rete, ecc., col vantaggio che spesso l’ibernazione cattura anche informazioni che un’acquisizione live potrebbe perdere (ad es. perché il sistema era troppo attivo per ottenere un snapshot coerente). Va considerato che su Windows 10/11 il file hiberfil.sys è usato anche per la funzione di Fast Startup (avvio ibrido): in tale caso il file può contenere solo una parte della memoria (kernel/sessione0), ma comunque arricchisce le evidenze con dati volatili aggiuntivi (es. record MFT e hive di registro SYSTEM recenti nel caso del Fast Startup). In conclusione, l’hiberfil.sys fornisce uno storico dello stato della RAM che può integrare un’analisi: ad esempio, se un incidente è avvenuto prima dell’ultimo ibernamento, il file conterrà ancora tracce di quel evento anche se la RAM live successiva è cambiata. È un complemento prezioso soprattutto quando non è stato possibile ottenere un dump live al momento dell’incidente – l’analisi dell’hiberfil può svelare informazioni altrimenti andate perdute.

In sintesi, pagefile.sys e hiberfil.sys arricchiscono l’indagine forense mettendo a disposizione dati della memoria volatile che altrimenti potrebbero sfuggire. Il pagefile estende l’orizzonte temporale delle evidenze volatili conservando tracce di attività passate (come uno storage ausiliario della RAM per dati paginati), mentre l’hiberfil offre un vero snapshot congelato della RAM in un momento specifico (ibernazione). Integrando l’analisi dell’immagine di memoria live con questi file, l’analista può ottenere una visione più completa e retrospettiva degli eventi, aumentando le chance di trovare indicatori utili (es. parti di malware in memoria virtuale, chiavi o password in pagine di swap, stato di sistema precedente all’incident response, ecc.). Di fatto, nelle fasi iniziali di acquisizione della memoria andrebbero sempre considerati anche questi file: ad esempio, copiando il pagefile.sys e l’hiberfil.sys dal disco del sistema target (quando presenti) per poi analizzarli assieme al dump della RAM . Questa visione integrata permette di colmare eventuali lacune e di corroborare le evidenze trovate, migliorando la robustezza delle conclusioni forensi.

Data theft: piano di intervento informatico forense

Scenario e obiettivi dell’indagine

Il CSIRT Italia ha segnalato la presenza online di file riservati appartenenti ai clienti di uno studio legale, presumibilmente sottratti dal file server interno dello studio. In qualità di consulente forense incaricato, l’obiettivo primario è preservare e acquisire in modo forense tutte le evidenze digitali rilevanti (server, workstation e dispositivi di rete) garantendone integrità e autenticità, in vista di una possibile indagine giudiziaria. Si seguiranno rigorosamente le best practice internazionali (es. standard ISO/IEC 27037) per identificare, raccogliere, acquisire e conservare le prove digitali. È fondamentale minimizzare qualsiasi alterazione dei dati durante la raccolta e documentare ogni attività svolta, mantenendo una catena di custodia rigorosa delle evidenze.

Assunzioni Operative: si assume che l’incidente sia recente e che i sistemi coinvolti siano ancora disponibili in sede. Il file server Linux è identificato come potenziale fonte dei dati esfiltrati; tuttavia, non si esclude il coinvolgimento di una o più delle 5 workstation Windows (ad esempio come punto d’ingresso iniziale dell’attacco). Il firewall perimetrale potrebbe contenere log utili sulle connessioni di esfiltrazione. Si dispone dell’accesso fisico a tutti i dispositivi e del consenso dello studio per procedere all’acquisizione forense. Si prevede inoltre di avere a disposizione strumenti forensi (hardware e software) adeguati, inclusi supporti di memorizzazione esterni capienti per salvare le immagini acquisite. Ogni attività verrà coordinata in modo da ridurre al minimo l’impatto sull’operatività dello studio, pur privilegiando la preservazione delle prove rispetto alla continuità di servizio.

Identificazione e preservazione delle evidenze

Come primo passo, identifichiamo tutte le potenziali fonti di evidenza digitale nell’infrastruttura compromessa. In questo caso includono:

File server Linux (contenente i dati dei clienti) – sorgente probabile dell’esfiltrazione.
Workstation Windows 10 (5 unità) – potrebbero aver subito compromissioni (ad es. tramite malware o furto credenziali) usate per accedere al server.
Firewall perimetrale – dispositivo di rete con possibili log di traffico in uscita e regole di accesso.
Copie dei file esfiltrati rinvenuti online – per confronti con i dati originali e conferma dell’effettiva violazione.

Una volta identificate, si procede alla preservazione immediata dello stato dei sistemi per evitare alterazioni o perdite di informazioni volatili. In particolare:

Isolamento dei dispositivi dalla rete: scolleghiamo il file server e le workstation dalla rete (cavo Ethernet o Wi-Fi) per impedire ulteriori comunicazioni con l’esterno o possibili azioni di copertura da parte di un eventuale attaccante ancora connesso. Anche il firewall, se compromesso, viene isolato (ad es. rimuovendo temporaneamente la connessione WAN) mantenendolo però acceso se necessario per preservare i log in memoria.
Valutazione dello stato (acceso/spento) dei sistemi: se i computer sono accesi, si considera di eseguire un’acquisizione live di dati volatili. In base all’ordine di volatilità (RFC 3227), le informazioni più volatili come il contenuto della RAM e le connessioni di rete attive vanno acquisite prima di spegnere i sistemi. La memoria RAM può contenere informazioni cruciali (password in chiaro, processi malware in esecuzione, connessioni di rete attive, ecc.) che andrebbero perse allo spegnimento. Dunque, per server e workstation accesi si pianifica di catturare un dump della memoria prima di procedere oltre.
Documentazione della scena: prima di manipolare i dispositivi, si documenta accuratamente la scena: fotografia dei cablaggi, posizione dei dispositivi, stato dei sistemi (acceso/spento, schermate visibili), etichette o seriali. Questo aiuta a ricostruire il contesto e dimostrare che ogni passaggio è stato eseguito correttamente. Ogni attività viene annotata con data, ora, luogo e persone coinvolte, pronto per essere inserita nel registro di catena di custodia.
Stabilizzazione del sistema compromesso: in caso il file server Linux sia in esecuzione e si tema la presenza di malware attivo (es. una backdoor), si valuterà se conviene spegnere immediatamente dopo la raccolta della RAM. Spesso, in incidenti gravi, l’arresto immediato (es. scollegando l’alimentazione) è consigliato dopo la raccolta dei dati volatili, per evitare che malware distruttivi cancellino tracce all’arresto ordinato. Tuttavia, questa decisione va ponderata in base alla situazione (ad esempio, la presenza di servizi critici potrebbe richiedere un arresto controllato). Nel dubbio, è preferibile privilegiare l’integrità delle prove rispetto alla continuità operativa.

Acquisizione forense dei sistemi coinvolti

Dopo aver messo in sicurezza l’ambiente, si procede con l’acquisizione forense bit-a-bit dei supporti di memoria e la raccolta dei log, utilizzando strumenti e procedure tali da garantire copie esatte e immodificabili degli originali. Tutte le acquisizioni avverranno utilizzando strumentazione forense dedicata (write blocker, software di imaging) e seguendo protocolli standard. Di seguito, il dettaglio per ciascun componente:

File server Linux (acquisizione disco e memoria)

Il file server è il principale indiziato da cui sarebbero stati esfiltrati i dati. Le attività previste sono:

Dump della memoria RAM: ce il server è ancora acceso, si esegue una copia della memoria volatile. Su sistemi Linux, si può utilizzare ad esempio Linux Memory Extractor (LiME) (modulo kernel) o strumenti come Magnet DumpIt for Linux (tool standalone) per ottenere un file dump della RAM completo. L’operazione viene svolta rapidamente, salvando l’output su un supporto esterno montato in sola lettura. Questa acquisizione live è fondamentale perché la RAM potrebbe contenere indicazioni di processi sospetti, chiavi di cifratura, o connessioni attive dell’attaccante. Si annotano orario e configurazione del sistema al momento del dump (es. elenco processi e connessioni aperte, utilizzando comandi come ps, netstat o tool forensi,se possibile, evitando però alterazioni significative).
Acquisizione forense del disco: successivamente, si procede allo shutdown del server per eseguire l’acquisizione del disco in modo sicuro. Idealmente, il disco fisso del server viene rimosso dalla macchina per evitare qualsiasi modifica dovuta all’avvio del sistema operativo. Il disco viene collegato a una workstation forense tramite un write-blocker hardware (es. un Tableau) che impedisce qualsiasi scrittura accidentale sul supporto originale. In alternativa, se non fosse possibile estrarre il disco (ad es. array RAID complesso in produzione), si potrebbe avviare il server da un bootable USB forense (es. distribuzione CAINE basata su Linux Ubuntu o Kali Linux in modalità forense) che non altera i dischi interni (automount disabilitato, accesso in sola lettura). Avviato l’ambiente forense, si può usare il tool dd o dcfldd per creare un’immagine bitstream di ogni unità logica. Ad esempio: dcfldd if=/dev/sda of=/media/esterna/server-image.img hash=sha256 log=server-img.log (dove si calcola anche l’hash durante la copia). È preferibile usare dcfldd o strumenti analoghi in quanto progettati per scopi forensi (permettono di calcolare direttamente hash MD5/SHA e suddividere l’immagine in segmenti, se necessario). In alternativa, si può impiegare Guymager (tool con interfaccia grafica su Linux) che consente di creare immagini in formato raw E01 con calcolo automatico degli hash. Durante l’acquisizione, non si deve mai salvare l’immagine sullo stesso disco oggetto dell’acquisizione ma su un dispositivo di destinazione separato (ad esempio un drive USB esterno capiente formattato exFAT/NTFS). Si raccomanda il formato E01 (EnCase Evidence File) per il disco del server, poiché comprime i dati e consente di includere metadati (es. informazioni del caso, timestamp di acquisizione, etc.) utili per la catena di custodia. Al termine, viene calcolato e registrato l’hash (tipicamente MD5 e SHA-1) dell’immagine e confrontato con quello calcolato sul disco originale, per verificare la conformità bit-a-bit. Un match degli hash conferma che la copia è identica all’originale e non alterata, garantendo l’autenticità dell’evidenza. Tutte le operazioni vengono registrate nel log di acquisizione (nome del dispositivo, orari di inizio/fine, dimensione dell’immagine, algoritmi di hash utilizzati, ecc.). Il supporto originale (disco server) viene poi sigillato e conservato come evidenza originale.
Raccolta di log e configurazioni: oltre all’immagine completa del file system (che include comunque i log di sistema), si può procedere a estrarre copie logiche di file di log chiave per un’analisi immediata. Ad esempio, i file in /var/log/ (log di autenticazione SSH, log di Samba NFS se il server fungeva da file server di rete, log di sistema) sono cruciali per ricostruire gli accessi e le operazioni avvenute. Tali log, se disponibili, vengono copiati separatamente (sempre tramite strumenti che garantiscano l’integrità, ad es. usando cp in ambiente forense o esportandoli con nc su un’altra macchina) e i loro hash calcolati, così da poterli utilizzare per un’analisi più rapida senza dover montare subito l’intera immagine del disco. Naturalmente l’integrità di questi file è garantita anche dal fatto che provengono da un’immagine forense verificata.

Workstation Windows 10 (acquisizione disco e, se opportuno, memoria)

Le cinque workstation Windows potrebbero aver giocato un ruolo nell’incidente (es. come punto di ingresso iniziale tramite phishing o malware, o come postazioni da cui è partito l’accesso non autorizzato al server). Il piano prevede:

Dump della RAM (se accese): per ogni workstation ancora accesa al momento dell’intervento, si effettua prima la cattura della memoria volatile. Su Windows, uno strumento pratico è Magnet Forensics RAM Capture (DumpIt), eseguibile da chiavetta USB: con un doppio click esegue il dump completo della RAM su un file .raw o .mem. Questo richiede pochi minuti per decine di GB di RAM e fornisce istantanee dei processi in esecuzione, connessioni di rete attive, moduli caricati, ecc. Spesso i ransomware o altri malware lasciano tracce in memoria (processi o librerie iniettate) che possono essere scoperte con analisi successive (es. con Volatility). Anche credenziali o token temporanei possono risiedere in RAM, quindi questa è un’evidenza preziosa. Si salva il dump su un disco esterno, annotando ora e macchina, e si calcola l’hash anche per questi file di memoria.
Spegnimento e rimozione dischi: subito dopo il dump (o immediatamente, se la macchina era spenta), si spengono le workstation. Idealmente, nel caso di sospetto malware attivo, è accettabile uno spegnimento improvviso (staccando l’alimentazione o la batteria) per evitare che eventuali programmi malevoli intercettino la normale procedura di shutdown (p.es. alcuni malware possono cancellare tracce al momento dello spegnimento). Dato che abbiamo già acquisito la RAM, il rischio di perdere dati volatili importanti è mitigato. Una volta spento il sistema, si procede a rimuovere il disco interno (HDD/SSD) dalla workstation.
Imaging forense dei dischi: ogni disco viene etichettato univocamente (es. WS1, WS2, … WS5) e collegato tramite write-blocker a una postazione forense. Su sistemi Windows, useremo FTK Imager (software forense gratuito di AccessData/Exterro) sulla nostra workstation forense per creare immagini bitstream dei dischi. FTK Imager permette di scegliere il formato (raw dd, E01, AFF, etc.) e di calcolare automaticamente hash MD5/SHA1 durante l’acquisizione. Prima di procedere, ci assicuriamo che Windows non effettui mount automatico delle partizioni del disco inserito: infatti Windows tende a montare qualsiasi volume riconosciuto, rischiando di alterare last access time o altri metadata. L’uso del write-blocker hardware previene questo problema, garantendo che il sistema operativo forense veda il disco come sola lettura. In FTK Imager, useremo l’opzione Create Disk Image selezionando la sorgente fisica (Physical Drive) e specificando come destinazione un percorso su un drive esterno. Scegliamo il formato E01 (EnCase Evidence) per coerenza e compressione, inserendo nei metadati dell’immagine i dettagli del caso (nome caso, numero evidenza, esaminatore, etc.). Abilitiamo l’opzione di verifica hash al termine (FTK Imager calcolerà hash MD5/SHA1 e li comparerà automaticamente). Procediamo quindi all’imaging completo. Ad acquisizione terminata, verifichiamo i log di FTK Imager che riporteranno gli hash calcolati; un confronto positivo tra hash di origine e copia conferma la bontà dell’immagine. Ripetiamo questo processo per tutti i dischi delle 5 postazioni.
Acquisizione dati di interesse dalle workstation: le immagini dei dischi Windows conterranno informazioni quali i log di Windows (eventi di sicurezza nel registro eventi), file temporanei, cronologia di navigazione, eventuali malware presenti, ecc. Sebbene l’analisi dettagliata avverrà successivamente in laboratorio, in sede di acquisizione si può già valutare di estrarre rapidamente alcuni artefatti se immediatamente utili. Ad esempio, log di Windows Event Viewer (Security.evtx) per vedere login sospetti, o la lista di utenti e gruppi locali, possono essere esportati usando strumenti come FTK Imager stesso (che consente di sfogliare il file system e salvare file singoli) prima di smontare il disco. Tuttavia, tali operazioni non sono strettamente necessarie in campo se l’obiettivo principale è acquisire tutto per analisi approfondita successiva. L’essenziale è che le immagini siano integre e complete.

Firewall perimetrale (raccolta log e configurazione)

Il firewall costituisce il punto di ingresso/uscita della rete aziendale. Anche se potrebbe non essere opportuno spegnerlo (specie se fornisce connettività Internet allo studio) prima di aver analizzato la situazione, ai fini forensi occorre acquisire i dati che possono testimoniare le connessioni di esfiltrazione. Le azioni prevedono:

Esportazione dei log di traffico: la maggior parte dei firewall di classe enterprise o SMB consente di esportare i log di sistema (ad esempio file di log di sessione, eventi di intrusion detection se integrato, log VPN, ecc.) tramite interfaccia di amministrazione o SSH. Si accede al firewall (in sola lettura) e si scaricano i log relativi al periodo sospetto dell’incidente. In particolare, interessano log di connessioni uscenti (egress) dal file server o dalle workstation verso l’esterno. Questi log possono rivelare indirizzi IP di destinazione e volumi di dati trasferiti durante l’esfiltrazione. Ad esempio, se i dati sono stati caricati su un sito web o cloud, il firewall potrebbe mostrare un flusso FTP/HTTP/HTTPS anomalo in uscita da un IP interno (quello del server) verso un IP esterno sconosciuto, magari con un volume di svariati gigabyte. Tali evidenze sono cruciali per ricostruire il canale di esfiltrazione. I log vengono salvati (in formato testo o CSV) su supporto forense e ne vengono calcolati gli hash per garantirne l’integrità.
Configurazione e regole: si acquisisce anche la configurazione del firewall (spesso esportabile come file di backup) per vedere che porte/servizi erano aperti verso l’esterno. Ad esempio, se il file server aveva porte aperte (SSH, SMB) o se esistevano regole di port forwarding, ciò può essere rilevante. La config, una volta esportata, viene sottoposta a hash e conservata.
Eventuale immagine del dispositivo: se il firewall è un appliance software (ad es. basato su Linux/BSD come pfSense) con storage interno, e se l’hardware lo permette, si può anche considerare di fare un’immagine forense del suo drive (similmente a quanto fatto per server/PC). Tuttavia, molti firewall commerciali hanno filesystem proprietari o sono crittografati; spesso è sufficiente raccogliere log e config. Nel caso di un firewall standard PC-based, si potrebbe spegnere e clonare il disco con gli stessi metodi (write-blocker, etc.), ma solo dopo aver ottenuto i log volatili se non persistenti.

Evidenze dei file esfiltrati online

Parallelamente all’acquisizione interna, recuperiamo i file trapelati sul sito Internet segnalato dal CSIRT. Questi file costituiscono prova dell’avvenuta violazione e saranno utili per confronti. Le attività sono:

Download dei file dal sito esterno: utilizzando un computer sicuro, si scaricano i file trovati online, preservandone i metadati ove possibile. Ad esempio, se disponibili via web, si può usare wget o browser, evitando di modificarli (impostando l’orario di modifica come originario se indicato). Si registra l’URL e l’ora del download e, se possibile, si fa uno screenshot della pagina web dove erano disponibili, come documentazione.
Calcolo hash e conservazione: su ogni file esfiltrato scaricato, si calcolano hash (MD5/SHA1) per poterli confrontare successivamente con gli hash dei file originali sul server. In ambito forense, il confronto degli hash permetterà di dimostrare che il file online è esattamente uguale a quello presente sul server (qualora nelle immagini acquisite del server sia rinvenuto lo stesso hash), confermando così l’origine dell’esfiltrazione. Questi file scaricati diventano anch’essi evidenze digitali e vengono inseriti nella catena di custodia.
Metadati e attributi: si analizzano brevemente i metadati di tali file (es. proprietà del documento, autore, date di creazione/modifica) poiché potrebbero rivelare informazioni sull’origine (ad es. username del sistema dal quale provengono, versione software, etc.). Tali informazioni, se trovate, saranno poi corroborate con l’analisi interna (ad esempio, se i documenti recano come autore il nome di un dipendente dello studio, ciò può suggerire da quale PC/server provenivano).

Verifica dell’integrità e documentazione della Catena di Custodia

Durante e dopo ogni acquisizione, si verifica l’integrità delle evidenze digitali e si aggiornano i documenti che compongono la Catena di Custodia:

Calcolo e verifica degli hash crittografici: come standard, per ogni immagine forense creata (dischi di server, PC) e per ogni file rilevante copiato (dump di RAM, log, file esfiltrati, ecc.), si calcola almeno un algoritmo di hash (tipicamente MD5 e SHA-1, oppure SHA-256 per maggiore sicurezza). Il valore di hash viene confrontato con quello ricalcolato all’occorrenza sulle stesse evidenze per assicurare che non vi siano alterazioni. Ad esempio, FTK Imager e altri tool riportano automaticamente hash MD5/SHA1 post-acquisizione. Questi hash vengono annotati nel verbale di acquisizione accanto all’identificativo dell’evidenza. La corrispondenza degli hash tra originale e copia forense prova formalmente che la copia è identica al bit all’originale, requisito fondamentale per la validità probatoria.
Documentazione dettagliata: si redige un verbale tecnico di acquisizione in cui per ogni dispositivo analizzato si riportano: descrizione (marca, modello, S/N), identificativo assegnato come evidenza, persona che ha eseguito l’operazione, data/ora di inizio e fine imaging, strumento usato, hash dell’immagine ottenuta, eventuali osservazioni (es. errori di lettura, settori danneggiati se presenti). Inoltre, come previsto dalle linee guida, si documenta ogni operazione svolta su ciascun reperto in ordine cronologico. La Catena di Custodia descrive l’intero ciclo di vita dell’evidenza digitale, dalla raccolta iniziale fino all’eventuale presentazione in tribunale. Ad esempio: “Evidenza E01: Disco fisso server SN… prelevato in data … ore … da Tizio, acquisito in copia forense file XYZ.E01 hash MD5=…, SHA1=…, da Caio con strumento FTK Imager vX, consegnato in custodia a Sempronio alle ore …”. Ogni trasferimento di custodia (passaggi di mano dell’evidenza, spostamento dal luogo di raccolta al laboratorio, etc.) viene parimenti registrato con data, ora, persona che consegna e persona che riceve e firma (quando possibile). Questo garantisce tracciabilità completa: in ogni momento si può stabilire chi ha avuto accesso all’evidenza e quando.
Protezione fisica delle evidenze: dopo l’acquisizione, i supporti originali (dischi rimossi, ecc.) vengono riposti in contenitori sigillati con etichette anti-manomissione (ad es. evidenziatori di apertura). Si appone un sigillo sia sull’originale sia su una delle copie forensi conservate (la seconda copia sarà utilizzata per l’analisi). Eventuali violazioni dei sigilli sarebbero evidenti e renderebbero dubbia l’integrità del reperto. Oltre ai sigilli fisici, si proteggono i dati da fattori esterni: ad esempio, i supporti vengono conservati in ambiente a temperatura e umidità controllata, lontano da campi elettromagnetici che potrebbero danneggiarli. Nel nostro caso, i dischi originali delle workstation e del server, dopo l’imaging, verranno ad esempio inseriti in sacchetti antistatici, sigillati, etichettati e messi in una cassaforte o armadio blindato. Lo stesso per eventuali USB contenenti i dump di RAM o i file scaricati: se tali dati sono salvati su supporti rimovibili (es. SSD esterno), anche questi supporti vengono sigillati e custoditi.
Conservazione delle copie forensi: le immagini forensi acquisite (file .E01, .dd, dump RAM, ecc.) verranno duplicate se possibile: una copia master immutabile, conservata come evidenza intoccabile, e una o più copie di lavoro su cui effettuare l’analisi tecnica. La copia master (ad es. su hard disk dedicato) viene anch’essa sigillata e custodita, mentre la copia di lavoro potrà essere caricata sulle workstation forensi per l’analisi senza rischiare di compromettere l’originale. In caso di contestazioni, la copia master potrà sempre essere riesaminata per verifica indipendente.

Consegna e destinazione delle evidenze

Una volta concluse le acquisizioni, le evidenze dovranno essere consegnate e/o conservate in modo appropriato in vista di procedimenti futuri:

Reportistica e verbali ufficiali: si consegna allo studio legale un rapporto forense preliminare che elenca tutte le evidenze raccolte e descrive sinteticamente le modalità di acquisizione seguite, certificando che sono stati rispettati i protocolli per assicurare conformità degli originali e immodificabilità delle copie. Questo rapporto include in allegato i verbali di cui sopra e i documenti costituenti la Catena di Custodia firmati dal consulente.
Consegna a autorità inquirenti (se previsto): se lo studio intende sporgere denuncia o se l’incidente configura reati perseguibili d’ufficio, le evidenze digitali dovranno essere messe a disposizione dell’Autorità Giudiziaria. In tal caso, si preparano i reperti secondo le regole richieste: ogni evidenza viene identificata con un numero di repertazione, descritta nel verbale di consegna e consegnata (es. alla Polizia Postale o altra forza di polizia competente). I rappresentanti dell’autorità firmano per ricevuta, entrando così loro nella catena di custodia come nuovi custodi dell’evidenza. Da quel momento, ogni accesso ai dati dovrà avvenire sotto il loro controllo o con la loro autorizzazione. È importante evidenziare che la documentazione della Catena di Custodia accompagna le evidenze: fornisce al giudice la garanzia che dal momento della raccolta alla presentazione in giudizio non vi siano state manomissioni.
Conservazione a lungo termine: sia lo studio sia l’autorità (se coinvolta) dovranno conservare le evidenze digitali in modo sicuro fino alla conclusione di ogni procedura legale, ed anche oltre se richiesto. Ciò significa storage in ambienti controllati, con accesso limitato solo a personale autorizzato. Ad esempio, i supporti sigillati possono essere custoditi in una sala prove dedicata con registro accessi, e le copie digitali possono essere conservate anche in cassaforte ignifuga (per prevenire perdita in caso di incendio). Si ricorda che anche i dati digitali soffrono il passare del tempo (bit rot, obsolescenza hardware): pertanto, per conservazioni prolungate, si potrebbero effettuare periodiche verifiche dell’integrità (ricalcolando gli hash a distanza di tempo per verificare che coincidano ancora) e migrazioni su nuovi supporti in caso di necessità, sempre documentando ogni passaggio.

Strumentazione e tecniche utilizzate

Di seguito un riepilogo degli strumenti specifici impiegati e la motivazione della loro scelta, in accordo con le best practice forensi:

Write Blocker Hardware (es. Tableau, Digital Intelligence UltraBay): dispositivo essenziale che si interpone tra il supporto originale (es. SATA/SAS/USB) e la macchina forense, consentendo solo comandi di lettura. Ciò previene modifiche accidentali ai dati originali durante l’imaging . L’uso del write blocker garantisce l’immodificabilità del reperto originale in linea con i requisiti legali (copia conforme e non alterata). Abbiamo utilizzato write blocker per tutti i dischi rimossi prima di leggerli sui nostri sistemi di acquisizione.

Software di imaging forense

FTK Imager: scelto per l’acquisizione delle workstation Windows. È uno strumento gratuito e affidabile, in grado di creare immagini forensi (raw, E01, AFF) e di calcolare hash integrati. Supporta anche la cattura della RAM su macchine Windows con pochi click. Lo abbiamo usato per comodità e per mantenere un formato standard (E01) ampiamente accettato nelle corti. Inoltre FTK Imager genera un log dettagliato utile per testimoniare la correttezza delle operazioni.
dd/dc3dd: utilizzato in ambienti Linux per la sua ubiquità e controllo. dc3dd in particolare è una variante di dd orientata al digital forensics, che permette hashing on the fly e log avanzati. È stato impiegato per duplicare il disco del server Linux in maniera forense.
Guymager: alternativa GUI su Linux per imaging, scelta nel caso di acquisizioni tramite live CD CAINE. Genera direttamente file .E01 e calcola hash, semplificando l’operatività.
Tableau TD3/TX1 Forensic Imager (opzionale): si tratta di unità hardware dedicate che clonano dischi a livello hardware senza bisogno di PC. Se disponibile, avremmo potuto usarla per velocizzare l’acquisizione dei dischi grandi (soprattutto il server) con copia diretta disk-to-disk. Tali dispositivi garantiscono velocità ottimizzata e logging automatico, con verifica hash in hardware. Nel nostro scenario, abbiamo ipotizzato l’uso prevalente di software, ma è menzionato per completezza.

Strumenti per il dump della memoria volatile

Magnet RAM Capture (DumpIt): utilizzato per dump veloci della RAM sulle macchine Windows. Scelto per la sua semplicità (eseguibile portabile) e velocità. Il dump risultante è compatibile con i più diffusi framework di analisi della memoria (Volatility, Rekall).
LiME (Linux Memory Extractor): modulo kernel per Linux usato per dump di RAM del server. Scelto perché consente di ottenere un dump consistente direttamente da kernel space, con un impatto minimo sul sistema. Richiede preparazione (compilazione modulo ad hoc per la versione di kernel), perciò si potrebbe optare in alternativa per AVML (Azure VM Memory Leaker) di Microsoft, un tool user-space che non necessita compilazione. In ogni caso, l’importante è aver ottenuto la memoria prima dello spegnimento.
Volatility Framework (analisi post acquisizione): citato come strumento che useremo successivamente per analizzare i dump di memoria e cercare indizi (processi anomali, moduli sospetti, connessioni residue, credenziali in chiaro, ecc.).

Utilities di sistema e log collection

Comandi come ifconfig/ipconfig, netstat, tasklist/ps, wmic etc., possonoessere stati eseguiti durante la fase live (se fatta) per raccogliere informazioni di stato (es. elenco connessioni di rete, processi attivi, utenti loggati). Tali informazioni sono state annotate e salvate come parte delle evidenze (es. reindirizzando l’output su file di testo).
Per il firewall, l’interfaccia di amministrazione web/SSH integrata è stata lo strumento per estrarre i log e configurazioni. In mancanza di esportazione diretta, si poteva eseguire uno script o screenshot.
Hashing tools: utilizzo di algoritmi MD5, SHA-1, SHA-256 tramite tool integrati (ad es. md5sum/sha1sum su Linux, o utilità come HashCalc su Windows) per calcolare le impronte digitali delle evidenze.

In sintesi, la combinazione di questi strumenti e tecniche è stata scelta per massimizzare l’affidabilità e la completezza della raccolta delle prove, minimizzando al contempo il rischio di alterazione dei dati originali. Ogni scelta (dall’uso del write blocker all’acquisizione della RAM) è motivata da esigenze probatorie: garantire che ogni bit di informazione utile venga conservato e possa essere presentato in giudizio con adeguato fondamento di autenticità.

Conclusione

Al termine di queste operazioni, lo studio legale disporrà di copie forensi integre di tutti i sistemi coinvolti, pronte per l’analisi approfondita. Nelle fasi successive, in laboratorio, si potranno esaminare le immagini acquisite con software di analisi forense (come Autopsy, EnCase, X-Ways o altri) per ricostruire la timeline dell’intrusione, identificare l’eventuale malware o tecnica di attacco utilizzata, e confermare quali dati sono stati esfiltrati e come. I log di firewall e di sistema aiuteranno a determinare quando e verso dove sono stati trasmessi i dati rubati . Tutto questo, unito alle evidenze conservate in modo corretto, permetterà eventualmente di presentare una prova tecnica solida alle autorità competenti e in sede legale, sostenendo le azioni che lo studio legale deciderà di intraprendere a tutela dei propri clienti e contro gli autori della violazione.

Fonti e riferimenti: le procedure adottate seguono gli standard riconosciuti in ambito digital forensics e incident response, tra cui le linee guida ISO/IEC 27037:2012 per la gestione delle evidenze digitali. Strumenti come FTK Imager e write-blocker hardware sono prassi comune per garantire copie forens affidabili, così come l’uso di hash crittografici per assicurare la conformità delle copie. La catena di custodia e la sigillatura dei reperti vengono gestite secondo le indicazioni della migliore dottrina forense 19 21 , assicurando in ogni momento l’integrità e l’autenticità del materiale probatorio raccolto. Con questo approccio metodico e documentato, l’indagine potrà proseguire sapendo di avere solide basi probatorie su cui fare affidamento.