Le journal USN (Update Sequence Number) de NTFS — souvent appelé simplement $UsnJrnl:$J — est l'un des artefacts les plus sous-estimés de la forensique Windows. Chaque fois que NTFS crée, supprime, renomme ou modifie un fichier sur un volume, il ajoute un enregistrement à ce journal. Les enregistrements sont minuscules (quelques dizaines d'octets chacun) et le journal est géré comme un tampon circulaire de taille fixe : sur une machine active, on conserve typiquement les derniers millions d'opérations fichier.
Où se trouve le journal
Le journal n'est pas un fichier ordinaire. C'est un flux de données alternatif nommé $J, attaché au fichier \$Extend\$UsnJrnl à la racine du volume. Depuis une image forensique, on l'extrait avec un outil capable de lire les flux NTFS (FTK Imager, X-Ways, icat de The Sleuth Kit…). Le blob $J résultant est ce que consomme le parseur WebAssembly de ce site, ou des outils comme usnrs.
Structure d'un enregistrement (USN_RECORD_V2)
Chaque enregistrement est une structure USN_RECORD_V2 :
| Champ | Octets | Signification |
|---|---|---|
| RecordLength | 4 | Taille totale, nom de fichier compris |
| Major / Minor version | 2 + 2 | Actuellement 2.0 |
| FileReferenceNumber | 8 | Entrée MFT + numéro de séquence du fichier |
| ParentFileReferenceNumber | 8 | Entrée MFT + séquence du dossier parent |
| USN | 8 | Position de l'enregistrement dans le journal |
| Timestamp | 8 | FILETIME Windows (tics de 100 ns depuis 1601-01-01) |
| Reason | 4 | Bitmask décrivant ce qui a changé (FileCreate, Close…) |
| SourceInfo | 4 | Indices (ex. DATA_MANAGEMENT pour les changements OS) |
| SecurityId | 4 | Index dans $Secure:$SII |
| FileAttributes | 4 | Attributs NTFS standard |
| FilenameLength / Offset | 2 + 2 | Localisation du nom UTF-16 dans l'enregistrement |
| Filename | n | UTF-16 LE, sans terminateur null |
Le champ « reason » est le plus informatif : c'est un bitmask, et un cycle de vie typique pour un fichier produit une séquence comme FileCreate | DataExtend → DataExtend | Close → BasicInfoChange | Close → FileDelete | Close. Reconstruire cette séquence est ce qui permet de raconter, après coup, ce qui est vraiment arrivé à un fichier.
Pourquoi c'est précieux en DFIR
Deux raisons :
- Survit à la suppression. Même après qu'un fichier a disparu du système (et de la corbeille), son historique d'opérations reste dans le journal jusqu'à ce que le tampon circulaire le recouvre.
- Bon marché à interroger. Un
$Jde 100 Mo contient typiquement des millions d'enregistrements couvrant des jours à des semaines d'activité, et chaque enregistrement est auto-descriptif.
En corrélant le journal avec le $MFT, on peut résoudre des chemins complets pour la majorité des enregistrements — le $MFT fournit la chaîne parente via l'attribut $FILE_NAME de chaque entrée. C'est précisément ce que fait l'option « déposez votre $MFT » sur ce site.
La suite
Si vous n'avez jamais examiné un journal, le plus simple est d'en récupérer un d'une machine de test et de le déposer dans la zone en haut de cette page. Les articles suivants de cette série creuseront les codes de raison, les compromis du carving de journal, et la place du journal dans le paysage des artefacts de timeline Windows ($LogFile, Prefetch, ShimCache).