← Zurück zum Blog

Beweisen, dass eine Datei einmal existierte, wenn sie nicht mehr auf der Platte ist

· 6 Min. Lesezeit

Forensische Engagements drehen sich oft um eine einzelne Frage: War diese Datei jemals auf diesem Computer? Nicht "ist sie jetzt dort" (das ist dir). Die schwierigere Frage: Können wir zeigen, dass sie gestern, letzte Woche, letztes Jahr da war? Bei NTFS-Volumes ist die Antwort meistens ja, und $MFT ist die stärkste einzelne Quelle. Häufig kommen die Inhalte der Datei auch zurück.

Das ist die Praktikersicht darauf, was du aus den MFT-Metadaten allein beweisen kannst, welche Bestätigung die Journale beitragen und die Fälle, in denen selbstbewusste Behauptungen bei der Prüfung zerfallen.

Was eine Löschung überlebt

Wenn eine Datei auf NTFS gelöscht wird, wird das IN_USE-Bit im Datensatzkopf gelöscht und der Indexeintrag des übergeordneten Verzeichnisses wird entfernt. Der Datensatz selbst bleibt und enthält:

  • $FILE_NAME mit dem ursprünglichen Dateinamen und der MFT-Datensatzreferenz des übergeordneten Verzeichnisses.
  • Acht Zeitstempel (vier in $STANDARD_INFORMATION, vier in $FILE_NAME), eingefroren zum Zeitpunkt der Löschung.
  • Logische und physische Größen der Daten der Datei.
  • Für kleine Dateien (~700 Bytes oder weniger $DATA) der gesamte Dateiinhalt inline im Datensatz gespeichert. Siehe residente Daten.
  • Für größere Dateien die Runliste der Cluster, die die Daten enthielten. Diese Cluster können die ursprünglichen Bytes noch enthalten oder nicht.
  • Die Sequenznummer des Datensatzes, die beweist, dass du dir die Datei ansiehst, die zu jener Zeit in jenem Slot lebte (und keinen späteren Bewohner).

Ein gelöschter MFT-Datensatz mit $FILE_NAME = secret-plan.docx, Eltern-Referenz, die zu \Users\bob\Documents auflöst, und SI created 2024-11-03T14:02:11Z weist nach, dass an jenem Tag eine Datei mit diesem Namen in diesem Verzeichnis existierte. Der Datensatz ist der Beweis, und der Beweis ist im Sinne dessen, dass der Dateisystemtreiber ihn geschrieben hat, von NTFS selbst signiert.

Was den Beweis verteidigbar macht

Drei Eigenschaften lassen MFT-Datensätze in einer Prüfung halten, in der jemand versucht, deinen Fall zu brechen:

  1. NTFS schreibt sie selbst, nicht der Benutzer. Datensätze sind über normale Windows-APIs nicht benutzerbearbeitbar. Ein Angeklagter kann nicht glaubhaft behaupten, dass ein einzelner Datensatz gepflanzt wurde, es sei denn, er argumentiert, dass die gesamte $MFT gefälscht wurde, was mit den unten stehenden Journal-Querverweisen eine hohe Latte ist.
  2. Acht Zeitstempel prüfen sich gegenseitig. Manipulation zeigt sich meist. SI geändert, aber FN unverändert, ist die Lehrbuch-Timestomping-Signatur; siehe die vier MFT-Zeitstempel. SI created vor FN created ist natürlich unmöglich.
  3. $UsnJrnl und $LogFile bestätigen. Wenn $MFT sagt, die Datei wurde zum Zeitpunkt T erstellt, sollte das USN-Journal FILE_CREATE zum gleichen Zeitpunkt aufzeichnen. Meinungsverschiedenheiten sind selbst Beweise (für Fälschung oder Parser-Fehler; in beiden Fällen verfolgenswert).
  4. VSS-Snapshots sind unabhängig. Ein Snapshot von vor der Löschung enthält eine MFT-Kopie, in der die Datei IN_USE=1 war. Der Snapshot wurde zu einem bekannten Zeitpunkt von VSS geschrieben. Zwei unabhängige Zeugen (Live-$MFT + Snapshot-$MFT), die dieselbe Datei zeigen, sind viel stärker als einer allein. Siehe Volume Shadow Copy und $MFT.

Bei diesem vierten Punkt lohnt es sich zu verweilen. In ernsten Fällen suche ich immer nach VSS-Snapshots. Sie verwandeln eine einzelne Beobachtung in eine Reihe von Beobachtungen, jede zu einem anderen Zeitpunkt, und sie werden von einem völlig anderen Codepfad als die Live-MFT geschrieben. Schwer beide konsistent zu fälschen.

Was du aus $MFT allein nicht beweisen kannst

Die MFT beweist, dass die Datei in einem bestimmten Verzeichnis zu einer bestimmten Zeit existierte, mit der bestimmten Größe und den Zeitstempeln im Datensatz. Sie beweist nicht:

  • Wer sie erstellt oder darauf zugegriffen hat. Das erfordert Security-Ereignisprotokolle (4663 mit SACLs, Sysmon Event ID 11/15 oder 4688 Prozesserstellung mit Kommandozeile, wenn die Datei auf einer Kommandozeile benannt wurde).
  • Welches Programm sie produziert hat. Prefetch, Amcache und Shimcache helfen hier. Sysmon Event ID 1 ist der Goldstandard, wenn es aktiviert war.
  • Was die Datei enthielt, bei großen Dateien, es sei denn, du stellst die Datencluster wieder her. Residente Dateien geben dir die Bytes; nicht-residente Dateien erfordern, dass die Cluster-Runliste weiterhin auf unallozierten, nicht überschriebenen Platz zeigt.
  • Ob ein Benutzer sie tatsächlich geöffnet hat. Jump-Listen, LNK-Dateien und RecentFileCache sind hier nützlicher.
  • Ob sie von jemandem außer dem Benutzer, der das Verzeichnis besaß, angesehen wurde. Das braucht ACL-Audit-Logs.

Eine vollständige Antwort fusioniert die MFT meist mit umgebenden Artefakten. Die MFT ist der Eckstein, weil ohne sie die anderen Stücke nichts zum Verankern haben. Ein Prefetch-Treffer für secret-tool.exe ist interessant; derselbe Treffer, gepaart mit einem MFT-Datensatz, der zeigt, dass secret-tool.exe in derselben Minute in \Temp\ abgelegt wurde, durch einen Prozess, dessen Sysmon Event ID 1 in der Timeline ist, ist schlüssig.

Ein Workflow, der bei der Prüfung hält

  1. Erwirb $MFT, $UsnJrnl:$J, $LogFile, alle VSS-Snapshots. Hashe alles (SHA-256). Dokumentiere die Akquisezeit.
  2. Parse die MFT. Finde den Datensatz für die fragliche Datei, lebendig oder gelöscht. Hole die Sequenznummer, die Eltern-Referenz, alle acht Zeitstempel, die resident $DATA, falls vorhanden, und die Cluster-Runliste, falls nicht.
  3. Löse die Eltern-Referenz auf, indem du dem MFT-Datensatz des Elternteils folgst. Wiederhole, bis du Datensatz 5 (die Wurzel) erreichst. Die resultierende Kette ist der Verzeichnispfad. Querprüfe ihn gegen jeden Pfad, den du aus Logs oder Zeugenberichten hast.
  4. Querverweis mit dem USN-Journal. Für dasselbe Datensatz/Sequenz-Paar liste jeden USN-Eintrag auf. FILE_CREATE gibt dir die ursprüngliche Erstellung; FILE_DELETE gibt dir die Löschung. Die Gründe dazwischen sind die Historie der Datei.
  5. Vergleiche mit den VSS-Snapshot-MFTs. Die Kopie jedes Snapshots desselben Datensatzes gibt dir einen Checkpoint. Wenn drei Snapshots den Datensatz IN_USE=1 mit konsistenten Zeitstempeln zeigen und die Live-MFT IN_USE=0 zeigt, hast du vier unabhängige Zeugen, die der Existenz der Datei zustimmen, und einen Zeugen für ihre Löschung.
  6. Dokumentiere die Unmöglichkeiten, die du ausgeschlossen hast. SI/FN-Divergenz geprüft. Sequenznummern konsistent. Snapshot-Zeitstempel kohärent. Die Erzählung der Verteidigung muss all diese erklären, um deine Schlussfolgerung zu untergraben.

Der letzte Schritt ist es, der ein Befund von einem Argument trennt. Aufzulisten, was du geprüft und ausgeschlossen hast, macht die Argumentationskette sichtbar.

Randfälle, die beißen

Hard Links. Eine Datei mit mehreren harten Links lebt über mehrere $FILE_NAME-Attribute. Das Entfernen eines Links entfernt nur diesen Namen; die Datei bleibt. Bestätige, dass die Löschung, die du verfolgst, tatsächlich dem Verschwinden der Datei entspricht und nicht dem Entfernen eines einzelnen Namens.

Vor der Löschung umbenannte Datei. Manche Dropper benennen ihre Staging-Datei in einen harmlosen Namen um, kurz vor der Löschung, in der Hoffnung, dass der überlebende $FILE_NAME unschuldig wirkt. Das USN-Journal bewahrt das RENAME_OLD_NAME / RENAME_NEW_NAME-Paar. Hole es.

Datensatzplatz wiederverwendet. Der Slot einer gelöschten Datei wurde von einer neuen Datei beansprucht. Der aktuelle MFT-Datensatz ist die neue Datei bei Sequenz N; das Journal verweist auf die alte Datei bei Sequenz N-1. Verwende die Sequenznummer zur Disambiguierung. Referenzen, die auf eine andere als die aktuelle Sequenz zeigen, zeigen auf einen früheren Bewohner.

Datei existierte nie und jemand lügt. Weniger häufig, aber wissenswert. Reine Metadatenfälschung ist schwer konsistent über MFT, USN und VSS zu machen, aber ein entschlossener Operator mit Admin-Zugriff hat Werkzeuge. Suche nach Inkonsistenzen zwischen Artefakten, die übereinstimmen sollten.

Weiterführende Literatur

Verwandte Artikel

Externe Ressourcen