NTFS offre à l'analyste forensique trois grandes sources de métadonnées, et la façon la plus rapide de perdre une journée, c'est de regarder la mauvaise. Carte rapide :
| Artefact | Ce qu'il enregistre | Étendue temporelle | Granularité | Localisation |
|---|---|---|---|---|
$MFT | L'état courant de chaque fichier et dossier du volume — noms, tailles, timestamps, parents | « Maintenant » + entrées supprimées tant qu'elles n'ont pas été réutilisées | Par fichier | Entrée MFT 0 |
$UsnJrnl:$J | Journal circulaire de chaque création/suppression/renommage/modification | Jours à semaines | Par opération | \$Extend\$UsnJrnl:$J (flux alternatif) |
$LogFile | Journal de transactions utilisé par NTFS pour récupérer après un crash — images avant/après des écritures de métadonnées | Minutes à heures | Par transaction de métadonnées | \$LogFile (entrée MFT 2) |
Cet article donne l'arbre de décision pratique : à une question donnée, quel artefact répond.
$MFT — « ce qui existe, à l'instant T »
La Master File Table est la colonne vertébrale de NTFS. Chaque fichier ou dossier a une entrée (1024 octets en général) contenant un $STANDARD_INFORMATION, un ou plusieurs $FILE_NAME et les data runs. Microsoft documente la structure dans la référence NTFS, et File System Forensic Analysis de Brian Carrier en est le traitement canonique en livre.
À utiliser pour :
- « Qu'y a-t-il sur ce volume ? » — y compris les timestamps de chaque entrée.
- Reconstituer les chemins complets via la chaîne d'entrées MFT parentes (c'est ainsi que notre parseur résout les chemins des enregistrements de journal quand on fournit aussi
$MFT). - Récupérer des fichiers récemment supprimés — tant que l'entrée n'a pas été écrasée, les data runs peuvent rester intacts.
Ne dira pas :
- Ce qui est arrivé à un fichier mardi dernier à 14h32 —
$MFTne porte que les quatre timestamps$STANDARD_INFORMATIONet$FILE_NAME, qui sont un état final, pas un historique.
Outils : MFTECmd d'Eric Zimmerman est le parseur de référence, avec mft (Rust) et analyzeMFT (Python) en alternatives open-source solides.
$UsnJrnl:$J — « ce qui s'est passé, dans quel ordre »
Le journal USN enregistre chaque création, suppression, renommage, troncature, modification d'attribut et fermeture qui survient sur le volume. Pour le contexte, voir notre introduction au format et la référence des codes de raison.
À utiliser pour :
- Reconstituer le cycle de vie d'un fichier, même après suppression.
- Reconstruire des timelines en réponse à incident, surtout les paires
RenameOldName/RenameNewNameet les clusters deDataOverwrite. - Détecter des patterns de ransomware à grande échelle (voir notre article dédié).
Ne dira pas :
- Qui a fait quoi — aucun utilisateur, processus ou ligne de commande. À coupler avec
Security.evtx(event ID4663) ou Sysmon. - Le contenu d'un fichier — seulement qu'il a changé.
- Quoi que ce soit en dehors de la fenêtre du buffer circulaire. Les tailles par défaut vont de ~10 Mo sur un client à 1 Go+ sur un serveur, soit des jours à des semaines d'historique.
Outils : usnrs, PoorBillionaire/USN-Journal-Parser, le parseur de ce site.
$LogFile — « ce que NTFS s'apprêtait à faire »
C'est le journal de métadonnées que NTFS utilise pour la récupération après crash. Il enregistre des images avant/après de chaque écriture de métadonnées — mises à jour d'INDEX_ALLOCATION, modifications d'attributs, réécritures d'entrées MFT. Le format n'est pas documenté mais bien rétro-ingénieré ; le repo libfsntfs de Joachim Metz est la référence ouverte la plus complète.
À utiliser pour :
- Récupérer des fichiers créés et supprimés dans les mêmes minutes —
$LogFilepeut encore contenir l'image « avant » de la suppression, qui contient le nom et le parent. - Repérer une activité anti-forensique qui a touché
$MFTdirectement —$LogFileenregistre l'écriture même si l'état visible paraît propre.
Ne dira pas :
- Quoi que ce soit au-delà des derniers milliers de transactions —
$LogFiletourne vite, parfois en moins d'une heure sur une machine active. - Le contenu d'un fichier. Seules les modifications de métadonnées sont journalisées.
Outils : LogFileParser et les parseurs bâtis sur libfsntfs.
L'arbre de décision
Connaissez-vous le fichier exact ?
├── Oui → État courant ? → $MFT (chemin, timestamps, taille)
│ Historique ? → $UsnJrnl (puis $LogFile pour le très récent)
└── Non → Fenêtre temporelle ?
├── Dernières minutes → $LogFile (la plus granulaire)
├── Derniers jours/semaines → $UsnJrnl (meilleur signal/bruit)
└── Plus ancien → $MFT seulement (les timestamps sont peut-être tout ce qu'il reste)
Faites-vous des corrélations entre fichiers ?
└── $UsnJrnl est le seul avec une timeline triable, par opération.
Les combiner
Les trois artefacts se composent bien :
$MFT+$UsnJrnlest la paire canonique —$MFTfournit l'arbre des dossiers pour la résolution de chemins,$UsnJrnlfournit l'historique des opérations. C'est exactement ce que fait le parseur de cette page quand on dépose les deux fichiers.$LogFileest un filet pour le passé immédiat, particulièrement utile quand$UsnJrnlest trop épars (petit ou désactivé).- Pour le contexte large, ajouter
Security.evtx(events processus/objet), Prefetch (preuve d'exécution) et les ruches du registre — voir le poster SANS Windows Forensic Analysis pour la vue d'ensemble.