TL;DR. Sichern Sie das $LogFile und die $MFT desselben Volumes. Legen Sie beide im $LogFile-Parser im Browser ab. Lesen Sie zuerst die Kopfzeile (Version, sauber oder nicht sauber ausgehängt, LSN-Bereich, Warnungen). Sichten Sie dann die Ereignisansicht mit Nur markierte, öffnen Sie bei jedem Befund die Detailansicht, um zu sehen, woher Zeit und Pfad stammen, springen Sie zu den Roheinträgen, um die Redo-/Undo-Bytes zu prüfen, und exportieren Sie als CSV/JSON. Die Markierungen sind Heuristiken; die Roheinträge sind das Beweismittel. Bestätigen Sie alles, was in einen Bericht einfließt, mit einem zweiten Werkzeug.

Diese Anleitung nutzt das eingebaute Beispiel des Parsers: ein synthetisches LFS-2.0-Log samt $MFT aus einem fiktiven Einbruch auf einer Arbeitsstation namens FIN-WKS-07. Klicken Sie auf der Werkzeugseite auf Beispiel ausprobieren, um mitzumachen. Alle Namen, Zeiten und Inhalte im Beispiel sind erfunden.

Schritt 1 — Die beiden Dateien gemeinsam sichern

Der Parser kann ein $LogFile auch allein lesen, aber die Pfade bleiben dann unvollständig. Logeinträge benennen Dateien über den MFT-Eintrag; der Name erscheint im Log nur, wenn die Datei angelegt, umbenannt oder gelöscht wird. Den Rest ergänzt die $MFT.

Ohne $MFT wird tools.zip im Beispiel zu [MFT #61]\svc_backup\Downloads\tools.zip aufgelöst (der Ordner Users wird im erhaltenen Log nirgends benannt). Mit ihr lautet der Pfad \Users\svc_backup\Downloads\tools.zip.

Die Sicherungsbefehle für KAPE, Velociraptor, FTK Imager, RawCopy und icat stehen in Das NTFS-$LogFile sichern: live und post mortem.

Schritt 2 — Die Dateien laden

Legen Sie die Dateien ab, wählen Sie einen Ordner oder legen Sie eine ZIP-Triage-Sammlung ab (KAPE- und Velociraptor-Strukturen funktionieren direkt). Jedes $LogFile wird mit der $MFT im selben Ordner gepaart, also halten Sie einen Ordner pro Volume.

Alles Weitere bleibt im Browser-Tab: Der Parser ist Rust, kompiliert nach WebAssembly, und läuft in einem Web Worker. Die $MFT wird in Blöcken von 16 MiB in einen Namensindex eingelesen, sodass auch MFTs mit mehreren Gigabyte funktionieren, ohne die ganze Datei in den Speicher zu laden. Einen Upload-Endpunkt gibt es nicht.

Dateien, mit denen der Parser nichts anfangen kann, werden mit Begründung aufgeführt statt stillschweigend verworfen: eine Kopie, die mit Nullen beginnt (beim Kopieren vermutlich gesperrt), ein $UsnJrnl:$J (wird von diesem Werkzeug nicht analysiert — nehmen Sie den USN-Journal-Parser) oder eine $MFT ohne $LogFile daneben.

Schritt 3 — Die Kopfzeile vor den Ereignissen lesen

Für das Beispiel besagt die Kopfzeile im Wesentlichen:

Feld	Wert im Beispiel	Was es Ihnen sagt
Log-Version	LFS 2.0	Windows 8 oder neuer, Volume bei der Sicherung eingehängt (1.1 vs. 2.0)
Größe	256 KiB	Ungewöhnlich klein; echte Systemvolumes liegen meist bei etwa 64 MiB
Eintragsseiten	5	Wie viele zirkuläre Seiten Einträge enthalten
LSN-Bereich	115720 → 117880	Ältester und neuester gefundener Eintrag (Restart Area und LSN im $LogFile erklärt)
Aushängen	nicht sauber ausgehängt	Live-Sicherung oder Absturz
Tail- / Fast Pages	1 Seite aus dem Fast-Page-Bereich gelesen	Die neueste Seite existierte nur dort — typisch für eine Live-Sicherung

Lesen Sie auch den Kasten Parser-Warnungen. Eine abgeschnittene Kopie, Seiten, die die Prüfung der Update Sequence nicht bestanden haben, oder eine CHKD-Restart-Seite ändern, wie weit Sie dem Ergebnis trauen können.

Schritt 4 — Die Ereignisansicht sichten

Die Übersichtskacheln zeigen die Anzahl pro Typ. Im Beispiel: 14 angelegte Dateien, 2 Löschungen, 2 Umbenennungen/Verschiebungen, 6 Änderungen an $STANDARD_INFORMATION, 2 Schreibvorgänge residenter Daten und 1 Timestomping-Hinweis.

Dann eingrenzen:

Ereignistyp: Angelegt, Gelöscht, Umbenannt / verschoben, Zeitstempel geändert ($SI), Residente Daten geschrieben.
Nur markierte: behält Ereignisse mit mindestens einer Markierung.
Suche: Pfad, Name, Inhalt, LSN oder Datum.

Die fünf Markierungen und was sie auslöst:

Markierung	Auslöser
Löschung	Das Ereignis ist eine Löschung
Umbenennung / Verschiebung	Das Ereignis ist eine Umbenennung oder Verschiebung
Zeitstempeländerung (mögliches Timestomping)	Erstellungszeit überschrieben, ein Wert ging zurück, ein Wert auf volle Sekunden oder Erstellung in `$SI` früher als Erstellung in `$FN`
Vom Benutzer beschreibbarer Ordner	Pfad unter AppData/Downloads/Desktop/Documents eines Benutzerprofils, `Users\Public`, `ProgramData`, `Windows\Temp`, `$Recycle.Bin` oder `PerfLogs`
Ausführbar	Name endet auf `.exe`, `.dll`, `.ps1`, `.bat`, `.js`, `.hta` und Ähnliches

Im Beispiel bringen Nur markierte und eine Sortierung nach LSN die Geschichte in einem Dutzend Zeilen ans Licht: m64.exe wird in Downloads\tools angelegt, nach \ProgramData\Intel verschoben und seine Zeitstempel werden überschrieben; rc.tmp wird in \Users\Public abgelegt und in rclone.exe umbenannt; creds.txt wird auf dem Desktop angelegt und gelöscht.

Schritt 5 — Die Detailansicht öffnen

Ein Klick auf ein Ereignis öffnet seine Details. Drei Felder verdienen jedes Mal Aufmerksamkeit:

Zeit aus. NTFS protokolliert keine Uhrzeit. Der Parser datiert jedes Ereignis anhand von Daten in den Einträgen — Erstellungszeit aus $FILE_NAME (beim Anlegen), Änderungszeit aus $FILE_NAME (bei Umbenennungen), der neue $SI-Wert (bei Zeitstempeländerungen) oder die letzte bekannte Zeit vor einer Löschung. Ereignisse ohne einen dieser Werte übernehmen die Zeit des nächstgelegenen datierten Ereignisses und werden mit ≈ gekennzeichnet. Die Zeitstempeländerung an m64.exe im Beispiel gehört dazu: Ihre neuen Werte zeigen auf 2019, also lehnt der Parser es ab, sie als Zeitpunkt der Änderung zu verwenden.
Pfad aus. Im Log gefundene Namen, die $MFT, teilweise (ein übergeordneter Ordner unbekannt) oder unbekannt.
Warum markiert. Bei m64.exe: Die Erstellungszeit wurde überschrieben, ein Zeitstempel ging zurück, ein Wert auf volle Sekunden, und die Erstellung in $SI liegt vor der in $FN. Die Ansicht zeigt $SI vorher (2026-09-14 10:06:52.3551871) und nachher (2019-03-19 07:14:22.0000000).

Wie diese Gründe zu bewerten sind, steht in Timestomping mit dem NTFS-$LogFile erkennen.

Schritt 6 — Gegen die Roheinträge prüfen

Jedes Ereignis verlinkt auf seine Logeinträge (Diese Logeinträge anzeigen). Die Ansicht der Logeinträge listet jeden Eintrag mit LSN, Transaktions-ID, Redo- und Undo-Operation, Zielattribut und MFT-Eintrag bzw. Datei als Ziel. Ihre Detailansicht ergänzt vorherige LSN, Undo-Next-LSN, Eintragstyp, Ziel-VCN, die Offsets von Eintrag / Attribut / Cluster-Block, den Offset in der Datei, ob sich der Eintrag über mehrere Seiten erstreckt, sowie Hexdumps der Redo- und Undo-Bytes.

Bei der Zeitstempeländerung an m64.exe sollten Sie ein Paar UpdateResidentValue / UpdateResidentValue auf $STANDARD_INFORMATION sehen, mit den neuen Werten in den Redo-Bytes und den alten in den Undo-Bytes. Bei einer Umbenennung ein DeleteIndexEntry*, gefolgt von einem AddIndexEntry* für denselben Eintrag. Was jeder Opcode bedeutet, erklärt Redo- und Undo-Operationen im NTFS-$LogFile erklärt.

Dieser Schritt macht einen Befund belastbar. Ein Ereignis ist die Interpretation des Parsers; ein Eintrag mit seinen Bytes und Offsets ist das, was Sie anderen zeigen können und was ein zweites Werkzeug reproduzieren sollte.

Schritt 7 — Exportieren und korrelieren

Beide Ansichten exportieren als CSV (mit Schutz gegen Formel-Injection) oder JSON. Zeiten lassen sich in UTC oder Ortszeit anzeigen, mit einer Genauigkeit von 100 ns. Exportieren Sie das Gefilterte, nicht das ganze Log, und behalten Sie die LSNs: Sie sind der stabile Schlüssel, um einen Eintrag zu zitieren.

Dann korrelieren:

$UsnJrnl:$J liefert datierte Einträge RENAME_*, FILE_CREATE, FILE_DELETE und BASIC_INFO_CHANGE (USN-Journal-Parser).
Prefetch zeigt, ob m64.exe oder rclone.exe ausgeführt wurden (Prefetch-Parser); das Beispiel protokolliert sogar das Anlegen von M64.EXE-1C9E54B7.pf.
LNK-Dateien und Jump Lists zeigen, was geöffnet wurde (LNK-Parser); die Datei Payroll_2026.xlsx.lnk in Recent im Beispiel ist dafür ein Ansatzpunkt.

Schritt 8 — Mit einem zweiten Werkzeug bestätigen

Der Parser wurde gegen synthetische Logs validiert, die nach dem veröffentlichten Format geschrieben wurden (Linux ntfs3, libfsntfs, die Beschreibung von dfir.ru), noch nicht gegen einen Korpus echter Windows-Logs. Die Gruppierung zu Ereignissen nutzt ein Fenster von Einträgen pro MFT-Eintrag statt Transaktionen. Für alles, was in einem Bericht landet, lassen Sie das Log erneut durch LogFileParser oder NTFS Log Tracker laufen und vergleichen die Einträge anhand der LSN. Siehe $LogFile-Parser im Vergleich: LogFileParser, NTFS Log Tracker.

Häufige Fehler

Ein $LogFile mit einer $MFT von einem anderen Tag auswerten: MFT-Einträge werden wiederverwendet, Namen werden falsch.
„≈“-Zeiten als Tatsachen lesen. Es sind die Zeiten der Nachbarn.
Eine Timestomping-Markierung als Beweis behandeln. Ein Wert auf volle Sekunden kann von einem Entpackprogramm stammen; ein Sprung zurück von einer legitimen Wiederherstellung.
Bei der Ereignisansicht aufhören. Manche Änderungen werden nicht zu Ereignissen rekonstruiert; die Ansicht der Roheinträge zeigt alles, was das Log noch enthält.

Ein NTFS-$LogFile Schritt für Schritt analysieren