← Zurück zum Blog

Eine Nutzer-Aktivitäts-Timeline aus dem USN-Journal rekonstruieren

Aus drei Minuten $UsnJrnl-Einträgen lässt sich meist rekonstruieren, was ein Nutzer gerade tat — Office, Browser, Downloads, Code. Wie man das Journal als Verhaltens-Log liest.

4 Min. Lesezeit

Ein großer Teil der Frage „Was geschah auf diesem Rechner zwischen 14:00 und 16:00?" lässt sich direkt aus dem USN-Journal beantworten. Die Einträge sind kein Syscall-Log und nicht mit einem Benutzer versehen — aber sie haben etwas fast genauso Nützliches: ein hochfrequentes, operations­scharfes Protokoll jeder Datei, die die Maschine angefasst hat. Mit etwas Muster­wissen kann man das Verhalten des Nutzers in der Granularität Office-Speichern, Browser-Navigation, IDE-Rebuild, Mittagspause rekonstruieren.

Dieser Beitrag ist der Feldleitfaden, das Journal als Verhaltens-Timeline zu lesen.

Warum das funktioniert

Das USN-Journal hält fest, welche Datei sich änderte, wann und wie — und die meisten sichtbaren Aktionen eines Nutzers auf einem Desktop erzeugen eine erkennbare Datei-Aktivitäts-Signatur. Der Nutzer klickt in Word auf Speichern; Word schreibt eine Temp-Datei, benennt atomar um und macht BasicInfoChange | Close auf das Ergebnis. Chrome öffnet einen neuen Tab; der Plattencache wächst. Das IDE baut neu; tausend Object-Dateien tauchen auf.

Diese Signaturen sind offiziell nirgends dokumentiert — sie werden gelernt. Hier ein Starter-Set, plus die Parser-Steuerungen, die sie handhabbar machen.

Office in freier Wildbahn

Wenn ein Nutzer eine Word-, Excel- oder PowerPoint-Datei speichert, sieht man:

FileCreate | Close            ~$<filename>.docx     (Lock-Datei)
FileCreate | Close            <filename>.tmp        (atomare Temp)
DataExtend | Close            <filename>.tmp        × N
RenameOldName | Close         <filename>.docx
FileDelete | Close            <filename>.docx
RenameNewName | Close         <filename>.docx       (war <filename>.tmp)
FileDelete | Close            ~$<filename>.docx
BasicInfoChange | Close       <filename>.docx

Die ~$-Lock-Datei ist Offices Signal, dass ein Dokument offen ist; ihre FileCreate- und FileDelete-Einträge geben den Öffnungs-/Schließmoment des Dokuments an. Das atomare Rename .tmp → .docx ist das Speichern selbst. Die führenden ~$-Dateien sind überraschend nützlich, weil sie nur existieren, solange das Dokument geöffnet ist.

Pivot-Trick: nach FileCreate-Einträgen filtern, deren Dateiname mit ~$ beginnt, um alle vom Nutzer im Fenster geöffneten Office-Dokumente aufzuzählen. FileDelete derselben Namen abziehen, um die zum Aufnahmezeitpunkt noch offenen zu finden (ein forensisches Image einer laufenden Box kann Lock-Dateien für Dokumente enthalten, die nie sauber geschlossen wurden).

Browser-Aktivität

Moderne Browser pflegen schwergewichtige Dateisystem-Caches. Chrome und Edge nutzen \Users\<u>\AppData\Local\<browser>\User Data\Default\Cache\Cache_Data\ (oder Code Cache\); Firefox nutzt \Users\<u>\AppData\Local\Mozilla\Firefox\Profiles\<id>\cache2\.

Was man beim Surfen sieht:

  • Eine anhaltende, niedrige Rate von FileCreate | Close und DataExtend | Close im Cache-Verzeichnis.
  • Gelegentliche FileDelete | Close, wenn LRU alte Einträge verdrängt.
  • Alle paar Minuten RenameNewName von Cache-Dateien, wenn der Index verdichtet wird.

Bursts von Cache-Schreibvorgängen korrelieren gut mit dem Besuch medienlastiger Sites oder SPAs. Ruhige Phasen korrelieren mit Abwesenheit oder einer lange ladenden Seite.

Die Cache-Dateinamen verraten nicht, welche URLs besucht wurden (das steht in der Browser-eigenen DB), aber die Kadenz des Cache-I/O verrät, dass der Nutzer surfte. Mit FileCreate-Events des Journals im Downloads\ des Nutzers kombinieren, um bewusste Downloads zu identifizieren.

Code-Aktivität

Ist der Nutzer Entwickler, erzeugen IDE-Rebuilds sehr charakteristische Bursts:

  • Webpack/Vite/Turbopack — viele FileCreate in node_modules\.cache\ und dist\, oft hunderte pro Build.
  • Visual Studio C++ — FileCreate von .obj- und .pdb-Dateien in Debug\- oder Release\-Teilbäumen.
  • Cargo (Rust) — inkrementelle Builds berühren target\debug\incremental\ stark; volle Builds berühren target\debug\deps\.

Ein 5-minütiger Burst von FileCreate in node_modules\, gefolgt von einem DataExtend-Schwarm auf einem dist\bundle.js, ist „Build gefahren, dann hat der Dev-Server neu geladen".

Downloads und Installationen

Ein direkter Download erzeugt:

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>

Die Endungen .crdownload, .part, .download sind Chrome, Firefox, Edge. Das atomare Rename am Ende lässt die Datei „vollständig" wirken.

Die Installation eines neuen Programms folgt typischerweise: FileCreate eines Installers .exe/.msi in Downloads, dann ein Burst von FileCreate in \Program Files\ oder \Program Files (x86)\ oder \Users\<u>\AppData\Local\Programs\. Das Minuten-Histogramm macht Installationen trivial identifizierbar.

Alles zusammen: eine Tages-Timeline

Das Rezept für einen „Was hat der Nutzer heute gemacht"-Bericht:

  1. Das geparste Journal des Nutzers für den Tag herausziehen. Auf Einträge unter \Users\<u>\ einschränken, um System-Rauschen zu entfernen.
  2. Pro 10-Minuten-Bucket berechnen: Zahl der FileCreate, DataExtend, BasicInfoChange.
  3. Die drei Serien plotten. Die Form sagt die grobe Aktivität:
    • Viele Creates + Extend: Inhalte schreiben/speichern.
    • Viel BasicInfoChange allein: Surfen, Scrollen, leichte Bearbeitung.
    • Viel Extend mit wenig Create: große Downloads oder Medienwiedergabe.
    • Anhaltende Creates in Cache\-Verzeichnissen: Surfen.
    • Anhaltende Creates in node_modules\ / Debug\ / target\: Programmieren.
  4. Spitzen annotieren, indem man die Top-Dateinamen im jeweiligen Bucket inspiziert. Office-Dateinamen sind großartige Anker; Cache-Namen lassen sich meist ignorieren.

Der Parser dieser Seite legt das Minuten-Histogramm in seiner Timeline-Komponente offen — ein Klick auf einen Balken filtert die Tabelle auf dieses Fenster, was dem obigen Workflow ohne Code­zeile entspricht.

Stolperfallen

  • Backups und AV-Scans erzeugen volumenweite BasicInfoChange-Bursts, die oberflächlich wie Nutzeraktivität aussehen. Sie folgen meist Zeitplänen und besuchen alle Verzeichnisse, nicht nur die des Nutzers, was sie leicht erkennbar macht.
  • Sync-Agenten (OneDrive, Dropbox) erzeugen Journal-Verkehr, der aussieht wie Nutzeraktivität, aber Arbeit des Agenten ist. Auf Einträge filtern, deren Pfad außerhalb des Sync-Ordners liegt, um sich auf nutzerinitiierte Arbeit zu konzentrieren.
  • Hintergrund-Indexer (SearchIndexer.exe) berühren Dateien in \Users\<u>\AppData\Roaming\Microsoft\Windows\Recent\ und \ProgramData\Microsoft\Search\ — leicht als System-Rauschen einzusortieren.

Wohin als nächstes

Das Journal allein ersetzt keine ordentliche Super-Timeline. Aber für 80 % der Untersuchungen ist „Was hat der Nutzer zwischen 14:00 und 16:00 getan?" allein mit $J und $MFT beantwortbar — in der Zeit, die das Ziehen auf diese Seite dauert.