Das NTFS-$LogFile sichern: live und post mortem

Q: Kann ich das $LogFile mit dem Explorer oder dem copy-Befehl kopieren?

Nein. Das $LogFile ist eine NTFS-Metadatendatei, die das Dateisystem geöffnet hält, solange das Volume eingehängt ist, und die vor den normalen Datei-APIs verborgen ist. Lesen Sie es über Rohzugriff auf NTFS (KAPE, Velociraptor, FTK Imager, RawCopy) oder aus einem Image mit icat oder ntfscat.

TL;DR. Das $LogFile ist MFT-Eintrag 2 im Stammverzeichnis jedes NTFS-Volumes und gesperrt, solange das Volume eingehängt ist. Auf einem laufenden System nehmen Sie KAPE (Targets $LogFile + $MFT), Velociraptor (Windows.Triage.Targets mit den Targets LogFile + MFT; auf älteren Versionen Windows.KapeFiles.Targets), FTK Imager oder RawCopy (/FileNamePath:C:2). Aus einem Image: icat image.dd 2 oder ntfscat -i 2. Sichern Sie es zuerst — es ist zirkulär, und Ihre eigene Aktivität überschreibt es — und sichern Sie die $MFT desselben Volumes im selben Durchgang. Prüfen Sie danach, dass die Kopie mit RSTR beginnt, die in der Restart Area angegebene Größe hat und nicht nur aus Nullen besteht.

Das $LogFile ist das vergänglichste Artefakt auf einem NTFS-Volume. Auf einem stark genutzten Systemlaufwerk kann es in deutlich weniger als einer Stunde einmal komplett durchlaufen. Jeder Befehl, den Sie auf dem System ausführen, schreibt Metadaten, und jeder Metadaten-Schreibvorgang läuft durch das Log. Reihenfolge und Ziel der Sicherung sind hier wichtiger als bei fast jeder anderen Datei.

Was Sie sichern

Datei	Ort	MFT-Eintrag	Wozu
`$LogFile`	Stammverzeichnis jedes NTFS-Volumes (`C:\$LogFile`)	2	Das Transaktionsprotokoll selbst
`$MFT`	Stammverzeichnis desselben Volumes	0	Namen und übergeordnete Ordner für jeden MFT-Eintrag, auf den das Log verweist
`$UsnJrnl:$J`	`$Extend\$UsnJrnl`, Stream `$J`	variiert	Datierte Änderungshistorie zur Korrelation (optional, aber empfohlen)

Auf aktuellen Windows-Volumes ist das Log meist etwa 64 MiB groß (die Größe lässt sich mit chkdsk /L einstellen, also prüfen statt annehmen). Sichern Sie alle relevanten Volumes, nicht nur C:. Wechsel- und Datenvolumes halten die Historie viel länger vor als das Systemlaufwerk.

Bevor Sie anfangen: das Log vor sich selbst schützen

Sichern Sie es zuerst, vor speicher- oder dateiintensiver Triage. dfir.ru hat in einem Test unter Windows 10 gemessen, dass alte Einträge nach 16 Minuten überschrieben waren (How the $LogFile works?).
Schreiben Sie die Ausgabe auf ein anderes Volume (USB-Laufwerk, Netzwerkfreigabe). Wer eine Sammlung nach C: schreibt, erzeugt auf C: Logeinträge für jede angelegte Datei.
Führen Sie kein chkdsk auf dem Beweisvolume aus. Es kann das Log zurücksetzen oder in der Größe ändern. Trägt eine Restart-Seite die Signatur CHKD, hat chkdsk das Log angefasst.
Sichern Sie $LogFile und $MFT im selben Durchgang, vom selben Volume, und behalten Sie die Ordnerstruktur (C/, D/) bei, damit sich jedes Log seiner eigenen $MFT zuordnen lässt.

Laufendes Windows-System

KAPE

Das Projekt KapeFiles liefert die Targets $LogFile.tkape und $MFT.tkape (dazu $J.tkape für das USN-Journal):

kape.exe --tsource C: --target $LogFile,$MFT,$J --tdest E:\case42\kape

KAPE liest gesperrte Dateien per Rohzugriff und übernimmt den Quellpfad in den Ausgabebaum. Wiederholen Sie --tsource für jedes Volume. Wenn Sie ein zusammengesetztes Target verwenden, öffnen Sie es und prüfen Sie, ob es wirklich auf $LogFile verweist, statt sich auf den Namen zu verlassen.

Velociraptor

Windows.Triage.Targets aus dem Velociraptor-Triage-Projekt sammelt dieselben Dateien in großem Maßstab. Haken Sie in einer Server-Collection oder einem Offline-Collector (Server Artifacts → Build offline collector) die Targets LogFile und MFT an und prüfen Sie MaxFileSize, damit eine große $MFT nicht übersprungen wird.

Ältere Velociraptor-Versionen liefern stattdessen das frühere Windows.KapeFiles.Targets mit den Targets $LogFile und $MFT. Es kann die Accessoren ntfs, lazy_ntfs und mft verwenden; lazy_ntfs ist schneller, stützt sich aber auf $I30-Indexdaten, die bei Metadatendateien nicht immer vollständig sind. Deshalb bietet das Artefakt die Option DontBeLazy, um auf den vollständigen NTFS-Parser zurückzufallen (Velociraptor: Massensicherung von Dateien). Für NTFS-Metadatendateien ist der vollständige Accessor vorzuziehen.

FTK Imager

File → Add Evidence Item → Logical Drive, Volume auswählen, [root] aufklappen, Rechtsklick auf $LogFile und $MFT → Export Files. Auf ein externes Laufwerk exportieren. FTK Imager liest das Volume direkt, daher greift die Sperre nicht.

RawCopy

RawCopy von Joakim Schicht akzeptiert statt eines Pfads ein Volume plus MFT-Eintragsnummer. Das Readme zeigt C:0 für die $MFT; das $LogFile ist Eintrag 2:

RawCopy.exe /FileNamePath:C:2 /OutputPath:E:\case42 /OutputName:LogFile_C.bin
RawCopy.exe /FileNamePath:C:0 /OutputPath:E:\case42 /OutputName:MFT_C.bin

Als Administrator ausführen. Benennen Sie die Ausgaben wieder in $LogFile / $MFT um oder halten Sie ein eindeutiges Namensschema ein; Parser, die Dateien über den Namen paaren (auch der $LogFile-Parser im Browser), suchen $LogFile und $MFT im selben Ordner.

Ausgeschaltetes System oder Datenträgerabbild

The Sleuth Kit

icat extrahiert eine Datei über ihre Metadatenadresse; unter NTFS ist das der MFT-Eintrag. -o ist der Sektor-Offset der Partition im Image (icat-Manpage):

mmls image.dd                         # find the NTFS partition start sector
icat -o 2048 image.dd 2 > '$LogFile'
icat -o 2048 image.dd 0 > '$MFT'

ntfs-3g unter Linux

ntfscat aus ntfs-3g akzeptiert mit -i eine Inode-Nummer (ntfscat-Manpage). Binden Sie das Image schreibgeschützt ein (zum Beispiel als Loop-Device mit --read-only), dann:

ntfscat -i 2 /dev/loop0p2 > '$LogFile'
ntfscat -i 0 /dev/loop0p2 > '$MFT'

Hängen Sie das Beweisvolume nie „nur mal eben zum Kopieren einer Datei“ beschreibbar ein. Das Einhängen schreibt ins Log.

Volume Shadow Copies

Schattenkopien enthalten ältere Kopien der NTFS-Metadatendateien und damit ältere Zeitfenster des $LogFile. Extrahieren Sie diese aus jedem Snapshot mit denselben Rohzugriffswerkzeugen (oder sichern Sie die Snapshots in Ihrem Imaging-Ablauf) und werten Sie jede Kopie getrennt aus. Beschriften Sie jede Kopie mit dem Erstellungszeitpunkt des Snapshots.

Die Kopie prüfen, bevor Sie gehen

Eine fehlgeschlagene Rohkopie sieht oft wie ein Erfolg aus: Die Datei ist da und hat die richtige Größe. Vier schnelle Prüfungen:

Prüfung	Wie	Schlechtes Zeichen
Signatur	Die ersten 4 Bytes	Nicht `RSTR` (oder `CHKD`)
Nicht mit Nullen gefüllt	Die ersten 4 KiB ansehen	Nur Nullen: Sperre oder Sparse-Lesen fehlgeschlagen
Größe	Mit der Loggröße in der Restart Area vergleichen	Kürzer: abgeschnittene Kopie
Zuordnung	`$MFT` vom selben Volume und Zeitpunkt	Unterschiedliche Sicherungszeitpunkte

xxd -l 16 '$LogFile'      # expect 52 53 54 52  -> "RSTR"
sha256sum '$LogFile' '$MFT' > hashes.txt

Der $LogFile-Parser führt dieselben Prüfungen beim Einlesen durch: Eine Datei, die mit Nullen beginnt, wird gemeldet als „beginnt mit Nullen — die Datei war beim Kopieren vermutlich gesperrt oder wurde noch geschrieben“, eine Kopie, die kürzer als ihre angegebene Größe ist, wird als abgeschnitten markiert, eine CHKD-Restart-Seite wird gemeldet, und eine $MFT ohne $LogFile im selben Ordner wird erklärt statt stillschweigend ignoriert.

Hinweise zur Beweismittelkette

Halten Sie für jede Kopie Werkzeugname und -version, Befehlszeile, Quellvolume, Ziel und Zeitpunkt fest.
Bilden Sie Hashwerte auf dem Sicherungssystem und erneut auf dem Analysesystem.
Wenn Sie von einem laufenden System gesichert haben, schreiben Sie das in den Bericht: Ein live gesichertes $LogFile ist ein bewegliches Ziel, und die neueste Seite existiert womöglich nur im Tail- oder Fast-Page-Bereich (siehe $LogFile-Format 1.1 vs. 2.0: was sich mit Windows 8 ändert).

Nächster Schritt

Öffnen Sie die Dateien im $LogFile-Parser im Browser — es wird nichts hochgeladen — und folgen Sie Ein NTFS-$LogFile Schritt für Schritt analysieren. Für die übrigen Artefakte derselben Sammlung decken der USN-Journal-Parser, der Prefetch-Parser und die Werkzeuge für Datenträgerabbilder aus derselben Familie die nächsten Schritte ab.

Häufige Fragen

Kann ich das $LogFile mit dem Explorer oder dem copy-Befehl kopieren?

Nein. Das $LogFile ist eine NTFS-Metadatendatei, die das Dateisystem geöffnet hält, solange das Volume eingehängt ist, und die vor den normalen Datei-APIs verborgen ist. Lesen Sie es über Rohzugriff auf NTFS (KAPE, Velociraptor, FTK Imager, RawCopy) oder aus einem Image mit icat oder ntfscat.

Warum die $MFT zusammen mit dem $LogFile sichern?

Logeinträge verweisen auf Dateien über die Nummer des MFT-Eintrags. Namen erscheinen im Log nur, wenn eine Datei angelegt, umbenannt oder gelöscht wird; ohne die $MFT desselben Volumes bleiben viele Pfade daher unvollständig.