← Torna al blog

Journal USN vs $MFT vs $LogFile: quale artefatto NTFS per quale domanda?

Riferimento comparativo dei tre artefatti di metadati NTFS che ogni indagine forense Windows finisce per toccare — cosa registra ciascuno, cosa non registra, e quando ricorrere a quale.

4 min di lettura

NTFS offre all'analista forense tre grandi sorgenti di metadati, e il modo più rapido di perdere una giornata è leggere quella sbagliata. Mappa rapida:

ArtefattoCosa registraFinestra temporaleGranularitàPosizione
$MFTLo stato corrente di ogni file e directory del volume — nomi, dimensioni, timestamp, padre"Ora" più le entry cancellate finché non vengono riusatePer fileEntry MFT 0
$UsnJrnl:$JLog circolare di ogni creazione/cancellazione/rinomina/modificaGiorni-settimanePer operazione\$Extend\$UsnJrnl:$J (flusso alternativo)
$LogFileLog transazionale che NTFS usa per recuperare da un crash — immagini prima/dopo delle scritture di metadatiMinuti-orePer transazione di metadati\$LogFile (entry MFT 2)

Questo articolo dà l'albero decisionale pratico: data una domanda, quale artefatto risponde.

$MFT — "cosa esiste, in questo istante"

La Master File Table è la spina dorsale di NTFS. Ogni file o directory ha una entry (tipicamente 1024 byte), contenente $STANDARD_INFORMATION, uno o più $FILE_NAME e i data run. Microsoft documenta la struttura nella reference NTFS, e File System Forensic Analysis di Brian Carrier è il trattamento canonico in formato libro.

Usalo per:

  • "Cosa c'è su questo volume?" — inclusi timestamp per ogni entry.
  • Ricostruire percorsi completi dalla catena di entry MFT padri (è così che il nostro parser risolve i percorsi dei record di journal quando fornisci anche $MFT).
  • Recuperare file recentemente cancellati — finché la entry non è stata sovrascritta, i data run possono essere intatti.

Non ti dirà:

  • Cosa è successo a un file martedì scorso alle 14:32 — $MFT porta solo i quattro timestamp $STANDARD_INFORMATION e $FILE_NAME, che sono uno stato finale, non uno storico.

Strumenti: MFTECmd di Eric Zimmerman è il parser di fatto, con mft (Rust) e analyzeMFT (Python) come solide alternative open source.

$UsnJrnl:$J — "cosa è successo, in quale ordine"

Il journal Update Sequence Number registra ogni creazione, cancellazione, rinomina, troncamento, cambio attributo e chiusura che avviene sul volume. Per il contesto, vedi la nostra introduzione al formato e il riferimento dei codici di razionale.

Usalo per:

  • Ricostruire il ciclo di vita di un file anche dopo la cancellazione.
  • Ricostruzione di timeline nella risposta a incidenti, soprattutto coppie RenameOldName/RenameNewName e cluster di DataOverwrite.
  • Rilevare pattern di ransomware su scala (vedi il nostro articolo dedicato).

Non ti dirà:

  • Chi ha fatto cosa — nessun utente, processo o riga di comando. Da accoppiare con Security.evtx (event ID 4663) o con Sysmon.
  • Il contenuto di alcun file — solo che è cambiato.
  • Nulla al di fuori della finestra del ring buffer. Le dimensioni di default vanno da ~10 MB su client a 1 GB+ su server, ovvero giorni-settimane di storico.

Strumenti: usnrs, PoorBillionaire/USN-Journal-Parser, il parser di questo sito.

$LogFile — "cosa NTFS stava per fare"

È il log di metadati che NTFS usa per il crash recovery. Registra immagini prima/dopo di ogni scrittura di metadati — aggiornamenti di INDEX_ALLOCATION, modifiche di attributi, riscritture di entry MFT. Il formato non è documentato ma è ben reingegnerizzato; il repo libfsntfs di Joachim Metz è la reference aperta più completa.

Usalo per:

  • Recuperare file creati e cancellati negli stessi minuti — $LogFile può avere ancora l'immagine "prima" della cancellazione, che contiene nome e padre.
  • Cogliere attività anti-forense che ha toccato $MFT direttamente — $LogFile registra la scrittura anche se lo stato visibile sembra pulito.

Non ti dirà:

  • Nulla oltre le ultime migliaia di transazioni — $LogFile ruota molto, talvolta entro un'ora su una macchina attiva.
  • Il contenuto dei file. Solo i cambiamenti di metadati sono loggati.

Strumenti: LogFileParser e i parser costruiti su libfsntfs.

L'albero decisionale

Conosci il file esatto?
├── Sì  → Stato corrente? → $MFT (percorso, timestamp, dimensione)
│         Storia?          → $UsnJrnl (poi $LogFile per il molto recente)
└── No  → Finestra temporale?
          ├── Ultimi minuti      → $LogFile (la più granulare)
          ├── Giorni-settimane   → $UsnJrnl (miglior rapporto segnale/rumore)
          └── Più indietro       → solo $MFT (i timestamp possono essere tutto ciò che rimane)

Stai correlando tra file?
└── $UsnJrnl è l'unico con una timeline ordinabile, per operazione.

Combinarli

I tre artefatti si compongono bene:

  1. $MFT + $UsnJrnl è la coppia canonica — $MFT fornisce l'albero delle directory per la risoluzione dei percorsi, $UsnJrnl fornisce lo storico delle operazioni. È esattamente quello che fa il parser di questa pagina quando depositi entrambi i file.
  2. $LogFile è una rete di sicurezza per il passato molto recente, particolarmente utile quando $UsnJrnl è troppo sparso (piccolo o disabilitato).
  3. Per un contesto più ampio, aggiungi Security.evtx (eventi processo/oggetto), Prefetch (prova di esecuzione) e le hive del registro — vedi il poster SANS Windows Forensic Analysis per la visione d'insieme.