NTFS donne à un analyste forensique trois gros artefacts de métadonnées, et la façon la plus sûre de perdre une journée est de lire le mauvais pour la question que tu as réellement. La version courte :
| Artefact | Ce qu'il enregistre | Plage temporelle | Granularité | Vit à |
|---|---|---|---|---|
$MFT | État actuel de chaque fichier et répertoire — nom, taille, timestamps, parent | « Maintenant » plus les entrées récemment supprimées | Par fichier | Entrée MFT 0 |
$UsnJrnl:$J | Log circulaire de chaque création/suppression/renommage/modification de fichier | Jours à semaines | Par opération | \$Extend\$UsnJrnl:$J (flux de données alternatif) |
$LogFile | Log de transactions que NTFS utilise pour la récupération de crash — images avant/après brutes des écritures de métadonnées | Minutes à heures | Par transaction de métadonnées | \$LogFile (entrée MFT 2) |
Continue pour l'arbre de décision que j'utilise vraiment, et les raisons pour lesquelles chaque artefact te laissera tomber tout seul.
$MFT — « ce qui existe, là maintenant »
La Master File Table est l'épine dorsale de NTFS. Chaque fichier ou répertoire a au moins une entrée de 1024 octets contenant $STANDARD_INFORMATION, un ou plusieurs attributs $FILE_NAME, et les data runs qui pointent vers le contenu réel.
Sors $MFT quand la question est :
- Qu'est-ce qui existe sur ce volume là maintenant, y compris les entrées récemment supprimées avant qu'elles ne soient réutilisées.
- Quels sont les quatre timestamps NTFS (M/A/C/B dans
$STANDARD_INFORMATIONcomme dans$FILE_NAME) pour un fichier spécifique. - Puis-je récupérer les octets d'un fichier supprimé dont l'entrée est encore allouée.
- Quel est le chemin complet d'un enregistrement qui ne porte qu'un numéro de référence parent — c'est exactement comme ça que le parser de cette page résout les enregistrements USN quand tu déposes aussi
$MFT.
Ce qu'il ne te dira pas, peu importe comment tu plisses les yeux :
- Ce qui est arrivé à un fichier mardi dernier à 14:32. Les quatre timestamps sont un état final, pas un historique. Ils te disent quand le fichier a été créé et touché en dernier. Ils ne te disent pas qu'il a été renommé, puis re-renommé, puis tronqué, puis écrasé, puis supprimé, puis qu'un nouveau fichier a été créé sur la même entrée MFT.
Outillage : MFTECmd d'Eric Zimmerman est le parser de fait. La crate Rust mft d'Omer BenAmram et le script Python analyzeMFT de David Kovar couvrent le côté open source.
$UsnJrnl:$J — « ce qui est arrivé, dans quel ordre »
Le Update Sequence Number Journal enregistre chaque création, suppression, renommage, troncature, changement d'attribut et fermeture qui arrive sur le volume. Pour le contexte, le billet d'introduction couvre le format sur disque et le billet sur les Reason codes est la référence de champ au niveau bit.
Sors-le quand la question est :
- Quel a été le cycle de vie de ce fichier, renommages inclus, avant qu'il ne soit supprimé.
- Quelque chose a-t-il chiffré en masse des fichiers sur ce volume — voir détection ransomware.
- Quelque chose a-t-il staged et archivé en masse des fichiers pour exfiltration — voir détection exfiltration.
- Les timestamps ont-ils été altérés — voir timestomping.
- Que faisait l'utilisateur entre 14:00 et 16:00 — voir reconstruction de timeline d'activité.
Ce qu'il ne te dira pas :
- Qui a fait quoi que ce soit. Pas d'utilisateur, pas de processus, pas de ligne de commande. Corrèle avec Security.evtx
4663(uniquement si les SACL ont été configurées) ou Sysmon événement 11. - Le contenu d'aucun fichier. Le journal enregistre qu'un flux a changé, pas quels octets étaient là avant.
- Quoi que ce soit de plus ancien que la fenêtre du ring buffer. Les défauts vont de ~10 Mo sur un client allégé à 1 Go+ sur un serveur correctement dimensionné, ce qui se traduit en jours ou semaines d'historique.
Outillage : usnrs d'Airbus CERT, USN-Journal-Parser de PoorBillionaire, MFTECmd d'Eric Zimmerman (qui parse aussi $J), et le parser WebAssembly de cette page.
$LogFile — « ce que NTFS s'apprêtait à faire »
C'est le journal de métadonnées que NTFS utilise pour la récupération de crash. Il enregistre des images avant/après de chaque écriture de métadonnées — mises à jour INDEX_ALLOCATION, changements d'attribut, réécritures d'entrées MFT. Le format n'est pas documenté mais bien rétro-ingéniéré ; libfsntfs de Joachim Metz est la référence ouverte la plus complète.
Sors-le quand :
- Un fichier a été créé et supprimé dans les mêmes quelques milliers de transactions et l'entrée de répertoire du parent a déjà été écrasée.
$LogFilepeut encore tenir l'image « avant » avec le nom feuille et le parent. - Tu suspectes une manipulation directe de
$MFT.$LogFileenregistre l'écriture brute même quand l'état visible a l'air propre ensuite. - Le journal est trop épars (petit ou récemment tourné) pour couvrir le moment d'intérêt, mais ça s'est passé dans la dernière heure.
Ce qu'il ne te donnera pas :
- Quoi que ce soit hors de la fenêtre de rotation.
$LogFileest petit et fortement réutilisé. Sur un file server chargé tout l'historique de transactions peut rouler en moins d'une heure. - Le contenu des fichiers. Les images avant/après sont uniquement des métadonnées.
Outillage : LogFileParser de Jonas Schicht et n'importe quel parser bâti sur libfsntfs.
L'arbre de décision que j'utilise vraiment
Sais-tu QUEL fichier ?
├── Oui → Veux l'état actuel ? → $MFT (chemin, timestamps, taille)
│ Veux l'historique ? → $UsnJrnl d'abord, $LogFile pour le passé très récent
└── Non → Fenêtre temporelle ?
├── Dernières minutes → $LogFile (le plus granulaire)
├── Derniers jours/sem → $UsnJrnl (meilleur signal/bruit)
└── Il y a longtemps → $MFT seul, attends-toi à te contenter de timestamps d'état final
Tu corrèles à travers de nombreux fichiers à la fois ?
└── $UsnJrnl est le seul des trois avec une timeline triable, par opération.
Le fichier a été supprimé et il te faut prouver qu'il a existé ?
└── $UsnJrnl d'abord (l'enregistrement FileDelete porte la référence parent et le timestamp)
$LogFile en filet de sécurité si la suppression est fraîche
$MFT uniquement si l'entrée n'a pas encore été réutilisée
Les combiner est là où le vrai travail se fait
Les trois artefacts se composent bien, ce qui est la partie que personne ne souligne tant qu'on n'en a pas besoin.
$MFT + $UsnJrnl est le couple canonique. La MFT fournit l'arbre des répertoires pour la résolution de chemin ; le journal fournit l'historique des opérations. Le parser de cette page résout automatiquement les chemins complets pour chaque enregistrement du journal quand tu déposes les deux fichiers. Acquiers-les ensemble ; tu t'épargneras un aller-retour neuf fois sur dix.
$LogFile est le filet de sécurité. Quand le journal est trop petit pour couvrir le moment d'intérêt, ou quand tu suspectes une altération directe de la MFT, $LogFile est ce vers quoi tu te tournes.
Pour un contexte plus large, apparie les trois artefacts NTFS avec EVTX (événements processus et objet), Prefetch et AmCache (preuves d'exécution), Shimcache (programme-a-tourné-à-un-moment), hives de registre, fichiers LNK et jump lists pour des preuves de fichiers ouverts par l'utilisateur, historique navigateur, SRUM pour l'usage des ressources, et le RecentFileCache.
Lectures complémentaires
- Microsoft Learn — Master File Table et Change Journals.
- Brian Carrier, File System Forensic Analysis — toujours la référence de longueur de livre sur les internes NTFS.
- Joachim Metz, documentation de
libfsntfs— la référence ouverte la plus détaillée sur les internes$LogFile. - SANS DFIR — le Windows Forensic Analysis poster est une seule page plastifiée qui met la pile d'artefacts en un seul endroit.