USN Reason Codes — zwischen den Bits lesen

Wenn Sie viel Zeit mit dem Lesen von USN-Journals verbringen, wird die Reason-Bitmaske zum Muskelgedächtnis, so wie es EVTX-EventIDs werden. Es ist das 32-Bit-Feld, das NTFS auf jedem USN_RECORD_V2 setzt, um zusammenzufassen, was sich gerade an einer Datei geändert hat. Die Bits sind additiv, nicht gegenseitig ausschließend, was als Erstes zu verinnerlichen ist: Ein einzelner Eintrag kann FileCreate | DataExtend | Close tragen, und diese Kombination bedeutet etwas anderes als jedes dieser Bits allein.

Was folgt, ist die Feldreferenz, die ich auf einem Klebezettel neben meinem Monitor halte.

Die Bits, in der Reihenfolge, in der Sie ihnen tatsächlich begegnen werden

Das Close-Bit verdient einen eigenen Absatz, weil es Ihre Ereigniszählung um eine Größenordnung verfälscht, wenn Sie es falsch lesen. NTFS fasst aufeinanderfolgende Operationen unter demselben Handle zusammen und gibt Zwischeneinträge aus, während es flusht, dann einen finalen Zusammenfassungseintrag mit gesetztem Close, sobald das Handle weg ist. Die Zwischeneinträge sind echt, aber sie zählen doppelt. Wenn Sie ein geparstes Journal triagieren, filtern Sie zuerst nach Close-tragenden Einträgen, um Operationen auf eine Zeile pro Handle zu deduplizieren. Ziehen Sie die Nicht-Close-Einträge nur heran, wenn Sie Sub-Handle-Granularität brauchen.

Muster, die so oft wiederkehren, dass es sich lohnt, sie auswendig zu lernen

Eine Handvoll Reason-Kombinationen taucht so häufig in Untersuchungen auf, dass Sie aufhören, sie Zeichen für Zeichen zu lesen, und anfangen, sie als Wörter zu lesen.

Neue Datei, von einer App geschrieben. FileCreate | DataExtend, dann weitere DataExtend | Close-Einträge, während die Datei wächst, abgeschlossen durch BasicInfoChange | Close. Der letzte Eintrag ist die Datei, die beim Schließen ihre mtime gestempelt bekommt.

Umbenennung über Verzeichnisse hinweg. Zwei Einträge, die dieselbe FileReferenceNumber teilen: RenameOldName | Close, dann RenameNewName | Close. Die übergeordnete Referenz unterscheidet sich zwischen den beiden — diese Differenz ist, wie Sie den Move rekonstruieren. Wenn Sie nur nach einem der Rename-Bits filtern, verlieren Sie die Hälfte der Geschichte.

Atomares Save-by-Rename. Office, VS Code, Notepad++, vim mit Backup, fast jeder moderne Editor. Sie sehen ein FileCreate auf einer Temp-Datei (~$report.docx, report.docx.tmp, .swp usw.), einen oder mehrere DataExtend-Einträge, ein FileDelete | Close auf dem Original und dann RenameNewName | Close auf der Temp-Datei, das auf den Namen des Originals zeigt. Die vollständige Sequenz passiert innerhalb einer einzigen Wanduhr-Sekunde.

Ransomware-Verschlüsseln-dann-Umbenennen. Anhaltende DataOverwrite-Einträge, die Megabytes pro Datei abdecken, gefolgt von RenameOldName / RenameNewName-Paaren mit einem einheitlichen Suffix oder einer Zufalls-Erweiterung fester Länge. Die DataOverwrite-Rate und der Same-Extension-Cluster auf den Umbenennungen sind die beiden Hälften der Diagnose. Der Beitrag zur Ransomware-Erkennung ist das Playbook.

Antivirus-Quarantäne. Ein FileDelete | Close unmittelbar nach einem kürzlichen FileCreate auf demselben MFT-Eintrag, oft mit einem SecurityChange dazwischen, während der AV-Agent die Datei in ein eingeschränktes Verzeichnis verschiebt. Das Journal bewahrt den Beweis, dass AV die Datei angerührt hat, selbst nachdem die Binärdatei selbst weg ist.

Cloud-Sync-Upload. RenameNewName | Close, dessen neuer Übergeordneter \Users\<u>\OneDrive\, \Dropbox\ oder \Google Drive\ ist und dessen alter Übergeordneter das Benutzerprofil ist. Der Agent selbst produziert DataExtend | Close-Einträge auf Dateien innerhalb des Sync-Ordners für Downloads — Uploads sehen tendenziell aus wie Umbenennungen in den Ordner hinein.

Timestomping. Ein nacktes BasicInfoChange | Close ohne umliegendes DataOverwrite, DataExtend, FileCreate oder Rename auf derselben FileReferenceNumber. Eine legitime Berührung wird vom Schreibvorgang begleitet, der die Zeitstempel-Aktualisierung ausgelöst hat. Der Timestomping-Beitrag ist der Ort, wo das ausführlich ausgearbeitet ist.

Stream-Injection / ADS-Missbrauch. StreamChange allein deutet meist auf einen Zone.Identifier von einem Browser-Download hin (gepaart mit dem FileCreate der Originaldatei). Wiederholte StreamChange-Einträge auf derselben FileReferenceNumber abseits von Downloads\, besonders auf signierten System-Binärdateien, sind es wert, geöffnet zu werden.

Was die Bits Ihnen nie sagen werden

Das Reason-Feld dreht sich um die Datei, nicht um den Akteur. Es gibt keinen Benutzer, keine PID, keine Kommandozeile, kein Integrity Level. Einen Akteur an eine Operation zu hängen, bedeutet immer, woanders nachzuschauen: Security.evtx 4663 (Object Access, nur wenn SACLs konfiguriert waren, was sie meistens nicht waren), Sysmon Event 11 (File Create) und Event 1 (Process Create mit Kommandozeile) oder Prozessausführungs-Beweise und Shimcache-Einträge, die eine Binärdatei zum richtigen Zeitpunkt auf die Festplatte bringen.

Die Bits sagen Ihnen auch nichts über Inhalte. Das Journal weiß, dass eine Region überschrieben wurde, nicht, welche Bytes dort vorher waren. Dafür benötigen Sie $LogFile-Vorher-Abbilder oder einen Volume Shadow Copy.

Ein Lese-Rezept, das sich bewährt

Wenn ich ein geparstes Journal kalt öffne:

1. Filtern Sie zuerst nach FileCreate. Was ist im Zeitfenster wirklich neu? Suchen Sie nach Pfaden in benutzerbeschreibbaren Verzeichnissen (\AppData\Local\Temp\, \Users\Public\, \ProgramData\ außerhalb bekannter Hersteller-Unterverzeichnisse, \PerfLogs\).
2. Wechseln Sie zu RenameNewName | Close und gruppieren Sie nach neuer Erweiterung oder neuem Übergeordneten. Save-by-Rename, Cloud-Sync-Bewegungen und Ransomware-Suffixe tauchen alle hier auf.
3. Bucketten Sie DataExtend pro Minute. Massenhafte Schreibvorgänge — Backups, Verschlüsselung, Wachstum von Exfil-Archiven — zeigen sich als anhaltende Spikes gegen eine ansonsten ruhige Baseline.
4. Lesen Sie zuerst Close-tragende Einträge. Behandeln Sie Zwischeneinträge als unterstützende Beweise, nicht als unabhängige Ereignisse.
5. Sobald Sie eine Kandidatendatei haben, gruppieren Sie jeden Eintrag auf derselben FileReferenceNumber und lesen Sie den vollständigen Lebenszyklus in chronologischer Reihenfolge. Diese Sequenz ist fast immer der Teil, der in den Bericht kommt.

Der Parser auf dieser Seite stellt das Reason-Filtering direkt zur Verfügung, sodass die Schritte 1-3 ein paar Klicks sind. Für Schritt 5 sortieren Sie nach FileReferenceNumber, dann nach USN.

Weiterführende Literatur

• Microsoft Learn — USN_RECORD_V2-Referenz deckt jede Bit-Definition direkt von der Quelle ab.
• Eric Zimmermans MFTECmd — sein $J-Parser legt die Reason-Bitmaske in einem flachen CSV offen, das sich für Tabellen-Pivots eignet.
• Airbus CERTs usnrs — die Open-Source-Rust-Implementierung; das Lesen von src/reason.rs ist der kürzeste Weg, das Bit-Layout zu verinnerlichen.