Analyse d'Artefact : Journal USN ($UsnJrnl)

Note

Résumé exécutif : le journal USN (Update Sequence Number) est une fonctionnalité cachée de NTFS qui enregistre méticuleusement les modifications apportées aux fichiers et répertoires sur un volume. Bien qu’il soit conçu pour permettre aux services de sauvegarde et d’indexation de suivre efficacement les changements du système, il agit pour les analystes DFIR comme un journal d’audit du système de fichiers de bas niveau. Le journal USN fournit la chronologie exacte des actions d’un acteur de la menace, prouvant de manière définitive la création de fichiers, la préparation de données (staging) et, plus important encore, la suppression de fichiers (anti-forensique).

1. Mécanique technique : tracer le changement

Le journal USN n’est pas un journal permanent et infini. Il est conçu pour être efficace et rapide.

Il est stocké sous la forme d’un métafichier NTFS caché nommé $UsnJrnl et se compose principalement de deux flux de données alternatifs (Alternate Data Streams) :

• $Max : contient les métadonnées définissant la taille maximale du journal.
• $J : les enregistrements de journaux réels. Ce flux fonctionne comme un tampon circulaire (circular buffer).

Danger

Limite forensique : en raison de sa nature de tampon circulaire, une fois la taille allouée atteinte, les entrées les plus anciennes sont écrasées par les nouvelles. Par conséquent, le journal USN ne contient que les modifications les plus récentes du système de fichiers. La période qu’il couvre peut aller de quelques jours à quelques semaines, dépendant fortement du niveau d’activité du volume. Une acquisition rapide lors de la réponse à incident est critique.

Chaque fois qu’un fichier est créé, modifié, supprimé ou renommé, une nouvelle entrée est ajoutée au flux $J. Chaque entrée se voit attribuer un numéro de séquence de mise à jour (USN) incrémentiel sur 64 bits.

2. Codes de raison (Reason Codes) : le “quoi” de l’action

Les données forensiques les plus précieuses au sein d’une entrée USN sont les codes de raison (Reason Codes). Chaque entrée est marquée d’un ou plusieurs indicateurs (flags) décrivant la nature exacte de la modification du système de fichiers.

Les codes de raison clés pour les analystes DFIR incluent :

• USN_REASON_FILE_CREATE : un nouveau fichier ou répertoire a été créé.
• USN_REASON_FILE_DELETE : un fichier ou répertoire a été supprimé. (crucial pour détecter l’effacement de charge utile).
• USN_REASON_RENAME_OLD_NAME : un fichier a été renommé (indique le nom d’origine).
• USN_REASON_RENAME_NEW_NAME : un fichier a été renommé (indique le nouveau nom).
• USN_REASON_DATA_OVERWRITE : les données à l’intérieur du fichier ont été écrasées.
• USN_REASON_DATA_EXTEND : des données ont été ajoutées à la fin du fichier.
• USN_REASON_CLOSE : un fichier ouvert pour modification a été fermé. Cela génère l’enregistrement final consolidé pour une interaction de fichier.

3. Scénarios d’investigation DFIR

Le journal USN est un outil phénoménal pour la reconstruction chronologique. Lorsque les artefacts d’exécution standards prouvent qu’une charge utile s’est exécutée, le journal USN révèle ce que cette charge utile a fait sur le disque.

A. Reconstituer la chronologie de l’attaque

En analysant et en triant chronologiquement le flux $J, les analystes peuvent observer le scénario de l’adversaire se dérouler étape par étape. Considérez ce scénario classique de ransomware/exfiltration trouvé dans les journaux :

14:32:05 | FILE_CREATE      | C:\PerfLogs\malware.exe
14:32:06 | FILE_CREATE      | C:\PerfLogs\lib.dll
14:35:10 | DATA_EXTEND      | C:\Users\Admin\Documents\secrets.zip
14:35:12 | RENAME_NEW_NAME  | C:\PerfLogs\data.bin (anciennement secrets.zip)
14:36:00 | FILE_DELETE      | C:\PerfLogs\malware.exe

Analyse : l’attaquant a déposé sa charge utile et ses dépendances, a regroupé des données sensibles dans une archive, a déguisé l’archive en un fichier .bin inoffensif dans PerfLogs, et a finalement supprimé sa charge utile principale pour échapper à une imagerie forensique basique.

B. Prouver la suppression de fichiers

Prouver qu’un fichier a été explicitement supprimé est un défi. Même si l’enregistrement de la Master File Table (MFT) du fichier est effacé ou écrasé, l’entrée USN_REASON_FILE_DELETE dans le journal USN survit (jusqu’à la rotation du tampon), fournissant la preuve définitive que l’attaquant a tenté de détruire des preuves.

C. Corrélation croisée d’artefacts

• Avec Amcache : si vous trouvez un hash de fichier suspect dans l’Amcache, interroger le journal USN pour ce nom de fichier révélera la seconde exacte où il a touché le disque et quand il a été supprimé.
• Avec Prefetch : si le Prefetch indique une exécution à 14:32:05, le journal USN révélera exactement quels fichiers ont été créés ou modifiés par ce processus dans les millisecondes qui ont suivi.

4. Outils et Threat Hunting

Extraire et analyser le flux $J nécessite un accès direct au disque ou une extraction via les clichés instantanés (Volume Shadow Copy - VSS).

MFTECmd (Eric Zimmerman)

parse_usn_journal.cmd

:: MFTECmd analyse à la fois la $MFT et le flux $J du journal USN.
:: Extrayez le fichier $J avec un outil comme KAPE ou FTK Imager, puis analysez :

MFTECmd.exe -f "C:\Forensics\Export\$J" --csv "C:\Forensics\Results" --csvf parsed_usn.csv

Splunk (Chasse aux droppers & suppression)

hunt_usn_rapid_delete.spl

# En supposant que les journaux USN analysés soient ingérés.
# Recherche d'exécutables déposés dans des dossiers suspects et rapidement supprimés (anti-forensique)
index=usn_journal (Reason="*FILE_CREATE*" OR Reason="*FILE_DELETE*")
| search FileName="*.exe" OR FileName="*.dll" OR FileName="*.ps1"
| search ParentPath="*\\PerfLogs\\*" OR ParentPath="*\\Users\\Public\\*" OR ParentPath="*\\Temp\\*"
| transaction FileName ParentPath startswith="*FILE_CREATE*" endswith="*FILE_DELETE*" maxspan=5m
| table _time, FileName, ParentPath, duration
| sort - _time

---

Références et lectures complémentaires

• SANS Institute : Windows Forensic Analysis
• Outils d’Eric Zimmerman : Dépôt GitHub MFTECmd
• Artefact parent : Analyse MFT ($MFT) et Timestomping
• Artefact lié : Analyse d’exécution via Prefetch (.pf)