Recuperare le prove di file eliminati con il journal USN

La domanda più comune che gli analisti forensi ricevono da parti non tecniche è una variante di «riesci a provare che quel file è esistito?». Quando il file è stato eliminato dal disco, il cestino svuotato e abbastanza tempo è passato perché la entry $MFT sia stata riciclata, la risposta dipende di solito da ciò che il journal USN ancora ricorda.

Questo articolo percorre cosa il journal preserva sui file eliminati, come estrarre quelle prove e le situazioni in cui il journal è il tuo ultimo testimone.

Cosa il journal trattiene dopo l'eliminazione

Quando un file viene eliminato su NTFS accadono diverse cose:

1. La entry $FILE_NAME nella directory padre viene scollegata.
2. La entry MFT viene marcata come libera — ma non azzerata.
3. Il journal USN riceve un record FileDelete | Close che nomina il file, la sua referenza padre, il numero di entry MFT e il timestamp.

Il record del journal è il più resiliente dei tre. La entry di directory scompare appena il padre viene riscritto; la entry MFT può essere riusata appena si crea un nuovo file; il record del journal vive in un ring buffer che si capovolge solo dopo giorni o settimane di attività.

Significa che, per file eliminati giorni fa, il journal spesso ti dà:

• Il nome file (solo il foglia, non il percorso completo).
• La referenza MFT della directory padre — combinata con un $MFT parsato, ottieni il percorso.
• Il timestamp di eliminazione in UTC.
• Il numero di entry MFT che il file occupava (utile per incrociare con artefatti carvati).
• Una traccia di ciclo di vita: i record FileCreate, DataExtend, BasicInfoChange prima dell'eliminazione dicono quando il file è stato creato, come è stato scritto e se i suoi timestamp sono mai stati modificati.

Un workflow minimo di recupero

Una volta che hai un journal parsato (il parser di questa pagina o usnrs vanno bene; vedi la guida di estrazione per come ottenere $J e $MFT):

1. Filtrare per FileDelete per far emergere ogni eliminazione nella finestra. Ordinare per timestamp.
2. Per ogni eliminazione di interesse, raggruppare per FileReferenceNumber per vedere la storia completa del file — creazione, scritture, coppie di rename, modifiche di attributi e infine l'eliminazione.
3. Risolvere il percorso padre tramite il $MFT. Con entrambi i file forniti, il nostro parser lo fa automaticamente.
4. Incrociare con $LogFile se l'eliminazione è molto recente — può contenere ancora l'immagine «prima» della entry di directory, dandoti un secondo testimone indipendente.

La combinazione «ho una referenza MFT, un nome file, un padre, un timestamp di creazione e uno di eliminazione» di solito basta a soddisfare un legal hold o ad ancorare un'indagine più profonda.

Quando il percorso padre non si risolve

A volte la entry MFT padre è stata a sua volta riciclata nel momento in cui guardi — particolarmente su host attivi. In quel caso il journal ti dà il nome file e la referenza padre, ma $MFT non sa più a quale cartella corrispondesse quel numero.

Tre cose di solito aiutano:

• Record RenameNewName precedenti sulla referenza padre — possono portare un padre risolvibile al momento del rename.
• Entry di indice in $LogFile — non documentate ma coperte da libfsntfs.
• File fratelli sotto la stessa referenza padre — raggruppare tutti i record del journal per padre. Se uno dei fratelli è stato rinominato in una directory la cui entry MFT è ancora valida, puoi pivotare tramite quello.

È anche per questo che i report provvisori di questo strumento dicono «filename: notes.docx» senza percorso: preferiamo non inventare un percorso che non possiamo verificare.

«Cancellato in sicurezza» non significa sparito

Alcuni strumenti di distruzione file (CCleaner, Eraser, BleachBit) sovrascrivono il contenuto e poi eliminano. Lasciano gli stessi record di journal di un'eliminazione normale più i record di sovrascrittura. Il journal rende quindi rumorosa la «cancellazione sicura», non silenziosa:

• Più DataOverwrite | Close sul file prima del suo FileDelete | Close indicano sovrascrittura intenzionale.
• Un FileCreate e un FileDelete dello stesso file in pochi secondi, con sovrascritture in mezzo, è il pattern canonico.
• Se lo shredder ha anche pulito lo slack space scrivendo file temporanei, quei temporanei hanno le loro sequenze create/extend/overwrite/delete — uno sciame di record intorno al momento della distruzione delle prove.

La tecnica MITRE ATT&CK corrispondente è T1485 Data Destruction e T1070.004 File Deletion.

E il contenuto del file?

Il journal USN non porta mai contenuto — solo metadati di operazioni. Se vuoi i byte indietro, il journal ti indica:

• Il numero di entry MFT del file eliminato. Se la entry non è stata riusata, l'MFT trattiene ancora i data run e il contenuto è recuperabile via icat di The Sleuth Kit o X-Ways.
• Le immagini «prima» di $LogFile per eliminazioni molto recenti.
• Le Volume Shadow Copies (VSS) se esistono — il file eliminato può vivere in uno snapshot precedente.
• Store specifici di applicazione — cestino OneDrive, cartella «Autosaved» di Office, cache dei browser.

Il ruolo del journal qui è dire che un file è esistito e quando è stato eliminato — il resto del recupero è a valle.

Limiti pratici

• Il journal ha una finestra temporale. File eliminati prima che il ring buffer si fosse riavvolto al record più vecchio che hai semplicemente non sono in questo artefatto. Tira $LogFile e le shadow copy come complemento.
• Alcune operazioni non toccano il journal: modifiche di crittografia a livello di filesystem, scritture in regioni sparse che toccano solo la mappa di allocazione e manipolazioni dei reparse point NTFS possono non produrre record DataExtend/DataOverwrite.
• Un FileDelete senza un FileCreate corrispondente nella finestra significa che il file è stato creato prima del record più vecchio del journal — il suo ciclo di vita è parziale, ma puoi comunque ancorare il timestamp di eliminazione.

Per un contesto più ampio sugli artefatti, vedi il poster SANS Windows Forensic Analysis e la reference change journal di Microsoft Learn.