Browser Forensics Guide: Artefacts, Timelines and Session Theft Investigation

When an infostealer runs or a session cookie is stolen, the browser profile is the crime scene, and most investigations lose it to a reboot, a sync or a reimage. Browsers now hold the keys to most of an organisation: saved passwords, single sign-on session cookies, OAuth tokens for SaaS apps and the extensions that can read every page. Browser forensics answers what was visited, what was downloaded, which credentials and sessions were exposed and when, so that responders can revoke the right things. This guide is for incident responders and forensic analysts working on Windows, macOS and Linux endpoints. It covers where Chromium-based browsers and Firefox keep their artefacts, how to acquire them without destroying evidence, how to read their timestamps, how to detect browser data theft on Windows, and how to turn findings into a revocation list.

Key takeaways

• The profile folder is the unit of evidence. Collect the whole profile, including SQLite write-ahead log files, not just the History database.
• Browser artefacts answer the identity question. Saved logins, cookies and extension data tell you which accounts and sessions to revoke, which matters more than which websites were browsed.
• Timestamps use three different epochs. Chromium, Firefox and Safari count time differently; a wrong conversion puts the infection on the wrong day.
• Windows can log browser secret decryption. DPAPI event 16385 with a browser DataDescription and an unexpected caller process is one of the clearest infostealer signals available.
• Sync and unmanaged devices widen scope. A password synced to a personal account or a contractor laptop can expose corporate credentials with no corporate endpoint involved.

Where browsers keep their evidence

Chromium-based browsers (Chrome, Edge, Brave, Opera and others) share one profile layout. Firefox has its own. Locate the profile before collection; in Chrome, chrome://version shows the exact Profile Path on a live system.

Chrome Beta, Dev and Canary use suffixed folders (for example Chrome SxS for Canary on Windows), and Linux paths move if $CHROME_CONFIG_HOME or $XDG_CONFIG_HOME is set. Each Chromium user data directory holds one or more profiles, the first usually named Default, plus a Local State file shared by all of them.

Artefact reference

The Firefox file names above come from Mozilla's own profile documentation. Chromium file names are stable across recent versions but not formally documented as an interface; check them against the browser version in front of you, because Chromium has moved files before (Cookies moved into the Network subfolder).

Acquisition without destroying evidence

NIST SP 800-86 frames forensics within incident response as collection, examination, analysis and reporting, with integrity preserved at each step. For browsers the practical rules are these.

1. Decide live or dead first. If the session is still active and the attack is ongoing, memory and live decryption matter: capture memory before shutting down, because the browser process holds decrypted cookies and tokens. See the Memory Forensics Guide.
2. Stop sync before it overwrites. Sign-in sync can replace local history, bookmarks and saved passwords with server copies or push deletions. Where you can, isolate the host from the network rather than closing the browser, then collect.
3. Copy the whole profile. Include every -wal, -shm and -journal file beside each SQLite database. Write-ahead logs often hold the most recent visits and cookie changes that are not yet in the main file. Hash everything on collection.
4. Collect the key material. Chromium's Local State holds the encrypted key that protects cookies and passwords; on Windows it is protected by DPAPI and, since Chrome 127, App-Bound Encryption for cookies. Decryption offline then needs the user's DPAPI master keys and credentials, or SYSTEM-level material, collected under legal authority. Firefox needs key4.db with logins.json.
5. Work on copies. Opening a SQLite database read-write can checkpoint the WAL into the main file and change it. Open copies read-only, or with tools that do not write.
6. Record context. Browser version, profile path, signed-in account, sync state, enterprise policies and time zone. Record chain of custody. See the Evidence Handling and Chain of Custody Guide.

Reading browser timestamps correctly

All three are stored in UTC; display time zones are applied by tools. Before trusting a parser, convert one known event by hand (for example a visit you can match to a proxy log) and confirm both the epoch and the units. Cookie creation and last access times are especially useful: a corporate SSO cookie last accessed from the device minutes after a malicious download marks the window in which the session could have been copied. Merge browser events into the host timeline with the file system and execution artefacts. See the Forensic Timeline Analysis Guide.

Investigating infostealer and session theft cases

Infostealers read browser files directly (MITRE ATT&CK T1555.003 Credentials from Web Browsers, T1539 Steal Web Session Cookie) and send them out; the attacker then replays the cookies elsewhere (T1550.004 Web Session Cookie). The host forensics questions are narrow.

• Entry: which download or visit came first? Look at History downloads, Zone.Identifier streams with the HostUrl, and visits to file-sharing, cracked software or fake update sites in the minutes before the first execution (T1204.002 Malicious File, T1189 Drive-by Compromise).
• Access: which process read the browser databases? On Windows, file access auditing or EDR file events on Login Data, Cookies and Local State by anything other than the browser is direct evidence.
• Decryption: did a non-browser process decrypt browser secrets? See the Windows detection section below.
• Exposure list: enumerate every domain with saved credentials in Login Data or logins.json and every cookie for corporate IdP, SaaS and cloud console domains. This is the revocation list, not just evidence.
• Persistence in the browser: new or sideloaded extensions, changed Secure Preferences, unexpected policies forcing an extension, or a changed proxy setting (T1176.001 Browser Extensions). See the Malicious Browser Extension Incident Playbook.

Absence of the device does not mean absence of exposure. In the Snowflake Breach 2024, credentials came from infostealer infections on machines Snowflake's customers did not own, some dating back to November 2020, and still worked in 2024 because they had never been rotated. In the Cisco Breach 2022, an employee's corporate password was synced from the browser to a personal Google account that the attacker took over. When the endpoint cannot be examined, scope from identity provider and SaaS logs and treat every credential the user could have saved as exposed. See the Infostealer Logs and Session Token Abuse Guide.

Detecting browser data theft on Windows

Chromium browsers on Windows protect cookies and passwords with the Data Protection API and have set the CRYPTPROTECT_AUDIT flag since 2013, which makes decryption auditable. Google's security team published a method that uses it.

Alert when a 16385 decryption for a browser DataDescription comes from a process that is not the browser. Google notes that recent Chrome and Edge builds may log decryptions from elevation_service.exe, which is legitimate, and that logs record only executable paths, so allow-listing and removal of local admin rights reduce spoofing. App-Bound Encryption, introduced for cookies in Chrome 127 on Windows, forces malware to gain SYSTEM privileges or inject into Chrome, both noisier than reading a file as the user. It can be controlled with the ApplicationBoundEncryptionEnabled policy and, according to Google, does not work correctly with profiles that roam between machines. See the Windows Forensic Artefacts Guide.

From findings to response actions

Choosing the depth of investigation

Not every case needs a full profile decryption. Match the effort to the question and the legal position.

• Small organisations: prioritise revocation from identity provider logs and a quick history and downloads review; keep a documented profile collection procedure for the cases that need it.
• Large organisations: centralise browser telemetry (enterprise browser management reports, EDR file events, DPAPI events) so most questions are answered before anyone touches the endpoint, and keep decryption for cases with clear authority.
• Privacy: browser data is among the most personal on a device. Limit examination to the incident's scope and record why each artefact was opened. See the Forensic Readiness Guide.

Where identity fits

The output of almost every browser investigation is a list of identities: the user's human accounts, but also the machine credentials a developer or administrator handles in a browser. Personal access tokens shown once in a web console, cloud access keys pasted into a web form, OAuth consents granted to SaaS integrations and service account passwords saved by an administrator all live in browser artefacts. Treat each as a non-human identity exposure with an owner who must rotate it, not as a note in the forensic report. See the Session Hijacking and Cookie Theft Guide.

Measuring readiness

• Telemetry coverage: percentage of Windows endpoints with Audit DPAPI Activity, the DPAPI Debug channel and process creation auditing enabled and forwarded.
• Collection time: median time from alert to a hashed copy of the browser profile.
• Revocation time: time from confirming browser credential theft to revocation of IdP sessions and reset of saved passwords.
• Exposure completeness: share of cases where the exposed-credential list was reconciled against IdP and SaaS logs.
• Saved corporate passwords: number of corporate credentials found saved in unmanaged browser password stores during routine checks.

Framework mapping

Common failure patterns

• Collecting History only. Investigators answer "which sites" and miss the Login Data, cookies and extensions that determine what must be revoked.
• Dropping the WAL files. Copying a .sqlite file without its -wal sibling loses the most recent and most relevant activity.
• Wrong epoch. Treating Chromium microseconds since 1601 as Unix time produces dates centuries off; subtler errors, such as seconds versus microseconds in Firefox cookie fields, produce plausible but wrong times.
• Reimaging before scoping. Wiping the laptop removes malware but also the only record of which cookies existed. Collect the profile first.
• Revoking passwords but not sessions. A password reset does not invalidate stolen session cookies in many applications; sessions and refresh tokens need explicit revocation.
• Ignoring personal sync. Corporate passwords synced to personal browser accounts are outside corporate monitoring, as the Cisco case shows.

Practitioner checklist

• Document browser profile paths for every browser you allow, by operating system.
• Collect whole profiles with WAL and journal files, plus Local State or key4.db, and hash on collection.
• Capture memory before shutdown when sessions may still be live.
• Isolate from the network rather than closing the browser, to stop sync overwriting evidence.
• Validate timestamp conversion against an independent log before reporting times.
• Enable Audit DPAPI Activity, the Crypto-DPAPI Debug channel and process creation auditing on Windows, and alert on non-browser decryption.
• Produce an exposed-credential and session list from every case and drive revocation from it.
• Block saving of corporate passwords in unmanaged browser stores and restrict sync by enterprise policy.

Standards and references

• NIST: SP 800-86 Guide to Integrating Forensic Techniques into Incident Response
• Mozilla: Profiles, Where Firefox Stores Your Bookmarks, Passwords and Other User Data
• Chromium: User Data Directory
• Google Security Blog: Detecting Browser Data Theft Using Windows Event Logs
• Google Security Blog: Improving the Security of Chrome Cookies on Windows
• MITRE ATT&CK: Credentials from Web Browsers
• MITRE ATT&CK: Steal Web Session Cookie

Related NHI Mgmt Group resources: Digital Forensics (DFIR) Guide · Infostealer Threat Guide · Browser Security Hardening Guide · Token and Session Security Guide