NTFS-$LogFile-Forensik: der vollständige Leitfaden

TL;DR. $LogFile ist das Crash-Recovery-Journal von NTFS (MFT-Eintrag 2). Jede Änderung, die NTFS an seinen eigenen Metadaten vornimmt — an einem FILE-Record, einem Verzeichnisindex, einer Bitmap —, wird vorher als Paar von Operationen protokolliert: Redo (wie die Änderung angewendet wird) und Undo (wie sie zurückgenommen wird). Diese Bytes enthalten Dateinamen, übergeordnete Ordner, MFT-Referenzen sowie Zeitstempel vorher und nachher. Damit ist das Log die beste Quelle für die Frage was sich in den letzten Minuten bis Stunden geändert hat: Anlegen, Löschen, Umbenennen und Verschieben sowie Überschreiben von $STANDARD_INFORMATION (Timestomping). Es hat keine eigene Uhr, es ist zirkulär und es arbeitet auf sehr niedriger Ebene. Sichern Sie es früh, nehmen Sie die $MFT dazu und korrelieren Sie mit $UsnJrnl:$J.

Die meisten Analysten stoßen erst spät auf das $LogFile: nachdem das USN-Journal ausgewertet und die $MFT in eine Zeitleiste überführt ist, wenn eine Frage immer noch offen ist. Stand dieser Zeitstempel schon immer auf 2019? Wie hieß die Datei vor der Umbenennung? Was stand in der gelöschten Textdatei? Dieser Leitfaden ist die Landkarte. Jeder Abschnitt verweist auf einen vertiefenden Artikel der Reihen NTFS-$LogFile-Grundlagen und Ermitteln mit dem $LogFile.

Was das $LogFile ist

NTFS ist ein wiederherstellbares Dateisystem. Es protokolliert keine Dateiinhalte, sondern Metadaten. Der Aufbau hat zwei Schichten, gut beschrieben in „How the $LogFile works?“ von dfir.ru:

• Der Log File Service (LFS) verwaltet ein zirkuläres („unendliches“) Log. Er vergibt Log Sequence Numbers (LSNs), schreibt Einträge in 4-KiB-Seiten und pflegt eine Restart Area, die festhält, wo die Wiederherstellung beginnen muss.
• Der NTFS-Client des LFS schreibt die eigentlichen Logeinträge. Jeder nennt eine Redo- und eine Undo-Operation und trägt die Bytes für beide.

Nach einem Absturz spielt Windows die Redo-Seite abgeschlossener Transaktionen erneut ab und wendet die Undo-Seite nicht abgeschlossener an. Für Ermittler beantworten dieselben Bytes die Frage: „Wie sah diese Struktur unmittelbar vor und unmittelbar nach dieser Änderung aus?“

$LogFile ist Dateieintrag 2 in der Master File Table, neben $MFT (0), $MFTMirr (1) und $Volume (3), wie in Microsofts Übersicht zu den NTFS-Metadateien und in der Formatdokumentation von libfsntfs aufgeführt. Es liegt im Stammverzeichnis jedes NTFS-Volumes (C:\$LogFile, D:\$LogFile…) und ist versteckt und gesperrt, solange das Volume eingehängt ist.

Wie die Datei aufgebaut ist

Jede Seite ist durch ein Update Sequence Array geschützt, denselben Schutz gegen unvollständige Schreibvorgänge (Torn Writes), den auch FILE-Records nutzen. Die Versionsaufteilung (1.1 vs. 2.0, Tail-Seiten vs. Fast Pages) spielt ab Windows 8 eine Rolle und wird in $LogFile-Format 1.1 vs. 2.0: was sich mit Windows 8 ändert behandelt. Restart Area und die Formel von der LSN zum Offset stehen in Restart Area und LSN im $LogFile erklärt.

Was ein Logeintrag enthält

Jeder Eintrag beginnt mit einem 0x30 Byte langen LFS-Header, gefolgt von den Daten des NTFS-Clients. Die folgenden Feld-Offsets stammen aus fslog.c des Linux-Treibers ntfs3:

Die Client-Daten beginnen dann mit dem NTFS-Log-Header: Redo-Opcode, Undo-Opcode, Offsets und Längen der Redo- und Undo-Bytes, der Index des Zielattributs in der Open Attribute Table, die Ziel-VCN und die Offsets, die die Änderung innerhalb eines MFT-Eintrags oder Indexpuffers verorten. Redo- und Undo-Operationen im NTFS-$LogFile erklärt geht die relevanten Opcodes durch.

Was es Ermittlern liefert

Aus den Redo-/Undo-Bytes ergeben sich vier Gruppen von Spuren:

Kleine Dateien ergeben eine fünfte, eher zufällige Kategorie: Inhalt, der im FILE-Record selbst liegt (residente Daten), kann im Abbild des Eintrags oder in den Nutzdaten eines CreateAttribute auftauchen. Betrachten Sie das als Zugabe, nicht als Garantie (siehe Grenzen unten).

Die zwei Anwendungsfälle, für die sich der Aufwand mit dem $LogFile lohnt:

1. Timestomping. Ein UpdateResidentValue auf $STANDARD_INFORMATION trägt in seinen Undo-Bytes den Wert vor der Änderung. Eine auf 2019 umgeschriebene Erstellungszeit ist als Überschreiben sichtbar, nicht nur als merkwürdiger Wert. Methode und Fehlalarme: Timestomping mit dem NTFS-$LogFile erkennen.
2. Kurzlebige Dateien. Ein Werkzeug, das innerhalb einer Stunde abgelegt, umbenannt, benutzt und gelöscht wird, hinterlässt womöglich keinen FILE-Record in der $MFT (Eintrag wiederverwendet) und im USN-Journal nur knappe Reason-Codes. Das Log kann trotzdem noch Name, übergeordneten Ordner, Größen und Zeiten enthalten. Siehe Spuren gelöschter Dateien im $LogFile finden.

Einordnung neben $MFT und $UsnJrnl

Kurz gesagt: Die $MFT ist die Momentaufnahme, das USN-Journal die Historie, das $LogFile der Beweis dafür, was sich genau geändert hat. Der vollständige Vergleich mit Szenarien steht in $LogFile, $UsnJrnl oder $MFT: welches NTFS-Artefakt wann. Für die Auswertung des USN-Journals selbst gibt es den USN-Journal-Parser aus derselben Familie.

Sichern

Auf einem eingehängten Volume lässt sich das $LogFile weder mit dem Explorer noch mit copy öffnen. Sie brauchen Rohzugriff auf NTFS: das KAPE-Target $LogFile, den NTFS-Accessor von Velociraptor, FTK Imager, RawCopy oder icat aus The Sleuth Kit auf einem Image (icat image.dd 2). Sichern Sie immer gleichzeitig die $MFT desselben Volumes — das Log verweist auf Dateien über den MFT-Eintrag, und erst die $MFT macht aus [MFT #322] den Pfad \ProgramData\Intel\m64.exe. Befehle und Stolperfallen: Das NTFS-$LogFile sichern: live und post mortem.

Auswerten

Der Ablauf in der Praxis:

1. Das Log in Roheinträge zerlegen (LSN, Transaktion, Redo-/Undo-Opcode, Ziel).
2. Aus Gruppen von Einträgen Dateisystem-Ereignisse rekonstruieren.
3. MFT-Einträge mit der $MFT in Pfade auflösen.
4. Ereignisse anhand der Zeitstempel in den Daten datieren und alles Undatierte kennzeichnen.
5. Mit USN-Journal, Prefetch und Ereignisprotokollen korrelieren.

Der $LogFile-Parser im Browser erledigt die Schritte 1 bis 4 lokal (Rust, kompiliert nach WebAssembly, nichts wird hochgeladen) und zeigt jeden Roheintrag neben den daraus gebildeten Ereignissen. Seine Markierungen — Löschung, Umbenennung, mögliches Timestomping, vom Benutzer beschreibbarer Pfad, ausführbar — sind Hinweise für die Triage, keine Urteile. Einen Durchlauf Schritt für Schritt mit den Beispieldaten zeigt Ein NTFS-$LogFile Schritt für Schritt analysieren, einen vollständigen fiktiven Fall Eine $LogFile-Untersuchung Schritt für Schritt (fiktiv).

Ein ehrlicher Hinweis: Dieser Parser wurde bisher gegen synthetische Logs validiert, die nach dem veröffentlichten Format erzeugt wurden, nicht gegen einen Korpus echter Windows-Logs. Bestätigen Sie alles, was in einen Bericht einfließt, mit einem zweiten Werkzeug; die Optionen vergleicht $LogFile-Parser im Vergleich: LogFileParser, NTFS Log Tracker.

Wo es endet

• Kurze Vorhaltezeit. Das Log ist zirkulär. Auf einem stark genutzten Systemvolume sind Minuten bis Stunden zu erwarten; in den Tests von dfir.ru unter Windows 10 waren alte Daten in einem Fall nach 16 Minuten überschrieben, in einem anderen nach 5 Stunden 20 Minuten.
• Keine Uhr. Einträge tragen LSNs, keine Zeiten. Zeiten stammen aus Werten von $FILE_NAME / $STANDARD_INFORMATION in den Daten.
• Nur Metadaten. Nicht residenter Dateiinhalt läuft nie durch das Log.
• Namen fehlen oft. Ein Eintrag nennt häufig nur einen MFT-Eintrag; der Name taucht auf, wenn die Datei angelegt, umbenannt oder gelöscht wird, oder über die $MFT.

Details und Gegenmaßnahmen: Wie weit reicht das $LogFile zurück? Grenzen und Fallstricke

Häufige Fragen

Was ist das NTFS-$LogFile?

Es ist das Transaktionsprotokoll von NTFS für Metadaten, gespeichert als MFT-Eintrag 2 im Stammverzeichnis jedes NTFS-Volumes. Bevor NTFS seine eigenen Metadaten ändert, schreibt es einen Logeintrag, der die Änderung als Redo- und als Undo-Operation beschreibt, damit sich das Volume nach einem Absturz reparieren lässt.

Enthält das $LogFile Zeitstempel?

Logeinträge haben keine eigene Uhrzeit. Zeiten stammen aus den protokollierten Daten selbst: aus Werten von $STANDARD_INFORMATION und $FILE_NAME in den Redo- und Undo-Bytes. Ereignisse ohne solchen Wert lassen sich nur relativ zu ihren Nachbarn über die LSN einordnen.

Wie weit reicht das $LogFile zurück?

Es ist zirkulär und meist etwa 64 MiB groß. Auf einem stark genutzten Systemvolume deckt es Minuten bis Stunden ab, auf ruhigen Datenvolumes mehr. In einem veröffentlichten Test unter Windows 10 waren alte Daten nach 16 Minuten überschrieben, in einem anderen nach 5 Stunden 20 Minuten.

Weiterführende Literatur

• Maxim Suhanov, How the $LogFile works? — die beste öffentliche Beschreibung der LFS-Interna.
• Linux-Kernel, fs/ntfs3/fslog.c — eine funktionierende Implementierung des Log-Replays, mit Struktur-Offsets.
• libyal, NTFS-Dokumentation von libfsntfs.
• Joakim Schicht, LogFileParser — der Open-Source-Referenzdecoder, mit ausführlichem Readme.
• Gyu-Sang Cho, A computer forensic method for detecting timestamp forgery in NTFS, Computers & Security 34 (2013).

Verwandte Artikel

• $LogFile, $UsnJrnl oder $MFT: welches NTFS-Artefakt wann
• Das NTFS-$LogFile sichern: live und post mortem
• Timestomping mit dem NTFS-$LogFile erkennen