Le USN journal peut-il me montrer quels documents Word un utilisateur a ouverts ?

Oui, avec une astuce simple : filtre sur les enregistrements FileCreate dont le nom de fichier commence par ~$. Office crée un fichier de verrouillage ~$ .docx au moment où un document est ouvert et le supprime à la fermeture — cette paire te donne la fenêtre précise d'ouverture/fermeture. Soustrais FileDelete du même nom pour trouver les documents encore ouverts au moment de l'acquisition.

Comment savoir depuis $UsnJrnl si un utilisateur naviguait sur le web ?

Les caches de navigateur génèrent un taux bas soutenu d'événements FileCreate | Close et DataExtend | Close sous \Users\ \AppData\Local\ \User Data\Default\Cache\Cache_Data\ (Chrome/Edge) ou \Users\ \AppData\Local\Mozilla\Firefox\Profiles\ \cache2\ (Firefox). La cadence d'écritures cache corrèle bien avec la navigation active ; les noms de fichier n'encodent pas les URLs mais le rythme si.

À quoi ressemblent les téléchargements dans le USN journal ?

Un téléchargement direct depuis Chrome produit FileCreate d'un fichier .crdownload dans Downloads\, puis un flux d'enregistrements DataExtend, puis un RenameNewName vers le nom final, puis BasicInfoChange. Firefox utilise .part, Edge utilise .download. Le rename atomique à la fin fait apparaître le fichier comme 'complet' à l'Explorateur.

Puis-je distinguer l'activité utilisateur des tâches en arrière-plan dans $UsnJrnl ?

Oui, avec un petit ensemble de filtres. Restreins les enregistrements aux chemins sous \Users\ \ pour enlever le bruit système. Exclus les daemons connus qui écrivent du cache (SearchIndexer, OneDrive, Dropbox, Chrome Software Reporter) par chemin. Les rafales de sauvegarde et AV sont à l'échelle du volume et suivent des horaires programmés ; les rafales utilisateur ciblent des sous-arbres spécifiques. Après ces exclusions, l'activité restante est presque entièrement pilotée par l'utilisateur.

Que ne puis-je pas reconstruire à partir de $UsnJrnl seul ?

L'identité utilisateur (aucun utilisateur ou processus n'est tagué sur un enregistrement — corrèle avec les logons 4624 de Security.evtx), les URLs visitées (les bases d'historique du navigateur les contiennent), le contenu d'un fichier (seules les métadonnées sont loguées), et tout ce qui dépasse la fenêtre du ring buffer. Pour 80 % des questions « que faisait l'utilisateur entre X et Y », le journal répond directement ; les 20 % restants ont besoin de Sysmon, event logs ou d'une super-timeline complète.

Reconstruire une timeline d'activité utilisateur depuis le USN journal

Une grande partie de « que se passait-il sur cet ordinateur entre 14:00 et 16:00 » peut être répondue directement depuis le USN journal, sans aucun autre artefact. Les enregistrements ne sont pas un log de syscalls et ne sont pas tagués avec un utilisateur, mais ils sont quelque chose presque aussi utile : un enregistrement à haute fréquence, par opération, de chaque fichier que la machine a touché. Avec une connaissance des motifs qui prend quelques engagements à bâtir, tu peux récupérer le comportement à la granularité d'un save Office, d'une navigation navigateur, d'un rebuild d'IDE, d'une pause déjeuner.

Ce billet est le guide de terrain pour lire le journal comme une timeline de comportement.

Pourquoi ça marche du tout

La plupart des actions visibles à l'utilisateur sur un poste Windows produisent une signature reconnaissable dans le système de fichiers. Clique Save dans Word et Word écrit un fichier temp, le renomme atomiquement, et fait BasicInfoChange | Close sur le résultat. Ouvre un nouvel onglet dans Chrome et le cache disque s'ajoute. Lance un npm install et mille fichiers package.json poussent en quelques secondes.

Ces signatures ne sont documentées dans aucune référence Microsoft. Elles s'apprennent en regardant des journals d'hôtes d'expériences contrôlées et en les matchant à une activité connue. En dessous il y a un set de départ, ordonné par la fréquence à laquelle je vois chacun en cas.

Office en milieu naturel

Quand un utilisateur sauve un fichier Word, Excel ou PowerPoint tu vois :

FileCreate | Close            ~$<filename>.docx     (fichier de verrouillage)
FileCreate | Close            <filename>.tmp        (temp atomique)
DataExtend | Close            <filename>.tmp        × N
RenameOldName | Close         <filename>.docx
FileDelete | Close            <filename>.docx
RenameNewName | Close         <filename>.docx       (était <filename>.tmp)
FileDelete | Close            ~$<filename>.docx
BasicInfoChange | Close       <filename>.docx

Le fichier de verrouillage ~$ est le signal d'Office qu'un document est ouvert. Son FileCreate et FileDelete encadrent la fenêtre d'ouverture/fermeture précisément. Le rename atomique .tmp vers .docx est le save lui-même. Le BasicInfoChange à la fin est le nouveau fichier qui se fait timestamper sa mtime à la fermeture.

Une astuce de pivot que j'utilise sur chaque engagement : filtre sur les enregistrements FileCreate dont le nom commence par ~$. Ça te donne chaque document Office que l'utilisateur a ouvert dans la fenêtre. Soustrais FileDelete des mêmes noms et tu as tout document encore ouvert au moment de l'acquisition, ce qui sur une capture vive correspond aux documents que l'utilisateur avait ouverts quand la machine a été imagée. Ce dernier point est entré dans plus d'un rapport comme la réponse à « que faisait vraiment l'utilisateur au moment où nous sommes arrivés ».

Activité navigateur

Les navigateurs modernes maintiennent de gros caches dans le système de fichiers. Chrome et Edge utilisent \Users\\AppData\Local\<browser>\User Data\Default\Cache\Cache_Data\ (plus Code Cache\). Firefox utilise \Users\\AppData\Local\Mozilla\Firefox\Profiles\<id>\cache2\. Pendant la navigation :

Un taux bas soutenu de FileCreate | Close et DataExtend | Close dans le répertoire cache.
Des FileDelete | Close occasionnels au fur et à mesure que le LRU évince les vieilles entrées.
Toutes les quelques minutes, des RenameNewName de fichiers cache pendant que l'index est compacté.

Les rafales d'écritures cache corrèlent avec la visite de sites lourds en médias ou single-page applications. Les périodes calmes corrèlent avec l'utilisateur absent ou sur une page longue à charger. La lecture vidéo active produit une forme différente — du gros DataExtend soutenu sur un seul fichier de cache plutôt que beaucoup de petits creates.

Les noms de fichier de cache n'encodent pas les URLs. Pour ça, pivote vers les bases SQLite propres du navigateur via l'outillage de forensique de navigateur. La contribution du journal est la cadence — que l'utilisateur naviguait activement pendant une fenêtre spécifique — plus les événements FileCreate explicites dans \Users\\Downloads\ pour les téléchargements délibérés.

Activité de code

Si l'utilisateur est développeur, l'activité IDE et outils de build produit des rafales très caractéristiques :

Webpack, Vite, Turbopack — beaucoup de FileCreate dans node_modules\.cache\, node_modules\.vite\, .next\ et dist\. Des centaines par build.
Visual Studio C++ — FileCreate de fichiers .obj et .pdb dans les sous-arbres Debug\ ou Release\.
Cargo (Rust) — Les builds incrémentaux touchent target\debug\incremental\ beaucoup ; les builds complets touchent aussi target\debug\deps\.
Go — Rafales courtes et intenses dans $GOPATH\pkg\ et le cache de build sous \Users\\AppData\Local\go-build\.
npm install et yarn install — Des milliers d'enregistrements FileCreate sous node_modules\ en dizaines de secondes. L'activité utilisateur la plus bruyante du journal.

Une rafale de cinq minutes de FileCreate dans node_modules\ suivie d'un essaim de DataExtend sur dist\bundle.js est « lancé le build, puis un serveur de dev a rechargé ». Lis la section d'exclusion en dessous — ces rafales noieront tout le reste si tu ne les filtres pas pour les analyses hors développement.

Téléchargements et installations

Un téléchargement direct via Chrome :

FileCreate | Close             \Users\<u>\Downloads\<file>.crdownload
DataExtend | Close             \Users\<u>\Downloads\<file>.crdownload  × N
RenameNewName | Close          \Users\<u>\Downloads\<file>
BasicInfoChange | Close        \Users\<u>\Downloads\<file>

Firefox utilise .part, Edge utilise .download. Le rename atomique à la fin fait apparaître le fichier comme « complet » à l'Explorateur et aux autres lecteurs.

L'installation d'un nouveau programme suit typiquement : FileCreate d'un installateur (.exe, .msi, .appx) dans Downloads, puis une rafale d'enregistrements FileCreate sous \Program Files\, \Program Files (x86)\ ou \Users\\AppData\Local\Programs\. L'histogramme par minute rend les installs trivialement identifiables. Croise avec AmCache et Prefetch pour le côté exécution.

Le tout ensemble : la recette de timeline quotidienne

La recette pour un rapport « qu'a fait l'utilisateur aujourd'hui » :

Tire le journal parsé de l'utilisateur pour la journée. Restreins aux enregistrements dont le chemin résolu commence par \Users\\ (l'utilisateur cible). Cela élimine Windows Update, les caches système et le bruit OS qui sinon domine.
Calcule, par bucket de 10 minutes : comptes de FileCreate, DataExtend, BasicInfoChange.
Trace les trois séries. La forme te dit l'activité grossière :
- Creates élevés plus extend. Écriture ou sauvegarde de contenu.
- BasicInfoChange élevé seul. Navigation, scroll, édition légère où Office ou l'éditeur touche le fichier sans écritures significatives.
- Extend élevé avec create bas. Gros téléchargement ou lecture multimédia.
- Creates soutenus dans les chemins Cache\. Navigation.
- Creates soutenus dans node_modules\ ou target\ ou Debug\. Coder.
Annote les pics en inspectant les cinq noms top dans chaque bucket. Les noms Office et les fichiers de verrouillage ~$ sont d'excellentes ancres. Les noms de cache tu peux d'habitude les ignorer.

Le parser sur cette page expose l'histogramme par minute sur son composant timeline. Cliquer sur une barre filtre la table à cette fenêtre, ce qui est le workflow ci-dessus sans écrire de code.

Pour l'attribution — quel utilisateur était au clavier — apparie la timeline du journal aux logons interactifs 4624 de Security.evtx (LogonType=2) et aux logoffs initiés par l'utilisateur 4647 du parser EVTX. Ça encadre les frontières de session et te donne un nom à mettre sur l'activité.

Exclusions et pièges

Les scans de sauvegarde et AV produisent des rafales BasicInfoChange à l'échelle du volume qui ressemblent superficiellement à de l'activité utilisateur. Ils suivent des horaires programmés et visitent chaque répertoire plutôt que de se concentrer sur un sous-arbre. Faciles à identifier par couverture de chemin et à exclure.

Les agents de sync (OneDrive, Dropbox, Google Drive Backup and Sync) génèrent du trafic journal qui ressemble à de l'activité utilisateur mais c'est le propre travail de l'agent. Filtre aux enregistrements hors du dossier de sync pour de l'activité initiée par l'utilisateur, ou regarde spécifiquement à l'intérieur du dossier de sync pour le motif exfil-via-cloud documenté dans le billet d'exfiltration.

Indexeurs en arrière-plan. SearchIndexer.exe touche des fichiers dans \Users\\AppData\Roaming\Microsoft\Windows\Recent\ et \ProgramData\Microsoft\Search\. MsMpEng.exe (Defender) produit des événements BasicInfoChange quand il scanne. Les deux faciles à bucketer comme bruit système.

Chrome Software Reporter, Edge updater, Windows Update. Tous produisent des rafales prévisibles de FileCreate et DataExtend dans \Program Files\ et \Windows\SoftwareDistribution\. Filtre par chemin.

node_modules\ et autres outputs de build dominent toute timeline qui les inclut. Pour les cas non développement, exclus node_modules\, target\, Debug\, Release\, obj\, bin\, .next\, dist\, build\ par préfixe de chemin.

Ce que le journal ne peut pas reconstruire

L'identité de l'utilisateur. Corrèle les timestamps avec les logons 4624 de Security.evtx.
Les URLs que l'utilisateur a visitées. Les bases d'historique du navigateur les contiennent — le journal ne connaît que la cadence d'écriture cache.
Le contenu d'un fichier quelconque. Métadonnées seulement.
Tout ce qui est hors de la fenêtre du ring buffer. Un $J de 32 Mo couvre quelques jours sur un poste. Tout ce qui est plus vieux est parti de cet artefact ; tire les Shadow Copies et $LogFile si tu as besoin de plus de portée.

Pour 80 % des questions « que faisait l'utilisateur entre X et Y », $J et $MFT ensemble répondent directement. Les 20 % restants veulent Sysmon, EVTX, SRUM pour l'usage réseau et CPU au niveau application, et une super-timeline propre.

Lectures complémentaires

Plaso (log2timeline) — l'outil canonique de super-timeline ingère des journals USN parsés et les fusionne avec chaque autre artefact de timeline Windows dans une vue triable.
SANS DFIR — le Windows Forensic Analysis poster est la référence en une page sur quels artefacts répondent à quelles questions d'activité utilisateur.
L'artifact exchange Velociraptor — plusieurs artefacts communautaires combinent des corrélations USN, MFT et EVTX comme celles ci-dessus.