Provare che un file è esistito quando non è più su disco

Gli ingaggi forensi ruotano spesso intorno a una singola domanda: questo file è mai stato su questo computer? Non "è lì ora" (quello è dir). La domanda più difficile: possiamo mostrare che c'era ieri, la scorsa settimana, l'anno scorso? Per volumi NTFS la risposta è solitamente sì, e $MFT è la singola fonte più forte. Spesso anche il contenuto del file torna.

Questa è la visione pratica di ciò che puoi provare dai soli metadati MFT, quale corroborazione aggiungono i journal e i casi in cui affermazioni sicure crollano in revisione.

Cosa sopravvive a una cancellazione

Quando un file viene eliminato su NTFS, il bit IN_USE nell'header del record viene azzerato e la voce di indice della directory padre viene rimossa. Il record stesso resta, contenendo:

$FILE_NAME con il nome file originale e il riferimento al record MFT della directory padre.
Otto timestamp (quattro in $STANDARD_INFORMATION, quattro in $FILE_NAME) congelati al momento dell'eliminazione.
Dimensioni logica e fisica dei dati del file.
Per file piccoli (~700 byte o meno di $DATA), l'intero contenuto del file memorizzato inline nel record. Vedi dati residenti.
Per file più grandi, la runlist dei cluster che contenevano i dati. Quei cluster possono o no contenere ancora i byte originali.
Il numero di sequenza del record, che dimostra che stai guardando il file che viveva in quello slot in quel momento (non un inquilino successivo).

Un record MFT eliminato con $FILE_NAME = secret-plan.docx, riferimento al padre che si risolve in \Users\bob\Documents e SI created 2024-11-03T14:02:11Z dimostra che un file con quel nome è esistito in quella directory quel giorno. Il record è la prova, e la prova è firmata da NTFS stesso nel senso che il driver del filesystem l'ha scritta.

Cosa rende la prova difendibile

Tre proprietà fanno reggere i record MFT in una revisione in cui qualcuno cerca di rompere il tuo caso:

NTFS li scrive da sé, non l'utente. I record non sono modificabili dall'utente tramite le normali API di Windows. Un imputato non può sostenere in modo credibile che un singolo record sia stato piantato a meno che non sostenga che l'intera $MFT sia stata falsificata, il che è un'asticella alta con i controlli incrociati sui journal qui sotto.
Otto timestamp si controllano a vicenda. La manomissione di solito si vede. SI cambiato ma FN invariato è la firma da manuale del timestomping; vedi i quattro timestamp MFT. SI created precedente a FN created è naturalmente impossibile.
$UsnJrnl e $LogFile corroborano. Se $MFT dice che il file è stato creato al tempo T, il journal USN dovrebbe registrare FILE_CREATE allo stesso momento. I disaccordi sono essi stessi prove (di falsificazione o di errore del parser; in ogni caso, vale la pena inseguirle).
Gli snapshot VSS sono indipendenti. Uno snapshot precedente all'eliminazione contiene una copia MFT in cui il file era IN_USE=1. Lo snapshot è stato scritto da VSS a un'ora nota. Due testimoni indipendenti ($MFT viva + $MFT dello snapshot) che mostrano lo stesso file sono molto più forti di uno solo. Vedi Volume Shadow Copy e $MFT.

Quel quarto punto vale la pena soffermarcisi. Nei casi seri cerco sempre gli snapshot VSS. Trasformano una singola osservazione in una serie di osservazioni, ciascuna in un punto diverso del tempo, e sono scritti da un percorso di codice completamente diverso da quello della MFT viva. Difficile falsificare entrambi in modo coerente.

Cosa non puoi provare dalla sola $MFT

La MFT prova che il file è esistito in una particolare directory a un particolare momento, con la particolare dimensione e i timestamp nel record. Non prova:

Chi l'ha creato o vi ha acceduto. Quello richiede log eventi Security (4663 con SACL, Sysmon Event ID 11/15 o 4688 creazione processo con command line se il file è stato nominato su una command line).
Quale programma l'ha prodotto. Prefetch, Amcache e Shimcache aiutano qui. Sysmon Event ID 1 è il gold standard se era abilitato.
Cosa conteneva il file, per file grandi, a meno che non recuperi i cluster di dati. I file residenti ti danno i byte; quelli non residenti richiedono che la runlist dei cluster punti ancora a spazio non allocato e non sovrascritto.
Se un utente l'ha davvero aperto. Le jump list, i file LNK e RecentFileCache sono più utili qui.
Se è stato visto da qualcuno diverso dall'utente proprietario della directory. Ciò richiede log di audit ACL.

Una risposta completa di solito fonde la MFT con gli artefatti circostanti. La MFT è la chiave di volta perché senza di essa gli altri pezzi non hanno nulla a cui ancorarsi. Un hit di Prefetch per secret-tool.exe è interessante; lo stesso hit accoppiato con un record MFT che mostra secret-tool.exe rilasciato in \Temp\ allo stesso minuto da un processo il cui Sysmon Event ID 1 è nella timeline è conclusivo.

Un workflow che regge in revisione

Acquisisci $MFT, $UsnJrnl:$J, $LogFile, tutti gli snapshot VSS. Fai l'hash di tutto (SHA-256). Documenta l'orario di acquisizione.
Parsa la MFT. Trova il record per il file in questione, vivo o eliminato. Tira fuori il numero di sequenza, il riferimento al padre, tutti e otto i timestamp, il $DATA residente se presente, e la runlist dei cluster altrimenti.
Risolvi il riferimento al padre seguendo il record MFT del padre. Ripeti fino a raggiungere il record 5 (la radice). La catena risultante è il percorso della directory. Incrociala con qualsiasi percorso tu abbia dai log o dalle testimonianze.
Incrocia con il journal USN. Per la stessa coppia record/sequenza, elenca ogni voce USN. FILE_CREATE ti dà la creazione originale; FILE_DELETE ti dà l'eliminazione. I motivi nel mezzo sono la storia del file.
Confronta con le MFT degli snapshot VSS. La copia di ogni snapshot dello stesso record ti dà un checkpoint. Se tre snapshot mostrano il record IN_USE=1 con timestamp coerenti e la MFT viva mostra IN_USE=0, hai quattro testimoni indipendenti d'accordo sull'esistenza del file e un testimone per la sua eliminazione.
Documenta le impossibilità che hai escluso. Divergenza SI/FN controllata. Numeri di sequenza coerenti. Timestamp degli snapshot coerenti. La narrazione della difesa deve spiegare tutte queste per minare la tua conclusione.

L'ultimo passo è ciò che separa un risultato da un argomento. Elencare cosa hai controllato e cosa hai escluso rende visibile la catena di ragionamento.

Casi limite che mordono

Hard link. Un file con più hard link vive in più attributi $FILE_NAME. Eliminare un link rimuove solo quel nome; il file resta. Conferma che l'eliminazione che stai tracciando corrisponda davvero al file che sparisce, non a un singolo nome che viene rimosso.

File rinominato prima dell'eliminazione. Alcuni dropper rinominano il loro file di staging in un nome benigno appena prima dell'eliminazione, sperando che il $FILE_NAME superstite suoni innocente. Il journal USN conserva la coppia RENAME_OLD_NAME / RENAME_NEW_NAME. Tirala fuori.

Slot di record riusato. Lo slot di un file eliminato è stato rivendicato da un nuovo file. Il record MFT attuale è il nuovo file alla sequenza N; il journal referenzia il vecchio file alla sequenza N-1. Usa il numero di sequenza per disambiguare. I riferimenti che puntano a una sequenza diversa da quella attuale puntano a un inquilino precedente.

Il file non è mai esistito e qualcuno mente. Meno comune, ma da sapere. La pura contraffazione di metadati è difficile da fare in modo coerente attraverso MFT, USN e VSS, ma un operatore determinato con accesso amministrativo ha strumenti. Cerca incoerenze tra artefatti che dovrebbero concordare.

Letture aggiuntive

Brian Carrier, File System Forensic Analysis. Il capitolo sulla forense NTFS è il riferimento standard per ciò che le prove MFT possono sostenere.
SANS, FOR500: Windows Forensic Analysis. I materiali del corso coprono prove di esistenza precedente basate su MFT con casi svolti.
Harlan Carvey, Investigating Windows Systems. Studi di caso pratici che mostrano il pattern di corroborazione MFT-più-journal.