La prima volta che ho costruito una timeline Windows da $MFT, ho emesso otto righe per record, ordinato per timestamp, aperto in Excel e mi sono sentito come se avessi ricostruito la realtà. Non l'avevo fatto. Avevo un log ordinato di cambiamenti di metadati NTFS. È una cosa utile. Non è, di per sé, un'indagine.
Questo post è ciò che vorrei qualcuno mi avesse detto sul timelining MFT prima che consegnassi il mio primo report.
Cos'è davvero una timeline MFT
Ogni record MFT attivo o eliminato porta otto timestamp che puoi estrarre in modo affidabile: quattro in $STANDARD_INFORMATION (SI) e quattro in $FILE_NAME (FN). Creato, modificato, acceduto e MFT-modificato, in entrambi gli attributi. Percorri la tabella, emetti una riga per ogni timestamp non nullo, ordina per ora, e hai una timeline di quando NTFS ha scritto particolari byte di particolari record. Quello è il pavimento.
Il soffitto è una super-timeline che fonde MFT con il journal USN, $LogFile, Prefetch, Sysmon, Shimcache, Amcache, hive del registro, cronologia del browser e SRUM. La MFT è la spina dorsale perché è la più densa e la più difficile da contraffare completamente per un attaccante. Tutto il resto si allinea ad essa.
Il layout che uso davvero
Dimentica mactime come formato di destinazione. Usalo come intermedio. La forma che regge in tribunale è una riga per evento con provenienza difendibile:
timestamp_utc | source | attribute | mft_record | seq | path | event
2026-05-15T10:23:01.123Z | MFT | SI | 12345 | 3 | /Users/alice/notes.txt | created
2026-05-15T10:23:01.123Z | MFT | FN | 12345 | 3 | /Users/alice/notes.txt | name_created
2026-05-15T10:24:18.456Z | MFT | SI | 12345 | 3 | /Users/alice/notes.txt | modified
2026-05-15T10:24:18.501Z | USN | - | 12345 | 3 | /Users/alice/notes.txt | DATA_OVERWRITE | CLOSE
source e la coppia record/sequenza sono le colonne che gli analisti saltano e poi rimpiangono di aver saltato. Il numero di sequenza è ciò che ti dice se due eventi che condividono un numero di record si riferiscono alla stessa incarnazione di un file o a un predecessore eliminato il cui slot è stato riusato. Senza di esso, la tua timeline li confonde silenziosamente.
L'output CSV di MFTECmd è il layout pronto all'uso più vicino a questo. Fai passare le sue righe attraverso uno script leggero che aggiunge source=MFT ed emette una riga per timestamp, e hai un corpus operativo.
I timestamp in ordine di quanto mentano
SI si muove praticamente a ogni operazione che Windows compie su un file. Le letture aggiornano accessed se a NTFS va (Windows 7+ di default non aggiorna accessed per performance, a meno che fsutil behavior set disablelastaccess 0 non sia impostato). Le scritture aggiornano modified e MFT-modified. I rinomini aggiornano MFT-modified. Il timestomping con SetFileTime aggiorna quello dei quattro che l'attaccante ha mirato.
FN viene aggiornato al rinomino, alla creazione di un hard link e alla creazione iniziale del file. Dopo, FN resta in gran parte fermo. La granularità degli aggiornamenti FN da parte di Windows è anche più grezza; molti file finiscono legittimamente in .0000000 se FN è stato impostato alla creazione e mai più toccato.
In pratica:
- FN creato è il segnale "questo file è apparso per la prima volta in questa directory" più affidabile che hai dalla sola MFT.
- SI creato è il più facile da falsificare. Trattalo come indizio, non come fatto.
- SI modificato è il cavallo da tiro. Combinato con il corrispondente
DATA_OVERWRITEUSN ti dice che i byte del file sono cambiati davvero in quell'istante. - SI acceduto in Windows 7+ è disabilitato di default. Se lo vedi cambiare, o un admin l'ha riabilitato, o il volume è su una SKU Server, o qualcosa sta montando volumi e percorrendo file (software di backup, scansioni AV, introspezione EDR).
La granularità sotto il secondo è il segnale. NTFS memorizza i timestamp in tick da 100 nanosecondi. Le operazioni native di Windows lasciano rumore nelle cifre più basse. Strumenti di timestomping come SetMACE e il famoso timestomp.exe arrotondano al secondo. Una colonna di suffissi .0000000 allineati è un'impronta.
Fusione con il journal USN
La MFT ti mostra il presente e una storia congelata dei metadati. Il journal USN ti mostra i verbi. Accoppiali e una singola riga della tua timeline diventa una frase.
Come fondo: parsa $UsnJrnl:$J separatamente, emetti una riga per record con source=USN, poi ordina il flusso combinato per timestamp. I codici di motivo USN (FILE_CREATE, DATA_OVERWRITE, RENAME_OLD_NAME, RENAME_NEW_NAME, FILE_DELETE, CLOSE) ti danno l'operazione; la MFT fornisce lo stato risultante. Un RENAME_OLD_NAME USN immediatamente seguito da RENAME_NEW_NAME allo stesso USN rivela il rinomino. Senza il journal, un diff MFT tra due snapshot potrebbe dirti che il file è stato spostato; non può dirti l'ordine.
Una trappola: i timestamp USN e quelli MFT SI divergono di millisecondi per lo stesso evento. Non sovra-indicizzare sull'allineamento. Ordina al secondo e usa il codice di motivo USN come tiebreaker.
Cosa rovina le timeline MFT
Acquisizione fuori ordine. Se raccogli MFT e USN a dieci minuti di distanza su un sistema vivo, il journal è andato avanti. Accoppiali dallo stesso istante, idealmente da uno snapshot VSS che hai innescato tu stesso.
Dimenticare l'array fixup. Ogni parser che si rispetti se ne occupa, ma se ne fai uno tuo (per favore non farlo, a meno che tu non stia imparando), leggere blocchi grezzi da 1.024 byte ti dà spazzatura agli offset 510 e 1022 di ogni record. Applica prima i fixup.
Confondere numeri di record attraverso i confini di sequenza. Record 12345 sequenza 3 non è lo stesso file di record 12345 sequenza 5. Lo slot è stato riusato. Se la tua timeline raggruppa solo per numero di record, confonderai un file eliminato con quello che ha preso il suo slot.
Fidarsi di SI sui binari di sistema. Windows Update tocca SI dei file patchati. Un SI modificato su C:\Windows\System32\svchost.exe è quasi sempre un'installazione CBS, non un'intrusione. Incrocia con setupapi.dev.log e CBS.log prima di fare affermazioni.
Trattare la timeline come la conclusione. È l'input dell'analisi. Devi ancora sapere cosa significa ogni evento nel contesto dell'host, dell'utente e del caso.
Un workflow che regge
- Acquisisci
$MFT,$UsnJrnl:$J,$LogFilee le copie disponibili negli snapshot VSS degli stessi. Fai l'hash di tutto (SHA-256) immediatamente. - Parsa MFT e USN con MFTECmd o
mft_dumppiù un parser USN. Verifica che i parser siano girati senza avvertimenti. - Emetti righe normalizzate: una per timestamp per MFT, una per record per USN, con
source,mft_record,seqepathespliciti. - Ordina per timestamp in un unico flusso. Non deduplicare ancora; i quasi duplicati portano segnale.
- Pivota sul periodo di interesse. Estrai una finestra di due ore prima e due ore dopo l'evento sospetto.
- Sovrapponi il resto: Prefetch, Amcache, Sysmon 1/11/15, artefatti LNK e jump list, record
$Idel cestino, SRUM per uso di risorse di rete e di processo. - Cerca ordinamenti impossibili. SI creato prima di FN creato. Un motivo USN
DATA_OVERWRITEsenza un corrispondente cambio SI modificato nella MFT. Due eventiFILE_CREATEallo stesso numero di record con la stessa sequenza (il parser è rotto).
Quell'ultimo passo è dove le timeline MFT guadagnano il loro stipendio. Espongono impossibilità. Ogni impossibilità è o un bug del parser o un artefatto dell'attaccante, ed entrambi vale la pena inseguirli.
Cosa la MFT non può dirti
Non può dirti quale processo ha toccato un file. Non può dirti quale utente. Non può dirti cosa c'era dentro un file più grande di qualche centinaio di byte che è stato eliminato e parzialmente sovrascritto. Per quello servono gli artefatti circostanti: 4688 con audit della command line (o Sysmon 1), la catena dei logon ID del log di sicurezza e, in un buon giorno, un dump RAM che ha colto il processo ancora residente.
La MFT è la spina dorsale. Gli altri artefatti sono i muscoli. Nessuno cammina senza l'altro.
Letture aggiuntive
- Eric Zimmerman, MFTECmd. Il layout CSV canonico e il parser su cui la maggior parte dei team IR si standardizza.
- SANS, Windows Forensic Analysis Poster. Inserisce correttamente gli eventi MFT nella timeline più ampia.
- Harlan Carvey, Investigating Windows Systems. I capitoli sulla costruzione della timeline restano il riferimento pratico.