Windows.edb und Windows.db öffnen: Schritt für Schritt
Schritt für Schritt: einen Windows-Search-Index (Windows.edb oder Windows.db) im Browser öffnen, Markierungen lesen, filtern und als CSV exportieren.
Kurz gesagt. Den ganzen Ordner C:\ProgramData\Microsoft\Search\Data\Applications\Windows\ sichern. Ihn, oder das KAPE- / Velociraptor-ZIP, auf den Windows Search Index Parser ziehen. Er ordnet Windows.db ihrer -wal-Datei und Windows-gather.db zu (Windows 11) oder liest Windows.edb (Windows 10), pivotiert jede Eigenschaft zu einer Zeile pro Element und markiert, was einen Blick verdient. Zuerst die Warnungen lesen, dann nach Markierungen filtern, interessante Elemente öffnen, als CSV exportieren. Nichts verlässt den Browser.
Wer nach „Windows.edb öffnen“ sucht, landet meist bei Exchange-EDB-Wiederherstellungsprodukten. Falsche Datei. Windows.edb ist der Windows-Search-Index, eine ESE-Datenbank, die mit Postfächern nichts zu tun hat. So öffnet man sie und ihren Windows-11-Nachfolger, ohne etwas zu installieren.
Vorab
Nötig ist eine Kopie, nicht die aktive Datei. Der Dienst Windows Search sperrt die Datenbanken. Die Sicherungsoptionen (Abbild, KAPE WindowsIndexSearch, Velociraptor, esentutl /y /vss) stehen in wo Windows.edb liegt und wie man es sichert.
Was vorliegen sollte:
| Windows-Version | Minimum | Besser |
|---|---|---|
| Windows 11 | Windows.db | Windows.db + Windows.db-wal + Windows-gather.db (+ deren -wal) |
| Windows 10 und älter | Windows.edb | Der ganze Ordner, und bei „dirty“ Datenbank eine Kopie mit nachgespielten Protokollen |
Wer nur sehen will, wie die Ausgabe aussieht, nutzt Beispiel testen (Windows 11) oder Windows-10-Beispiel (.edb) auf der Startseite. Beides sind synthetische Datenbanken für einen fiktiven Einbruch; keine echten Daten.
Schritt 1: den Ordner ablegen
Den Parser öffnen und den Ordner auf die Ablagefläche ziehen, oder Ordner wählen / Dateien wählen verwenden. ZIP-Sammlungen werden im Browser geöffnet, auch verschachtelte ZIPs über einige Ebenen. Ein KAPE-Archiv muss vorher nicht entpackt werden.
Was dann passiert:
Windows.dbwird derWindows.db-walund derWindows-gather.dbaus demselben Ordner zugeordnet.Windows.edbliest der eingebaute ESE-Leser.- ESE-Protokolle (
MSS*.log,*.jrs),MSS.chk,tmp.edb,-shm-Dateien und die übrigen Windows-Search-Datenbanken (Windows-usn.dbund Co.) erscheinen unter Nicht ausgewertete Dateien mit Begründung. - Eine Datei, die mit Nullen beginnt, wird als beim Kopieren vermutlich gesperrt oder noch im Schreibvorgang gemeldet.
Die Auswertung läuft in einem Web Worker mit WebAssembly. Es gibt keinen Upload-Endpunkt. Das zählt, wenn der Index den Dokumenttext eines Mandanten enthält.
Schritt 2: erst die Warnungen, dann die Zahlen
Der Kopfbereich zeigt Zähler: Computer, indizierte Elemente, Elemente mit Inhalt, Elemente nicht in der Gather-Tabelle, Elemente nur im WAL, markierte Elemente. Darunter sagen die Warnungen, wie weit man diesen Zählern trauen kann:
| Warnung | Bedeutung | Maßnahme |
|---|---|---|
Keine -wal-Datei zu Windows.db | Die neuesten bestätigten Transaktionen fehlen | Windows.db-wal zusammen mit der Datenbank neu sichern |
| Keine Windows-gather.db | Keine Pfade aus dem Gather-Baum, keine Prüfung „nicht in der Gather-Tabelle“ | Die Windows-gather.db aus demselben Ordner ergänzen |
| WAL ignoriert (unplausibel) | Das WAL gehört nicht zu dieser Datenbank oder wurde zu einem anderen Zeitpunkt kopiert | Beide Dateien in einem Vorgang neu sichern |
| Dirty Shutdown (Windows.edb) | Änderungen, die noch in MSS*.log stehen, fehlen | Protokolle auf einer Kopie nachspielen (Anleitung) und erneut parsen |
| Nur an synthetischen Datenbanken validiert | Der ESE-Leser wurde noch nicht an echten Windows.edb-Dateien geprüft | Wichtige Befunde mit einem zweiten Tool gegenprüfen |
| N gelöschte (defunct) Datensätze gesehen | Gelöschte ESE-Einträge stehen noch in den Seiten, werden aber noch nicht wiederhergestellt | Bei Bedarf ein Carving-Tool einsetzen |
Schritt 3: mit Kategorien und Markierungen sichten
Die Kategorie-Schaltflächen teilen die Elemente in Dateien, Ordner, ausführbare Dateien & Skripte, Archive & Datenträgerabbilder, Web / Verlauf, Sonstige und Elemente mit Inhaltsauszug. Nur markierte behält Elemente mit mindestens einer Markierung:
| Markierung | Regel |
|---|---|
| Vom Benutzer beschreibbarer Ordner | AppData, Downloads oder Desktop eines Profils, Users\Public, ProgramData, Windows\Temp, $Recycle.Bin, PerfLogs |
| Ausführbar / Skript | .exe, .dll, .ps1, .bat und weitere ausführbare oder Skript-Erweiterungen |
| Archiv / Abbild | .zip, .7z, .rar, .iso, .vhdx und ähnliche |
| Anderes Laufwerk (USB?) | Laufwerksbuchstabe außer C: |
| Netzwerkpfad | UNC-Pfad (\\server\freigabe) |
| Kürzlich indiziert | Nach der letzten Änderung indiziert und innerhalb von 24 h vor der jüngsten Gather-Zeit dieses Index |
| Inhaltsauszug | System.Search.AutoSummary ist vorhanden |
| Nur im WAL / Im WAL geändert | Durch Transaktionen hinzugefügt oder geändert, die noch in Windows.db-wal stehen und noch nicht in Windows.db gecheckpointet sind |
| Nicht in der Gather-Tabelle (gelöscht?) | Im Eigenschaftenspeicher, aber kein Gather-Eintrag für diese WorkId |
| Nur in der Gather-Tabelle | Gather-Eintrag, dessen Eigenschaften aus dem Speicher verschwunden sind |
Das sind Triage-Heuristiken, keine Urteile. „Anderes Laufwerk“ kann eine zweite interne Platte sein. „Nicht in der Gather-Tabelle“ kann ein Element sein, das der Gatherer noch nicht abgeglichen hat. Das Suchfeld filtert gleichzeitig nach Pfad, Name, Inhalt, Besitzer, URL und Datum. creds, .ps1, \\ oder ein Kontoname sind oft der schnellste Einstieg.
Schritt 4: ein Element öffnen
Eine Zeile anklicken. Das Detailfenster zeigt:
- Pfad, URL, Typ und Art
- Erstellt, geändert, Zugriff und Indiziert (Gather-Zeit)
- Besitzer und Computer
- WorkId / DocumentID und wo das Element gefunden wurde (Eigenschaftenspeicher und Gather-Tabelle, nur Speicher, nur Gather)
- Status im Write-Ahead-Log für Windows 11
- Inhaltsauszug
- Eintrag der Gather-Tabelle: Gatherer-Pfad, letzte Änderung, Bereichs-ID
- Alle Eigenschaften: jede Roh-Eigenschaft dekodiert, damit nichts hinter den Übersichtsspalten verborgen bleibt
Die Bedeutung jeder Eigenschaft steht in die Eigenschaften des Windows-Search-Index erklärt.
Schritt 5: Zeitzone und Export
Zeitstempel sind als FILETIME in UTC gespeichert. Der Schalter UTC / Lokal ändert nur die Anzeige. Die aktuelle gefilterte Ansicht als CSV oder JSON exportieren. Die CSV ist gegen Formel-Injection geschützt, was zählt, weil Pfade und Auszüge vom Angreifer kontrollierter Text sind, der in irgendjemandes Tabellenkalkulation landet. Große Indizes werden in Schritten von 500 Zeilen angezeigt; der Export enthält alle Zeilen, die zu den Filtern passen.
Schritt 6: absichern
Der Index sagt, dass eine Datei unter einem Pfad mit bestimmten Metadaten existierte, und manchmal, was sie enthielt. Bevor „der Angreifer hat X benutzt“ im Bericht steht:
- Ausführung: Prefetch, Amcache, ShimCache.
- Öffnen einer Datei: LNK-Dateien und Jump Lists.
- Erstellungs- und Löschzeitpunkte: das USN-Journal und der Papierkorb.
- Anmeldungen und Dienste: Ereignisprotokolle.
Wann etwas anderes passt
Für flottenweite Sicherung und Berichte passt SIDR mit seinem Velociraptor-Artefakt besser. Zum Carving gelöschter ESE-Datensätze WinSearchDBAnalyzer ansehen. Für einen Roh-Dump der Tabellen beliebiger ESE-Dateien esedbexport oder ESEDatabaseView von NirSoft. Die Abwägungen stehen in Parser für den Windows-Search-Index im Vergleich.