Windows-Search-Index: Spuren gelöschter Dateien
Wie der Windows-Search-Index Pfade, Metadaten und Text gelöschter Dateien bewahrt, wo jede Spur in Windows.edb und Windows.db überlebt und wie man sie prüft.
Kurz gesagt. Der Windows-Search-Index löscht einen Datensatz nicht in dem Moment, in dem eine Datei verschwindet. Gelöschte Dateien finden sich an drei Stellen: in aktiven Datensätzen, die noch im Eigenschaftenspeicher stehen (Pfad, Größe, Besitzer, Zeitstempel, Indizierungszeit und oft ein Inhaltsauszug), in WAL-Unterschieden unter Windows 11 (ein Datensatz, der in einem Zustand von Windows.db vorkommt und im anderen nicht) und im freien Speicher der Datenbank (defunct ESE-Einträge, SQLite-Freelist-Seiten), was Carving erfordert. Ein Element im Eigenschaftenspeicher ohne passenden Gather-Eintrag ist ein starker „gelöscht?“-Hinweis. Der Inhaltsauszug in System.Search.AutoSummary ist der Hauptgewinn: Text einer Datei, die nicht mehr existiert, ohne die Platte zu carven.
Warum gelöschte Dateien bleiben
Der Indexer erfährt über die Änderungsverfolgung des Dateisystems von einer Löschung, reiht die Arbeit ein und entfernt das Element irgendwann. Mehreres verzögert das:
- Der Rechner wurde direkt nach der Löschung heruntergefahren, in den Ruhezustand versetzt oder sichergestellt.
- Der Indexer war pausiert, ausgelastet, im Akkubetrieb oder hat sich wegen Benutzeraktivität zurückgenommen. Microsofts Troubleshooting-Leitfaden listet diese Zustände.
- Das Element lag auf einem Laufwerk, das nicht mehr verbunden ist: ein abgezogener USB-Stick oder eine nicht erreichbare Freigabe. Chivers und Hargreaves wiesen in ihrem Beitrag von 2011 darauf hin, dass Datensätze nicht verfügbarer Dateien bestehen bleiben.
- Unter Windows 11 ist die Entfernung eine bestätigte Transaktion in
Windows.db-wal, bis ein Checkpoint sie inWindows.dbschreibt. Die Arbeit von Stroz Friedberg hält fest, dass der Datensatz einer gelöschten Datei in der Hauptdatenbank verfügbar bleibt, bis die WAL-Änderungen zurückgeschrieben werden.
Nichts davon ist garantiert. Es ist ein Wettlauf, den man manchmal gewinnt.
Stufe 1: aktive Datensätze nicht mehr existierender Dateien
Der einfachste Fall. Die Datei ist von der Platte verschwunden, ihr Datensatz aber noch eine normale Zeile im Eigenschaftenspeicher. Jeder Parser zeigt ihn, mit allen Eigenschaften:
| Eigenschaft | Was sie über die gelöschte Datei verrät |
|---|---|
System.ItemPathDisplay | Vollständiger Pfad, einschließlich des Bereitstellungsordners |
System.Size | Größe bei der Indizierung: mit gecarvten Fragmenten oder Exfiltrationsvolumen vergleichen |
System.FileOwner | Das besitzende Konto |
System.DateCreated / DateModified / DateAccessed | Dateisystemzeiten, wie sie bei der Indizierung vorlagen |
System.Search.GatherTime | Wann der Indexer die Datei verarbeitet hat |
System.Search.AutoSummary | Auszug aus dem Inhalt |
Woher weiß man, dass die Datei gelöscht ist? Der Index sagt es nicht. Man vergleicht mit dem Dateisystem im Abbild (MFT, Verzeichnisliste). Oder, schneller, man schaut in die Gather-Tabellen.
Der Abgleich mit der Gather-Tabelle
Eigenschaftenspeicher und Gather-Tabellen (SystemIndex_Gthr) sind zwei Sichten auf dieselben Elemente, verknüpft über WorkId = DocumentID. Verarbeitet der Gatherer eine Löschung, verschwinden beide nicht immer gemeinsam. Der Windows Search Index Parser vergleicht sie:
- Nicht in der Gather-Tabelle (gelöscht?): Der Eigenschaftenspeicher hat das Element noch, die Gather-Tabelle nicht mehr. Ein guter Kandidat für „nach der Indizierung gelöscht“.
- Nur in der Gather-Tabelle: Der Gatherer führt das Dokument noch, seine Eigenschaften sind aber verschwunden. Typisch für temporäre Dateien, etwa ein in einen Temp-Ordner entpacktes und dann aufgeräumtes Archiv.
Beide Markierungen sind Heuristiken. Mit dem Dateisystem, dem USN-Journal (Grund FILE_DELETE für denselben Namen) oder dem Papierkorb (die $I-Dateien enthalten Originalpfad und Löschzeit) bestätigen.
Stufe 2: das Write-Ahead-Log von Windows 11
Windows.db-wal enthält bestätigte Seiten, die neuer sind als die entsprechenden Seiten in Windows.db. Damit hat man zwei Zustände des Index:
- Die Datenbank allein: der Stand beim letzten Checkpoint.
- Datenbank plus WAL: der aktuelle Stand.
Ein Element, das im ersten vorkommt und im zweiten fehlt, wurde von einer jüngeren Transaktion entfernt. Ein Element nur im zweiten wurde kürzlich hinzugefügt; das markiert der Parser als nur im WAL. Ein Element mit abweichenden Eigenschaften wurde kürzlich neu indiziert (im WAL geändert), zum Beispiel eine überschriebene oder erneut ausgeführte Datei. Der Tiefgang zu SQLite und dem WAL erklärt Frames und Checkpoints und warum das WAL sogar mehrere ältere Versionen derselben Seite enthalten kann.
Praktische Folge: einen Windows-11-Index nie ohne sein WAL auswerten und nie ein Tool das Original im Lese-Schreib-Modus öffnen lassen. Ein normaler SQLite-Client kann beim Schließen checkpointen, das WAL einarbeiten und den „Vorher“-Zustand zerstören.
Stufe 3: Datensätze im freien Speicher
Wenn die Datenbank einen Datensatz tatsächlich löscht, werden die Bytes nicht sofort überschrieben.
- ESE: Der gelöschte Eintrag wird auf seiner Seite als defunct markiert und später bereinigt. Leer gewordene Seiten gehen in den freien Speicher zurück. Die Formatdokumentation von libesedb beschreibt die beteiligten Page Tags.
- SQLite: Gelöschte Zellen wandern in Freeblocks innerhalb der Seite, geleerte Seiten in die Freelist, und ältere Seitenversionen können in WAL-Frames verbleiben, die logisch, aber nicht physisch überschrieben sind.
Um sie wiederherzustellen, braucht es ein Carving-Tool, das das Format versteht. Chivers und Hargreaves bauten eines (wdsCarve) für ihre Forschung. WinSearchDBAnalyzer stellt gelöschte Datensätze aus Windows.edb wieder her. Der Windows Search Index Parser carvt noch nicht: Bei ESE zählt er die gesehenen defunct-Einträge und nennt die Zahl in einer Warnung, damit klar ist, dass mit einem anderen Tool etwas zu holen ist.
Inhaltsauszüge: der eigentliche Grund
System.Search.AutoSummary beschreibt Microsoft als automatische Zusammenfassung des Volltexts eines Dokuments. In der Praxis ist es ein Auszug vom Anfang des Texts. Die Forschung von Stroz Friedberg nennt bis zu den ersten 1.024 Bytes unter Windows 11 und listet die Dateitypen, bei denen sie ihn beobachtet haben: Dokumente (.txt, .docx, .xlsx, .pdf, .one, .eml), Web- und Konfigurationsdateien (.html, .xml, .ini, .reg, .sql, .asp) und Skripte (.bat, .cmd, .vbs, .js).
Wonach ich in Auszügen suche:
- Zugangsdaten und Notizen, die ein Angreifer auf dem Rechner gespeichert und dann gelöscht hat.
- Skripte: Die ersten Zeilen einer
.batoder.vbszeigen die Absicht, auch wenn die Datei weg ist. - Lösegeldforderungen mit ihren Kontaktangaben.
- Titel und erste Zeilen von Dokumenten, die belegen, dass ein sensibles Dokument in einem Bereitstellungsordner lag.
Zwei Vorbehalte:
- Der Auszug spiegelt den Inhalt zum Zeitpunkt der Indizierung. Wurde die Datei danach geändert und nicht neu indiziert, ist der Auszug veraltet.
System.DateModifiedmit der Indizierungszeit vergleichen. - Die Inhaltsindizierung hängt von der Konfiguration ab. Steht ein Dateityp in den Indizierungsoptionen auf „nur Eigenschaften“ oder ist der Ort nicht indiziert, gibt es keinen Auszug. Microsoft dokumentiert beide Optionen. Das Fehlen eines Auszugs beweist nichts.
Ein kurzes Beispiel
Im fiktiven Fall, der als Beispiel mit dem Tool geliefert wird, löscht der Eindringling eine Datei C:\ProgramData\Intel\creds.txt. Die Datei ist weg, und die Gather-Tabelle führt sie nicht mehr, aber der Eigenschaftenspeicher enthält noch Pfad, Besitzer (FIN-WKS-07\svc_backup), Größe (214 Bytes), Zeitstempel und einen Auszug mit den Zugangsdaten, die der Angreifer gesammelt hatte. Der vollständige Durchlauf steht in Ermittlung eines Einbruchs mit dem Windows-Search-Index.
Korrekt berichten
- „Der Windows-Search-Index enthält einen Datensatz für Pfad X, indiziert um T“ schreiben. Nicht „die Datei existierte bis T“.
- Den Auszug als „indizierten Inhalt“ zitieren, mit dem Hinweis, dass er die Datei zum Indizierungszeitpunkt wiedergibt.
- Angeben, ob WAL und Gather-Datenbank vorlagen und ob eine ESE-Datenbank „dirty“ war.
- Wer sich auf die Markierungen des Tools stützt, sagt dazu, dass es Heuristiken sind und wie sie bestätigt wurden.
FAQ
Wie lange bleibt eine gelöschte Datei im Windows-Search-Index?
Es gibt keine feste Dauer. Das hängt davon ab, wann der Indexer die Löschung verarbeitet, ob der Rechner lief, und von der Datenbankpflege. Jeden überlebenden Datensatz als Glücksfall behandeln und dokumentieren, wann der Index gesichert wurde.
Liefert der Index den vollständigen Inhalt eines gelöschten Dokuments?
In der Regel nicht. System.Search.AutoSummary enthält einen Auszug, nicht die Datei. Die Forschung von Stroz Friedberg beschreibt bis zu den ersten 1.024 Bytes unter Windows 11. Das reicht oft für Zugangsdaten, eine Lösegeldforderung oder die ersten Zeilen eines Skripts.