Windows-Search-Index-Forensik: der vollständige Leitfaden
Was der Windows-Search-Index speichert, wo Windows.edb und Windows.db liegen, was das Löschen einer Datei überdauert und wie man beide Formate auswertet.
Kurz gesagt. Windows Search führt eine Datenbank über alles, was es indiziert: vollständiger Pfad, Größe, Besitzer, MAC-Zeitstempel, Zeitpunkt der Indizierung und bei textartigen Dokumenten ein Stück des Inhalts. Unter Windows 10 und älter heißt diese Datenbank Windows.edb (ESE). Unter Windows 11 sind es Windows.db und Windows-gather.db (SQLite, mit Write-Ahead-Logs). Beide liegen in C:\ProgramData\Microsoft\Search\Data\Applications\Windows\. Der Index wird nicht in Echtzeit bereinigt und enthält daher regelmäßig Pfad, Metadaten und Text von Dateien, die längst von der Platte gelöscht wurden. Er ist eines der wenigen Artefakte, die den Inhalt einer gelöschten Datei ohne Carving liefern können. Er belegt, dass eine Datei existierte und vom Indexer gesehen wurde, nicht, dass jemand sie geöffnet hat.
Ich habe dieses Artefakt in mehr Berichten übergangen gesehen, als ich zählen kann, meist weil die Tool-Suite des Analysten es nicht auswertete oder weil Windows.edb nach einem Exchange-Postfach klang. Schade: Auf einem typischen Arbeitsplatzrechner ist es ein strukturiertes, mit Zeitstempeln versehenes Inventar der Dokumente des Benutzers, des Startmenüs und, je nach Windows-Version, des Browserverlaufs und der Aktivität.
Was der Windows-Search-Index ist
Der Dienst Windows Search (WSearch, Prozess SearchIndexer.exe) durchsucht die konfigurierten Orte, wendet Eigenschaftenhandler und Filter auf jede Datei an und speichert das Ergebnis, damit Startmenü und Datei-Explorer Suchanfragen sofort beantworten. Microsofts Leitfaden zur Windows-Search-Leistung nennt für einen typischen Rechner weniger als 30.000 indizierte Elemente und eine praktische Obergrenze von etwa einer Million.
Ein Index bedient den ganzen Rechner. Elemente aller Benutzerprofile, die in einem indizierten Ort liegen, landen in derselben Datenbank, deshalb ist die Besitzer-Eigenschaft (System.FileOwner) so wichtig.
Was indiziert wird, hängt von der Konfiguration ab:
| Einstellung | Auswirkung auf die Spuren |
|---|---|
| Klassischer Modus | Microsoft beschreibt ihn als Indizierung von Dokumente, Bilder, Musik und Desktop. In der Praxis enthält die Liste der Indizierungsoptionen meist den Ordner Users und das Startmenü. |
| Erweiterter Modus | Der gesamte PC, auch Ordner außerhalb des Profils. Mehr Abdeckung, größerer Index. |
| Hinzugefügte Orte | Jeder Ordner, jedes Laufwerk, jede Freigabe, die ein Administrator oder Benutzer ergänzt hat. Wechseldatenträger erscheinen mit eigenem Laufwerksbuchstaben. |
| „Nur Eigenschaften“ oder „Eigenschaften und Inhalt“ je Dateityp | Entscheidet, ob es für diese Erweiterung einen Inhaltsauszug gibt. |
Vor jedem Argument aus einer Abwesenheit prüfen, was auf diesem Rechner indiziert wurde. Die Gather-Tabellen (siehe unten) listen die durchsuchten Bereiche, und das Tool zeigt den daraus rekonstruierten Ordnerbaum.
Wo die Datenbanken liegen
| Windows-Version | Dateien in C:\ProgramData\Microsoft\Search\Data\Applications\Windows\ | Format |
|---|---|---|
| Windows Vista bis Windows 10 | Windows.edb, MSS*.log, MSS.chk, *.jrs, tmp.edb | ESE (JET Blue) mit Transaktionsprotokollen |
| Windows 11 | Windows.db + Windows.db-wal, Windows-gather.db + -wal, Windows-usn.db und weitere | SQLite im WAL-Modus |
Microsofts eigener Troubleshooting-Artikel nennt für diesen Ordner Windows.edb unter Windows 10 und Windows.db unter Windows 11. Die Quellen sind sich über die genaue Windows-11-Version des Wechsels nicht einig, deshalb gilt für mich eine einfache Regel: in den Ordner schauen. Die vollständige Sicherung samt gesperrter Dateien und Schattenkopien steht in wo Windows.edb und Windows.db liegen und wie man sie sichert.
Wie die Daten organisiert sind
Beide Formate enthalten zwei Arten von Datensätzen.
Der Eigenschaftenspeicher enthält einen logischen Datensatz pro indiziertem Element, identifiziert durch eine WorkId. Unter Windows 10 ist das SystemIndex_PropertyStore, eine sehr breite ESE-Tabelle mit Hunderten von Spalten namens 4447-System_ItemPathDisplay und ähnlich. Unter Windows 11 ist es SystemIndex_1_PropertyStore, eine schmale SQLite-Tabelle mit einer Zeile pro (WorkId, ColumnId, Value), und SystemIndex_1_PropertyStore_Metadata ordnet jeder ColumnId einen Eigenschaftsnamen zu. Der Formatvergleich behandelt beide Strukturen.
Die Gather-Tabellen (SystemIndex_Gthr und SystemIndex_GthrPth) sind die Buchführung des Crawlers: welche Dokumente er kennt, in welchem Bereich (Ordner), mit welchem Änderungszeitpunkt. Unter Windows 11 liegen sie in Windows-gather.db. Die DocumentID der Gather-Tabelle entspricht der WorkId im Eigenschaftenspeicher.
Diese Trennung ist nützlich. Ein Element, das noch im Eigenschaftenspeicher steht, aber in der Gather-Tabelle fehlt, ist ein Kandidat für „nach der Indizierung gelöscht“. Der Windows Search Index Parser markiert genau diesen Fall.
Was man daraus gewinnt
| Spur | Eigenschaft oder Tabelle | Warum sie zählt |
|---|---|---|
| Vollständiger Pfad einer Datei oder eines Ordners | System.ItemPathDisplay | Existenz einer Datei an einem Ort, auch lange nach ihrem Verschwinden |
| Größe, Besitzer, Computername | System.Size, System.FileOwner, System.ComputerName | Zuordnung und Identifizierung |
| Erstellt / geändert / Zugriff | System.DateCreated, System.DateModified, System.DateAccessed | Dateisystemzeiten, wie sie bei der Indizierung vorlagen |
| Wann der Indexer das Element verarbeitet hat | System.Search.GatherTime | Ein unabhängiger Zeitstempel, an den Angreifer selten denken |
| Textinhalt | System.Search.AutoSummary | Teil eines Dokuments, Skripts oder einer Notiz, auch nach dem Löschen |
Browserverlauf (IE / altes Edge; System.Link.TargetUrl unter Windows 11) | URL-Eigenschaften | Web-Aktivität, wenn die Browser-Datenbanken fehlen |
| Aktivitätsverlauf | System.ItemType = ActivityHistoryItem | Anwendungs- und Dateinutzung, einer Benutzer-SID zugeordnet |
Die Punkte zu URLs und ActivityHistory stammen aus der Forschung von Stroz Friedberg von 2023, veröffentlicht von Phalgun Kulkarni und Julia Paluch als Windows Search Index: The Forensic Artifact You've Been Searching For. Es ist die beste öffentliche Beschreibung dessen, was die Windows-11-Struktur enthält. Jede Eigenschaft wird ausführlich in die Eigenschaften des Windows-Search-Index erklärt behandelt.
Der Blick auf gelöschte Dateien
Dieses Artefakt gehört in jede Windows-Triage, weil der Index der Platte hinterherläuft. Wird eine Datei gelöscht, erfährt der Indexer davon und entfernt den Datensatz irgendwann, aber „irgendwann“ kann auf einem ausgelasteten oder ausgeschalteten Rechner lange dauern. Unter Windows 11 landet die Entfernung zuerst im Write-Ahead-Log. Chivers und Hargreaves zeigten schon 2011 (Forensic data recovery from the Windows Search Database, Digital Investigation), dass Datensätze nicht verfügbarer Dateien bestehen bleiben und gelöschte Datensätze aus ungenutztem Datenbankspeicher gecarvt werden können.
In der Praxis gibt es drei Situationen, beschrieben in was der Index über gelöschte Dateien bewahrt:
- Der Datensatz ist noch aktiv im Eigenschaftenspeicher. Jeder Parser zeigt ihn.
- Der Datensatz fehlt in der gecheckpointeten Datenbank, steht aber noch im WAL (Windows 11), oder umgekehrt.
- Der Datensatz wurde aus der Datenbank gelöscht und überlebt nur in freien Seiten. Das erfordert Carving.
Ein belastbarer Ablauf
- Den ganzen Ordner sichern, nicht nur die Hauptdatenbank: WAL-Dateien, Gather-Datenbank, ESE-Protokolle. Mit dem KAPE-Target
WindowsIndexSearch, Velociraptor oder aus einem Datenträgerabbild. - Den Zustand prüfen. Bei ESE bedeutet ein Dirty Shutdown, dass jüngste Änderungen noch in den Protokollen stehen. Siehe Windows.edb nach Dirty Shutdown mit esentutl reparieren. Bei SQLite
Windows.dbundWindows.db-walzusammen halten. - Parsen und pivotieren. Den Ordner im Parser im Browser öffnen (siehe die Schritt-für-Schritt-Anleitung) oder im Tool der Wahl. Für die Zeitleiste als CSV exportieren.
- Auf das Wesentliche filtern: vom Benutzer beschreibbare Pfade, ausführbare Dateien, Archive, andere Laufwerksbuchstaben, Netzwerkpfade, Inhaltsauszüge, Elemente ohne Gather-Eintrag.
- Absichern. Ein Pfad im Index ist ein Hinweis. Vor „der Benutzer hat geöffnet“ mit LNK-Dateien, Jump Lists, dem USN-Journal, dem Papierkorb oder Amcache verknüpfen.
Ein vollständig durchgespielter (fiktiver) Fall steht in Ermittlung eines Einbruchs mit dem Windows-Search-Index.
Grenzen, die in den Bericht gehören
- Umfang. Nur indizierte Orte sind abgedeckt. Ausgeschlossene Ordner, nicht indizierte Laufwerke und Dateitypen mit „nur Eigenschaften“ hinterlassen Lücken.
- Die Konfiguration kann geändert werden. Der Dienst lässt sich deaktivieren, der Index neu erstellen oder löschen. Siehe Anti-Forensik gegen den Index.
- Zeitstempel sind Kopien. Die MAC-Zeiten sind die, die das Dateisystem bei der Indizierung meldete; spätere Änderungen sind nur sichtbar, wenn das Element neu indiziert wurde.
- Undokumentiertes Schema. Microsoft dokumentiert die Eigenschaften, nicht den Datenbankaufbau. Alles zur Tabellenstruktur stammt aus öffentlicher Forschung und Reverse Engineering.
- Reife der Tools. Parser sind sich in Randfällen uneinig. Zentrale Befunde mit einem zweiten Tool gegenprüfen; der Parser-Vergleich listet die Optionen. Speziell für den Windows Search Index Parser gilt: Sein ESE-Leser (Windows.edb) wurde bisher nur an synthetischen Datenbanken validiert, seine Windows-11-Dekodierung folgt öffentlicher Forschung, weil Microsoft das Schema nicht dokumentiert, und er stellt gelöschte Datensätze aus freien Seiten noch nicht wieder her.
FAQ
Ist der Windows-Search-Index standardmäßig aktiv?
Ja. Der Dienst Windows Search (WSearch) startet auf Client-Editionen von Windows automatisch und indiziert die Standardorte, sofern niemand den Dienst deaktiviert oder Ordner ausgeschlossen hat.
Beweist der Index, dass ein Benutzer eine Datei geöffnet hat?
Nein. Er beweist, dass der Indexer die Datei unter einem bestimmten Pfad mit bestimmten Metadaten gesehen hat. Öffnen und Ausführen belegen andere Artefakte wie LNK-Dateien, Jump Lists, Prefetch oder die ActivityHistory-Elemente, die der Index selbst enthalten kann.
Kann man den Zeitstempeln trauen?
Erstellungs-, Änderungs- und Zugriffszeit sind Kopien der Dateisystemwerte zum Zeitpunkt der Indizierung. Die Gather-Zeit stammt aus der Uhr des Indexers selbst. Alle sind FILETIME-Werte in UTC.
Siehe auch die Definition von FILETIME.
Weiterführende Quellen
- Microsoft Learn: Troubleshoot Windows Search performance.
- Kulkarni und Paluch (Stroz Friedberg): Forschung zum Windows-Search-Index und SIDR.
- Kaspersky Securelist: forensische Artefakte in Windows 11.
- Chivers und Hargreaves (2011): Forensic data recovery from the Windows Search Database.