{"id":3546,"date":"2025-10-23T19:48:43","date_gmt":"2025-10-23T17:48:43","guid":{"rendered":"https:\/\/www.fabriziogiancola.eu\/?p=3546"},"modified":"2025-11-04T09:27:31","modified_gmt":"2025-11-04T08:27:31","slug":"memoria-volatile-windows-analisi-dump-memoria","status":"publish","type":"post","link":"https:\/\/www.fabriziogiancola.eu\/index.php\/2025\/10\/23\/memoria-volatile-windows-analisi-dump-memoria\/","title":{"rendered":"Memoria volatile in Windows. Analisi del dump di memoria"},"content":{"rendered":"\n<p class=\"has-dark-gray-color has-very-light-gray-to-cyan-bluish-gray-gradient-background has-text-color has-background has-link-color has-medium-font-size wp-elements-5d013d3ea3d7addb21cdd4eaca9c2fd9\"><strong>Procedure di acquisizione e precauzioni operative<\/strong><\/p>\n\n\n\n<p>L\u2019acquisizione <strong>live <\/strong>della memoria RAM su sistemi Windows richiede una strategia che minimizzi l\u2019alterazione 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. \u00c8 fondamentale <strong>non spegnere n\u00e9<\/strong> <strong>riavviare <\/strong>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, \u00e8 buona prassi preparare un supporto esterno (come una chiavetta USB) contenente l\u2019eseguibile di acquisizione, in modo da <strong>eseguire il tool da un supporto<\/strong> <strong>rimovibile <\/strong>e salvare il dump di memoria su un\u2019unit\u00e0 esterna o share di rete. Ci\u00f2 riduce le scritture sul disco locale del sistema in esame e limita la possibilit\u00e0 che malware o altri processi notino l\u2019operazione, oltre a diminuire il rischio di sovrascrivere dati volatili critici. Ad esempio, \u00e8 comune avviare <strong>WinPmem <\/strong>da USB e salvare l\u2019immagine di memoria direttamente su un server remoto. Durante l\u2019acquisizione, 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 <em>memory smear<\/em>, cio\u00e8 piccole discrepanze dovute al continuo cambiamento dei dati in RAM). In ogni caso, \u00e8 consigliato avviare la cattura il prima possibile, prima che ulteriori attivit\u00e0 del sistema sovrascrivano informazioni potenzialmente importanti. Nel processo di acquisizione bisogna anche <strong>documentare orario e modalit\u00e0 <\/strong>di cattura (utile per correlare in seguito gli eventi di memoria con log di sistema) e, completata l\u2019operazione, <strong>calcolare hash<\/strong> crittografici (MD5\/SHA) del file di dump ottenuto. Ci\u00f2 garantisce l\u2019integrit\u00e0 dell\u2019evidenza e permette di attestare che l\u2019immagine di memoria analizzata corrisponda esattamente a quella acquisita sul sistema live. L\u2019originale va conservato in modo sicuro e l\u2019analisi va eseguita su copie, mantenendo una chiara <em>chain of custody <\/em>qualora l\u2019evidenza dovesse essere presentata in sede legale. <\/p>\n\n\n\n<p class=\"has-dark-gray-color has-very-light-gray-to-cyan-bluish-gray-gradient-background has-text-color has-background has-link-color has-medium-font-size wp-elements-e9798055a6cc9cf909ff6e382b527ace\"><strong>Strumenti principali per l\u2019acquisizione di memoria volatile<\/strong><\/p>\n\n\n\n<p>In ambiente Windows esistono diversi strumenti specializzati per acquisire il contenuto della memoria fisica in modo forense. Tutti questi caricano un <strong>driver kernel <\/strong>per accedere alla RAM a basso livello e producono un file (tipicamente in formato <em>raw <\/em>o <em>mem<\/em>) contenente l\u2019intera memoria volatile. Di seguito alcuni dei tool comunemente impiegati.<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>WinPmem <\/strong>\u2013 strumento open source (parte del progetto Rekall) che permette il dump completo della RAM; utilizza un driver kernel dedicato e salva l\u2019immagine in formato raw. \u00c8 un tool a riga di comando ed \u00e8 apprezzato per la sua affidabilit\u00e0.<\/li>\n\n\n\n<li><strong>FTK Imager (Memory Capture) <\/strong>\u2013 il noto tool di imaging forense FTK Imager include una funzione \u201c<em>Capture Memory<\/em>\u201d per acquisire la RAM live; tramite un\u2019interfaccia grafica consente di specificare destinazione del file di output e offre l\u2019opzione di includere automaticamente il pagefile di Windows.<\/li>\n\n\n\n<li><strong>DumpIt <\/strong>\u2013 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; \u00e8 popolare per la sua <strong>facilit\u00e0 d\u2019uso one-click<\/strong>, sebbene introduca un footprint in memoria molto ridotto (carica pochissimi DLL).<\/li>\n\n\n\n<li><strong>Mandiant Redline <\/strong>\u2013 strumento freeware di FireEye con interfaccia GUI che include funzionalit\u00e0 sia di acquisizione live (tramite un driver kernel) sia di analisi basica. Redline pu\u00f2 essere eseguito da USB e consente di collezionare la RAM in un file di dump; internamente utilizza la componente <strong>Memoryze <\/strong>per l\u2019accesso raw alla memoria.<\/li>\n\n\n\n<li><strong>Belkasoft Live RAM Capturer <\/strong>\u2013 tool gratuito orientato all\u2019acquisizione rapida anche in presenza di tecniche anti-debug\/anti-dump. Ha un\u2019interfaccia semplice (\u201cCapture\u201d button) e produce un file raw; supporta sia x86 che x64 e cerca di bypassare eventuali protezioni del malware durante la lettura della RAM.<\/li>\n\n\n\n<li><strong>F-Response <\/strong>\u2013 soluzione commerciale che permette di acquisire memoria da macchine live <strong>da remoto<\/strong>. Consiste in un driver e connettore di rete che espone la RAM del sistema target come una periferica accessibile dall\u2019analista, consentendo il dump anche via LAN\/WAN. \u00c8 usato in contesti enterprise per incident response distribuito.<\/li>\n<\/ul>\n\n\n\n<p><strong>Nota: <\/strong>Indipendentemente dallo strumento scelto per l\u2019acquisizione, il file grezzo ottenuto (immagine di memoria) \u00e8 generalmente analizzabile con i principali framework di memory forensics (Volatility, Rekall, etc.), a prescindere dal tool che lo ha generato.<\/p>\n\n\n\n<p>L\u2019importante \u00e8 assicurarsi che il tool supporti il sistema operativo target (versione e architettura) e sia testato in anticipo, per evitare incompatibilit\u00e0 al momento critico.<\/p>\n\n\n\n<p class=\"has-dark-gray-color has-very-light-gray-to-cyan-bluish-gray-gradient-background has-text-color has-background has-link-color has-medium-font-size wp-elements-d8ec3ca5a0bf1f956341454a8506c785\"><strong>Principali artefatti estratti da un dump di memoria<\/strong><\/p>\n\n\n\n<p>Una volta ottenuta un\u2019immagine di memoria, l\u2019analisi forense si concentra sull\u2019<strong>estrazione degli artefatti <\/strong>volatili, ossia tutte le informazioni significative sullo stato del sistema al momento della cattura. La memoria RAM conserva tracce di quasi ogni attivit\u00e0 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.<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Processi e thread in esecuzione: <\/strong>l\u2019elenco dei processi attivi al momento della cattura pu\u00f2 essere ricostruito attraversando la <em>doubly-linked list <\/em>dei processi in kernel mode. In Windows il kernel mantiene una lista concatenata di strutture <code>_EPROCESS<\/code> (puntata da <code>PsActiveProcessHead<\/code>), ciascuna rappresentante un processo attivo. Ogni record EPROCESS contiene vari metadata (PID, nome eseguibile, stato, ecc.) e un puntatore al <strong>PEB <\/strong>(<em>Process Environment Block<\/em>) in user mode, dove sono presenti ulteriori info come i parametri di avvio, le variabili d\u2019ambiente e i moduli caricati del processo. Dal PEB si pu\u00f2 risalire anche al tree <strong>VAD <\/strong>(<em>Virtual Address Descriptors<\/em>) che descrive le regioni di memoria allocate dal processo. L\u2019analisi dell\u2019elenco dei processi (ad es. tramite plugin Volatility <code>pslist\/pstree<\/code>) consente di identificare processi sospetti \u2013 ad esempio nomi anomali o processi senza parent legittimo. Un esempio tipico: individuare un <code>svchost.exe<\/code> il cui parent process non \u00e8 <code>services.exe<\/code> pu\u00f2 indicare un processo <em>spoofed<\/em> 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\u00f2 incrociare con una scansione di strutture non collegate tramite plugin <code>psscan <\/code>per trovare eventuali EPROCESS orfani). In sintesi, la lista dei processi attivi fornisce una \u201cfotografia\u201d dello stato di esecuzione del sistema, analoga a ci\u00f2 che mostrerebbe un Task Manager al momento del dump.<\/li>\n\n\n\n<li><strong>Moduli e DLL caricati nei processi: <\/strong>per ogni processo, la memoria contiene l\u2019elenco delle <strong>DLL <\/strong>e librerie caricate nello spazio di indirizzamento di quel processo. Questa informazione \u00e8 ottenuta leggendo le strutture di <em>loader <\/em>del PEB (lista dei moduli in memoria) o tramite scanning delle pagine di memoria alla ricerca di intestazioni PE in uso. Un\u2019analisi dei moduli caricati (<code>dlllist<\/code> 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 \u00e8 un forte indicatore di code injection. Analogamente, driver e moduli del kernel caricati possono essere elencati tramite la struttura globale <code>PsLoadedModuleList<\/code>(o plugin Volatility <code>modules\/modscan<\/code>): eventuali driver non firmati o posizionati fuori dalle directory di sistema standard potrebbero indicare rootkit in kernel space.<\/li>\n\n\n\n<li><strong>Connessioni di rete e socket: <\/strong>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 <code>_TCPT_OBJECT<\/code> per connessioni TCP in Windows Vista+), \u00e8 possibile elencare connessioni con relativi endpoint locali\/remoti e processo associato. I tool forensi (es. plugin <code>netscan<\/code> di Volatility) effettuano una scansione della memoria kernel alla ricerca di queste strutture per recuperare connessioni di rete live <strong>e anche recentemente chiuse<\/strong>. Ci\u00f2 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\u2019analisi della memoria ne riveler\u00e0 l\u2019IP e la porta, informazione preziosa per comprendere canali di <em>command-and-control <\/em>o esfiltrazione dati. Anche socket in ascolto (porte aperte in <em>listening<\/em>) possono essere identificate attraverso le strutture di socket in memoria (es. plugin <code>sockets<\/code>). 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).<\/li>\n\n\n\n<li><strong>File e handle aperti: <\/strong>la tabella degli <em>handle <\/em>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 <code>handles<\/code> o <code>files<\/code>) 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\u00e0 cancellato sul disco, tali informazioni emergono dalla memoria (poich\u00e9 l\u2019handle resta in vita finch\u00e9 il file \u00e8 aperto, anche se \u00e8 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.<\/li>\n\n\n\n<li><strong>Informazioni di registro e configurazione: <\/strong>parte del <strong>Registro di Windows <\/strong>risiede in memoria quando il sistema \u00e8 acceso, in particolare le hive principali e le chiavi recentemente accedute. Tramite un dump di memoria \u00e8 possibile estrarre intere hive di registro o singole chiavi\/pair valore che erano caricate in RAM. Ad esempio, la Volatility con plugin come <code>hivelist<\/code> individua le basi di registro in memoria, e printkey pu\u00f2 leggerne il contenuto. Ci\u00f2 consente di rilevare modifiche al registro effettuate da malware <strong>solo in memoria <\/strong>(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\u00f2 rivelare l\u2019<strong>ultimo stato noto <\/strong>di alcune parti del registro di sistema, anche meglio di un\u2019analisi post-mortem sul disco.<\/li>\n\n\n\n<li><strong>Dati sensibili in memoria (credenziali, input utente): <\/strong>la memoria pu\u00f2 contenere frammenti di dati in chiaro che non sono salvati altrove. Un esempio notevole sono le <strong>credenziali utente e hash <\/strong>conservati nei processi di sistema come <code>lsass.exe<\/code>: 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 <strong>testi in chiaro <\/strong>digitati o copiati: ad esempio, la <strong>clipboard <\/strong>utente (appunti) pu\u00f2 contenere l\u2019ultimo testo copiato, e ci\u00f2 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 <em>string carving <\/em>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 <strong>chiavi di cifratura <\/strong>durante l\u2019esecuzione: 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.<\/li>\n\n\n\n<li><strong>Strutture del kernel e segni di rootkit: <\/strong>un\u2019analisi approfondita del dump include l\u2019esame di strutture del kernel per individuare manipolazioni malevole. Ad esempio, un rootkit in <em>kernel <u>mode <\/u><\/em>potrebbe nascondere un processo rimuovendolo dalla lista dei processi (modificando i link <code>ActiveProcessLinks<\/code> in EPROCESS). Un analista, tuttavia, pu\u00f2 eseguire scansioni grezze della memoria alla ricerca di pattern di EPROCESS non collegati (Volatility <code>psscan<\/code>) e scoprire cos\u00ec processi \u201cnascosti\u201d nonostante non appaiano nella lista attiva. Analogamente, si controllano le <strong>SSDT e IDT <\/strong>(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 &nbsp;nel kernel, di sezioni di memoria marcate come eseguibili ma non appartenenti a moduli noti (<code>malfind<\/code> 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 <strong>tecniche di occultamento <\/strong>utilizzate da malware avanzati (DKOM \u2013 <em>Direct Kernel Object Manipulation<\/em>, hooking di funzioni, patch in-line in memoria, ecc.) e completano il quadro evidenziale individuando anche minacce che non lasciano tracce nei file system.<\/li>\n<\/ul>\n\n\n\n<p>In sintesi, dall\u2019analisi di un dump di memoria si possono estrarre <strong>moltissime evidenze<\/strong>: processi attivi e terminati, moduli e codice iniettato, connessioni di rete, attivit\u00e0 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\u2019incidente, offrendo una visibilit\u00e0 unica che integra l\u2019analisi dei dischi e di altri log persistenti. La memory forensics fornisce dunque uno <strong>snapshot puntuale <\/strong>dello stato di un sistema compromesso, fondamentale per comprendere attivit\u00e0 altrimenti inaccessibili dopo lo shutdown.<\/p>\n\n\n\n<p class=\"has-dark-gray-color has-very-light-gray-to-cyan-bluish-gray-gradient-background has-text-color has-background has-link-color has-medium-font-size wp-elements-71cbb16716baf754240bed551d394931\"><strong>Ruolo complementare di pagefile.sys e hiberfil.sys nell\u2019arricchimento delle evidenze<\/strong><\/p>\n\n\n\n<p>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\u2019indagine forense. In particolare <strong>pagefile.sys <\/strong>(file di paging) e <strong>hiberfil.sys <\/strong>(file di ibernazione) svolgono un ruolo complementare nell\u2019arricchire i dati acquisiti dalla RAM.<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Pagefile.sys: <\/strong>\u00e8 il file di paging usato da Windows come <strong>estensione della RAM <\/strong>sul disco. Quando la memoria fisica si riempie, parti dei dati meno usati in RAM vengono \u201cswappati\u201d 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\u2019istantanea della memoria acquisita (perch\u00e9 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, <strong>cronologie di navigazione<\/strong>, immagini o altri artefatti di attivit\u00e0 utente che non risiedono pi\u00f9 nella RAM attiva. In un caso pratico, l\u2019analisi del pagefile ha permesso di estrarre centinaia di URL di siti visitati dall\u2019utente e immagini relative alla navigazione web, informazioni non presenti altrove poich\u00e9 la cronologia del browser era stata cancellata ma rimasta in pagine di memoria virtuale. Tuttavia, va notato che il pagefile <strong>non <\/strong>mantiene la struttura allocativa della RAM bens\u00ec solo pagine isolate: di conseguenza, non \u00e8 direttamente \u201cmontabile\u201d con tool come Volatility per estrarre processi o socket. L\u2019analisi forense del pagefile si basa su <strong>techiche di carving <\/strong>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 <strong>miniera di dati residuali<\/strong>: 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\u00f9 lavoro manuale e possa produrre anche falsi positivi, dato che include frammenti di pagine appartenenti anche a software di sicurezza, sistema operativo, ecc.).<\/li>\n\n\n\n<li><strong>Hiberfil.sys: <\/strong>\u00e8 il file in cui Windows salva il contenuto completo della RAM quando il sistema entra in modalit\u00e0 <strong>ibernazione <\/strong>(sospensione su disco). In pratica, hiberfil.sys rappresenta un\u2019istantanea byte-per-byte della memoria al momento in cui il sistema \u00e8 stato ibernato. Questo significa che, dal punto di vista forense, esso equivale a un <strong>dump di memoria <\/strong>effettuato dal sistema stesso durante il processo di ibernazione. Se un computer sospetto viene trovato spento in modalit\u00e0 ibernata (o se si dispone del file hiberfil.sys da un\u2019immagine disco), analizzarlo consente di recuperare uno stato della memoria di interesse. L\u2019hiberfil.sys conserva <em>lo stato completo del sistema <\/em>al momento dell\u2019ibernazione, inclusi tutti i processi attivi, le loro memorie, le connessioni di rete aperte, le impostazioni correnti e cos\u00ec via. \u00c8 dunque una <strong>miniera d\u2019oro forense <\/strong>che permette di sbirciare \u201cl\u2019ultimo respiro\u201d del sistema prima dello stop. In termini pratici, esistono strumenti per convertire hiberfil.sys in un\u2019immagine di RAM standard: ad esempio Volatility (v2 o v3) offre plugin <code>imagecopy\/hiberfile<\/code> per trasformare il file di ibernazione in un file raw analizzabile e tool dedicati come <strong>Hibernation Recon<\/strong> supportano i vari formati di hiberfil (che differiscono tra Windows 7 e Windows 8+ a causa di compressione). Una volta convertito, l\u2019analista pu\u00f2 trattarlo come un normale dump di memoria e applicare gli stessi plugin per estrarre processi, rete, ecc., col vantaggio che spesso l\u2019ibernazione cattura anche informazioni che un\u2019acquisizione live potrebbe perdere (ad es. perch\u00e9 il sistema era troppo attivo per ottenere un snapshot coerente). Va considerato che su Windows 10\/11 il file hiberfil.sys \u00e8 usato anche per la funzione di <strong>Fast Startup <\/strong>(avvio ibrido): in tale caso il file pu\u00f2 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\u2019hiberfil.sys fornisce uno <strong>storico dello<\/strong> <strong>stato della RAM <\/strong>che pu\u00f2 integrare un\u2019analisi: ad esempio, se un incidente \u00e8 avvenuto prima dell\u2019ultimo ibernamento, il file conterr\u00e0 ancora tracce di quel evento anche se la RAM live successiva \u00e8 cambiata. \u00c8 un complemento prezioso soprattutto quando non \u00e8 stato possibile ottenere un dump live al momento dell\u2019incidente \u2013 l\u2019analisi dell\u2019hiberfil pu\u00f2 svelare informazioni altrimenti andate perdute.<\/li>\n<\/ul>\n\n\n\n<p>In sintesi, <strong>pagefile.sys e hiberfil.sys <\/strong>arricchiscono l\u2019indagine forense mettendo a disposizione dati della memoria volatile che altrimenti potrebbero sfuggire. Il pagefile estende l\u2019orizzonte temporale delle evidenze volatili conservando tracce di attivit\u00e0 passate (come uno <strong>storage ausiliario della RAM <\/strong>per dati paginati), mentre l\u2019hiberfil offre un vero <strong>snapshot congelato <\/strong>della RAM in un momento specifico (ibernazione). Integrando l\u2019analisi dell\u2019immagine di memoria live con questi file, l\u2019analista pu\u00f2 ottenere una visione pi\u00f9 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\u2019incident response, ecc.). Di fatto, nelle fasi iniziali di <strong>acquisizione della memoria <\/strong>andrebbero sempre considerati anche questi file: ad esempio, copiando il pagefile.sys e l\u2019hiberfil.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.<\/p>\n","protected":false},"excerpt":{"rendered":"<p>Procedure di acquisizione e precauzioni operative L\u2019acquisizione live della memoria RAM su sistemi Windows richiede una strategia che minimizzi l\u2019alterazione 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. \u00c8 fondamentale non spegnere n\u00e9 riavviare la macchina (per evitare &hellip; <a href=\"https:\/\/www.fabriziogiancola.eu\/index.php\/2025\/10\/23\/memoria-volatile-windows-analisi-dump-memoria\/\" class=\"more-link\">Leggi tutto<span class=\"screen-reader-text\"> &#8220;Memoria volatile in Windows. Analisi del dump di memoria&#8221;<\/span><\/a><\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"iawp_total_views":4,"footnotes":""},"categories":[12,14],"tags":[77,102,103,104,58,53,105],"class_list":["post-3546","post","type-post","status-publish","format-standard","hentry","category-cyber-security","category-digital-forensics","tag-dump","tag-hiberfil-sys","tag-ibernazione","tag-pagefile-sys","tag-ram","tag-volatility","tag-windows"],"_links":{"self":[{"href":"https:\/\/www.fabriziogiancola.eu\/index.php\/wp-json\/wp\/v2\/posts\/3546","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.fabriziogiancola.eu\/index.php\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.fabriziogiancola.eu\/index.php\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.fabriziogiancola.eu\/index.php\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.fabriziogiancola.eu\/index.php\/wp-json\/wp\/v2\/comments?post=3546"}],"version-history":[{"count":30,"href":"https:\/\/www.fabriziogiancola.eu\/index.php\/wp-json\/wp\/v2\/posts\/3546\/revisions"}],"predecessor-version":[{"id":3671,"href":"https:\/\/www.fabriziogiancola.eu\/index.php\/wp-json\/wp\/v2\/posts\/3546\/revisions\/3671"}],"wp:attachment":[{"href":"https:\/\/www.fabriziogiancola.eu\/index.php\/wp-json\/wp\/v2\/media?parent=3546"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.fabriziogiancola.eu\/index.php\/wp-json\/wp\/v2\/categories?post=3546"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.fabriziogiancola.eu\/index.php\/wp-json\/wp\/v2\/tags?post=3546"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}