Comment extraire $UsnJrnl:$J d'une image disque (ou d'un système en production)

Un guide pratique pour sortir le USN Journal NTFS d'une image forensique, d'un volume monté ou d'un poste Windows vif, avec FTK Imager, X-Ways, The Sleuth Kit, fsutil et PowerShell.

Par 6 min de lecture

Le plus dur quand on travaille avec le USN journal n'est en général pas de le parser. C'est de mettre la main sur le fichier en premier lieu. $UsnJrnl:$J est un flux de données alternatif, pas un fichier régulier, donc il n'apparaît pas dans l'Explorateur, il ne survit pas à un copy naïf, et robocopy te mentira en silence sur le fait de l'avoir extrait. Voici le guide de terrain pour vraiment récupérer les octets du disque, ventilé par les trois endroits où on les rencontre typiquement : une image forensique, un volume monté et une machine vive.

Ce que tu cherches

Le journal vit dans :

\$Extend\$UsnJrnl:$J

$Extend est un répertoire de métadonnées NTFS caché et $J est l'un des deux flux alternatifs sur le fichier de métadonnées $UsnJrnl. L'autre flux est $Max, qui ne contient que la taille maximale configurée du journal et le delta d'allocation — pas d'enregistrements. Si tu carves $Max par erreur tu obtiens quelques octets de config inutiles. Choisis toujours $J.

Microsoft documente le layout dans la référence Change Journals et la référence de structure USN_RECORD_V2. Un $J typique fait de 30 Mo à plusieurs Go selon la configuration de fsutil usn à l'installation. Le défaut sur les clients Windows est d'environ 32 Mo ; les serveurs sont souvent dimensionnés à 1 Go ou plus.

Pendant que tu tires $J, tire aussi $MFT du même volume. Sans elle, le parser ne peut que te montrer des noms feuille — chaque enregistrement est lié à un numéro d'entrée MFT parent, pas à un chemin. Avec les deux fichiers tu as les chemins complets gratuitement.

Depuis une image disque forensique (E01, dd, AFF4)

Le cas le plus courant en DFIR. Choisis l'outil pour lequel tu as déjà une licence.

FTK Imager (gratuit, GUI)

  1. File → Add Evidence Item, ouvre l'image.
  2. Descends dans [root]/$Extend/$UsnJrnl.
  3. Le panneau montre $J et $Max comme lignes frères. Clic droit sur $J et choisis Export Files.

Le détail « ligne frère » est ce que les débutants ratent : il est facile de cliquer droit sur le fichier parent et d'exporter le flux par défaut, qui est vide. Choisis spécifiquement la ligne $J.

X-Ways Forensics (commercial)

Déplie Root directory → $Extend → $UsnJrnl. Le flux $J apparaît dessous. Recover/Copy le sort. Même chemin, même piège que FTK.

The Sleuth Kit (gratuit, CLI, multiplateforme)

Ce vers quoi se tournent la plupart des analystes Mac/Linux. icat de TSK est l'outil standard :

# Trouver l'entrée MFT pour $UsnJrnl
fls -r -p image.dd | grep '\$UsnJrnl'

# Disons qu'il rapporte inode 81 et que le flux $J est l'attribut 128-2 :
icat image.dd 81-128-2 > UsnJrnl-J.bin

Le triplet <inode>-<type>-<id> est la manière dont TSK adresse les flux alternatifs. L'attribut dont le nom se termine par :$J est celui que tu veux ; fls le montre dans sa sortie longue.

Velociraptor et KAPE

Pour la collecte de triage large, le pack d'artefacts Windows.NTFS.MFT de Velociraptor et le KAPE de Kroll tirent le journal automatiquement. KAPE utilise des fichiers target (!ALL ou USNJournal) ; Velociraptor utilise le plugin parse_ntfs. Les deux récupèrent aussi $MFT et $LogFile dans la même passe, ce qui est ce que tu veux vraiment.

Depuis un volume monté

Si l'image est montée en lecture seule via ntfs-3g sur Linux ou Arsenal Image Mounter sur Windows, le chemin de métadonnées apparaît comme un fichier régulier mais la plupart des outils refusent de lire les flux alternatifs de manière transparente.

Sur Linux avec ntfs-3g, le flux est lisible directement :

sudo cat '/mnt/image/$Extend/$UsnJrnl:$J' > UsnJrnl-J.bin

Selon l'option de montage streams_interface, :$J peut apparaître comme un composant de chemin séparé. Vérifie d'abord ls -la /mnt/image/\$Extend/.

Depuis un hôte Windows vif

Il faut les privilèges administratifs et un lecteur NTFS-aware, parce que Windows bloque l'accès ordinaire aux fichiers de métadonnées même depuis des processus administrateur.

RawCopy

La suite d'outils d'Eric Zimmerman inclut RawCopy.exe (et RawCopy64.exe), qui contourne l'API fichier standard :

RawCopy.exe /FileNamePath:"C:\$Extend\$UsnJrnl:$J" /OutputPath:"D:\Out"

C'est ce que KAPE utilise sous le capot quand son target USNJournal tourne.

PowerForensics (PowerShell pur)

Si tu ne peux pas déposer un binaire, PowerForensics lit les structures NTFS brutes en PowerShell pur :

Import-Module PowerForensics
Get-ForensicFileRecord -Path 'C:\$Extend\$UsnJrnl' |
  ForEach-Object { $_.GetContent() } |
  Set-Content -Path 'C:\Out\UsnJrnl-J.bin' -Encoding Byte

fsutil intégré (vérification, pas extraction)

fsutil usn est la surface de contrôle supportée pour le journal mais ce n'est pas un outil d'extraction. Il peut lire, interroger et supprimer des enregistrements, pas streamer le blob $J complet. Ce pour quoi il est utile, c'est de vérifier que le journal est activé et dimensionné avant de tenter l'extraction :

fsutil usn queryjournal C:

Status: 0x00000000 avec une Maximum Size non nulle signifie que le journal est actif. 0x80000005 signifie qu'il est désactivé et qu'il n'y a rien à extraire jusqu'à ce qu'il soit créé via fsutil usn createjournal. Voir la référence fsutil usn pour les commandes de cycle de vie et leurs exigences de privilèges.

Après l'extraction

Une fois le fichier $J en main, dépose-le dans le parser en haut de cette page, ou alimente-le à l'outil offline dans lequel tu as confiance : usnrs, PoorBillionaire/USN-Journal-Parser ou MFTECmd d'Eric Zimmerman (qui parse $J malgré le nom).

Récupère $MFT (entrée 0, même emplacement adjacent à $Extend) en même temps. Avec les deux fichiers fournis, n'importe lequel des parsers ci-dessus remonte la chaîne de référence parent pour résoudre les chemins complets pour chaque enregistrement du journal. Sans $MFT tu lis des noms de fichiers en isolation.

Pendant que tu acquiers les métadonnées NTFS, récupère aussi $LogFile si tu peux. Il est petit, il tourne vite, et sur des incidents où le journal seul ne remonte pas assez loin, $LogFile est le filet de sécurité. Le billet USN journal vs MFT vs LogFile couvre quand chacun gagne sa place.

Pièges courants

Copie Explorateur. Le glisser-déposer de $UsnJrnl copie le flux par défaut sans nom, qui est vide. Tu n'auras pas d'avertissement. Utilise un des outils ci-dessus.

Journal désactivé. Les machines workgroup et les builds agressivement allégés ont parfois le journal coupé. fsutil usn queryjournal est le check pré-vol le moins cher.

Zéros de tête sparse. Le journal est un flux sparse. Les premières centaines de mégaoctets d'un $J fraîchement carved peuvent être tous à zéro avant le premier enregistrement réel. usnrs, le parser de cette page et la plupart des autres sautent automatiquement. Si tu écris un parser à partir de zéro, cherche le premier mot non nul et un RecordLength plausible.

Bouclage du ring buffer. Selon l'activité, le journal peut avoir bouclé — les anciennes entrées sont parties. Le plus petit USN dans le fichier te dit jusqu'où remonte vraiment l'historique du volume. Traite-le comme ton plancher dur.

Récupérer $Max par erreur. Même fichier parent, mais sans enregistrements. Si ton extraction produit un fichier minuscule (quelques octets à quelques Ko), tu as presque certainement pris le mauvais flux.

Lectures complémentaires

  • Microsoft Learn — Change Journals pour la surface API et le cycle de vie.
  • Documentation des outils d'Eric Zimmerman — RawCopy et le reste de la suite couvrent l'acquisition sur hôte vif de bout en bout.
  • Les pages man de fls et icat de The Sleuth Kit — la référence CLI canonique pour l'extraction au niveau image.
  • Documentation KAPE — Kroll publie des fichiers target incluant USNJournal et !BasicCollection ; lire le XML du target est le moyen le plus rapide d'apprendre à quoi ressemble une acquisition de triage soignée.