Recuperare prove di file cancellati con il USN journal

La domanda più comune che gli analisti forensi ricevono da stakeholder non tecnici è una variante di "puoi provare che questo file è esistito?". Quando il file è stato cancellato dal disco, il cestino svuotato, e abbastanza tempo è passato perché l'entry $MFT sia stata riutilizzata per qualcos'altro, la risposta dipende quasi sempre da cosa il USN journal ricorda ancora. Il journal è, nella mia esperienza, il testimone più duraturo per "questo file è mai esistito" una volta che tutto il resto è stato cancellato.

Questo post percorre cosa il journal preserva sui file cancellati, come estrarre quella prova, e i casi in cui il journal è la tua ultima linea.

Cosa il journal mantiene dopo la cancellazione

Quando un file viene cancellato su NTFS, succedono tre cose:

1. La voce $FILE_NAME nella directory padre viene scollegata. L'INDEX_ALLOCATION della directory viene riscritta senza di essa.
2. L'entry MFT viene marcata inutilizzata ma non azzerata. Il prossimo file allocato a quell'entry sovrascrive i data run, attributi e timestamp.
3. Il USN journal riceve un record FileDelete | Close che nomina il file, il suo riferimento padre, il numero e la sequenza di entry MFT, e il timestamp di cancellazione.

Il record del journal è il più resiliente dei tre. La voce di directory sparisce nel momento in cui il padre viene riscritto — a volte in secondi su un volume attivo. L'entry MFT può essere riutilizzata appena viene creato un nuovo file — a volte in minuti. Il record del journal sta in un ring buffer che gira solo dopo giorni o settimane.

Per file cancellati giorni fa, il journal tipicamente ti dà:

• Il nome del file come foglia UTF-16 LE. Solo la foglia, nessun percorso.
• Il numero di riferimento MFT della directory padre. Combinato con un $MFT parsato si risolve in un percorso.
• Il timestamp di cancellazione in FILETIME UTC.
• Il numero e la sequenza di entry MFT che il file occupava. Utile per incrociare artefatti estratti e immagini prima di $LogFile.
• Una traccia di ciclo di vita. I record FileCreate, DataExtend, BasicInfoChange e rename sulla stessa FileReferenceNumber ti dicono quando il file è stato creato, come è stato scritto e se i suoi timestamp sono stati modificati prima della cancellazione.

Una tupla a quattro campi — riferimento MFT, nome del file, riferimento padre, FILETIME di cancellazione — più un evento di creazione da prima nello stesso journal di solito basta per soddisfare un legal hold o ancorare un'indagine più profonda. La maggior parte delle volte ottieni anche il record FileCreate dallo stesso $J, che ti dà l'età del file e un timestamp di creazione indipendente da $STANDARD_INFORMATION.

Un workflow di recupero minimale

Con un journal parsato e un $MFT parsato (vedi la guida all'estrazione per entrambi):

1. Filtra per FileDelete nella finestra temporale di interesse. Ordina per timestamp. Questa è la tua lista master di cancellazioni da triagiare.
2. Raggruppa per FileReferenceNumber per ogni cancellazione che conta. Ottieni la storia completa del file: creazione, scritture, coppie di rename, cambi di attributo e infine la cancellazione.
3. Risolvi il percorso padre via $MFT. Il parser di questa pagina lo fa automaticamente quando entrambi i file sono forniti. Senza $MFT ti fermi al nome foglia.
4. Incrocia $LogFile se la cancellazione è molto recente. Può ancora contenere l'immagine "prima" della voce di directory, dando un secondo testimone indipendente dell'esistenza del file.

La combinazione "riferimento MFT, nome del file, percorso padre, timestamp di creazione, timestamp di cancellazione, traccia completa del ciclo di vita" di solito basta a scrivere un report difendibile.

Quando il percorso padre non può essere risolto

A volte l'entry MFT padre è stata essa stessa riciclata quando guardi — comune su host con filesystem occupato, in particolare file server e runner di CI. Il journal ti dà ancora il nome del file e il numero di riferimento padre, ma $MFT non sa più a quale cartella quel riferimento puntava.

Tre fallback di solito sbloccano il percorso:

Record RenameNewName precedenti sullo stesso riferimento padre. Raggruppa tutti i record del journal per riferimento padre. Qualsiasi RenameNewName precedente il cui padre nuovo corrisponda al tuo riferimento non risolto, e il cui percorso si risolva, ti dice quale cartella era quel riferimento.

Voci di indice di $LogFile. Il log di crash recovery contiene immagini prima degli aggiornamenti di INDEX_ALLOCATION. libfsntfs di Joachim Metz e LogFileParser di Jonas Schicht le estraggono. Su una cancellazione abbastanza recente, l'immagine prima della voce di directory è ancora in $LogFile e si risolve in un percorso.

File fratelli nello stesso riferimento padre. Raggruppa tutti i record del journal per riferimento padre. Se uno dei fratelli è stato rinominato dentro una directory la cui entry MFT è ancora valida, pivotaci attraverso: il vecchio padre al momento del rename è la tua cartella sconosciuta.

Quando nessuno funziona, il parser farà emergere il file come "nome: notes.docx, padre: 1234-5" senza percorso risolto. È intenzionale. Inventare un percorso che non puoi verificare è peggio che ammettere che ne manca uno.

"Cancellato" non significa scomparso

Gli strumenti di shredding di file — secure delete di CCleaner, Eraser, BleachBit, sdelete — sovrascrivono il contenuto del file e poi lo cancellano. Lasciano una traccia journal più rumorosa, non più silenziosa:

• Molteplici record DataOverwrite | Close sul file prima del suo FileDelete | Close indicano sovrascrittura intenzionale di contenuto. La cancellazione normale non produce sovrascritture.
• Un FileCreate più DataOverwrite più FileDelete sullo stesso file in secondi è la firma canonica di distruzione di prove.
• Dove lo shredder ha anche pulito slack space scrivendo e poi cancellando file di riempimento, quei file di riempimento hanno le loro sequenze create/extend/overwrite/delete — uno sciame di record attorno al momento della distruzione.

La mappatura MITRE ATT&CK è T1485 Data Destruction per la sovrascrittura del contenuto e T1070.004 File Deletion per la cancellazione stessa. Su un host dove sospetti distruzione deliberata di prove, il journal spesso ti dà un timestamp più stretto di qualsiasi altro artefatto.

E il contenuto del file

Il USN journal non porta mai contenuto. Solo metadati sulle operazioni. Se ti servono i byte indietro, il journal ti punta ai posti dove guardare:

• Il numero di entry MFT del file cancellato. Se l'entry non è stata riutilizzata, $MFT tiene ancora i data run e il contenuto può essere recuperabile via icat di The Sleuth Kit o X-Ways.
• Le immagini prima di $LogFile per cancellazioni molto recenti.
• Volume Shadow Copy (VSS) se esistono sull'host. Il file cancellato può vivere in uno snapshot precedente. vssadmin list shadows su un host vivo o vshadowmount da libyal su un'immagine li faranno emergere.
• Store specifici dell'applicazione. Il cestino online di OneDrive, la cartella "Autosaved" di Office sotto \Users\<u>\AppData\Roaming\Microsoft\Office\UnsavedFiles\, cache del browser (il tooling di forense del browser copre questo), copie staged Outlook OST/PST.
• Il pagefile e un dump RAM se il file è stato aperto abbastanza di recente.

Il ruolo del journal è dirti che un file è esistito e quando è stato cancellato. Il recupero del contenuto è a valle.

Limiti pratici

Finestra del ring buffer. I file cancellati prima che il journal girasse sopra il record più vecchio che puoi vedere sono spariti da questo artefatto. Tira $LogFile e shadow copy come complementi.

Operazioni che non colpiscono il journal. I cambi di cifratura a livello filesystem che aggiornano solo attributi, le scritture di regioni sparse che toccano solo la mappa di allocazione, e alcune manipolazioni di reparse-point NTFS possono non produrre record DataExtend o DataOverwrite. Il journal vede ciò che NTFS sceglie di loggare.

FileDelete senza FileCreate precedente. Significa che il file è stato creato prima del record corrente più vecchio del journal. Il suo ciclo di vita in $J è parziale, ma il timestamp di cancellazione e il riferimento padre ancorano comunque un report.

Condivisioni bind-mounted o volume-mounted. Se i dati vivono su un filesystem remoto, il journal sul tuo host conosce solo gli handle locali. Tira il journal dal filesystem di hosting effettivo.

Letture aggiuntive

• Microsoft Learn — Change Journals copre la superficie API e il ciclo di vita che produce record FileDelete.
• Le man page di The Sleuth Kit — icat e fls per il recupero del contenuto contro entry MFT ancora allocate.
• SANS DFIR — il poster Windows Forensic Analysis mette il journal in contesto con $LogFile, Volume Shadow Copy e altri artefatti di recupero di cancellazione su una singola pagina.
• libfsntfs di Joachim Metz — il riferimento aperto per l'estrazione di immagini prima di $LogFile quando la cancellazione è fresca e la voce di directory non è ancora stata sovrascritta altrove.