Web Browser Forensics: Cookies, Cache, History and Session Recovery

The browser share on Indian desktops sits around 70 percent Chrome, with Edge in the low double digits, Safari pinned to macOS, Firefox in single digits, and Brave and Opera making up the long tail. Mobile is heavier on Chrome and Safari. The forensic implication is clean: in most Indian cases the examiner is reading Chromium artefacts, with a Firefox or Safari profile as a secondary source.

The Chromium layout repeats across Chrome, Edge, Brave and Opera, so a competent Chrome parser handles four of the top six browsers with no change. The differences sit at the edges: Edge writes a small number of extra preference files, Brave adds a Wallet directory and a Tor profile, Opera ships a separate VPN config that is worth pulling.

The second beat to remember is that a single seized laptop usually has more than one profile. The Default folder is one profile; Profile 1, Profile 2 and so on are alternative profiles, often used to separate work and personal accounts. Each profile has its own History, Cookies and Login Data. A common defence point in Indian phishing prosecutions is that the prosecution analysed only the Default profile and missed exculpatory activity under Profile 1. The acquisition checklist must list every profile directory it found.

The Chromium profile keeps its evidentiary core in a handful of SQLite databases. Each of them answers a different investigative question, and a careful examiner queries them in the order that builds the user-activity timeline cleanly.

The Network Action Predictor is the database most students forget and the one that surprises in court. It records partial user input that triggered a URL prediction, even when the user never pressed Enter. A suspect who typed the first six letters of a phishing-template hosting domain and then backed out leaves a row in network_action_predictor and nothing in History. The defence point that "the suspect never visited the site" can be answered by producing the predictor row.

Login Data stores password_value as a blob encrypted with the OS-level master key. On Windows the master key sits under DPAPI scoped to the user account; the examiner needs the user's Windows password or a memory-resident master key to decrypt. On macOS the master key sits under Keychain. On Linux the key lives in libsecret or kwallet. The presence of an encrypted blob is itself evidence of a saved credential; decryption is a separate step that often needs the live machine or a memory image.

The History database records what URL was requested. The Cache, Local Storage and Sessions stores record what the user actually saw and what sessions were active when the machine was last closed.

The Chromium Cache is a key-and-body store, typically deflate-compressed, that holds full HTTP response bodies until they expire or the user clears them. In phishing investigations, the Cache frequently contains the HTML and CSS of the lookalike banking page the victim rendered, including hidden form actions pointing to the attacker's collection endpoint. ChromeCacheView from NirSoft and the Hindsight cache module both extract cache entries as files keyed to their original URLs.

1. Acquire the profile directory cold
   Image the User Data directory while Chrome is closed. Live SQLite files have a journal or WAL sidecar that must be copied alongside the main file or the most recent activity is lost.
2. Verify integrity at acquisition
   Hash every file (SHA-256) and write the hash list into the chain-of-custody log. The Section 63 BSA certificate will reference these hashes.
3. Open History first, then Cookies
   Build the URL timeline before reading the cookie state. The cookie state is meaningful only relative to the visits that set it.
4. Walk the Cache
   Map cache keys back to URLs in History. Extract response bodies for phishing-page or download evidence.
5. Open Local Storage and IndexedDB
   These are LevelDB stores; read them with leveldb-py or the Hindsight LevelDB module. WhatsApp Web and Telegram Web tokens sit here.
6. Walk the Sessions folder
   Current Tabs, Current Session, Last Tabs, Last Session record open tabs and their state. Use these to reconstruct what the suspect was looking at when they closed the lid.

Local Storage and Session Storage are LevelDB key-value stores, one directory per origin. IndexedDB is also LevelDB-backed and is the heavier of the two, often holding cached message bodies and contact lists for web apps. For WhatsApp Web the IndexedDB store at web.whatsapp.com holds the full local message cache and the session token; collecting it from a live machine produces an artefact equivalent to a logged-in WhatsApp handset, which is why preserving the live profile (rather than rebooting) matters when the suspect is caught at the console.

The Sessions folder is the artefact that wins the "what was open on screen" question. Current Tabs records the currently open tabs and their scroll positions; Current Session records the navigation history within each tab. Last Tabs and Last Session record the equivalents from the previous browser run. After a crash, Chrome restores from Current Session; the file therefore often survives even when the user thought they closed everything.

Firefox keeps its profile in a randomly-named directory under the Profiles folder (the random prefix discourages accidental shared profiles). The core stores are SQLite, like Chromium, but the names and the timestamp format differ.

• places.sqlite is the combined history and bookmarks store. The moz_places, moz_historyvisits and moz_bookmarks tables carry visits, visit types and the bookmark tree. Visit timestamps are PRTime: microseconds since the Unix epoch (1 January 1970 UTC), one thousand times Unix time.
• cookies.sqlite mirrors Chromium Cookies.
• formhistory.sqlite stores typed form values keyed to field name, which is the Firefox equivalent of Chromium autofill.
• key4.db and logins.json together hold saved credentials. logins.json carries the encrypted username and password blobs; key4.db carries the master key, itself wrapped by the user's primary password if one is set. Without a primary password the credentials are recoverable offline; with one the examiner needs the password.
• sessionstore.jsonlz4 carries open tabs and session state, compressed with the Mozilla mozlz4 variant of LZ4. Decompression needs lz4json (the Python tool) or the equivalent JavaScript routine; ordinary lz4 will reject the file because of the leading "mozLz40\0" magic.

Safari keeps its profile under ~/Library/Safari on macOS only. The core stores are SQLite and plist.

• History.db carries the visit history. The schema is small (history_items, history_visits) and the timestamps are Cocoa time (seconds since 1 January 2001 UTC). Conversion is unix_seconds = cocoa_value + 978307200.
• TopSites.plist carries the Top Sites tiles.
• Bookmarks.plist carries the bookmark tree.
• Downloads.plist carries downloads with their original URLs and target paths.
• LastSession.plist carries the session-restore state.

Edge ships Chromium under a Microsoft skin and writes the same layout under User Data. Adding to the Chromium baseline, Edge writes a Collections store (SQLite) and a Wallet store; on managed Indian banking-fraud cases where the suspect is a corporate user, Edge's enterprise-sync flags in Preferences often point to a corresponding Microsoft 365 tenant whose admin logs are themselves a parallel evidence source.

The cross-link to remember is the operating-system layer that backs these stores. Saved credentials on Safari, and to some extent on Chrome for macOS, are not in the browser profile at all; they sit in the macOS Keychain. The acquisition strategy on macOS therefore differs from Windows because the keychain database (login.keychain-db) is the credential source, not the browser file. See our macOS Forensic Artefacts topic for the keychain workflow end to end.

Incognito and private browsing modes prevent the browser from writing to its own profile, but they do not suppress writes to the operating system, network layer, or any third-party agent on the host. A thorough examination accounts for each of these layers.

What survives an incognito session on Windows:

• DNS cache in the Windows DNS Client Resolver Cache (ipconfig /displaydns on a live system; the cache lives in memory and is lost on reboot but is rich for a live machine).
• Pagefile.sys and hiberfile.sys which routinely capture browser process memory and therefore URL strings, form values and even page text. Strings analysis on these files after acquisition often recovers incognito URLs verbatim.
• Memory image taken from a live machine carries the same content as the pagefile, only fresher.
• Registry MUICache and UserAssist which record process launches with timestamps, including private-mode browser launches.
• Prefetch files which record process executions on Windows client SKUs (Server SKUs disable prefetch by default).
• Event Logs which carry process-creation records when audit-process-creation is enabled (Sysmon, AppLocker and recent Defender configurations switch this on by default in many Indian government and PSU images).
• Antivirus and EDR telemetry which often retain visited-URL telemetry independent of the browser profile.
• Network-layer logs at the gateway: corporate proxy logs, ISP NetFlow, hotspot logs all see the request regardless of incognito state.

Session recovery is the other half of this section. A cookie file collected from a live browser, together with the Sessions folder and a snapshot of Local Storage and IndexedDB, can be replayed into a fresh browser to resume the suspect's logged-in session. This matters in two scenarios. First, suspect-at-the-console arrest cases where the live machine is open to WhatsApp Web, the bank account, or the cloud workspace. Second, court-authorised intercept where the warrant covers continued access to a service that the suspect has already logged into. The forensic playbook is to image the running profile cold (not after closing the browser), preserve the Sessions folder and Local Storage in particular, and only then shut the machine down. In the Indian banking-phishing prosecutions of 2023-2024 (HDFC and ICICI lookalike-domain rings), the prosecution case in several charge sheets cited replayable session cookies recovered from suspect endpoints as corroboration of the operator's role; the evidentiary path used the Section 63 BSA certificate over the imaged profile and a separate certificate over the analyst's worksheet.

A typical browser forensics workflow combines a SQLite GUI, a Chromium profile parser, and a cache viewer.

• DB Browser for SQLite is the workhorse SQLite GUI. Reads History, Cookies, Login Data, Web Data and the Firefox SQLite stores directly. Useful for ad-hoc queries; weak at timestamp conversion (no auto WebKit/PRTime/Cocoa handling).
• Hindsight is the NIST-aligned Chromium parser. Walks History, Cookies, Login Data metadata, Local Storage, Downloads and Cache, normalises timestamps to UTC, and emits CSV, JSONL and XLSX. The single most useful tool for a Chrome timeline.
• ChromeCacheView (NirSoft) renders the Chrome HTTP cache as a file table with the original URLs and lets you extract response bodies.
• NirSoft BrowsingHistoryView does a quick parallel parse across Chrome, Firefox, Edge and Internet Explorer for triage.
• Magnet AXIOM is the commercial integrated platform that most central and state cyber-forensic units in India use; AXIOM Browser modules parse Chromium, Firefox and Safari with one workflow.
• BrowserHistoryCapturer and BrowserHistoryViewer (Foxton) are paired tools for a live or dead acquisition and review.
• ChromeForensic is a smaller open-source script set used in academic labs.

1. Plan acquisition before touching the device
   Decide live, dead or both. Live capture is needed if Sessions, Local Storage or IndexedDB are evidentiary. Dead capture suffices for History and Cookies on a powered-off machine.
2. Image the profile with hashes
   Copy the User Data directory (or the Firefox profile or ~/Library/Safari) with all sidecar files (journal, WAL, shm). SHA-256 every file. Record the listing in the chain-of-custody log.
3. Parse with Hindsight or equivalent
   Run the parser against a working copy, never the original. Verify hashes match before and after.
4. Cross-validate against a second tool
   Re-parse with AXIOM or NirSoft BHV. Note any deltas and explain them in the report. A two-tool result is harder to challenge under Section 39 BSA cross-examination.
5. Draft the Section 63 BSA certificate
   Identify the records, describe the device and the imaging method, state that the device was operating normally, sign as the responsible official. Cross-reference our BSA topic for the certificate template.
6. Annexe to the BNSS Section 193 charge sheet
   The report and certificate travel with the FSL annexures. The trial court reads them in through Section 39 BSA deposition.

The Section 63 BSA workflow for browser-extracted evidence mirrors the workflow for any other electronic record: the original electronic record (the source device) does not need a certificate, but every copy produced in court does. The forensic image of the User Data directory is a copy; the Hindsight CSV exported from that image is a copy of a copy; both need a Section 63 certificate, and the safer practice is for the responsible official (typically the senior analyst or the section head) to certify the source image rather than the downstream artefacts. See our BSA Section 63 topic for the certificate template and the leading case law (Anvar P V; Arjun Pandit Rao Khotkar).

A practical Indian cross-link to keep in mind: browser artefacts in phishing prosecutions almost always sit next to email artefacts. The phishing message arrived by email; the click trail lives in the browser. The two evidence streams are read together. See our Email Forensics topic for the header-tracing methodology that pairs with browser analysis.