NTFS $LogFile Parser

Was ist die NTFS-$LogFile?

$LogFile ist das Transaktionsjournal von NTFS (MFT-Eintrag 2). Bevor NTFS seine eigenen Metadaten ändert — einen FILE-Eintrag, einen Ordnerindex, eine Bitmap —, schreibt es einen Logeintrag, der die Änderung zweimal beschreibt: als Redo-Operation (wie sie angewendet wird) und als Undo-Operation (wie sie rückgängig gemacht wird). Nach einem Absturz spielt Windows diese Einträge nach oder macht sie rückgängig, damit das Volume konsistent bleibt.

Für Ermittler sind diese Redo- und Undo-Bytes Gold wert: Sie enthalten Dateinamen, Elternordner, MFT-Referenzen und Zeitstempel jeder Metadatenänderung, vorher und nachher. Daraus lassen sich Anlegen, Löschen, Umbenennen und das Überschreiben von Zeitstempeln rekonstruieren — selbst wenn das USN-Journal deaktiviert oder geleert wurde.

Wo sie gespeichert ist

• \$LogFile im Stammverzeichnis jedes NTFS-Volumes (C:\$LogFile, D:\$LogFile…). Es ist eine versteckte Metadatendatei: Explorer und normales Kopieren kommen nicht heran — es braucht einen Raw-NTFS-Leser.
• Standardgröße: 64 MiB auf aktuellen Windows-Versionen (änderbar mit chkdsk /L). Das Log ist zirkulär: Neue Einträge überschreiben die ältesten, auf einem ausgelasteten System deckt es meist Minuten bis wenige Stunden ab.
• Aufbau: zwei Restart-Seiten (RSTR), dann 2 Tail-Seiten (Format 1.1, Windows XP bis 7 sowie Windows 8+ nach sauberem Herunterfahren) oder 32 Fast Pages (Format 2.0, Windows 8+ bei eingehängtem Volume), danach der zirkuläre Bereich der Eintragsseiten (RCRD), jede durch ein Update-Sequence-Array geschützt.

Warum sie für Ermittlungen wichtig ist

• Anlegen von Dateien und Ordnern (InitializeFileRecordSegment + AddIndexEntry), Löschungen (DeleteIndexEntry + DeallocateFileRecordSegment) sowie Umbenennungen und Verschiebungen, mit MFT-Eintrag und Sequenznummer.
• Timestomping: Ein UpdateResidentValue auf $STANDARD_INFORMATION enthält den alten und den neuen Zeitstempel — eine auf 2019 zurückgesetzte Erstellungszeit ist als solche sichtbar.
• Inhalt kleiner Dateien, manchmal: Daten innerhalb des FILE-Eintrags (resident, bis ca. 700 Bytes) können in den Redo/Undo-Daten auftauchen — gelegentlich sogar von Notizen oder Skripten, die eine Minute später gelöscht wurden. Auf aktuellen Windows-Versionen protokollieren viele Änderungen nur, dass etwas geändert wurde: Wiederhergestellter Inhalt ist ein Bonus, keine Gewissheit.
• Sie ergänzt $UsnJrnl:$J (längere Historie, aber nur Gründe und Namen) und die $MFT (nur der aktuelle Zustand): Die $LogFile liefert die Werte vorher / nachher.

Einschränkungen

• Kurze Aufbewahrung: Das Log ist zirkulär, nur die jüngste Aktivität ist noch vorhanden. Früh sichern.
• Logeinträge haben keine Uhrzeit. Angezeigte Zeiten stammen aus den $FILE_NAME- / $STANDARD_INFORMATION-Werten in den Daten; Ereignisse ohne Zeit übernehmen die des nächstgelegenen datierten Ereignisses und sind mit ≈ markiert.
• Namen sind nur bekannt, wenn sie im Log vorkommen; ohne $MFT beginnen manche Pfade mit [MFT #n] oder fehlen.
• Nicht residenter Dateiinhalt steht nie in der $LogFile (nur Metadaten). Gruppierung nach Transaktionen, das $UsnJrnl als Ergänzung und $I30-Slack werden noch nicht genutzt.
• Der Parser ist mit synthetischen Logs validiert, die nach dem veröffentlichten Format (Linux ntfs3, libfsntfs) erzeugt wurden — wichtige Befunde mit einem zweiten Werkzeug prüfen.

So kommen Sie an die Dateien

• KAPE: Die Targets $LogFile und $MFT (oder !SANS_Triage) sichern sie roh von jedem Volume. Velociraptor: Windows.Triage.Targets mit den Targets LogFile und MFT (früher Windows.KapeFiles.Targets) oder der NTFS-Accessor.
• Aus einem Datenträgerabbild: FTK Imager (Export aus [root]) oder The Sleuth Kit: icat -f ntfs image.dd 2 > '$LogFile' und icat … 0 > '$MFT'.
• $LogFile und $MFT desselben Volumes gleichzeitig sichern und die Ordnerstruktur (C/, D/…) beibehalten, damit jedes Log mit seiner eigenen $MFT gepaart wird.

FAQ