$LogFile, $UsnJrnl oder $MFT: welches NTFS-Artefakt wann

Q: Was ist der Unterschied zwischen $LogFile und $UsnJrnl?

$UsnJrnl:$J ist ein Änderungsjournal für Anwendungen: ein Eintrag pro Änderung mit Zeitstempel, Reason-Flags, Dateireferenz und Name, oft über Tage oder Wochen. Das $LogFile ist das Crash-Recovery-Log von NTFS: Redo- und Undo-Bytes auf niedriger Ebene für jede Metadatenänderung, ohne eigene Zeitstempel, über Minuten bis Stunden.

TL;DR. Die $MFT sagt Ihnen, was jetzt existiert. $UsnJrnl:$J sagt Ihnen, welche Art von Änderung an welcher Datei wann stattfand, über Tage bis Wochen. Das $LogFile sagt Ihnen, welche Bytes sich genau geändert haben — alte und neue Namen, alte und neue Zeitstempel —, aber nur für die letzten Minuten bis Stunden und ohne eigene Uhr. Beginnen Sie mit der $MFT und dem USN-Journal und gehen Sie dann zum $LogFile für die Fragen, die diese beiden nicht beantworten: „Welcher Wert stand vorher da?“ und „Was ist in der letzten Stunde passiert, das die anderen beiden verloren haben?“

Alle drei liegen auf demselben Volume, beschreiben dieselben Dateien über dieselben MFT-Referenzen und werden routinemäßig gemeinsam gesichert. Austauschbar sind sie nicht. Wer mit dem falschen beginnt, verliert Stunden; wer das dritte ignoriert, verliert Befunde.

Die drei in einer Tabelle

	`$MFT`	`$UsnJrnl:$J`	`$LogFile`
MFT-Eintrag	0	in `$Extend\$UsnJrnl`, Stream `$J`	2
Zweck	Index aller Dateien und Ordner	Änderungsjournal für Anwendungen (Backup, Suche, Replikation)	Crash-Recovery der Metadaten
Einheit	FILE-Record (1 KiB oder 4 KiB)	USN-Eintrag	Logeintrag (Redo + Undo)
Zeitstempel pro Eintrag	Nein (die Zeiten der Datei selbst)	Ja, Zeitpunkt der Änderung	Nein
Namen	Aktuelle `$FILE_NAME`s	Name zum Zeitpunkt der Änderung	Wenn der Name Teil der Änderung ist (Anlegen, Umbenennen, Löschen)
Werte vorher/nachher	Nein	Nein (nur Reason-Flags)	Ja
Typische Historie	Aktueller Zustand + nicht wiederverwendete gelöschte Einträge	Tage bis Wochen	Minuten bis Stunden
Abschaltbar	Nein	Ja (`fsutil usn deletejournal`)	Nein

Die letzte Zeile zählt bei Einbrüchen. Das USN-Journal ist eine optionale Funktion, die ein Administrator — oder ein Angreifer mit Adminrechten — löschen kann. Das $LogFile gehört zur Funktionsweise von NTFS; auf einem eingehängten Volume lässt es sich nicht deaktivieren, nur in der Größe ändern (chkdsk /L, laut Microsofts chkdsk-Referenz).

Was jedes Artefakt bei einer Umbenennung sieht

Nehmen wir ein Ereignis: rc.tmp in C:\Users\Public wird zu rclone.exe.

$MFT im Nachhinein: ein FILE-Record namens rclone.exe, übergeordneter Ordner Public. Der alte Name ist weg, es sei denn, ein veralteter Eintrag im $I30-Slack hat überlebt.
$UsnJrnl:$J: zwei Einträge mit derselben Dateireferenz — RENAME_OLD_NAME mit rc.tmp, dann RENAME_NEW_NAME mit rclone.exe —, jeweils mit Zeitstempel.
$LogFile: ein DeleteIndexEntry, der rc.tmp aus dem Index des übergeordneten Ordners entfernt, ein AddIndexEntry, der rclone.exe hinzufügt, und Änderungen am $FILE_NAME-Attribut im FILE-Record. Die Indexeinträge enthalten vollständige $FILE_NAME-Strukturen, einschließlich der vier $FILE_NAME-Zeitstempel.

Bei einer Umbenennung ist das USN-Journal einfacher und datiert. Das $LogFile gewinnt nur, wenn die USN-Einträge weg sind oder Sie die eingebetteten Werte brauchen.

Was jedes Artefakt sieht, wenn ein Zeitstempel überschrieben wird

Jetzt der Fall, in dem das $LogFile einzigartig ist. Ein Angreifer setzt die Erstellungszeit von m64.exe auf den 2019-03-19.

$MFT: Erstellung in $STANDARD_INFORMATION = 2019-03-19. Erstellung in $FILE_NAME = heute. Diese Abweichung ist ein klassischer Hinweis, aber eben nur ein Hinweis: Auch ein Kopiervorgang, das Entpacken eines Archivs oder ein Installer können seltsame Kombinationen erzeugen.
$UsnJrnl:$J: ein Eintrag mit Reason BASIC_INFO_CHANGE zum Zeitpunkt der Änderung. Sie wissen, dass sich etwas an den Basisinformationen (Zeiten oder Attribute) geändert hat, aber nicht was.
$LogFile: ein UpdateResidentValue auf $STANDARD_INFORMATION, dessen Undo-Bytes die vorherige Erstellungszeit und dessen Redo-Bytes 2019-03-19 enthalten. Das ist das Überschreiben selbst.

Deshalb stützt sich die Timestomping-Analyse auf das Log. Methode und Fehlalarme stehen in Timestomping mit dem NTFS-$LogFile erkennen. Chos Aufsatz von 2013 (Computers & Security 34) argumentiert genauso: Frühere Zeitwerte, die im $LogFile gefunden werden, machen aus einem verdächtigen Zeitstempel einen Beweis.

Wie sie zusammenhängen

Die drei Artefakte teilen sich Schlüssel — David Cowen nannte das die NTFS TriForce:

Schlüssel	In der `$MFT`	In `$UsnJrnl:$J`	Im `$LogFile`
MFT-Eintrag + Sequenznummer	Eintragsnummer, Sequenz im Header	Dateireferenz, Referenz des übergeordneten Ordners	Zieleintrag (aus VCN + Offsets), Indexeinträge
LSN	FILE-Record-Header `0x08`: LSN der letzten protokollierten Änderung	—	Jeder Eintrag
USN	Letzte USN in `$STANDARD_INFORMATION`	Jeder Eintrag	Schreibvorgänge ins USN-Journal werden selbst protokolliert

Die letzte Zeile ist nützlich. Das Readme von LogFileParser weist darauf hin, dass bei aktivem USN-Journal die während der Lebensdauer des Logs geschriebenen USN-Einträge auch im $LogFile stehen, und dekodiert sie in eine eigene CSV. In der Praxis reicht das USN-Journal meist trotzdem weiter zurück, aber für das jüngste Zeitfenster kann das Log eine Lücke füllen.

Welches zuerst? Vier Szenarien

„Welche Dateien hat dieses Konto heute Morgen angelegt?“ Zuerst das USN-Journal (datiert, lange Historie), die $MFT für die Pfade. Das $LogFile nur, wenn der Morgen noch darin enthalten ist.

„Wurde diese Binärdatei zurückdatiert?“ Die $MFT, um die $SI/$FN-Abweichung zu erkennen, dann das $LogFile, um das eigentliche Überschreiben und den ursprünglichen Wert zu finden. Das USN-Journal liefert den Zeitpunkt der BASIC_INFO_CHANGE.

„Der Angreifer hat das USN-Journal gelöscht.“ Das $LogFile für die letzten Minuten bis Stunden; die $MFT für den aktuellen Zustand und gelöschte, aber nicht wiederverwendete Einträge; Volume Shadow Copies für ältere Kopien aller drei.

„Was stand in der gelöschten Textdatei?“ Nur das $LogFile hat eine Chance, und nur wenn die Datei klein genug war, um resident zu sein, und die relevanten Einträge überlebt haben. Siehe Spuren gelöschter Dateien im $LogFile finden.

Werkzeuge für jedes Artefakt

$MFT: jeder MFT-Parser (MFTECmd, analyzeMFT, kommerzielle Suiten).
$UsnJrnl:$J: der USN-Journal-Parser aus derselben Familie im Browser oder MFTECmd. usnparser.com hat auch einen eigenen Vergleich der drei Artefakte, geschrieben aus Sicht des USN-Journals.
$LogFile: der $LogFile-Parser im Browser (legen Sie die $MFT dazu, um vollständige Pfade zu erhalten), LogFileParser, NTFS Log Tracker, TZWorks mala — verglichen in $LogFile-Parser im Vergleich: LogFileParser, NTFS Log Tracker.

Denken Sie daran, die Dateien eines Volumes gemeinsam zu sichern. Ein $LogFile vom Montag und eine $MFT vom Dienstag lösen manche MFT-Einträge in falsche Namen auf, sobald Einträge wiederverwendet wurden.

Häufige Fragen

Was ist der Unterschied zwischen $LogFile und $UsnJrnl?

$UsnJrnl:$J ist ein Änderungsjournal für Anwendungen: ein Eintrag pro Änderung mit Zeitstempel, Reason-Flags, Dateireferenz und Name, oft über Tage oder Wochen. Das $LogFile ist das Crash-Recovery-Log von NTFS: Redo- und Undo-Bytes auf niedriger Ebene für jede Metadatenänderung, ohne eigene Zeitstempel, über Minuten bis Stunden.

Brauche ich das $LogFile noch, wenn ich das USN-Journal habe?

Ja, wenn es um Werte statt um Ereignisse geht. Das USN-Journal sagt, dass sich die Basisinformationen einer Datei geändert haben; das $LogFile kann die alten und neuen Zeitstempel zeigen. Außerdem hilft es für die jüngste Aktivität, wenn das USN-Journal gelöscht oder deaktiviert wurde.

Weiterführende Literatur

Microsoft Learn, Change Journals.
David Cowen, NTFS TriForce — a deeper look inside the artifacts.
Maxim Suhanov, How the $LogFile works?