Beweise gelöschter Dateien mit dem USN Journal wiederherstellen

Die häufigste Frage, die forensische Analysten von nicht-technischen Stakeholdern bekommen, ist eine Variante von "können Sie beweisen, dass diese Datei existierte?". Wenn die Datei von der Festplatte gelöscht wurde, der Papierkorb geleert wurde und genug Zeit vergangen ist, dass der $MFT-Eintrag für etwas anderes wiederverwendet wurde, hängt die Antwort fast immer davon ab, woran sich das USN Journal noch erinnert. Das Journal ist meiner Erfahrung nach der dauerhafteste Zeuge für "hat diese Datei jemals existiert", sobald alles andere gelöscht wurde.

Dieser Beitrag durchläuft, was das Journal über gelöschte Dateien bewahrt, wie man diese Beweise extrahiert und die Fälle, in denen das Journal Ihre letzte Linie ist.

Was das Journal nach der Löschung behält

Wenn eine Datei auf NTFS gelöscht wird, passieren drei Dinge:

1. Der $FILE_NAME-Eintrag im übergeordneten Verzeichnis wird ausgelinkt. Die INDEX_ALLOCATION des Verzeichnisses wird ohne ihn neu geschrieben.
2. Der MFT-Eintrag wird als unbenutzt markiert, aber nicht genullt. Die nächste Datei, die diesem Eintrag zugewiesen wird, überschreibt die Data Runs, Attribute und Zeitstempel.
3. Das USN Journal erhält einen FileDelete | Close-Eintrag, der die Datei, ihre übergeordnete Referenz, ihre MFT-Eintragsnummer und Sequenz sowie den Löschzeitstempel benennt.

Der Journal-Eintrag ist der widerstandsfähigste der drei. Der Verzeichniseintrag verschwindet in dem Moment, in dem der Übergeordnete neu geschrieben wird — manchmal innerhalb von Sekunden auf einem ausgelasteten Volume. Der MFT-Eintrag kann wiederverwendet werden, sobald eine neue Datei erstellt wird — manchmal innerhalb von Minuten. Der Journal-Eintrag sitzt in einem Ringpuffer, der erst nach Tagen oder Wochen umläuft.

Für vor Tagen gelöschte Dateien gibt Ihnen das Journal typischerweise:

• Den Dateinamen als UTF-16 LE-Blatt. Nur das Blatt, kein Pfad.
• Die MFT-Referenznummer des übergeordneten Verzeichnisses. Kombiniert mit einer geparsten $MFT löst sie sich zu einem Pfad auf.
• Den Löschzeitstempel in FILETIME UTC.
• Die MFT-Eintragsnummer und Sequenznummer, die die Datei belegte. Nützlich für das Querverweisen mit extrahierten Artefakten und $LogFile-Vor-Bildern.
• Eine Lebenszyklus-Spur. Die FileCreate-, DataExtend-, BasicInfoChange- und Rename-Einträge auf derselben FileReferenceNumber sagen Ihnen, wann die Datei erstellt wurde, wie sie geschrieben wurde und ob ihre Zeitstempel vor der Löschung jemals modifiziert wurden.

Ein Vier-Feld-Tupel — MFT-Referenz, Dateiname, übergeordnete Referenz, Lösch-FILETIME — plus ein Erstellungsereignis aus früher im selben Journal reicht in der Regel aus, um einen Legal Hold zu erfüllen oder eine tiefere Untersuchung zu verankern. Meistens erhalten Sie auch den FileCreate-Eintrag aus demselben $J, was Ihnen das Alter der Datei und einen Erstellungszeitstempel unabhängig von $STANDARD_INFORMATION gibt.

Ein minimaler Recovery-Workflow

Mit einem geparsten Journal und einer geparsten $MFT (siehe die Extraktionsanleitung für beide):

1. Nach FileDelete filtern im interessierenden Zeitfenster. Nach Zeitstempel sortieren. Das ist Ihre Hauptliste der zu triagierenden Löschungen.
2. Nach FileReferenceNumber gruppieren für jede wichtige Löschung. Sie erhalten die vollständige Historie der Datei: Erstellung, Schreibvorgänge, Rename-Paare, Attributänderungen und schließlich die Löschung.
3. Den übergeordneten Pfad über $MFT auflösen. Der Parser auf dieser Seite tut das automatisch, wenn beide Dateien bereitgestellt werden. Ohne $MFT halten Sie beim Blatt-Dateinamen an.
4. $LogFile gegenprüfen, wenn die Löschung sehr kürzlich ist. Es kann noch das "Vorher"-Bild des Verzeichniseintrags enthalten und einen zweiten unabhängigen Zeugen für die Existenz der Datei liefern.

Die Kombination "MFT-Referenz, Dateiname, übergeordneter Pfad, Erstellungszeitstempel, Löschzeitstempel, vollständige Lebenszyklus-Spur" reicht in der Regel aus, um einen verteidigungsfähigen Bericht zu schreiben.

Wenn der übergeordnete Pfad nicht aufgelöst werden kann

Manchmal wurde der übergeordnete MFT-Eintrag selbst recycelt, wenn Sie hinschauen — häufig auf dateisystem-belasteten Hosts, besonders Dateiservern und CI-Runnern. Das Journal gibt Ihnen immer noch den Dateinamen und die übergeordnete Referenznummer, aber $MFT weiß nicht mehr, auf welchen Ordner diese Referenz früher zeigte.

Drei Rückfälle lösen den Pfad in der Regel:

Frühere RenameNewName-Einträge auf derselben übergeordneten Referenz. Gruppieren Sie alle Journal-Einträge nach übergeordneter Referenz. Jedes frühere RenameNewName, dessen neuer Übergeordneter mit Ihrer unaufgelösten Referenz übereinstimmt und dessen eigener Pfad aufgelöst wird, sagt Ihnen, was dieser Ordner früher war.

$LogFile-Index-Einträge. Das Crash-Recovery-Log enthält Vor-Bilder von INDEX_ALLOCATION-Updates. Joachim Metzs libfsntfs und Jonas Schichts LogFileParser extrahieren sie. Bei einer kürzlichen genug Löschung ist das Vor-Bild des Verzeichniseintrags noch in $LogFile und löst sich zu einem Pfad auf.

Geschwisterdateien in derselben übergeordneten Referenz. Gruppieren Sie alle Journal-Einträge nach übergeordneter Referenz. Wenn eines der Geschwister in ein Verzeichnis umbenannt wurde, dessen MFT-Eintrag noch gültig ist, pivotieren Sie darüber: Der alte Übergeordnete zum Zeitpunkt der Umbenennung ist Ihr unbekannter Ordner.

Wenn keines davon funktioniert, wird der Parser die Datei als "Dateiname: notes.docx, übergeordneter: 1234-5" ohne aufgelösten Pfad zum Vorschein bringen. Das ist beabsichtigt. Einen Pfad zu erfinden, den Sie nicht verifizieren können, ist schlimmer als zuzugeben, dass einer fehlt.

"Gewischt" bedeutet nicht weg

Datei-Shredder-Tools — CCleaners sichere Löschung, Eraser, BleachBit, sdelete — überschreiben den Dateiinhalt und löschen ihn dann. Sie hinterlassen eine lautere Journal-Spur, keine leisere:

• Mehrere DataOverwrite | Close-Einträge auf der Datei vor ihrem FileDelete | Close weisen auf absichtliches Überschreiben von Inhalt hin. Normale Löschung produziert keine Überschreibungen.
• Ein FileCreate plus DataOverwrite plus FileDelete auf derselben Datei innerhalb von Sekunden ist die kanonische Beweis-Vernichtungs-Signatur.
• Wo der Shredder auch Slack Space gewischt hat, indem er Füller-Dateien geschrieben und dann gelöscht hat, haben diese Füller-Dateien ihre eigenen Erstellungs-/Erweiterungs-/Überschreibungs-/Löschsequenzen — ein Schwarm von Einträgen um den Moment der Vernichtung.

Die MITRE-ATT&CK-Zuordnung ist T1485 Data Destruction für die Inhaltsüberschreibung und T1070.004 File Deletion für die Löschung selbst. Auf einem Host, bei dem Sie absichtliche Beweis-Vernichtung vermuten, gibt Ihnen das Journal oft einen engeren Zeitstempel als jedes andere Artefakt.

Was ist mit dem Dateiinhalt

Das USN Journal trägt nie Inhalt. Nur Metadaten über Operationen. Wenn Sie Bytes zurückbrauchen, zeigt Ihnen das Journal die Orte, wo Sie suchen müssen:

• Die MFT-Eintragsnummer der gelöschten Datei. Wenn der Eintrag nicht wiederverwendet wurde, hält $MFT noch die Data Runs und der Inhalt kann über The Sleuth Kits icat oder X-Ways wiederherstellbar sein.
• Die $LogFile-Vor-Bilder für sehr kürzliche Löschungen.
• Volume Shadow Copies (VSS), falls sie auf dem Host existieren. Die gelöschte Datei kann in einem früheren Snapshot leben. vssadmin list shadows auf einem Live-Host oder vshadowmount aus libyal auf einem Image bringen sie an die Oberfläche.
• Anwendungsspezifische Speicher. OneDrives Online-Papierkorb, der Office-"AutoSaved"-Ordner unter \Users\<u>\AppData\Roaming\Microsoft\Office\UnsavedFiles\, Browser-Caches (das Browser-Forensik-Tooling deckt das ab), Outlook OST/PST-gestagte Kopien.
• Die Pagefile und ein RAM-Dump, wenn die Datei kürzlich genug offen war.

Die Rolle des Journals ist, Ihnen zu sagen, dass eine Datei existierte und wann sie gelöscht wurde. Inhaltswiederherstellung ist nachgelagert.

Praktische Grenzen

Ringpuffer-Fenster. Dateien, die gelöscht wurden, bevor das Journal über den ältesten Eintrag, den Sie sehen können, rollte, sind aus diesem Artefakt verschwunden. Ziehen Sie $LogFile und Shadow Copies als Ergänzungen.

Operationen, die das Journal nicht treffen. Filesystem-Level-Verschlüsselungsänderungen, die nur Attribute aktualisieren, Sparse-Region-Schreibvorgänge, die nur die Allocation-Map berühren, und einige NTFS-Reparse-Point-Manipulationen können keine DataExtend- oder DataOverwrite-Einträge produzieren. Das Journal sieht, was NTFS zu loggen entscheidet.

FileDelete ohne vorangehendes FileCreate. Bedeutet, dass die Datei vor dem aktuellen ältesten Eintrag des Journals erstellt wurde. Ihr Lebenszyklus in $J ist teilweise, aber der Löschzeitstempel und die übergeordnete Referenz verankern immer noch einen Bericht.

Bind-gemountete oder volume-gemountete Freigaben. Wenn die Daten auf einem entfernten Dateisystem leben, weiß das Journal auf Ihrem Host nur über lokale Handles Bescheid. Ziehen Sie das Journal vom tatsächlichen hostenden Dateisystem.

Weiterführende Literatur

• Microsoft Learn — Change Journals deckt die API-Oberfläche und den Lebenszyklus ab, der FileDelete-Einträge produziert.
• The Sleuth Kit Manpages — icat und fls für die Inhaltswiederherstellung gegen noch zugewiesene MFT-Einträge.
• SANS DFIR — das Windows Forensic Analysis Poster setzt das Journal in Kontext mit $LogFile, Volume Shadow Copies und anderen Lösch-Wiederherstellungs-Artefakten auf einer einzigen Seite.
• Joachim Metzs libfsntfs — die offene Referenz für die $LogFile-Vor-Bild-Extraktion, wenn die Löschung frisch ist und der Verzeichniseintrag noch nicht anderweitig überschrieben wurde.