File di ibernazione, di paging e di arresto anomalo

Le lezioni da 5.1 a 5.3 presupponevano un'acquisizione della memoria a sistema acceso. Spesso non è disponibile: il computer era spento oppure si dispone soltanto di un'immagine del disco o di una raccolta di triage. La memoria viene comunque scritta su disco tramite l'ibernazione, i file di paging, i dump di arresto anomalo e i rispettivi equivalenti Linux. Questa lezione spiega quando viene scritto ciascun file, quanta struttura viene preservata e come datare ciò che si trova. Le raccolte di triage spesso escludono pagefile.sys e hiberfil.sys perché sono di grandi dimensioni, mentre i piccoli rapporti di arresto anomalo vengono solitamente raccolti.

Perché la memoria finisce su disco

I sistemi scrivono la RAM su disco per liberare RAM (paging), per spegnersi senza perdere lo stato (ibernazione) e per documentare un errore (dump di arresto anomalo). Maggiore è la struttura preservata, maggiore è la parte del flusso di lavoro di Volatility descritto nelle lezioni 5.2 e 5.3 che rimane applicabile.

Il file di ibernazione

C:\hiberfil.sys è un file di sistema nascosto nella radice del volume di sistema. Quando l'utente sceglie Iberna, Windows vi scrive il contenuto compresso della RAM e si spegne; all'avvio successivo, il boot loader ripristina la memoria da questo file. Il valore di registro HibernateEnabled in SYSTEM\<ControlSet>\Control\Power indica se l'ibernazione è attivata. In un hive offline, leggere Select\Current per individuare il ControlSet00x corretto (lezione 2.1).

Avvio rapido

Avvio rapido (detto anche arresto ibrido) utilizza lo stesso file. Quando l'utente fa clic su Arresta il sistema, Windows disconnette tutte le sessioni utente e poi iberna soltanto la sessione del kernel: il kernel, i driver e i processi e servizi di sistema della sessione 0. Il successivo avvio a freddo ripristina quell'immagine invece di eseguire l'avvio da zero. Avvio rapido è abilitato per impostazione predefinita in molte installazioni client di Windows 10 e 11 che supportano l'ibernazione, ma occorre verificarlo anziché presumerlo: il valore HiberbootEnabled in SYSTEM\<ControlSet>\Control\Session Manager\Power è 1 quando la funzione è attiva. Un Riavvio non utilizza Avvio rapido, ma esegue un arresto completo. All'avvio successivo, l'evento 27 di Kernel-Boot nel registro Sistema riporta il tipo di avvio: 0x0 per un avvio completo, 0x1 per un avvio con Avvio rapido (ibrido) e 0x2 per una ripresa dall'ibernazione.

Pertanto, un computer sequestrato mentre è spento conserva spesso un'istantanea della sessione del kernel al momento dell'ultimo arresto: processi di sistema, servizi, driver e strutture di rete del kernel, ma non applicazioni utente come explorer.exe, perché le sessioni utente sono state prima disconnesse. Un'ibernazione vera e propria conserva anche le sessioni utente.

Conversione e datazione

Il file non è un'immagine di memoria in formato raw. Contiene un'intestazione e insiemi di pagine compresse (compressione Microsoft Xpress; la variante dipende dalla versione di Windows), quindi deve essere decompresso prima che la maggior parte degli strumenti possa utilizzarlo. Le versioni ufficiali di Volatility 3 non leggono direttamente i file di ibernazione: occorre quindi convertire prima il file con uno strumento come Hibr2Bin, che genera un'immagine raw. Dopo la conversione, i plugin delle lezioni 5.2 e 5.3 funzionano come di consueto.

L'intestazione inizia con una firma come HIBR (hibr in minuscolo nelle versioni precedenti) quando l'immagine è valida. La firma dell'intestazione cambia dopo una ripresa: Windows sovrascrive o azzera l'intestazione, quindi si possono osservare valori come WAKE, RSTR o zeri, e un file obsoleto potrebbe non essere convertito correttamente. Le pagine compresse di quell'immagine precedente possono comunque rimanere e vale la pena cercarvi stringhe o eseguire una ricerca YARA.

Soprattutto, datare l'istantanea: essa descrive il momento in cui il file è stato scritto, eventualmente diversi giorni prima del sequestro. Utilizzare l'ora di sistema memorizzata nell'intestazione di ibernazione, se lo strumento la interpreta, e l'ora di modifica del file in $STANDARD_INFORMATION nella $MFT, quindi corroborare entrambe con gli eventi di arresto e avvio nel registro Sistema (lezione 2.7).

Pagefile e swapfile

C:\pagefile.sys contiene le pagine che il gestore della memoria ha trasferito fuori dalla RAM. La posizione e la dimensione sono impostate nel valore PagingFiles in SYSTEM\<ControlSet>\Control\Session Manager\Memory Management, quindi occorre verificare anche la presenza di file di paging su altri volumi. C:\swapfile.sys (Windows 8 e versioni successive) è un file complementare più piccolo, utilizzato per trasferire fuori dalla RAM le app moderne (dello Store) nella loro interezza.

Un file di paging è una raccolta di pagine da 4 KiB scritte nel tempo, senza una mappa: le tabelle delle pagine che indicano a quale processo e indirizzo virtuale appartenesse una pagina si trovano nella RAM, non nel file. Non è possibile ricostruire i processi da un solo file di paging. Alcuni framework di analisi della memoria possono combinare un file di paging con un'acquisizione della RAM effettuata nello stesso momento per risolvere gli indirizzi trasferiti fuori dalla RAM, ma in un caso in cui si dispone soltanto del disco il file di paging è una fonte di stringhe: URL, frammenti di e-mail e chat, comandi digitati, percorsi di file e talvolta credenziali. Per impostazione predefinita, Windows riutilizza il file tra un avvio e l'altro senza azzerarlo, quindi una pagina può provenire da una sessione precedente.

Due fattori riducono ciò che è possibile trovare:

• Compressione della memoria (Windows 10 e versioni successive): le pagine possono essere compresse nell'archivio di compressione della memoria nella RAM prima di essere trasferite fuori dalla RAM, quindi il contenuto del file di paging può essere compresso e risultare invisibile a una semplice ricerca di stringhe. Esistono strumenti di ricerca per decomprimere l'archivio, ma gli strumenti standard non rilevano tale contenuto.
• ClearPageFileAtShutdown: quando questo DWORD in Memory Management è impostato su 1, Windows sovrascrive il file di paging con zeri all'arresto. Un file di paging composto interamente da zeri, con questo valore impostato, è un risultato previsto, non un segno di cancellazione da parte dell'utente.

Eseguire l'analisi con strings sia in ASCII sia in UTF-16LE (strings -el), con bulk_extractor (i suoi file delle caratteristiche elencano ogni riscontro con il relativo offset in byte e il contesto circostante) e con regole YARA. Registrare l'offset di ogni riscontro: è l'unico riferimento per localizzarlo.

Dump di arresto anomalo e rapporti di errore

Quando Windows si arresta con un bugcheck (una "schermata blu"), scrive la memoria nel file di paging e, all'avvio successivo, la salva come file di dump e registra l'evento Sistema 1001 con origine BugCheck. Il tipo è impostato da CrashDumpEnabled in SYSTEM\<ControlSet>\Control\CrashControl:

I dump completi e del kernel vengono salvati in C:\Windows\MEMORY.DMP (il valore DumpFile; per impostazione predefinita, ogni arresto anomalo sovrascrive il precedente), mentre i dump ridotti vengono salvati in C:\Windows\Minidump\*.dmp. Volatility 3 legge soltanto i dump completi della memoria (i formati full e bitmap, DumpType 1 e 5), non i dump del kernel o ridotti; pertanto, un dump completo si comporta come un'acquisizione della RAM; analizzare i dump del kernel con WinDbg. Un dump del kernel elenca processi e driver, ma manca tutto ciò che si trova nella memoria utente, come le righe di comando memorizzate nell'ambiente del processo. In WinDbg, !analyze -v spiega l'arresto anomalo, lm elenca i moduli e !process 0 0 elenca i processi.

Gli arresti anomali delle applicazioni sono gestiti da Windows Error Reporting (WER). I rapporti vengono archiviati in C:\ProgramData\Microsoft\Windows\WER\ReportArchive (inviati o elaborati) e ReportQueue (in attesa), con copie per utente in %LOCALAPPDATA%\Microsoft\Windows\WER. I nomi delle cartelle iniziano con il tipo di rapporto e il nome dell'eseguibile, ad esempio AppCrash_xfer.exe_…. Ciascuna contiene un file di testo UTF-16 Report.wer con righe chiave=valore, ad esempio EventType=APPCRASH, un EventTime scritto come FILETIME decimale, nonché il nome dell'applicazione e, nelle versioni più recenti, il suo percorso completo. Un rapporto di arresto anomalo dimostra che il programma è stato eseguito, quindi è un artefatto di esecuzione che sopravvive all'eliminazione del programma (la lezione 2.3 tratta gli altri). Gli eventi 1000 (Application Error) e 1001 (Windows Error Reporting) del registro Applicazione lo corroborano.

I dump completi in modalità utente di un processo che subisce un arresto anomalo vengono scritti soltanto se LocalDumps è configurato in SOFTWARE\Microsoft\Windows\Windows Error Reporting\LocalDumps: DumpFolder (valore predefinito %LOCALAPPDATA%\CrashDumps), DumpType (1 mini, 2 completo) e DumpCount (valore predefinito 10). Un dump completo di un browser può contenere contenuti decifrati.

Linux: swap e core dump

Linux trasferisce le pagine fuori dalla RAM in una partizione di swap o in un file di swap come /swapfile; /etc/fstab li specifica. Un'area di swap contiene la firma SWAPSPACE2 negli ultimi 10 byte della prima pagina (offset 4.086 con pagine da 4 KiB). Come un file di paging, lo swap è una fonte di stringhe. L'ibernazione (sospensione su disco) in Linux scrive l'immagine della memoria nello swap, e l'implementazione del kernel sostituisce la firma con S1SUSPEND fino alla ripresa. Lo swap è spesso cifrato insieme al disco e zram mantiene lo swap compresso soltanto nella RAM.

Gli arresti anomali dei processi nelle distribuzioni basate su systemd vengono acquisiti da systemd-coredump: file core compressi in /var/lib/systemd/coredump/, il cui nome include il nome del programma, l'ID utente, l'ID di avvio, l'ID del processo e l'ora dell'arresto anomalo, oltre a una voce del journal che coredumpctl list mostra anche dopo la rimozione del file core.

Tabella riepilogativa

Esempio svolto

File di ibernazione. Un computer desktop è stato trovato spento e sequestrato il 2026-03-16T09:30:00Z. L'immagine contiene hiberfil.sys con un'ora di modifica nella $MFT pari a 2026-03-13T22:47:10Z. In ControlSet001\Control\Session Manager\Power, HiberbootEnabled = 1. L'immagine convertita mostra lsass.exe, services.exe, numerose istanze di svchost.exe e un servizio sconosciuto, ma nessun explorer.exe e nessun browser.

Interpretazione: si tratta di un'immagine di Avvio rapido risalente all'ultimo arresto, non al sequestro. L'intervallo va da 2026-03-13T22:47:10Z a 2026-03-16T09:30:00Z: 2 giorni (fino a 2026-03-15T22:47:10Z) più 10 h 42 min 50 s, quindi 2 d 10 h 42 min 50 s. Riportare il servizio sconosciuto come "in esecuzione il 2026-03-13T22:47:10Z, al momento dell'ultimo arresto con Avvio rapido" e corroborare l'ora con gli eventi di arresto nel registro Sistema. L'assenza di processi utente non significa che nessuno avesse effettuato l'accesso.

File di paging. bulk_extractor segnala la stringa UTF-16LE transfer.example.com/upload all'offset in byte 1.234.567.890 di pagefile.sys e, nelle vicinanze, un frammento di e-mail rcos.vidal@exampl. 1.234.567.890 = 0x499602D2. Con pagine da 4 KiB: 1.234.567.890 ÷ 4.096 = 301.408 con resto 722, quindi pagina 301.408 (0x49960), byte 722 (0x2D2) al suo interno. Riportare:

• la stringa esatta, la codifica, l'offset in decimale e in esadecimale e l'hash del file pagefile.sys esportato;
• il frammento esattamente come trovato, senza completare l'indirizzo;
• che il file di paging non fornisce né un'ora né un processo di appartenenza e che la pagina può essere precedente all'ultimo avvio;
• la corroborazione da fonti con riferimenti temporali: cronologia e download del browser (modulo 4), utilizzo della rete in SRUM (lezione 2.8) oppure registri di proxy e firewall.

Gestione dei contenuti sensibili

Questi file contengono tutto ciò che era in memoria: password, messaggi di terzi, dati sanitari o finanziari e comunicazioni coperte da privilegio legale. Mantenere le ricerche entro i limiti dell'autorizzazione, riportare soltanto i riscontri pertinenti e proteggere le stringhe e i dump esportati come gli elementi di prova stessi.

Focus sull'esame: Sono previste domande sul contenuto di ciascun file e sul momento in cui viene scritto, in particolare sul fatto che un hiberfil.sys di Avvio rapido contiene soltanto la sessione del kernel dell'ultimo arresto e deve essere datato. Occorre conoscere i valori di CrashDumpEnabled, i percorsi predefiniti dei dump, le cartelle WER come prova di esecuzione e i valori di registro HiberbootEnabled e ClearPageFileAtShutdown. I riscontri nel file di paging vengono riportati mediante offset, senza un'ora.

Punti chiave

• hiberfil.sys è un'istantanea compressa della RAM risalente all'ultima ibernazione o all'ultimo arresto con Avvio rapido; convertirla e datarla prima di interpretarla.
• Avvio rapido salva soltanto la sessione del kernel, quindi le applicazioni utente sono assenti per progettazione.
• pagefile.sys, swapfile.sys e lo swap di Linux sono pagine prive di struttura: cercare stringhe, riportare gli offset e non dedurne mai un'ora.
• CrashDumpEnabled imposta il tipo di dump (1 completo, 2 kernel, 3 ridotto, 7 automatico); un dump del kernel non contiene la memoria in modalità utente.
• I file WER Report.wer e le voci di systemd-coredump dimostrano che un programma è stato eseguito, anche dopo la sua eliminazione.
• Questi file contengono dati di terzi e dati sensibili; rimanere entro l'ambito autorizzato.