Spuren gelöschter Dateien im $LogFile finden

TL;DR. Eine Löschung im $LogFile besteht typischerweise aus einem DeleteIndexEntry* (Name wird aus dem übergeordneten Ordner entfernt), gefolgt von DeallocateFileRecordSegment (FILE-Record wird freigegeben). Diese Logeinträge – plus die Erstellung der Datei, falls sie noch im Log steht – liefern Namen, übergeordneten Ordner, MFT-Eintrag und Sequenznummer, $FILE_NAME-Zeitstempel und Größen, oft die letzten $STANDARD_INFORMATION-Werte, manchmal Data Runs und bei winzigen Dateien sogar den Inhalt. Einen Löschzeitpunkt liefert das Log nicht; mehr als „zu diesem oder nach dem letzten bekannten Zeitstempel“ ist nicht drin. Dateien, die im Papierkorb landen, sind Umbenennungen, keine Löschungen.

Kurzlebige Dateien sind das Lieblingswerkzeug von Angreifern: herunterladen, entpacken, ausführen, löschen. Bis Sie die Platte sichern, ist der FILE-Record wiederverwendet, der $I30-Slack überschrieben, und das USN-Journal meldet FILE_DELETE mit einem Namen und sonst nichts. Das $LogFile kann die Struktur der Datei dagegen noch so enthalten, wie NTFS sie zuletzt gesehen hat – für die letzten Minuten bis Stunden.

Was eine Löschung ins Log schreibt

Schritt	Operation	Was die Bytes enthalten
Name wird aus dem Ordner entfernt	`DeleteIndexEntryRoot` oder `DeleteIndexEntryAllocation`	Der entfernte Indexeintrag: Dateireferenz (Eintrag + Sequenz) und ein eingebettetes `$FILE_NAME` mit Elternreferenz, Name, vier Zeitstempeln, zugewiesener und tatsächlicher Größe, Flags
FILE-Record wird freigegeben	`DeallocateFileRecordSegment`	Ziel-Eintrag; über die Undo-Seite kann NTFS den Record wiederherstellen
Bit in der MFT-Bitmap wird gelöscht	`ClearBitsInNonresidentBitMap`	Welcher MFT-Eintrag frei wurde
Cluster werden freigegeben	`ClearBitsInNonresidentBitMap` auf `$Bitmap`	Welche Cluster frei wurden (nicht residente Dateien)

Ob der entfernte Indexeintrag auf der Redo- oder der Undo-Seite steht, ist eines der Details, die Parser unterschiedlich behandeln; der Browser-Parser probiert beide. Die Operationen selbst behandelt der Artikel Redo- und Undo-Operationen im NTFS-$LogFile erklärt.

Was sich rekonstruieren lässt

Name und Ort. Aus dem Indexeintrag, auch wenn die Erstellung schon aus dem Log gefallen ist. Der übergeordnete Ordner ist eine MFT-Referenz; lösen Sie sie mit der $MFT desselben Volumes auf, sonst sehen Sie [MFT #n] für unbekannte Ordner.

Identität. MFT-Eintrag und Sequenznummer. Wird ein Eintrag wiederverwendet, erhöht NTFS die Sequenznummer (wie das LogFileParser-Readme für seine Dateinamen-Historie festhält). Eintrag plus Sequenz unterscheidet die gelöschte Datei also von dem, was heute in diesem Eintrag steht.

Zeiten. Die $FILE_NAME-Zeitstempel aus dem Indexeintrag und – falls das Log noch ältere Einträge zu diesem MFT-Eintrag enthält – die letzten $STANDARD_INFORMATION-Werte. Keiner davon ist der Löschzeitpunkt.

Größen. Zugewiesene und tatsächliche Größe aus dem $FILE_NAME im Indexeintrag. Vorsicht damit: Die $FILE_NAME-Größen in Verzeichniseinträgen werden nicht immer aktuell gehalten.

Data Runs. Stehen die Erstellung der Datei (InitializeFileRecordSegment, CreateAttribute) und spätere UpdateMappingPairs-Einträge noch im Log, lassen sich ihre Cluster-Runs rekonstruieren. LogFileParser setzt das um und dokumentiert die Wiederherstellung fragmentierter gelöschter Dateien, deren FILE-Record überschrieben war – vorausgesetzt, die Cluster selbst wurden nicht wiederverwendet.

Inhalt (nur kleine Dateien). Eine Datei, die klein genug ist, um resident zu sein, speichert ihren Inhalt im FILE-Record. Überlebt das Record-Abbild oder das CreateAttribute für ihr $DATA im Log, dann auch der Inhalt. Das ist Glückssache: Der Autor von LogFileParser merkt an, dass unter modernen Windows-Versionen spätere Änderungen an residenten Daten in der Regel nur als „es hat sich etwas geändert“ protokolliert werden, ohne die neuen Bytes.

Löschzeitpunkt: was sich sagen lässt und was nicht

Logeinträge haben keine Uhr. Für eine Löschung ist die beste Schranke aus dem Log allein „zum oder nach dem jüngsten bekannten Zeitstempel dieser Datei“ – meist ihr letzter $SI-Wert für Änderung bzw. MFT-Änderung. Der Browser-Parser kennzeichnet solche Ereignisse mit „letzte bekannte Zeit — zu diesem Zeitpunkt oder danach gelöscht“.

Für eine echte Uhrzeit korrelieren Sie:

den FILE_DELETE-Eintrag im USN-Journal für dieselbe Dateireferenz (USN-Journal-Parser);
ein benachbartes Ereignis im Log, das doch eine Zeit trägt (Reihenfolge nach LSN);
Security- oder Sysmon-Ereignisse zur Prozessaktivität im selben Zeitraum (EVTX-Parser).

Papierkorb: eine Verschiebung, keine Löschung

Wer im Explorer ohne Umschalttaste löscht, verschiebt die Datei unter einem $R…-Namen nach $Recycle.Bin\<SID>\ und erzeugt dazu eine $I…-Datei mit Originalpfad und Löschzeitpunkt. Im $LogFile erscheint das als Umbenennung/Verschiebung nach $Recycle.Bin plus Erstellung der $I-Datei, nicht als Freigabe. Die eigentliche Freigabe folgt erst, wenn der Papierkorb geleert wird. Die $I-Datei ist klein und resident, ihr Inhalt kann also ebenfalls im Log auftauchen; sauber auswerten lässt sie sich mit dem Papierkorb-Parser.

Durchgerechnetes Beispiel (synthetisches Sample)

Im Sample des Parsers (synthetisch, fiktiver Host FIN-WKS-07):

LSN	Ereignis	Detail
117494	Angelegt	`\Users\svc_backup\Desktop\creds.txt`, `$FN` erstellt 10:38:10.5119430
117577	Residente Daten geschrieben	Erste Bytes der Datei (eine fingierte Notiz mit Zugangsdaten, als SYNTHETIC markiert)
117610	`$SI`-Änderung	Geändert / MFT geändert / Zugriff → 10:38:27.7024018
117804	Gelöscht	Derselbe Eintrag; Zeit „letzte bekannte — zu diesem Zeitpunkt oder danach gelöscht“ 10:38:27.7024018

Zwischen Erstellung und Löschung zeigt das Log außerdem eine in Recent angelegte .lnk – eine Spur für den LNK-Parser. In einem echten Fall würden Sie jetzt den USN-Eintrag FILE_DELETE suchen, um die Löschung zu datieren, und den Inhalt in anderen Kopien (Backups, Cloud-Synchronisierung, Arbeitsspeicher: RAM-Parser).

Dasselbe Sample enthält auch eine harmlose Löschung: \Windows\Temp\~DF3A1B7C2E.TMP, innerhalb einer Minute angelegt und gelöscht. Temporäre Dateien entstehen und verschwinden ständig; die Markierung „Löschung“ ist eine Triage-Hilfe, kein Befund.

Wo es an Grenzen stößt

Aufbewahrung. Eine Löschung von gestern auf einem Systemvolume ist so gut wie sicher weg. Siehe Wie weit reicht das $LogFile zurück? Grenzen und Fallstricke.
Gruppierung. Zu einer Löschung, deren Erstellung außerhalb des Logs liegt, gibt es weniger Fakten; ein Parser, der nach Nähe gruppiert (wie derzeit der Browser-Parser), kann benachbarte Logeinträge falsch zuordnen. Prüfen Sie die Rohdaten.
Wiederverwendete Einträge. Pfade aus einer später gesicherten $MFT können den neuen Bewohner eines Eintrags oder übergeordneten Ordners benennen. Vergleichen Sie Sequenznummern; der Browser-Parser prüft sie beim Auflösen von Pfaden aus der $MFT noch nicht.
Validierung. Der Browser-Parser ist nur an synthetischen Logs validiert; bestätigen Sie relevante Löschungen mit LogFileParser oder NTFS Log Tracker ($LogFile-Parser-Vergleich).

Häufig gestellte Fragen

Kann das $LogFile gelöschte Dateien zeigen?

Ja, sofern die Löschung so frisch ist, dass sie noch im zirkulären Log steht. Das Entfernen des Indexeintrags und die Freigabe des FILE-Records enthalten Namen, übergeordneten Ordner, MFT-Eintrag und Sequenznummer, die $FILE_NAME-Zeitstempel und die Größen der Datei.

Kann ich den Inhalt einer gelöschten Datei aus dem $LogFile wiederherstellen?

Selten, und nur bei kleinen residenten Dateien, deren Inhalt in einem FILE-Record-Abbild oder einer Attributerstellung steckt, die noch im Log steht. Bei größeren Dateien kann das Log Data Runs enthalten, die auf Cluster zeigen – das hilft beim Carving, falls die Cluster nicht wiederverwendet wurden.