Web Browser and E-mail Forensics

Forensic Artifact Extraction from Chrome, Firefox, and Edge

Modern web browsers are among the richest sources of evidentiary material on an endpoint. They persist, often without the user's explicit awareness, a granular trace of navigation, authentication, search intent, and downloaded content. For the forensic examiner, the browser profile is effectively a longitudinal diary of the subject's online behavior. This section develops the architectural foundations, storage primitives, and extraction techniques required to recover and interpret artifacts from the three dominant desktop engines: the Chromium family (Google Chrome, Microsoft Edge, Brave, Opera, Vivaldi) and Mozilla's Gecko family (Firefox, Thunderbird, Waterfox).

1. Architectural Divergence: Chromium versus Gecko

Chromium-based browsers share a common rendering engine, Blink, and JavaScript engine, V8, organized around a multi-process architecture in which each tab, extension, and plugin is isolated into a sandboxed renderer. Microsoft Edge migrated from its proprietary EdgeHTML/Chakra stack to Chromium in January 2020, meaning that, from a forensic standpoint, contemporary Edge is functionally indistinguishable from Chrome save for profile paths and branding strings. Gecko-based browsers, by contrast, rely on the SpiderMonkey JavaScript engine and a historically single-process (now increasingly multi-process via Electrolysis, or e10s) model.

This divergence has direct forensic consequences. Chromium stores the majority of structured artifacts in SQLite databases located within a per-profile directory, while Firefox uses a similar SQLite-backed approach but with distinct schema conventions, a different timestamp epoch, and a separate credential vault. Cache formats also differ: Chromium employs the Simple Cache format (a hashed, block-oriented layout), whereas Firefox uses a monolithic cache2 directory with entry files keyed by SHA-1 hashes of the origin and URL.

2. Profile Layout and Canonical Artifact Files

On Windows, the canonical Chromium profile resides at %LOCALAPPDATA%\Google\Chrome\User Data\Default\, while Edge uses %LOCALAPPDATA%\Microsoft\Edge\User Data\Default\. Firefox profiles live under %APPDATA%\Mozilla\Firefox\Profiles\<random>.default-release\. The examiner should inventory, at minimum, the following files:

Artifact	Chromium File	Firefox File
Browsing history	History	places.sqlite
Bookmarks	Bookmarks (JSON)	places.sqlite
Cookies	Cookies	cookies.sqlite
Autofill / forms	Web Data	formhistory.sqlite
Saved passwords	Login Data	logins.json + key4.db
HTTP cache	Cache/ (Simple Cache)	cache2/entries/
Local storage	Local Storage/leveldb/	webappsstore.sqlite
IndexedDB	IndexedDB/	storage/default/
Extensions	Extensions/	extensions/

Note that Chromium's Local Storage migrated from SQLite to a LevelDB key-value store circa version 61; this transition is a common source of missed artifacts in legacy toolchains.

3. SQLite Internals and Recovery of Deleted Records

Both engines rely heavily on SQLite, a page-oriented B-tree database with a default page size of 4096 bytes (though Chromium's History database often uses 4096 while Firefox's places.sqlite may use 32768). The file header occupies the first 100 bytes and begins with the magic string SQLite format 3\000. Each page $p_i$ is classified as interior or leaf, and records are stored as variable-length serial-type tuples.

The forensic significance of SQLite lies in its treatment of deleted rows. When a row is removed, SQLite does not zero the underlying page; instead, the cell pointer is removed from the page's cell-pointer array and the freed space is added to the freeblock chain. Until the page is defragmented or reused, the raw bytes of the deleted record remain recoverable. The examiner should therefore:

1. Parse the page header to identify the cell-content region offset $o_c$ and the number of cells $n_c$.
2. Walk the freeblock linked list starting at offset 1 of the page, where each freeblock header is $\langle \text{next\_offset}:2, \text{size}:2 \rangle$ bytes.
3. Carve residual record payloads by decoding the SQLite varint serial-type stream: a serial type $s$ encodes a blob of length $\lfloor (s-13)/2 \rfloor$ bytes when $s \geq 13$ and odd, or a text string of length $\lfloor (s-13)/2 \rfloor$ when $s \geq 13$ and even.

In addition to the main database file, the examiner must acquire the WAL (Write-Ahead Log) file (History-wal) and the rollback journal (History-journal). The WAL contains committed transactions not yet checkpointed into the main file and frequently holds the most recent — and most forensically valuable — records. A WAL frame header is 24 bytes, followed by a page-sized payload; the frame checksum uses either native or byte-swapped byte order as indicated in the WAL header at offset 24.

4. Decryption of Stored Credentials and Cookies

Chromium encrypts sensitive values (cookies, saved passwords, WebCrypto keys) using AES-128-CBC or, in modern versions, AES-256-GCM. The ciphertext is prefixed with a version tag: v10 indicates AES-CBC with a static key derived from the OS credential store, while v11 (Linux) and v20 (newer Chrome on Windows with App-Bound encryption) indicate alternative derivations.

On Windows, the master key is stored in the JSON file Local State under the path $.os_crypt.encrypted_key as a Base64-encoded blob. After Base64 decoding, the blob begins with the literal DPAPI; the remaining bytes are decrypted via the Windows DPAPI (Data Protection API) call CryptUnprotectData, which binds the key to the user's logon credentials and, optionally, to the machine SID. Formally, let $K_m$ denote the master key; then

$$K_m = \text{DPAPI}^{-1}\big(\text{Base64Decode}(\texttt{encrypted\_key})[5:]\big).$$

Each cookie value $C$ in the Cookies database is then recovered as

$$P = \text{AES-GCM}^{-1}_{K_m}\big(C[3:15],\; C[15:-16],\; C[-16:]\big),$$

where $C[3:15]$ is the 12-byte nonce, $C[15:-16]$ is the ciphertext, and $C[-16:]$ is the 16-byte GCM authentication tag. Failure of the tag to verify indicates either key mismatch (e.g., the profile was copied from a different user or machine) or corruption.

On macOS, Chromium retrieves $K_m$ from the Keychain under the service name Chrome Safe Storage; on Linux, it is drawn from libsecret or KWallet, with a fallback to the hard-coded string peanuts (which yields a trivially derivable key via PBKDF2). Firefox uses a different model: encrypted logins in logins.json are wrapped with 3DES or AES-CBC using a key unwrapped from key4.db (a SQLite database containing a PKCS#11 soft-token). The master password, if set, gates the unwrap via

$$K_{\text{wrap}} = \text{PBKDF2}_{\text{HMAC-SHA256}}(\text{pwd},\; \text{salt},\; c,\; 32),$$

with $c$ typically 10,000 iterations. Absent a master password, $K_{\text{wrap}}$ is derivable from the global salt alone, rendering the vault accessible to any examiner with file-system access.

5. Temporal Normalization Across Engines

A persistent source of error in cross-browser timeline analysis is the heterogeneity of timestamp epochs. Chromium records most timestamps in the WebKit epoch — microseconds since 1601-01-01 00:00:00 UTC, the Windows FILETIME epoch. Conversion to Unix time $t_U$ proceeds as

$$t_U = \frac{t_W}{10^6} - 11644473600,$$

where $11644473600$ is the number of seconds between 1601-01-01 and 1970-01-01. Firefox, by contrast, uses PRTime: microseconds since the Unix epoch. Cookies in Firefox's cookies.sqlite are stored as Unix seconds, while places.sqlite history visits are PRTime. Edge, being Chromium-based, inherits the WebKit epoch. The examiner must normalize all timestamps to a single reference frame — typically UTC Unix milliseconds — before merging events into a unified

Email Forensics Header Analysis and Client Investigation

Email Forensics is the systematic process of capturing, preserving, and analyzing electronic mail to establish the origin, integrity, and intent of a message. In graduate-level investigations, analyzing an email extends far beyond reading the body text; it requires a rigorous examination of the underlying routing protocols, authentication mechanisms, and local storage artifacts. This section details the technical methodologies for parsing email headers to trace network provenance, applies microeconomic models to understand attacker behavior regarding spoofing, and outlines the extraction of artifacts from local clients and webmail environments.

Header Parsing and Network Provenance

The foundation of email tracing lies in the analysis of the message header, governed by the RFC 5322 Internet Message Format standard. When an email is transmitted, it passes through a series of Mail Transfer Agents (MTAs). Each MTA that handles the message prepends a Received header to the top of the header block, creating a chronological chain of custody that must be read from bottom to top.

To trace the true origin of a message, an investigator must isolate the originating IP address. This is typically found in the earliest trusted Received header, or in proprietary headers such as X-Originating-IP or X-Mailer. However, because headers can be trivially forged by the originating client, forensic validity requires corroborating the client-injected headers with the server-injected Received chain.

Let the header chain be modeled as a directed acyclic graph $G = (V, E)$, where vertices $V$ represent MTAs and edges $E$ represent the transmission paths. For each hop $i$, the MTA records a timestamp $T_i$. The transmission latency between hop $i$ and the preceding hop $i-1$ is defined as $\delta_i = T_{i-1} - T_i$. Under normal network conditions, $\delta_i$ follows a stochastic distribution $\delta_i \sim \mathcal{N}(\mu, \sigma^2)$. An anomalous latency where $\delta_i > \mu + 3\sigma$ often indicates a queuing delay, a manual replay attack, or a break in the automated MTA chain (e.g., a message drafted offline and injected later). By mapping the IP addresses extracted from the trusted $V$ nodes against Autonomous System Numbers (ASNs) and Border Gateway Protocol (BGP) routing tables, investigators can geolocate the origin and determine the organizational ownership of the sending infrastructure.

Spoofing Identification and the Economics of Authentication

Email spoofing—the forgery of the From address to masquerade as a trusted entity—is mitigated by a triad of authentication protocols: Sender Policy Framework (SPF), DomainKeys Identified Mail (DKIM), and Domain-based Message Authentication, Reporting, and Conformance (DMARC). SPF (RFC 7208) validates the Return-Path IP against authorized DNS records; DKIM (RFC 6376) applies cryptographic signatures to verify message integrity; and DMARC (RFC 7489) aligns the From header with SPF and DKIM results, dictating a policy (none, quarantine, or reject) for failed validations.

To understand why an attacker chooses a specific spoofing methodology, forensic investigators must apply economic intuition to cyber deception. Let the attacker’s utility function be defined as $U(x_1, x_2)$, where $x_1$ represents the capital invested in infrastructure evasion (e.g., acquiring aged domains, executing account takeovers) and $x_2$ represents the volume of malicious emails dispatched. The expected utility is:

$$U(x_1, x_2) = p(x_1, d) \cdot x_2 \cdot R - C(x_1, x_2)$$

where $p(x_1, d)$ is the probability of successful delivery contingent on the defender's DMARC policy $d$, $R$ is the expected revenue per successful compromise, and $C(x_1, x_2)$ is the cost function. Within feasible operational bounds, we assume $\frac{\partial U}{\partial x_1} > 0$ and $\frac{\partial U}{\partial x_2} > 0$, meaning increased investment in evasion and higher volume yield greater utility.

However, when a target organization enforces a strict DMARC policy ($d = \text{reject}$), the marginal probability of success for direct domain spoofing approaches zero ($\frac{\partial p}{\partial x_1} \to 0$ for $x_1$ directed at direct spoofing). The economic intuition here is profound: DMARC does not eliminate phishing; rather, it acts as a regulatory tax that alters the attacker's cost-benefit calculus. Forced to abandon direct spoofing, the attacker must shift their investment $x_1^*$ toward higher-barrier strategies, such as registering lookalike domains (typosquatting) or compromising legitimate vendor accounts.

When a forensic investigator analyzes a phishing email and discovers a meticulously crafted lookalike domain (e.g., rnicrosoft.com instead of microsoft.com) alongside valid DKIM signatures for that fraudulent domain, they are observing the direct economic outcome of the target's DMARC enforcement. This artifact profiles the attacker as sophisticated and confirms that the target's security posture has successfully shifted the attacker's marginal costs, forcing them to expend resources on domain registration and reputation building rather than relying on trivial header forgery.

Local Email Client Artifacts and Timeline Reconstruction

When investigating endpoints, forensic examiners must extract and parse local email client databases to reconstruct communication timelines, recover deleted messages, and identify local manipulation.

For Microsoft Outlook, data is stored in Personal Storage Table (PST) or Offline Storage Table (OST) files. These are proprietary, B-tree structured databases. Forensic parsing requires extracting the PR_CREATION_TIME and PR_CLIENT_SUBMIT_TIME MAPI properties. Discrepancies between these local properties and the RFC 5322 Date header can indicate local clock manipulation or the use of third-party email injection tools.

Open-source and Apple clients typically rely on MBOX files or SQLite databases. For instance, Mozilla Thunderbird utilizes global-messages-db.sqlite to index metadata, while Apple Mail uses an Envelope Index SQLite database. Investigators can execute SQL queries against these databases to recover "soft-deleted" emails—messages marked with a tombstone flag but not yet vacuumed from the database pages. Furthermore, analyzing the thread-id and in-reply-to metadata within these local databases allows investigators to reconstruct fragmented conversation threads that may have been intentionally dispersed across different local folders by a malicious insider attempting to obscure communication patterns.

Webmail Forensics and Browser Artifact Extraction

The proliferation of webmail services (e.g., Gmail, Outlook Web Access) shifts the forensic locus from local file systems to the web browser. Webmail investigations require the extraction of browser artifacts to prove that a specific user account was accessed, drafted, or read from a specific machine.

Modern webmail clients are essentially Single Page Applications (SPAs) that heavily utilize browser storage mechanisms to cache data for offline access and performance optimization. Key artifacts include:

1. IndexedDB: Webmail clients store large blobs of data, including email bodies and base64-encoded attachments, in IndexedDB object stores. Forensic tools can parse the underlying SQLite or LevelDB files of the browser's IndexedDB to recover drafts that were composed but never transmitted.
2. LocalStorage and SessionStorage: These key-value stores often contain session tokens, user preferences, and cached snippets of the most recently viewed email subjects.
3. Service Workers and Cache API: Intercepted network requests, including GraphQL or REST API responses containing JSON-formatted email payloads, are frequently cached by Service Workers. Extracting the browser's Cache Storage can yield complete email payloads even if the user has since deleted the message from the webmail interface.

By correlating the timestamps of these browser artifacts with the network proxy logs and the email header Received chain, an investigator can establish an irrefutable timeline of user interaction, definitively linking a physical endpoint to the composition and transmission of a fraudulent or malicious email.

---