Zum Inhalt springen
Pagefile.sys Parser
← Zurück zum Blog

Browser-Verlauf (URLs, Cookies, Autofill) aus pagefile.sys rekonstruieren

20.5.2026 · 4 Min. Lesezeit

Browser sind die lautesten Anwendungen auf einem Windows-System. Sie öffnen pro Session Tausende Tabs, entschlüsseln HTTPS im Speicher zu Klartext, halten Caches und Autofill-Daten dauerhaft im laufenden Betrieb und aktualisieren permanent SQLite-Datenbanken. Wenn Speicherdruck einsetzt, wird irgendetwas ausgelagert — und sehr häufig sind das Browserdaten.

Was rekonstruierbar ist

In grober Häufigkeitsreihenfolge in einem typischen User-Pagefile:

  1. Besuchte URLs — https://…-Strings aus der Adressleiste, Klickziele und HTTP-Fetch-Header.
  2. Suchanfragen — https://www.google.com/search?q=…, https://duckduckgo.com/?q=…, Bing usw. Die Suchanfrage bleibt in der URL.
  3. Formular-Submissions — application/x-www-form-urlencoded-Bodies überleben oft kurz im Renderer-Heap.
  4. Cookies — Cookie:-/Set-Cookie:-HTTP-Header-Fragmente.
  5. Autofill-Werte — Benutzernamen, Adressen, Kreditkartennummern, Telefonnummern (Chrome / Edge halten diese in Web Data-SQLite, beim Ausfüllen eines Formulars im Speicher entschlüsselt).
  6. SQLite-Datenbank-Fragmente — Seiten aus History, Cookies, Login Data, Web Data.
  7. JWT- und Session-Tokens in gecachten XHR-/Fetch-Responses.

Browser-Dateilayouts

Eine kurze Übersicht, wo Browserdaten auf Disk liegen (nützlich zum Gegenchecken dessen, was Sie im Pagefile finden):

BrowserProfil-Root
Chrome%LOCALAPPDATA%\Google\Chrome\User Data\Default\
Edge (Chromium)%LOCALAPPDATA%\Microsoft\Edge\User Data\Default\
Brave%LOCALAPPDATA%\BraveSoftware\Brave-Browser\User Data\Default\
Firefox%APPDATA%\Mozilla\Firefox\Profiles\<profile>\
Opera%APPDATA%\Opera Software\Opera Stable\
Chrome (UWP/Modern)Spuren landen auch in swapfile.sys — siehe den Paging-Datei-Vergleich

Die interessanten SQLite-Dateien in jedem (Chromium-Familie):

  • History — urls, visits, keyword_search_terms, downloads.
  • Cookies — Name, Wert, Host, Ablaufzeit, encrypted_value (DPAPI).
  • Login Data — Tabelle logins (gespeicherte Passwörter, DPAPI- verschlüsselt).
  • Web Data — autofill, autofill_profile_*, Kreditkarten (DPAPI-verschlüsselt).

Solange diese vom laufenden Browser geöffnet sind, liegen ihre Pages im Prozessspeicher des Renderers — und die entschlüsselte Form von Cookies, Autofill und Login-Daten liegt zum Nutzungszeitpunkt im Speicher. Beide Zustände können ausgelagert werden.

Was der Artifacts-Tab dieses Tools liefert

Werfen Sie ein Pagefile in den Parser. Der Tab Artifacts extrahiert automatisch:

  • URLs — https?://[A-Za-z0-9\-._~:/?#\[\]@!$&'()*+,;=%]+ über jeden extrahierten String. Inklusive der vollständigen Query-Strings von Suchmaschinen.
  • E-Mails — häufig in Autofill, Account-Recovery-Flows, Kontaktseiten.
  • IPv4 / IPv6 — nützlich, wenn ein Query-Parameter oder X-Forwarded-For eine Adresse enthielt.

Der Tab Page map markiert Seiten, die mit SQLite format 3\0 beginnen — das sind SQLite-Datenbankseiten, fast sicher aus einer der oben genannten Browser-DBs.

Der Tab Strings ist die Anlaufstelle nach den IOCs:

  • Nach Cookie: filtern, um HTTP-Cookie-Fragmente zu sehen.
  • Nach Set-Cookie: filtern, um vom Server ausgestellte Cookies zu finden (mit Namen, Domains, Pfaden).
  • Nach Authorization: filtern, um Bearer-Tokens in API-Aufrufen zu finden.
  • Nach user-agent filtern, um auf bestimmte Tabs / Sessions zu pivotieren.
  • Nach searchTerm, q=, query= filtern für site-spezifische Suche.

SQLite-Carving

Wenn die Page Map SQLite format 3 (eine B-Tree-Header-Seite) oder eine innere B-Tree-Seite markiert, haben Sie ein Fragment einer Browser-DB. Seiten sind standardmäßig 4 KB groß (Chromium) oder 32 KB (neuere Firefox-Builds).

Um strukturierte Datensätze aus einer gecarvten SQLite-Seite zu extrahieren:

  1. Verwenden Sie sqlite_carving oder bring2lite — beide speziell für SQLite-Record-Carving aus rohem Speicher gebaut.
  2. Oder öffnen Sie die Bytes in undark / sqlite-deleted-records, um gelöschte Zeilen zu lesen.

Was üblicherweise extrahierbar ist:

  • URL + visit_time + title-Zeilen aus History.urls / History.visits. Mit etwas Glück die letzten 90 Tage Browsing in einer einzigen Seite.
  • Cookie-Name/Host/Pfad/Wert-Zeilen aus Cookies.
  • Autofill-Key/Value-Zeilen aus Web Data.autofill.

Firefox vs. Chromium

Firefox speichert den Verlauf in places.sqlite und Lesezeichen in derselben DB. Das Schema ist anders, der Carving-Ansatz aber identisch — suchen Sie nach places.sqlite-Strings in der Nähe von SQLite-Seiten und nach den Tabellennamen moz_places, moz_bookmarks, moz_historyvisits.

Firefox legt Session-Restore-Daten zudem in JSON-Dateien (sessionstore.jsonlz4) ab, die LZ4-komprimiert sind; als SQLite-Treffer sehen Sie diese nicht, aber der dekomprimierte Inhalt liegt im Speicher und kann als reines JSON ausgelagert werden. Filtern Sie den Tab Strings nach "entries": und "lastAccessed":.

Edge IE-Mode und Reste von Internet Explorer

Wenn das System Edge im IE-Mode betreibt (in Unternehmen noch immer verbreitet), sehen Sie auch Fragmente von WebCacheV01.dat (der ESE-Datenbank seit IE10+). ESE-Seiten haben einen eigenen Header (page header + tag array); der aktuelle Signaturkatalog erfasst sie nicht, aber die Strings darin tauchen im Tab Strings auf — Hostnamen, URLs, Zeitstempel.

Operative Tipps

  • So schnell wie möglich erfassen. Mit jeder Minute, in der der Browser weiterläuft, werden Seiten überschrieben.
  • Mit dem lebenden Profil kombinieren. Gecarvte Pagefile-Daten sind nützlicher, wenn man sie gegen das lebende SQLite diffen kann — alles, was im Pagefile steht und nicht in der lebenden DB, ist entweder kürzlich überschrieben, eine gelöschte Zeile oder InPrivate-/ Inkognito-Traffic.
  • Inkognito / InPrivate schützen nicht vor dem Pagefile. Der Modus weist den Browser an, nicht persistent auf Disk zu speichern, aber das RAM hält URLs und Cookies trotzdem — und der Memory Manager weiß nicht, welcher Renderer privat ist. Inkognito-Tabs tauchen garantiert in Pagefiles auf.

Verwandt