Anti-Forensik gegen den Windows-Search-Index

Kurz gesagt. Wer Administratorrechte hat, kann den Windows-Search-Index leicht ausschalten: den Dienst WSearch deaktivieren, den Index neu erstellen, ihn komprimieren oder C:\ProgramData\Microsoft\Search\Data löschen. Ebenso leicht lässt er sich umgehen, indem man außerhalb indizierter Orte arbeitet. Nichts davon ist sauber. Dienständerungen landen im System-Ereignisprotokoll und in der Registry. Ein neu erstellter Index hat verräterische Gather-Zeiten und eine junge Datenbankdatei. Gelöschte Datenbankdateien hinterlassen Spuren in USN und MFT. Bevor man aus einem fehlenden Datensatz etwas schließt, Indizierungsumfang und Alter des Index prüfen. Eine Abwesenheit im Index ist für sich allein ein schwacher Beleg.

Dies ist auch ein Artikel über Grenzen. Die meisten Lücken im Index sind keine Angriffe: Sie entstehen durch Konfiguration, Wartung und das Eigenverhalten des Indexers. Die Arbeit besteht darin, beides zu unterscheiden.

Was ein Angreifer (oder Administrator) tun kann

Aktion	Wie	Wirkung auf den Index
Außerhalb des Umfangs bleiben	In `C:\ProgramData`, `C:\Windows\Temp`, einem neuen Stammordner oder auf einem nicht indizierten Laufwerk arbeiten	Nichts wird indiziert. Keine Manipulation, nur Umgehung.
Einen Ort ausschließen	Indizierungsoptionen → Ändern, oder Einstellungen → „Ausgeschlossenen Ordner hinzufügen“	Elemente darunter verschwinden mit der Zeit aus dem Index
Dienst pausieren oder deaktivieren	`sc config wsearch start= disabled` + `net stop wsearch`, oder Dienste	Index zu diesem Zeitpunkt eingefroren
Neu erstellen	Indizierungsoptionen → Erweitert → Neu erstellen	Alte Datenbank durch eine von Grund auf neu aufgebaute ersetzt
Komprimieren	`esentutl /d` auf `Windows.edb` (Dienst gestoppt)	Freier Speicher wird zurückgewonnen: carvbare Reste gelöschter Datensätze verschwinden
Daten löschen	Dienst stoppen, `C:\ProgramData\Microsoft\Search\Data\…` löschen	Index weg; Windows legt beim Dienststart einen leeren an
Dateityp-Einstellungen ändern	Indizierungsoptionen → Erweitert → Dateitypen: „Nur Eigenschaften indizieren“	Keine Inhaltsauszüge mehr für diese Erweiterung

Jede dieser Aktionen steht in Microsofts eigenem Troubleshooting-Leitfaden als legitimer Optimierungs- oder Reparaturschritt, einschließlich der esentutl /d-Komprimierungsbefehle und des Löschens des Inhalts von C:\ProgramData\Microsoft\Search\Data. Das ist für den Bericht wichtig: Dieselbe Aktion kann Wartung oder Vertuschung sein, und die Absicht muss sich aus dem Kontext ergeben.

Welche Spuren jede Aktion hinterlässt

Dienst deaktiviert oder gestoppt

Registry: HKLM\SYSTEM\CurrentControlSet\Services\WSearch\Start. Der Wert 4 bedeutet deaktiviert. Microsofts Leitfaden erwartet auf einem normalen Client Automatisch (Verzögerter Start). Mit einem Registry-Parser auslesen.
System-Ereignisprotokoll: Der Dienststeuerungs-Manager protokolliert Zustands- und Starttypänderungen von Diensten. In den Ereignisprotokollen rund um das Vorfallsfenster nach dem Dienst Windows Search suchen.
Ausführungsspuren von sc.exe, net.exe oder services.msc: Prefetch, Amcache.
Der Index selbst: Die jüngste Gather-Zeit in der Datenbank markiert, wann die Indizierung tatsächlich endete. Liegt sie auf einem genutzten Rechner Stunden oder Tage vor dem Vorfall, nach dem Grund fragen.

Index neu erstellt

Junge Datenbank: Die Erstellungszeit von Windows.edb / Windows.db in der MFT ist jung, weit nach der Betriebssysteminstallation und den Benutzerprofilen.
Gestauchte Gather-Zeiten: Fast jedes Element hat eine Gather-Zeit in einem kurzen Fenster nach der Neuerstellung, auch alte Dateien. Bei einem normal gealterten Index verteilen sich die Gather-Zeiten über Monate.
Fehlende Historie: Elemente von vor der Neuerstellung gelöschten Dateien sind weg, ebenso älterer Webverlauf und ältere Aktivitätselemente.
Volumeschattenkopien (VSS) können die vorherige Datenbank noch enthalten. Vor dem Aufgeben prüfen.

Datenbank komprimiert

esentutl /d schreibt die Datenbank in eine neue, kompakte Datei. Aktive Datensätze überleben; defunct-Einträge und Reste in freien Seiten nicht. In einem normalen Parser ist kein Unterschied zu sehen, nur bei dem, was ein Carving-Tool wiederherstellen kann. In Ausführungsartefakten nach esentutl.exe suchen und nach einer Windows.edb, deren MFT-Zeitstempel sich änderten, während der Dienst gestoppt war.

Datenordner gelöscht

USN-Journal: Löscheinträge für Windows.edb, Windows.db, Windows-gather.db, MSS*.log in …\Search\Data\Applications\Windows. Das $J mit einem USN-Journal-Parser auswerten.
MFT: Die neuen Datenbankdateien haben Erstellungszeiten beim nächsten Dienststart.
Wiederherstellbare Reste: Die Cluster der alten Dateien können noch nicht zugeordnet sein. Eine ganze ESE- oder SQLite-Datenbank aus nicht zugeordnetem Speicher zu carven ist Glückssache, aber die Header-Signaturen (0x89ABCDEF an Offset 4 bei ESE, SQLite format 3 bei SQLite) geben einen Suchansatz.

Ausschlüsse und Dateityp-Änderungen

Sie stehen in der Windows-Search-Konfiguration in der SOFTWARE-Hive, und die Gather-Bereiche in der Datenbank zeigen, was tatsächlich durchsucht wurde. Ein am Vorfallstag hinzugefügter Ausschluss für einen Ordner, der sich später als Bereitstellungsbereich erweist, ist selbst ein Befund.

Was keine Anti-Forensik ist (aber so aussieht)

Verschlüsselte oder nicht verfügbare Inhalte. Chivers und Hargreaves stellten 2011 fest, dass Indizierungsumfang und Verschlüsselungsattribute beeinflussen, was indiziert wird.
Zurückhaltung des Indexers. Laut Microsofts Leitfaden pausiert der Indexer im Akkubetrieb, bei Benutzeraktivität oder knappen Ressourcen. Eine Lücke von einigen Stunden in den Gather-Zeiten eines Notebooks ist normal.
Jüngste Upgrades. Ein Funktionsupdate oder der Wechsel von Windows.edb zu Windows.db kann einen frischen Index erzeugen. Vor dem Urteil „Neuerstellung“ die Installationshistorie prüfen.
Erweiterter oder klassischer Modus. Eine Datei außerhalb der Orte des klassischen Modus wäre ohnehin nie indiziert worden.
Timestomping. Geänderte Dateizeitstempel ändern, was der Index bei der nächsten Indizierung für DateCreated / DateModified verzeichnet. Die Gather-Zeit, die eigene Uhr des Indexers, ändert sich nicht. Eine ausführbare Datei „von 2019“ mit einer Gather-Zeit von 2026 ist ein Hinweis, kein Widerspruch.

Checkliste vor dem Argument aus einer Abwesenheit

Lief WSearch im fraglichen Zeitraum? (Registry, Ereignisprotokolle, jüngste Gather-Zeit.)
War der Ort indiziert? (Gather-Bereiche, Konfiguration der Indizierungsoptionen, klassischer oder erweiterter Modus.)
Wurde der Inhalt dieses Dateityps indiziert? (Einstellungen unter Dateitypen.)
Wie alt ist der Index? (MFT-Erstellungszeit der Datenbank, Streuung der Gather-Zeiten.)
Wurden WAL und Gather-Datenbank gesichert (Windows 11) bzw. die ESE-Protokolle nachgespielt (Windows 10)? Siehe Sicherung.
Gibt es Volumeschattenkopien mit einem älteren Index?

Erst wenn alle sechs beantwortet sind, kann „nicht im Index“ Gewicht haben, und selbst dann sollte es andere Belege stützen, statt allein zu stehen.

Wobei das Tool hilft und wobei nicht

Im Windows Search Index Parser liefert das Sortieren nach der Spalte Indiziert die jüngsten und ältesten Gather-Zeiten, die Markierung „Kürzlich indiziert“ hebt den letzten Tag der Indizierungsaktivität hervor, und die Warnungen sowie die Liste „Nicht ausgewertete Dateien“ zeigen, welche Begleitdateien (WAL, Gather-Datenbank, Protokolle) vorlagen. Das deckt Teile der Fragen 1 und 4 sowie Frage 5 schnell ab. Registry, MFT und USN-Journal liest es nicht, und es carvt weder gelöschte Datensätze noch ganze Datenbanken aus freiem Speicher. Dafür die oben verlinkten Schwester-Tools verwenden.