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.