NTFS dà a un analista forense tre grossi artefatti di metadati, e il modo più sicuro di perdere una giornata è leggere quello sbagliato per la domanda che si ha davvero. La versione breve:
| Artefatto | Cosa registra | Periodo | Granularità | Vive in |
|---|---|---|---|---|
$MFT | Stato attuale di ogni file e directory: nome, dimensione, timestamp, padre | "Adesso" più le entry recentemente cancellate | Per file | Entry MFT 0 |
$UsnJrnl:$J | Log circolare di ogni creazione/cancellazione/rinomina/modifica di file | Giorni a settimane | Per operazione | \$Extend\$UsnJrnl:$J (flusso di dati alternativo) |
$LogFile | Log delle transazioni che NTFS usa per la crash recovery: immagini grezze prima/dopo delle scritture di metadati | Minuti a ore | Per transazione di metadati | \$LogFile (entry MFT 2) |
Continua per l'albero decisionale che uso davvero, e i motivi per cui ogni artefatto ti lascerà in panne da solo.
$MFT — "cosa esiste, adesso"
La Master File Table è la spina dorsale di NTFS. Ogni file o directory ha almeno una entry da 1024 byte che contiene $STANDARD_INFORMATION, uno o più attributi $FILE_NAME e i data run che puntano al contenuto reale.
Vai a $MFT quando la domanda è:
- Cosa esiste su questo volume adesso, comprese alcune entry recentemente cancellate prima che vengano riutilizzate.
- Quali sono i quattro timestamp NTFS (M/A/C/B sia in
$STANDARD_INFORMATIONsia in$FILE_NAME) per un file specifico. - Posso recuperare i byte di un file cancellato la cui entry è ancora allocata.
- Qual è il percorso completo di un record che porta solo un numero di riferimento padre — esattamente come il parser di questa pagina risolve i record USN quando rilasci anche
$MFT.
Cosa non ti dirà, per quanto strizzi gli occhi:
- Cosa è successo a un file martedì scorso alle 14:32. I quattro timestamp sono uno stato finale, non una storia. Ti dicono quando il file è stato creato e toccato per ultimo. Non ti dicono che è stato rinominato, poi ri-rinominato, poi troncato, poi sovrascritto, poi cancellato, poi un nuovo file è stato creato sulla stessa entry MFT.
Tooling: MFTECmd di Eric Zimmerman è il parser de facto. La crate Rust mft di Omer BenAmram e lo script Python analyzeMFT di David Kovar coprono il lato open source.
$UsnJrnl:$J — "cosa è successo, in che ordine"
Il Update Sequence Number Journal registra ogni creazione, cancellazione, rinomina, troncamento, cambio di attributo e chiusura che accade sul volume. Per il contesto, il post introduttivo copre il formato su disco e il post sui Reason code è il riferimento di campo a livello di bit.
Vai a esso quando la domanda è:
- Qual è stato il ciclo di vita di questo file, incluse le rinomine, prima che venisse cancellato.
- Qualcosa ha cifrato in massa file su questo volume — vedi rilevamento ransomware.
- Qualcosa ha messo in staging e archiviato in massa file per l'esfiltrazione — vedi rilevamento esfiltrazione.
- I timestamp sono stati manomessi — vedi timestomping.
- Cosa stava facendo l'utente tra le 14:00 e le 16:00 — vedi ricostruzione di timeline di attività.
Cosa non ti dirà:
- Chi ha fatto cosa. Nessun utente, nessun processo, nessuna riga di comando. Correla con Security.evtx
4663(solo se le SACL sono state configurate) o evento 11 di Sysmon. - Il contenuto di nessun file. Il journal registra che uno stream è cambiato, non quali byte c'erano prima.
- Qualsiasi cosa più vecchia della finestra del ring buffer. I default vanno da ~10 MB su un client snellito a 1 GB+ su un server ben dimensionato, traducendosi in giorni o settimane di storia.
Tooling: usnrs di Airbus CERT, USN-Journal-Parser di PoorBillionaire, MFTECmd di Eric Zimmerman (che parsa anche $J), e il parser WebAssembly di questa pagina.
$LogFile — "cosa NTFS stava per fare"
Questo è il journal di metadati che NTFS usa per la crash recovery. Registra immagini prima/dopo di ogni scrittura di metadati: aggiornamenti INDEX_ALLOCATION, cambi di attributo, riscritture di entry MFT. Il formato non è documentato ma è stato ben reverse-engineered; libfsntfs di Joachim Metz è il riferimento aperto più approfondito.
Vai a esso quando:
- Un file è stato creato e cancellato nelle stesse poche migliaia di transazioni e la voce di directory del padre è già stata sovrascritta.
$LogFilepuò ancora avere l'immagine "prima" con il nome foglia e il padre. - Sospetti manipolazione diretta di
$MFT.$LogFileregistra la scrittura grezza anche quando lo stato visibile sembra pulito dopo. - Il journal è troppo scarno (piccolo o ruotato di recente) per coprire il momento di interesse, ma è successo nell'ultima ora.
Cosa non ti darà:
- Qualsiasi cosa fuori dalla finestra di rotazione.
$LogFileè piccolo e pesantemente riusato. Su un file server attivo tutta la storia delle transazioni può girare in meno di un'ora. - Contenuto dei file. Le immagini prima/dopo sono solo metadati.
Tooling: LogFileParser di Jonas Schicht e qualsiasi parser basato su libfsntfs.
L'albero decisionale che uso davvero
Sai QUALE file?
├── Sì → Vuoi lo stato attuale? → $MFT (percorso, timestamp, dimensione)
│ Vuoi la storia? → $UsnJrnl prima, $LogFile per il passato molto recente
└── No → Finestra temporale?
├── Ultimi minuti → $LogFile (il più granulare)
├── Ultimi giorni/settimane → $UsnJrnl (miglior rapporto segnale/rumore)
└── Tanto tempo fa → Solo $MFT, aspettati di accontentarti dei timestamp di stato finale
Stai correlando attraverso molti file in una volta?
└── $UsnJrnl è l'unico dei tre con una timeline ordinabile, per-operazione.
Il file è stato cancellato e devi provare che esisteva?
└── $UsnJrnl prima (il record FileDelete porta il riferimento al padre e il timestamp)
$LogFile come rete di sicurezza se la cancellazione è fresca
$MFT solo se l'entry non è ancora stata riutilizzata
Combinarli è dove avviene il vero lavoro
I tre artefatti si compongono bene, che è la parte che nessuno sottolinea finché non ne ha bisogno.
$MFT + $UsnJrnl è la coppia canonica. La MFT fornisce l'albero delle directory per la risoluzione dei percorsi; il journal fornisce la storia delle operazioni. Il parser di questa pagina risolve automaticamente i percorsi completi per ogni record del journal quando rilasci entrambi i file. Acquisiscili insieme; ti risparmierai un round trip nove volte su dieci.
$LogFile è la rete di sicurezza. Quando il journal è troppo piccolo per coprire il momento di interesse, o quando sospetti manomissione diretta di MFT, $LogFile è dove ricorri.
Per un contesto più ampio, abbina i tre artefatti NTFS con EVTX (eventi processo e oggetto), Prefetch e AmCache (prove di esecuzione), Shimcache (programma-girato-in-qualche-momento), hive del registro, file LNK e jump list per prove di file aperti dall'utente, storia del browser, SRUM per l'uso delle risorse, e il RecentFileCache.
Letture aggiuntive
- Microsoft Learn — Master File Table e Change Journals.
- Brian Carrier, File System Forensic Analysis — sempre il riferimento di lunghezza-libro sugli interni NTFS.
- Joachim Metz, documentazione di
libfsntfs— il riferimento aperto più dettagliato sugli interni di$LogFile. - SANS DFIR — il Windows Forensic Analysis poster è una singola pagina plastificata che mette lo stack di artefatti in un posto solo.