Ermittlung mit dem Windows-Search-Index: ein Fallbeispiel

Kurz gesagt. Fiktives Szenario, aufgebaut auf dem synthetischen Beispiel, das mit dem Tool ausgeliefert wird. Auf dem Arbeitsplatzrechner FIN-WKS-07 liefert der Windows-11-Suchindex allein die Umrisse eines Einbruchs über das Konto svc_backup: ein heruntergeladenes Tool-Archiv, eine in C:\ProgramData\Intel abgelegte Binärdatei, eine geschriebene und dann gelöschte Datei mit Zugangsdaten (ihr Text überlebt in System.Search.AutoSummary), eine Gehaltstabelle, die von einer Netzwerkfreigabe auf ein Wechsellaufwerk kopiert wurde, rclone.exe in Users\Public und der Besuch einer Cloud-Speicher-Website. Die jüngsten Schritte stehen nur in Windows.db-wal. Jeder Befund ist ein Hinweis, der mit anderen Artefakten zu bestätigen ist; welche das sind, steht jeweils dabei.

Alles ist erfunden. Unternehmen, Rechner, Konten, Dateinamen, Zeitstempel und Zugangsdaten stammen aus den Demo-Datenbanken, die für die Schaltfläche „Beispiel testen“ der Website erzeugt wurden. Es wird kein echter Vorfall und keine echten Daten beschrieben. Dieselben Daten lassen sich mit Beispiel testen (Windows 11) im Windows Search Index Parser laden und nachvollziehen.

Die Lage

Der IT-Ansprechpartner der Finanzabteilung meldet, dass svc_backup, ein Dienstkonto, das sich nie interaktiv anmelden sollte, in der Liste der zuletzt angemeldeten Benutzer auf FIN-WKS-07 auftaucht. Der Rechner wird am 14. September 2026 nachmittags isoliert. Es liegt eine KAPE-Sicherung einschließlich des Targets WindowsIndexSearch vor. Die Ereignisprotokolle bearbeitet ein Kollege. Der Einstieg erfolgt über den Suchindex, weil er schnell ist und zu den wenigen Artefakten gehört, die Dateiinhalte enthalten können.

Schritt 1: laden und Vollständigkeit prüfen

Nach dem Ablegen des Sicherungs-ZIPs erscheinen Windows.db, Windows.db-wal und Windows-gather.db aus demselben Ordner einander zugeordnet. Keine Warnung wegen fehlendem WAL oder fehlender Gather-Datenbank. Gut: Wir haben den aktuellen Stand und den Gather-Abgleich. Die Zähler zeigen einen kleinen Index: Es ist eine Demo. Ein echter Arbeitsplatzrechner hätte Zehntausende Elemente, und genau deshalb ist Filtern wichtig.

Alle Zeitstempel sind UTC (die gespeicherten FILETIME-Werte sind UTC; die Anzeige bleibt für den Bericht auf UTC).

Schritt 2: zuerst die markierten Elemente

Nur markierte, sortiert nach Erstellungszeit (Auszug; die Markierung „Kürzlich indiziert“, die die meisten tragen, ist der Lesbarkeit halber weggelassen):

Erstellt (UTC)	Pfad	Markierungen
09:58:41	`C:\Users\svc_backup`	—
10:05:31	`C:\Users\svc_backup\Downloads\tools.zip`	beschreibbarer Ordner, Archiv
10:07:14	`C:\ProgramData\Intel\m64.exe`	beschreibbarer Ordner, ausführbar, im WAL geändert
10:09:48	`C:\ProgramData\Intel\creds.txt`	beschreibbarer Ordner, Inhaltsauszug, nicht in der Gather-Tabelle
10:40:12	`E:\exfil\finance_2026\Payroll_2026.xlsx`	anderes Laufwerk, Inhaltsauszug, nur im WAL
10:45:03	`C:\Users\Public\rclone.exe`	beschreibbarer Ordner, ausführbar, nur im WAL

Dazu kommt ein Eintrag nur in der Gather-Tabelle: m64.exe unter C:\Users\svc_backup\AppData\Local\Temp\7zS4A2.tmp, ohne verbliebene Eigenschaften im Speicher.

Schritt 3: die Elemente einzeln lesen

Das Profil

C:\Users\svc_backup, erstellt um 09:58:41. Ein Profilordner für ein Dienstkonto auf einem Arbeitsplatzrechner bedeutet, dass eine interaktive oder RDP-Anmeldung ihn angelegt hat. Absichern: Anmeldeereignisse (4624 mit Anmeldetyp 10 oder 2) in den Ereignisprotokollen um 09:58.

Das Tool-Archiv und die temporäre Entpackung

tools.zip, 4.812.331 Bytes, Besitzer FIN-WKS-07\svc_backup, erstellt um 10:05:31, indiziert um 10:05:58. Um 10:06:38 zeigt die Startmenü-Verknüpfung 7-Zip File Manager.lnk eine neue Zugriffszeit. Um 10:06:55 kennt die Gather-Tabelle eine m64.exe in einem 7zS…tmp-Ordner unter dem Temp des Kontos. Ihre Eigenschaften sind aus dem Speicher verschwunden: das Muster nur in der Gather-Tabelle einer bereinigten temporären Datei. Deutung: Das Archiv wurde mit 7-Zip geöffnet und m64.exe entpackt, zunächst an einen temporären Ort. Absichern: Jump Lists von 7-Zip und das USN-Journal für den Temp-Ordner.

Die abgelegte Binärdatei

C:\ProgramData\Intel\m64.exe, 1.359.872 Bytes, erstellt um 10:07:14. ProgramData\Intel ist ein klassischer Bereitstellungspfad, der „legitim aussieht“; ein nach einem Hardwarehersteller benannter Ordner mit einer einzelnen ausführbaren Datei verdient einen Blick. Das Element ist im WAL geändert: Die gecheckpointete Datenbank hat eine Zugriffszeit von 10:07:14, das WAL eine neue Zugriffszeit von 10:51:02 und eine neue Gather-Zeit von 10:51:30. Die Datei wurde 45 Minuten später erneut angefasst. Der Index beweist keine Ausführung. Absichern: Prefetch, Amcache, ShimCache.

Die gelöschte Datei mit Zugangsdaten

C:\ProgramData\Intel\creds.txt, 214 Bytes, erstellt um 10:09:48, geändert um 10:14:02, indiziert um 10:14:30. Sie steht nicht in der Gather-Tabelle, und der Gather-Eintrag des Ordners Intel zeigt eine letzte Änderung um 10:55:04. Auf der Platte ist die Datei verschwunden. Ihr Inhaltsauszug steht noch im Eigenschaftenspeicher:

FIN-SQL01 sa / Winter2026! | FILESRV01 CORP\svc_backup / Bkp#2026-fin | mega: fin-backup

Drei Sätze von Zugangsdaten: das sa-Konto des SQL-Servers, das Domänenpasswort des Dienstkontos selbst und etwas, das wie ein Cloud-Speicher-Kontoname aussieht. In einem echten Bericht würde ich das in einem Anhang mit eingeschränkter Verteilung zitieren und Passwortänderungen veranlassen. Das ist der Wert, der in Spuren gelöschter Dateien im Windows-Search-Index beschrieben ist: Inhalt einer Datei, die nicht mehr existiert, ganz ohne Carving. Absichern: Papierkorb (über den Explorer gelöscht?), USN-Journal (Löscheintrag für creds.txt gegen 10:55) und Authentifizierungsprotokolle auf FIN-SQL01 und FILESRV01.

Die Gehaltsdatei, zweimal

\\FILESRV01\Finance\Payroll\Payroll_2026.xlsx: ein Netzwerkpfad im Besitz von CORP\payroll-admins, 188.406 Bytes, zuletzt geändert am 12. September um 16:02, aufgerufen am 14. September um 10:32:15, indiziert um 10:33:01. Auszug: die Spaltenüberschriften einer Gehaltstabelle. Die Freigabe wurde auf diesem Rechner indiziert, daher verzeichnet der Index die Zugriffszeit so, wie er sie gesehen hat.

Dann E:\exfil\finance_2026\Payroll_2026.xlsx: anderes Laufwerk, gleiche Größe, gleiche Änderungszeit (12. September 16:02, durch die Kopie erhalten), erstellt um 10:40:12, Besitzer FIN-WKS-07\svc_backup. Nur im WAL: Dieser Datensatz existiert nur in den jüngsten Transaktionen, nicht in der gecheckpointeten Datenbank. Ohne Windows.db-wal wäre er unsichtbar. Siehe Windows.db-Forensik: SQLite und das WAL. Deutung: Kopie der Gehaltsdatei auf ein Wechsellaufwerk gegen 10:40. Absichern: USB-Geräteverlauf in der Registry und den Ereignisprotokollen, LNK-Dateien mit Ziel E:\.

rclone und die Cloud-Website

C:\Users\Public\rclone.exe, 58.720.256 Bytes, erstellt um 10:45:03, Zugriff um 10:47:12, nur im WAL. Rclone ist ein legitimes Synchronisationswerkzeug, das häufig zur Exfiltration missbraucht wird. Ein um 10:46:52 indiziertes Webverlaufselement zeigt auf https://mega.nz/start, aufgerufen um 10:46:30, mit einer Benutzer-SID auf -1013 in seiner iehistory://-URL. Absichern: die SID über die Hives SAM / ProfileList einem Konto zuordnen, Browser-Artefakte prüfen, nach rclone.conf sowie Netzwerk- oder Proxy-Protokollen suchen.

Schritt 4: die Zeitleiste

Zeit (UTC)	Ereignis	Quelle im Index	Belastbarkeit
09:58:41	Profil `svc_backup` erstellt	Ordnerelement	Mittel: Anmeldung bestätigen
10:05:31	`tools.zip` heruntergeladen	Dateielement	Mittel
10:06:38–10:06:55	7-Zip verwendet, `m64.exe` temporär entpackt	LNK-Zugriffszeit, Eintrag nur in Gather	Gering bis mittel
10:07:14	`m64.exe` in `ProgramData\Intel` abgelegt	Dateielement	Mittel: Ausführung bestätigen
10:09–10:14	`creds.txt` geschrieben	Dateielement + Auszug	Hoch für den Inhalt um 10:14
10:32:15	Gehaltsdatei auf der Freigabe aufgerufen	Netzwerkelement	Mittel
10:40:12	Gehaltsdatei nach `E:\exfil\…` kopiert	Element nur im WAL	Mittel: USB bestätigen
10:45:03	`rclone.exe` abgelegt	Element nur im WAL	Mittel
10:46:30	MEGA-Website besucht	Webverlaufselement	Mittel
10:51:02	`m64.exe` erneut angefasst	Im WAL geändertes Element	Gering bis mittel
~10:55	`creds.txt` gelöscht	Fehlender Gather-Eintrag, Ordneränderung	Mittel: mit USN bestätigen

Jede Zeile ist eine Beobachtung des Indexers, für sich genommen keine Ausführung und keine Benutzeraktion. Die Spalte Belastbarkeit gibt wieder, was ich vor der Absicherung gegenüber einem Reviewer vertreten würde.

Was der Index nicht sagen konnte

Ob m64.exe oder rclone.exe ausgeführt wurden. Dafür braucht es Ausführungsartefakte.
Was rclone hochgeladen hat. Netzwerk-, Proxy- und Cloud-Protokolle oder rclone.conf.
Alles außerhalb indizierter Orte. Ein Tool, das aus einem nicht indizierten Ordner lief, bliebe hier unsichtbar.
Alles nach 10:51. Die letzte Gather-Zeit im Index markiert die Grenze seiner Sicht.

Fazit

WAL und Gather-Datenbank sichern: Drei der zentralen Befunde hängen daran.
Markierte Elemente zuerst nach Zeit sortieren, Details danach öffnen.
Inhaltsauszüge als Beleg für den Inhalt zum Indizierungszeitpunkt behandeln und wie die Daten schützen, die sie enthalten.
Jeden Befund als „der Index verzeichnet…“ formulieren und das absichernde Artefakt danebenschreiben.