Analyse forensique du $LogFile NTFS : le guide complet

TL;DR. $LogFile est le journal de reprise après incident de NTFS (entrée MFT 2). Chaque modification que NTFS apporte à ses propres métadonnées — un enregistrement FILE, un index de répertoire, un bitmap — est d'abord journalisée sous forme d'une paire d'opérations : redo (comment l'appliquer) et undo (comment l'annuler). Ces octets contiennent noms de fichiers, dossiers parents, références MFT et horodatages avant/après. C'est donc la meilleure source pour savoir ce qui a changé ces dernières minutes ou heures : créations, suppressions, renommages et déplacements, réécritures de $STANDARD_INFORMATION (timestomping). Il n'a pas d'horloge, il est circulaire et il est très bas niveau. Collectez-le tôt, associez-le au $MFT et corrélez avec $UsnJrnl:$J.

La plupart des analystes arrivent tard au $LogFile : après avoir parsé le journal USN, après la chronologie du $MFT, quand une question reste sans réponse. Cet horodatage a-t-il toujours été en 2019 ? Comment s'appelait ce fichier avant d'être renommé ? Que contenait ce fichier texte supprimé ? Ce guide sert de carte. Chaque section renvoie vers un article détaillé des séries Fondamentaux du $LogFile NTFS et Enquêter avec le $LogFile.

Ce qu'est le $LogFile

NTFS est un système de fichiers récupérable. Il ne journalise pas le contenu des fichiers, mais les métadonnées. La conception repose sur deux couches, bien décrites dans « How the $LogFile works? » sur dfir.ru :

• Le Log File Service (LFS) gère un journal circulaire (« infini »). Il attribue les numéros de séquence de journal (LSN), écrit les enregistrements dans des pages de 4 Kio et tient une zone de redémarrage qui indique où la reprise doit commencer.
• Le client NTFS du LFS écrit les enregistrements proprement dits. Chacun nomme une opération redo et une opération undo et transporte les octets des deux.

Après un plantage, Windows rejoue le côté redo des transactions validées et applique le côté undo des transactions non validées. Pour l'enquêteur, ces mêmes octets répondent à la question : « à quoi ressemblait cette structure juste avant et juste après ce changement ? »

$LogFile est l'enregistrement 2 de la Master File Table, à côté de $MFT (0), $MFTMirr (1) et $Volume (3), comme l'indiquent la présentation des métafichiers NTFS de Microsoft et la documentation de format de libfsntfs. Il se trouve à la racine de chaque volume NTFS (C:\$LogFile, D:\$LogFile…), caché et verrouillé tant que le volume est monté.

Organisation du fichier

Chaque page est protégée par un tableau de séquence de mise à jour, la même protection contre les écritures partielles que pour les enregistrements FILE. La différence de version (1.1 contre 2.0, pages de queue contre pages rapides) compte à partir de Windows 8 ; elle est détaillée dans Format du $LogFile 1.1 et 2.0. La zone de redémarrage et la formule LSN → offset sont expliquées dans Zone de redémarrage et LSN du $LogFile.

Ce que contient un enregistrement

Chaque enregistrement commence par un en-tête LFS de 0x30 octets, suivi des données du client NTFS. Les offsets ci-dessous proviennent du fslog.c du pilote Linux ntfs3 :

Les données client commencent ensuite par l'en-tête d'enregistrement NTFS : opcode redo, opcode undo, offsets et longueurs des octets redo et undo, index de l'attribut cible dans la table des attributs ouverts, VCN cible et offsets qui situent le changement dans un enregistrement MFT ou un tampon d'index. Les opérations redo/undo expliquées passe en revue les opcodes utiles.

Ce qu'il apporte à l'enquêteur

Quatre familles de preuves ressortent des octets redo/undo :

Les petits fichiers ajoutent une cinquième catégorie, opportuniste : un contenu stocké dans l'enregistrement FILE (données résidentes) peut apparaître dans l'image de l'enregistrement ou dans une charge CreateAttribute. C'est un bonus, pas une garantie (voir les limites plus bas).

Les deux cas d'usage qui justifient l'effort :

1. Le timestomping. Un UpdateResidentValue sur $STANDARD_INFORMATION contient la valeur d'avant dans ses octets undo. Une date de création réécrite en 2019 apparaît comme une réécriture, pas seulement comme une valeur étrange. Méthode et faux positifs : Détecter le timestomping avec le $LogFile.
2. Les fichiers éphémères. Un outil déposé, renommé, utilisé puis supprimé en moins d'une heure peut ne laisser aucun enregistrement FILE dans le $MFT (entrée réutilisée) et seulement des codes de raison laconiques dans le journal USN. Le journal peut encore contenir son nom, son parent, ses tailles et ses horodatages. Voir Retrouver les traces de fichiers supprimés.

Sa place à côté du $MFT et de $UsnJrnl

En résumé : le $MFT est l'instantané, le journal USN est l'historique, le $LogFile est la preuve de ce qui a exactement changé. La comparaison complète, avec des scénarios, se trouve dans $LogFile, $UsnJrnl ou $MFT. Pour le parsing USN lui-même, utilisez le parseur de journal USN de la même famille.

L'acquérir

$LogFile ne s'ouvre ni avec l'Explorateur ni avec copy sur un volume monté. Il faut un accès NTFS brut : la cible $LogFile de KAPE, l'accesseur NTFS de Velociraptor, FTK Imager, RawCopy, ou icat de The Sleuth Kit sur une image (icat image.dd 2). Prenez toujours le $MFT du même volume au même moment : le journal désigne les fichiers par leur entrée MFT, et c'est le $MFT qui transforme [MFT #322] en \ProgramData\Intel\m64.exe. Commandes et pièges : Acquérir le $LogFile NTFS.

Le lire

En pratique :

1. Parser le journal en enregistrements bruts (LSN, transaction, opcode redo/undo, cible).
2. Reconstruire les événements du système de fichiers à partir de groupes d'enregistrements.
3. Résoudre les entrées MFT en chemins grâce au $MFT.
4. Dater les événements à partir des horodatages présents dans les données, et signaler ceux qui n'en ont pas.
5. Corréler avec l'USN, le Prefetch, les journaux d'événements.

Le parseur de $LogFile dans le navigateur réalise les étapes 1 à 4 en local (Rust compilé en WebAssembly, rien n'est envoyé) et affiche chaque enregistrement brut à côté des événements qu'il en a tirés. Ses signalements — suppression, renommage, timestomping possible, chemin modifiable par l'utilisateur, exécutable — sont des pistes de tri, pas des verdicts. Une analyse pas à pas sur les données d'exemple figure dans Analyser un $LogFile NTFS pas à pas, et un cas fictif complet dans Étude de cas $LogFile.

Une précision honnête : ce parseur n'a été validé jusqu'ici que sur des journaux synthétiques construits à partir du format publié, pas sur un corpus de journaux Windows réels. Pour tout ce qui finit dans un rapport, confirmez avec un second outil ; les options sont comparées dans Comparatif des parseurs de $LogFile.

Ses limites

• Une rétention courte. Le journal est circulaire. Sur un volume système chargé, comptez de quelques minutes à quelques heures ; dans les tests de dfir.ru sous Windows 10, les anciennes données ont été écrasées au bout de 16 minutes dans un cas et de 5 h 20 dans un autre.
• Pas d'horloge. Les enregistrements portent des LSN, pas des heures. Les heures viennent des valeurs $FILE_NAME / $STANDARD_INFORMATION contenues dans les données.
• Métadonnées uniquement. Le contenu non résident des fichiers ne passe jamais par le journal.
• Les noms ne sont pas toujours là. Un enregistrement ne désigne souvent qu'une entrée MFT ; le nom apparaît quand le fichier est créé, renommé ou supprimé, ou via le $MFT.

Détails et parades : Jusqu'où remonte le $LogFile ?

Questions fréquentes

Qu'est-ce que le $LogFile NTFS ?

C'est le journal de transactions des métadonnées NTFS, stocké dans l'entrée MFT 2 à la racine de chaque volume NTFS. Avant de modifier ses propres métadonnées, NTFS écrit un enregistrement décrivant le changement sous forme d'une opération redo et d'une opération undo, pour pouvoir réparer le volume après un plantage.

Le $LogFile contient-il des horodatages ?

Les enregistrements du journal n'ont pas d'horloge propre. Les heures viennent des données journalisées : les valeurs $STANDARD_INFORMATION et $FILE_NAME présentes dans les octets redo et undo. Un événement sans ces valeurs ne peut être situé que par rapport à ses voisins, via le LSN.

Jusqu'où remonte le $LogFile ?

Il est circulaire et fait généralement environ 64 Mio : il couvre de quelques minutes à quelques heures d'activité sur un volume système chargé, davantage sur un volume de données peu actif. Dans un test publié sous Windows 10, les anciennes données ont été écrasées au bout de 16 minutes, dans un autre au bout de 5 h 20.

Pour aller plus loin

• Maxim Suhanov, How the $LogFile works? — la meilleure description publique du fonctionnement interne du LFS.
• Noyau Linux, fs/ntfs3/fslog.c — une implémentation fonctionnelle du rejeu du journal, avec les offsets des structures.
• libyal, documentation NTFS de libfsntfs.
• Joakim Schicht, LogFileParser — le décodeur open source de référence, avec un readme détaillé.
• Gyu-Sang Cho, A computer forensic method for detecting timestamp forgery in NTFS, Computers & Security 34 (2013).

Articles liés

• $LogFile, $UsnJrnl ou $MFT : quel artefact NTFS, et quand
• Acquérir le $LogFile NTFS
• Détecter le timestomping avec le $LogFile NTFS