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

Une grande partie de la question « que s'est-il passé sur cet ordinateur entre 14h00 et 16h00 » se résout directement avec le journal USN. Les enregistrements ne sont pas un log de syscalls, et ils ne sont pas étiquetés par utilisateur — mais ils ont quelque chose presque aussi utile : un journal haute fréquence, par opération, de chaque fichier que la machine a touché. Avec un peu de connaissance des patterns, on peut récupérer le comportement de l'utilisateur à la granularité de sauvegarde Office, navigation web, rebuild IDE, pause déjeuner.

Cet article est le guide de terrain pour lire le journal comme une timeline comportementale.

Pourquoi ça marche

Le journal USN enregistre quel fichier a changé, quand, et comment — et la plupart des actions visibles d'un utilisateur sur un desktop produisent une signature reconnaissable d'activité fichier. L'utilisateur clique Enregistrer dans Word ; Word écrit un fichier temporaire, le renomme atomiquement, et BasicInfoChange | Close le résultat. Chrome ouvre un nouvel onglet ; le cache disque s'allonge. L'IDE recompile ; mille fichiers objets naissent.

Ces signatures ne sont documentées nulle part officiellement — elles s'apprennent. Voici un kit de démarrage, plus les contrôles du parseur qui les rendent maniables.

Office en pratique

Quand un utilisateur sauvegarde un Word, Excel ou PowerPoint, on voit :

FileCreate | Close            ~$<filename>.docx     (fichier de lock)
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 lock ~$ est le signal d'Office qu'un document est ouvert ; son FileCreate et son FileDelete indiquent le moment d'ouverture/fermeture du document. Le rename atomique .tmp → .docx est la sauvegarde elle-même. Les fichiers ~$ en tête sont étonnamment utiles parce qu'ils existent uniquement pendant que le document est ouvert.

Astuce de pivot : filtrer les FileCreate dont le nom commence par ~$ pour énumérer tous les documents Office ouverts par l'utilisateur dans la fenêtre. Soustraire les FileDelete des mêmes noms pour trouver ceux encore ouverts au moment de l'acquisition (une image forensique prise sur un poste actif peut avoir des fichiers de lock pour des documents jamais correctement fermés).

Activité navigateur

Les navigateurs modernes maintiennent de gros caches sur le système de fichiers. Chrome et Edge utilisent \Users\<u>\AppData\Local\<browser>\User Data\Default\Cache\Cache_Data\ (ou Code Cache\) ; Firefox utilise \Users\<u>\AppData\Local\Mozilla\Firefox\Profiles\<id>\cache2\.

Ce qu'on voit pendant la navigation :

• Un taux faible et soutenu de FileCreate | Close et DataExtend | Close dans le dossier de cache.
• Quelques FileDelete | Close quand le LRU évince de vieilles entrées.
• Toutes les quelques minutes, des RenameNewName de fichiers de cache au fur et à mesure que l'index se compacte.

Les salves d'écritures cache se corrèlent bien avec la visite de sites lourds en média ou de SPA. Les périodes calmes se corrèlent avec l'utilisateur absent ou sur une page longue à charger.

Les noms de fichiers de cache ne vous disent pas quelles URL ont été visitées (c'est dans la base du navigateur), mais le rythme d'I/O cache vous dit que l'utilisateur naviguait. À combiner avec les FileCreate du journal dans le dossier Downloads\ pour identifier des téléchargements délibérés.

Activité code

Si l'utilisateur est développeur, les rebuilds IDE produisent des salves très caractéristiques :

• Webpack/Vite/Turbopack — beaucoup de FileCreate dans node_modules\.cache\ et dist\, souvent des centaines par build.
• Visual Studio C++ — FileCreate de fichiers .obj et .pdb dans des sous-arbres Debug\ ou Release\.
• Cargo (Rust) — les builds incrémentaux touchent fortement target\debug\incremental\ ; les builds complets touchent target\debug\deps\.

Une salve de 5 minutes de FileCreate dans node_modules\ suivie d'un essaim de DataExtend sur un dist\bundle.js, c'est « a lancé le build, puis un dev server a rechargé ».

Téléchargements et installations

Un téléchargement direct produit :

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

Les extensions .crdownload, .part, .download sont respectivement Chrome, Firefox, Edge. Le rename atomique à la fin est ce qui fait apparaître le fichier comme « complet ».

L'installation d'un nouveau programme suit typiquement : FileCreate d'un installer .exe/.msi dans Downloads, puis une salve de FileCreate dans \Program Files\ ou \Program Files (x86)\ ou \Users\<u>\AppData\Local\Programs\. L'histogramme minute par minute rend les installations triviales à identifier.

Tout assembler : une timeline quotidienne

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

1. Tirer le journal parsé de l'utilisateur pour la journée. Restreindre aux enregistrements sous \Users\<u>\ pour retirer le bruit système.
2. Calculer, par bucket de 10 minutes : nombre de FileCreate, DataExtend, BasicInfoChange.
3. Tracer les trois séries. Leur forme dit l'activité approximative :
   • Beaucoup de creates + extend : écriture/sauvegarde de contenu.
   • Beaucoup de BasicInfoChange seul : navigation, scroll, édition légère.
   • Beaucoup d'extend avec peu de create : gros téléchargements ou lecture média.
   • Creates soutenus dans des dossiers Cache\ : navigation.
   • Creates soutenus dans node_modules\ / Debug\ / target\ : code.
4. Annoter les pics en inspectant les noms de fichiers les plus fréquents dans chaque bucket. Les noms de fichiers Office sont d'excellents ancrages ; les noms de cache, on peut les ignorer.

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

Pièges

• Sauvegardes et scans AV produisent des salves BasicInfoChange à l'échelle du volume qui ressemblent superficiellement à de l'activité utilisateur. Elles suivent en général des horaires planifiés et visitent tous les dossiers, pas seulement ceux de l'utilisateur, ce qui les rend faciles à identifier et exclure.
• Agents de sync (OneDrive, Dropbox) génèrent du trafic journal qui ressemble à de l'activité utilisateur, mais c'est le travail de l'agent. Filtrer aux enregistrements dont le chemin est hors du dossier de sync pour se concentrer sur le travail initié par l'utilisateur.
• Indexeurs en tâche de fond (SearchIndexer.exe) touchent des fichiers dans \Users\<u>\AppData\Roaming\Microsoft\Windows\Recent\ et \ProgramData\Microsoft\Search\ — faciles à classer comme bruit système.

La suite

• La référence des événements Windows de Microsoft Learn pour coupler l'activité journal aux events Security/Sysmon.
• Le pack d'artefacts Velociraptor — beaucoup d'artefacts communautaires utilisent des corrélations journal + MFT comme celles ci-dessus.
• Pour une timeline en production à l'échelle, Plaso (log2timeline) peut ingérer un journal parsé et le fusionner avec tous les autres artefacts de timeline Windows en une super-timeline unique.

Le journal seul ne remplacera pas une super-timeline en règle. Mais pour 80% des investigations, « qu'est-ce que l'utilisateur faisait entre 14h00 et 16h00 » est répondable rien qu'avec $J et $MFT, dans le temps qu'il faut pour les glisser sur cette page.