← Zurück zum Blog

Mit dem USN-Journal Spuren gelöschter Dateien wiederherstellen

Wenn eine Datei gelöscht, der Papierkorb geleert und der MFT-Eintrag wiederverwendet wurde — das USN-Journal kennt häufig noch Namen, Eltern und Zeitlinie. So holt man die Spuren heraus.

4 Min. Lesezeit

Die häufigste Frage, die forensische Analysten von Nicht-Technikern hören, ist eine Variante von „Kannst du beweisen, dass diese Datei existiert hat?". Wenn die Datei vom Datenträger gelöscht, der Papierkorb geleert und genug Zeit vergangen ist, dass der $MFT-Eintrag überschrieben wurde, hängt die Antwort meist davon ab, woran sich das USN-Journal noch erinnert.

Dieser Beitrag zeigt, was das Journal über gelöschte Dateien aufbewahrt, wie man diese Spuren herauszieht und in welchen Situationen das Journal der letzte Zeuge ist.

Was das Journal nach dem Löschen behält

Beim Löschen auf NTFS passiert mehreres:

  1. Der $FILE_NAME-Eintrag im Elternverzeichnis wird ausgehängt.
  2. Der MFT-Eintrag wird als unbenutzt markiert — aber nicht genullt.
  3. Das USN-Journal bekommt einen FileDelete | Close-Eintrag, der den Dateinamen, die Elternreferenz, die MFT-Entry-Nummer und den Zeitstempel benennt.

Der Journal-Eintrag ist der widerstandsfähigste der drei. Der Verzeichniseintrag verschwindet, sobald der Eltern­ordner umgeschrieben wird; der MFT-Eintrag kann wiederverwendet werden, sobald eine neue Datei angelegt wird; der Journal-Eintrag liegt in einem Ringpuffer, der erst nach Tagen oder Wochen Aktivität rollt.

Für Dateien, die vor Tagen gelöscht wurden, liefert dir das Journal also häufig:

  • Den Dateinamen (nur den Blattname, nicht den vollständigen Pfad).
  • Die MFT-Referenz des Elternverzeichnisses — kombiniert mit einer geparsten $MFT ergibt das den Pfad.
  • Den Lösch-Zeitstempel in UTC.
  • Die MFT-Entry-Nummer, die die Datei belegte (nützlich für den Querbezug zu carvbaren Artefakten).
  • Eine Lebenszyklus-Spur: die FileCreate-, DataExtend- und BasicInfoChange-Einträge vor dem Löschen sagen dir, wann die Datei angelegt, wie sie geschrieben und ob ihre Zeitstempel je verändert wurden.

Ein minimaler Recovery-Workflow

Mit einem geparsten Journal (der Parser dieser Seite oder usnrs funktionieren; siehe den Extraktions-Leitfaden, um $J und $MFT zu erhalten):

  1. Nach FileDelete filtern, um jede Löschung im Fenster sichtbar zu machen. Nach Zeitstempel sortieren.
  2. Für jede interessante Löschung nach FileReferenceNumber gruppieren, um die vollständige Historie der Datei zu sehen — Anlegen, Schreibvorgänge, Rename-Paare, Attributänderungen und schließlich das Löschen.
  3. Den Elternpfad über die $MFT auflösen. Mit beiden Dateien übergeben macht das unser Parser automatisch.
  4. $LogFile querchecken, wenn die Löschung sehr frisch ist — es kann noch das „Vorher"-Bild des Verzeichnis­eintrags enthalten und dir einen zweiten, unabhängigen Zeugen geben.

Die Kombination „Ich habe eine MFT-Referenz, einen Dateinamen, einen Elternordner, einen Erstellungs- und einen Lösch-Zeitstempel" reicht meist für einen Legal Hold oder als Ankerpunkt für eine tiefere Untersuchung.

Wenn der Elternpfad nicht auflösbar ist

Manchmal wurde der MFT-Elterneintrag selbst bereits wiederverwendet, wenn du nachschaust — besonders auf sehr aktiven Hosts. Dann gibt dir das Journal Dateiname und Elternreferenz, aber $MFT weiß nicht mehr, welchem Ordner diese Nummer einmal entsprach.

Drei Hilfen typischerweise:

  • Frühere RenameNewName-Einträge auf der Elternreferenz — sie können einen zum Renaming-Zeitpunkt auflösbaren Elternpfad tragen.
  • $LogFile-Index-Einträge — undokumentiert, aber von libfsntfs abgedeckt.
  • Geschwisterdateien unter derselben Elternreferenz — alle Journal-Einträge nach Eltern gruppieren. Wenn eines der Geschwister in ein Verzeichnis umbenannt wurde, dessen MFT-Eintrag noch gültig ist, kannst du darüber pivotieren.

Das ist auch der Grund, warum vorläufige Berichte dieses Tools „filename: notes.docx" ohne Pfad sagen: wir erfinden keinen Pfad, den wir nicht verifizieren können.

„Gewiped" heißt nicht „weg"

Eine Handvoll Datei-Shredder-Tools (CCleaner, Eraser, BleachBit) überschreiben den Dateiinhalt und löschen ihn dann. Sie hinterlassen dieselben Journal-Einträge wie ein normales Löschen plus die Overwrite-Einträge. Das Journal macht „sicheres Löschen" damit laut, nicht leise:

  • Mehrere DataOverwrite | Close-Einträge auf der Datei vor ihrem FileDelete | Close zeigen vorsätzliches Überschreiben.
  • Ein FileCreate und ein FileDelete derselben Datei innerhalb von Sekunden, mit Overwrites dazwischen, ist das kanonische Muster.
  • Wenn der Shredder auch Slack Space säuberte, indem er temporäre Dateien schrieb, haben diese Temps ihre eigenen Create/Extend/Overwrite/Delete-Sequenzen — ein Schwarm von Einträgen rund um den Moment der Beweisvernichtung.

Die zugehörige MITRE-ATT&CK-Technik ist T1485 Data Destruction und T1070.004 File Deletion.

Und der Inhalt der Datei?

Das USN-Journal trägt nie Inhalte — nur Metadaten zu Operationen. Wenn du Bytes wiederhaben willst, zeigt das Journal dir den Weg:

  • Die MFT-Entry-Nummer der gelöschten Datei. Wenn der Eintrag noch nicht wiederverwendet wurde, hält die $MFT noch die Data Runs, und der Inhalt ist über icat aus The Sleuth Kit oder X-Ways evtl. wiederherstellbar.
  • Die $LogFile-Vorher-Bilder für ganz frische Löschungen.
  • Volume Shadow Copies (VSS), falls vorhanden — die gelöschte Datei lebt vielleicht in einem früheren Snapshot.
  • Anwendungs-spezifische Speicher — OneDrive-Papierkorb, Office-„Autosaved"-Ordner, Browser-Caches.

Die Rolle des Journals hier ist zu sagen, dass eine Datei existiert hat und wann sie gelöscht wurde — der Rest der Recovery ist nachgelagert.

Praktische Grenzen

  • Das Journal hat ein Zeitfenster. Dateien, die vor dem Wrappen des Ringpuffers auf den ältesten Eintrag, den du hast, gelöscht wurden, sind in diesem Artefakt schlicht weg. Zieh $LogFile und Shadow Copies als Ergänzung.
  • Einige Operationen berühren das Journal nicht: dateisystemweite Verschlüsselungsänderungen, Schreibvorgänge in sparse-Regionen, die nur die Allocation-Map antasten, und NTFS-Reparse-Point-Manipulationen können DataExtend/DataOverwrite-Einträge unter Umständen nicht erzeugen.
  • Ein FileDelete ohne vorangehendes FileCreate im Fenster bedeutet, dass die Datei vor dem ältesten Journal-Eintrag angelegt wurde — der Lebenszyklus ist unvollständig, aber den Lösch-Zeitstempel kannst du immer noch als Anker setzen.

Für breiteren Artefakt-Kontext siehe das SANS-Poster Windows Forensic Analysis und die Microsoft-Learn-Change-Journal-Referenz.