Retrouver les preuves d'un fichier supprimé avec le journal USN

La question la plus fréquente que reçoivent les analystes forensiques de la part de non-techniques est une variante de « peux-tu prouver que ce fichier a existé ? ». Quand le fichier a été supprimé du disque, la corbeille vidée et qu'assez de temps s'est écoulé pour que l'entrée $MFT soit recyclée, la réponse dépend généralement de ce dont le journal USN se souvient encore.

Cet article passe en revue ce que le journal préserve à propos des fichiers supprimés, comment en extraire les preuves, et les situations dans lesquelles le journal est votre dernier témoin.

Ce que le journal garde après une suppression

Lors d'une suppression sur NTFS, plusieurs choses se passent :

L'entrée $FILE_NAME dans le dossier parent est dé-liée.
L'entrée MFT est marquée libre — mais pas remise à zéro.
Le journal USN reçoit un enregistrement FileDelete | Close nommant le fichier, sa référence parente, son numéro d'entrée MFT, et l'horodatage.

L'enregistrement du journal est le plus résilient des trois. L'entrée de dossier disparaît dès que le parent est réécrit ; l'entrée MFT peut être réutilisée dès qu'un nouveau fichier est créé ; l'enregistrement journal reste dans un buffer circulaire qui ne tourne qu'après des jours ou des semaines d'activité.

Donc, pour des fichiers supprimés il y a plusieurs jours, le journal vous donne souvent :

Le nom du fichier (seulement le nom feuille, pas le chemin complet).
La référence MFT du dossier parent — combinée à un $MFT parsé, vous obtenez le chemin.
L'horodatage de suppression en UTC.
Le numéro d'entrée MFT que le fichier occupait (utile pour recouper des artefacts carvés).
Une trace de cycle de vie : les enregistrements FileCreate, DataExtend, BasicInfoChange avant la suppression vous disent quand le fichier a été créé, comment il a été écrit, et si ses horodatages ont jamais été modifiés.

Un workflow minimal de récupération

Une fois le journal parsé (le parseur de cette page ou usnrs conviennent ; voir le guide d'extraction pour obtenir $J et $MFT) :

Filtrer par FileDelete pour faire ressortir chaque suppression dans la fenêtre. Trier par horodatage.
Pour chaque suppression d'intérêt, grouper par FileReferenceNumber pour voir l'historique complet du fichier — création, écritures, paires de rename, changements d'attributs, et enfin la suppression.
Résoudre le chemin parent via le $MFT. Avec les deux fichiers fournis, notre parseur fait cela automatiquement.
Croiser avec $LogFile si la suppression est très récente — il peut encore contenir l'image « avant » de l'entrée de dossier, vous donnant un second témoin indépendant.

La combinaison « j'ai une référence MFT, un nom de fichier, un parent, un horodatage de création et un horodatage de suppression » suffit généralement à satisfaire une mise sous séquestre ou à ancrer une investigation plus profonde.

Quand le chemin parent ne peut pas être résolu

Parfois, l'entrée MFT parente elle-même a été recyclée le temps que vous regardiez — particulièrement sur les hôtes très actifs. Dans ce cas, le journal vous donne le nom de fichier et la référence parente, mais $MFT ne sait plus à quel dossier ce numéro correspondait.

Trois pistes aident généralement :

Enregistrements RenameNewName antérieurs sur la référence parente — ils peuvent porter un parent résoluble au moment du renommage.
Entrées d'index $LogFile — non documentées mais couvertes par libfsntfs.
Fichiers frères sous la même référence parente — grouper tous les enregistrements journal par parent. Si l'un des frères a été renommé dans un dossier dont l'entrée MFT est encore valide, on peut pivoter par lui.

C'est aussi pour cela que les rapports provisoires de cet outil disent « filename: notes.docx » sans chemin : on préfère ne pas inventer un chemin qu'on ne peut pas vérifier.

« Effacé » ne veut pas dire disparu

Certains outils de destruction de fichiers (CCleaner, Eraser, BleachBit) écrasent le contenu puis suppriment. Ils laissent les mêmes enregistrements journal qu'une suppression normale, plus les enregistrements d'écrasement. Le journal rend donc la « suppression sécurisée » bruyante, pas silencieuse :

Plusieurs DataOverwrite | Close sur le fichier avant son FileDelete | Close indiquent un écrasement intentionnel.
Un FileCreate et un FileDelete du même fichier en quelques secondes, avec des écrasements entre, est le motif canonique.
Si le shredder a aussi nettoyé l'espace libre en écrivant des fichiers temporaires, ces temporaires ont leurs propres séquences create/extend/overwrite/delete — un essaim d'enregistrements autour du moment de la destruction.

La technique MITRE ATT&CK correspondante est T1485 Data Destruction et T1070.004 File Deletion.

Et le contenu du fichier ?

Le journal USN ne porte jamais de contenu — seulement des métadonnées d'opérations. Si vous voulez récupérer des octets, le journal vous oriente vers :

Le numéro d'entrée MFT du fichier supprimé. Si l'entrée n'a pas été réutilisée, le MFT contient encore les data runs et le contenu peut être récupérable via icat de The Sleuth Kit ou X-Ways.
Les images « avant » de $LogFile pour des suppressions très récentes.
Les Volume Shadow Copies (VSS) s'il y en a — le fichier supprimé peut vivre dans un snapshot précédent.
Les stockages applicatifs — corbeille OneDrive, dossier « Récupération automatique » d'Office, caches de navigateur.

Le rôle du journal ici est de dire qu'un fichier a existé et quand il a été supprimé — la suite de la récupération est en aval.

Limites pratiques

Le journal a une fenêtre temporelle. Les fichiers supprimés avant que le buffer circulaire n'ait recouvert l'enregistrement le plus ancien que vous avez ne sont simplement plus dans cet artefact. Tirez $LogFile et les shadow copies en complément.
Certaines opérations ne touchent pas le journal : changements de chiffrement au niveau du système de fichiers, écritures dans des régions sparse qui ne touchent que la carte d'allocation, et manipulations de reparse points NTFS peuvent ne produire aucun enregistrement DataExtend/DataOverwrite.
Un FileDelete sans FileCreate correspondant dans la fenêtre signifie que le fichier a été créé avant l'enregistrement journal le plus ancien — son cycle de vie est partiel, mais l'horodatage de suppression peut quand même être ancré.

Pour le contexte des artefacts au sens large, voir le poster SANS Windows Forensic Analysis et la référence Microsoft Learn change journals.