Recovering browser history (URLs, cookies, autofill) from pagefile.sys

Browsers are the noisiest applications on a Windows system. They open thousands of tabs over a session, decode HTTPS into plaintext in memory, hold caches and autofill data permanently while running, and constantly update SQLite databases. When memory pressure hits, something gets paged out — and that something is very often browser data.

What you can recover

In rough order of frequency in a typical user pagefile:

1. Visited URLs — https://… strings from the address bar, click targets, and HTTP fetch headers.
2. Search queries — https://www.google.com/search?q=…, https://duckduckgo.com/?q=…, Bing, etc. The query stays in the URL.
3. Form submissions — application/x-www-form-urlencoded bodies often survive briefly in renderer heap.
4. Cookies — Cookie: / Set-Cookie: HTTP header fragments.
5. Autofill values — usernames, addresses, credit-card numbers, phone numbers (Chrome / Edge keep these in Web Data SQLite, decrypted in memory when filling a form).
6. SQLite database fragments — pages from History, Cookies, Login Data, Web Data.
7. JWT and session tokens in cached XHR / fetch responses.

Browser file layouts

A quick map of where browser data lives on disk (useful for cross-checking what you find in the pagefile):

The interesting SQLite files in each (Chromium-family):

• History — urls, visits, keyword_search_terms, downloads.
• Cookies — name, value, host, expiry, encrypted_value (DPAPI).
• Login Data — logins table (saved passwords, DPAPI-encrypted).
• Web Data — autofill, autofill_profile_*, credit cards (DPAPI-encrypted).

When any of these are open by the live browser, their pages live in the renderer's process memory — and the decrypted form of cookies, autofill, and login data lives in memory at use time. Both states can end up paged.

What this tool's Artifacts tab gives you

Drop a pagefile in the parser. The Artifacts tab automatically extracts:

• URLs — https?://[A-Za-z0-9\-._~:/?#\[\]@!$&'()*+,;=%]+ over every extracted string. Includes the full search-engine query strings.
• Emails — common in autofill, account recovery flows, contact pages.
• IPv4 / IPv6 — useful when a query parameter or X-Forwarded-For contained an address.

The Page map tab tags pages that started with SQLite format 3\0 — those are SQLite database pages, almost certainly from one of the browser DBs above.

The Strings tab is where you go after IOCs:

• Filter for Cookie: to see HTTP cookie fragments.
• Filter for Set-Cookie: to find server-issued cookies (with names, domains, paths).
• Filter for Authorization: to find bearer tokens in API calls.
• Filter for user-agent to pivot to specific tabs / sessions.
• Filter for searchTerm, q=, query= for site-specific search.

SQLite carving

When the page map flags SQLite format 3 (a B-tree header page) or an interior B-tree page, you've got a fragment of a browser DB. Pages are 4 KB by default (Chromium) or 32 KB (newer Firefox builds).

To extract structured records from a carved SQLite page:

1. Use sqlite_carving or bring2lite — both purpose-built for SQLite record carving from raw memory.
2. Or open the bytes in undark / sqlite-deleted-records to read deleted rows.

What's commonly extractable:

• URL + visit_time + title rows from History.urls / History.visits. Last 90 days of browsing in one page if you're lucky.
• Cookie name/host/path/value rows from Cookies.
• Autofill key/value rows from Web Data.autofill.

Firefox vs Chromium

Firefox stores history in places.sqlite and bookmarks in the same DB. The schema is different but the carving approach is identical — just look for places.sqlite strings near SQLite pages, and look for table names moz_places, moz_bookmarks, moz_historyvisits.

Firefox also stores session restore data in JSON files (sessionstore.jsonlz4) which are LZ4-compressed; you won't see those as SQLite hits but the decompressed content lives in memory and can page out as plain JSON. Filter the Strings tab for "entries": and "lastAccessed":.

Edge IE-mode and Internet Explorer leftovers

If the system has Edge in IE-mode (still common in enterprise), you'll see fragments of WebCacheV01.dat (the IE10+ ESE database) too. ESE pages start with their own header (page header + tag array); they're not picked up by the current signature catalog but the strings inside will surface in the Strings tab — host names, URLs, timestamps.

Operational tips

• Capture as soon as possible. Every minute the browser keeps running, pages get rewritten.
• Pair with the live profile. Carved pagefile data is more useful when you can diff it against the live SQLite — anything in the pagefile that's not in the live DB is either recently overwritten, a deleted row, or InPrivate / Incognito traffic.
• Incognito / InPrivate are not safe from pagefile. The mode tells the browser not to persist to disk, but RAM still holds the URLs and cookies — and the Memory Manager doesn't know which renderer is private. Incognito tabs absolutely show up in pagefiles.

Related

• How pagefile.sys forensics actually works
• Finding credentials in pagefile.sys — for bearer tokens, JWTs, saved passwords.
• pagefile.sys vs hiberfil.sys vs swapfile.sys — Edge UWP traces sometimes land in swapfile.sys instead.