Der einzelne nützlichste Satz, den ich einem neuen Examiner über NTFS bieten kann: Löschen ist keine Löschung. Es ist eine Flag-Änderung und ein Index-Update. Der MFT-Datensatz der Datei bleibt erhalten. Die Datencluster werden in $Bitmap als frei markiert. Nichts wird überschrieben, bis etwas anderes diesen Platz beansprucht.
Die Leute wissen das abstrakt. Den Fehler, den ich sie immer wieder machen sehe, ist anzunehmen, dass das Überlebensfenster auf jeder Maschine großzügig ist. Ist es nicht. Auf einem stark beschäftigten Dateiserver wird der Slot innerhalb von Minuten wiederverwendet. Auf einer Workstation, die niemand am Wochenende benutzt, kann der gelöschte Datensatz einen Monat herumliegen. Du musst wissen, mit welchem Host-Typ du es zu tun hast, bevor du dich auf eine Geschichte einlässt, ob etwas noch wiederherstellbar ist.
Was der Datensatz noch enthält
Ein gelöschter MFT-Datensatz sieht strukturell identisch zu einem aktiven aus. Das IN_USE-Bit (Bit 0 im Flags-Feld an Offset 0x16) ist gelöscht. Alles andere ist, falls der Datensatz nicht beansprucht wurde, das, was NTFS zuletzt geschrieben hat:
$STANDARD_INFORMATION(Attributtyp0x10): alle vier Zeitstempel in SI, die DOS-Flags, die Sicherheitsdeskriptor-Referenz, die Besitzer-ID, der USN-Verweis. Die Zeitstempel überleben das Löschen unversehrt. Beachte, dass das SI, das du siehst, dem entspricht, wie die Datei zum Zeitpunkt der Löschung aussah, nicht wann sie ursprünglich erstellt wurde (Windows aktualisiert SI ständig, während die Datei lebt).$FILE_NAME(0x30): eines pro hartem Link, plus der 8.3-Kurzname auf Volumes, bei denendisable8dot3deaktiviert ist. Die Verzeichnisreferenz des übergeordneten Verzeichnisses ist die MFT-Datensatznummer des Verzeichnisses, in dem die Datei lebte. Diese Referenz bleibt, selbst wenn das Verzeichnis selbst später gelöscht wurde, weshalbflsund MFTECmd Pfade in gelöschte Verzeichnishierarchien rekonstruieren können.$DATA(0x80): bei residenten Dateien (unter ~700 Bytes Daten) liegen die Bytes selbst inline im Datensatz. Bei nicht-residenten Dateien verweist die Runliste auf die Cluster, die die Datei waren. Diese Cluster sind nicht mehr als alloziert markiert, aber sie wurden nicht genullt.$ATTRIBUTE_LIST(0x20), falls vorhanden, mit Verweisen auf alle Erweiterungsdatensätze, die die Datei verwendet hat. Diese Erweiterungsdatensätze sind selbst gelöscht, aber bis zur Wiederbeanspruchung noch parsbar.
Die Sequenznummer ist das, was die Analyse gelöschter Dateien verteidigbar macht. Jeder Datensatz trägt eine 16-Bit-Sequenznummer, die bei jeder Wiederverwendung des Slots inkrementiert wird. Ein USN-Journal-Eintrag oder eine $LogFile-Referenz, die auf Datensatz 12345 Sequenz 3 verweist, verweist weiterhin auf Sequenz 3, auch nachdem der Slot jetzt Sequenz 4 ist. Diese Diskrepanz sagt dir, dass der Slot seitdem wiederverwendet wurde.
Wann der Slot tatsächlich verschwindet
Zwei unabhängige Ereignisse beenden die Wiederherstellbarkeit:
Der MFT-Datensatzplatz wird wiederverwendet. NTFS hat hier keine feste Allokationsstrategie. In der Praxis, wenn eine neue Datei einen Datensatz braucht, schaut der Treiber in $MFT:$BITMAP nach dem niedrigsten freien Datensatz und verwendet ihn. Gelöschte Datensätze werden ungefähr der Reihe nach zurückgewonnen. Auf einem stark genutzten Volume bewegt sich diese Reihenfolge schnell. Die MFT selbst wächst nur; sie schrumpft nie, sodass alte gelöschte Datensätze weit oberhalb der aktuellen High-Water-Mark jahrelang überleben können.
Die Datencluster werden überschrieben. Unabhängig vom Datensatz. Die Cluster wurden in $Bitmap als frei markiert, sodass jeder Allokator sie beanspruchen kann. Bei einer frisch gelöschten Datei müssen beide Ereignisse eintreten, bevor die Wiederherstellung aussichtslos wird. Ich habe Datensätze überleben sehen, während Cluster längst weg waren (du stellst nur die Metadaten und residenten Daten wieder her), und das Gegenteil (Datensatz wurde wiederverwendet, aber die Cluster enthalten noch die Originalbytes und können geborgen werden).
Es gibt keinen klaren Timer für beides. "Wie lange halten gelöschte Dateien auf NTFS" hat die gleiche ehrliche Antwort wie "wie lange ist ein freier Platz an der Bar verfügbar": bis ihn jemand nimmt.
Was die Journale beitragen
Die MFT zeigt dir die Gegenwart. Das USN-Journal zeigt dir das Verb. Ein FILE_DELETE-USN-Datensatz benennt die Datei, das übergeordnete Verzeichnis und den Zeitstempel des Löschens. Selbst wenn der MFT-Slot seitdem wiederverwendet wurde, bewahrt der USN-Eintrag noch den alten Namen und das ursprüngliche Datensatz/Sequenz-Paar. Paare die beiden und du bekommst so etwas wie:
2026-04-12T13:08:11Z USN FILE_DELETE | CLOSE rec=44231 seq=7 path=\Users\bob\Documents\secrets.zip
2026-04-12T13:08:11Z MFT rec=44231 IN_USE=0 seq=7 (immer noch lesbar, gelöscht)
2026-04-12T13:08:11Z MFT FN parent=12, name=secrets.zip
Das ist eine rekonstruierbare Antwort auf "wie sah diese Datei zum Zeitpunkt der Löschung aus", selbst wenn die Datei sonst weg ist. $LogFile fügt Detail auf Transaktionsebene in den Sekunden auf beiden Seiten hinzu: das Löschen ist eingeklammert von einem DeleteAttribute- und DeallocateFileRecordSegment-Paar, und du kannst meist die umgebenden Operationen identifizieren.
Wenn VSS aktiv war und ein Snapshot von vor dem Löschen existiert, zeigt das $MFT des Snapshots immer noch IN_USE=1 für denselben Datensatz/Sequenz, und die Datencluster wurden durch Copy-on-Write erhalten. Siehe Volume Shadow Copy und $MFT für die Extraktionsdetails.
Die Fälle, die Leute falsch verstehen
Secure-Delete-Tools. SDelete im Standardmodus überschreibt die Datencluster, tut aber nichts am MFT-Datensatz. Du erhältst einen gelöschten Datensatz mit vollständigem $FILE_NAME, vollständigem $STANDARD_INFORMATION und $DATA, das auf genullte Cluster verweist. Name und Zeitstempel überleben absolut. Das stolpert Benutzer, die erwartet hatten, dass SDelete gründlicher ist, als es ist.
Dateilöschung über harte Links. Das Entfernen eines harten Links löscht die Datei nicht; das $FILE_NAME-Attribut für diesen Link wird entfernt und die Hardlink-Anzahl sinkt. Die Datei selbst wird erst gelöscht, wenn der letzte Link entfernt ist. Wenn du einen gelöschten MFT-Datensatz mit hardlink_count von null und ohne verbleibendes $FILE_NAME siehst, wurde die Datei wirklich gelöscht. Wenn du einen Datensatz mit einer Hardlink-Anzahl ungleich null und einem fehlenden $FILE_NAME siehst, war die Löschung teilweise.
Vor dem Löschen umbenannte Dateien. Manche Dropper benennen ihre Staging-Datei in einen harmlosen Namen um, kurz bevor sie sie löschen, in der Hoffnung, dass der überlebende $FILE_NAME unschuldig wirkt. Das USN-Journal bewahrt das Paar RENAME_OLD_NAME und RENAME_NEW_NAME, sodass du den ursprünglichen Namen von dort wiederherstellen kannst. Die MFT allein zeigt nur den endgültigen Namen.
Der Papierkorb ist kein Löschen. In den Papierkorb verschobene Dateien werden umbenannt und nach \$Recycle.Bin\<SID>\ verschoben. Der MFT-Datensatz bleibt IN_USE=1 und die Datei ist unter einem $R<ID>-Namen intakt. Der $I<ID>-Begleitdatensatz speichert den ursprünglichen Pfad. Das Leeren des Papierkorbs löscht dann normal.
Tools, die gelöschte Datensätze gut lesen
Für die Triage greife ich zu einem von:
- MFTECmd mit
--de 1(Einträge ablegen) oder einfach ungefilterte Ausgabe, nachgelagert gefiltert. Markiert residente Daten und gibt dir die Sequenznummer. omerbenamram/mft_dumpmit-o json. Sequenznummer, Resident-Flag, vollständige Attributliste. Gut, um in ein Skript zu pipen, das Datensätze zieht, bei denenIN_USE=0undseqeiner USN-Referenz entspricht.- Sleuth Kits
fls -m -rfür ein Bodyfile, das gelöschte Einträge enthält. Old-School, funktioniert noch.icat -rstellt die Daten für nicht-residente Dateien wieder her, deren Cluster intakt sind. - analyzeMFT, wenn du speziell eine reine Python-Option willst und die Geschwindigkeit dir egal ist.
Der Browser-Parser auf dieser Seite filtert mit einem Klick auf IN_USE=0 und zeigt residente Daten inline an. Wenn das Volume wichtig war, die Datei klein war und der Slot nicht wiederverwendet wurde, hast du die Bytes oft direkt in der Tabelle vor dir.
Was du immer noch nicht aus der MFT allein beantworten kannst
Die MFT sagt dir, dass ein Datensatz existiert und gelöscht wurde. Sie sagt dir nicht, wer ihn gelöscht hat. Dafür willst du Security 4663 (Object Access), falls SACLs konfiguriert waren, oder Sysmon Event ID 23 (FileDelete), das den Benutzer und den Prozess protokolliert. Auf den meisten Hosts ist keines davon aktiviert. In diesem Fall greifst du auf bestätigende Beweise zurück: ein Prefetch-Treffer für ein Löschwerkzeug, ein Amcache-Eintrag für eine unbekannte Binärdatei, die zur passenden Zeit lief, Recent File Cache-Einträge aus demselben Fenster.
Die MFT ist der Boden. Baue den Rest der Geschichte darauf auf.
Weiterführende Literatur
- Brian Carrier, File System Forensic Analysis. Die Kapitel über NTFS-Löschsemantik sind weiterhin definitiv.
- Sleuth Kits
fls-Dokumentation für die kanonische Bodyfile-Ausgabe, die gelöschte Einträge enthält. - Microsoft, Master File Table. Die MS-Level-Referenz dafür, was NTFS garantiert und was nicht.