Browser, Email & Cloud Forensics

Web browsers and email clients generate a surprisingly detailed record of user activity — history, cached pages, form data, passwords, and more. Add cloud storage into the picture and the investigator may find evidence that never touched the local disk at all. This chapter covers where each artifact lives and how to extract it.

6.1Browser Forensic Artifacts

Think of a browser as an automatic evidence-collection machine that runs silently in the background. Every page visited, every file downloaded, every password saved, and every form filled — all of it lands in a set of SQLite databases on the local disk. SQLite is especially forensic-friendly because deleted records remain in the database's "free pages" until the space is reused, which means a row that the user or attacker deleted from the history table may still be physically present in the file.

Chrome and Edge store their artifacts under %USERPROFILE%\AppData\Local\Google\Chrome\User Data\Default\ on Windows (Edge uses Microsoft\Edge in the same parent path). The key files:

• History (SQLite) — URLs visited, visit count, visit timestamps, typed search queries, and downloaded files (file name, source URL, local save path, download start/end timestamps).
• Cache — web page content stored locally in cache_data/. The cache reveals pages the user visited even if the History database was manually cleared, because clearing history does not wipe the cache.
• Cookies (SQLite) — session tokens, login state indicators, and tracking identifiers. A valid session cookie can be replayed to impersonate a logged-in user.
• Login Data (SQLite, DPAPI-encrypted) — saved usernames and passwords, encrypted with the Windows Data Protection API. Decryptable on the same machine with the user's credentials, or with tools such as ChromePass.
• Web Data (SQLite) — autofill form data: addresses, phone numbers, and credit card numbers (encrypted).

Firefox stores the same categories under %APPDATA%\Mozilla\Firefox\Profiles\[random.profile]\. The main files are places.sqlite (browsing history and bookmarks), cookies.sqlite, and formhistory.sqlite.

Private / Incognito browsing does not write history or cookies to disk during the session. However, the DNS cache, some cached resources, and OS-level access timestamps may persist even after the window closes.

6.2Email Types & Protocols

The forensic approach to email evidence depends entirely on which protocol the account uses, because the protocol determines where the primary copy of the email actually lives.

POP3 (Post Office Protocol v3) downloads email from the server to the local device and, by default, deletes it from the server after download. If you seize the device, all the email is there. If the device is unavailable, the server may have nothing — especially for older messages.

IMAP (Internet Message Access Protocol) keeps email on the server and shows the device a synchronised view. Seizure of the device gives a snapshot of what was downloaded at that moment, but the server holds the authoritative record including deleted emails (held for 30–90 days typically). For a complete picture, both the device and a legal request to the provider are needed.

SMTP (Simple Mail Transfer Protocol) is the outgoing transmission protocol. It is not used to retrieve mail. SMTP server logs at the sender's ISP or corporate mail server show when a message was sent, from which IP address, and to which recipient — useful for proving an email was sent even if it was deleted from the sender's sent folder.

Webmail (Gmail, Outlook.com, Yahoo Mail) has no local client at all. Evidence is entirely server-side, except for what appeared in the browser cache or history during a session. Obtaining the full mailbox requires a legal process — a domestic court order or, for providers in other jurisdictions, a Mutual Legal Assistance Treaty (MLAT) request.

Email file formats an examiner encounters on a seized device:

• .PST — Outlook Personal Storage Table; a local archive of the entire mailbox including inbox, sent, deleted, and calendar items.
• .OST — Outlook Offline Storage Table; a local cache of the IMAP/Exchange mailbox. Can be forensically parsed even without server access.
• .EML — a single email message in RFC 2822 format, complete with full headers.
• .MBOX — Unix mail spool format; all emails in a single file, concatenated.

6.3Email Header Analysis

An email header is the routing slip attached to every message — it records every mail server the message passed through, each adding its own timestamp and IP address. Headers are the most reliable way to trace the true origin of an email, because while the body and From: address can be trivially forged, the routing records added by mail servers cannot be altered retroactively.

Reading order: headers are read from the bottom up. The bottom-most Received: line was added by the sender's mail server — it is closest to the origin. Each subsequent line above it represents the next hop. The top Received: line is the one added by the recipient's incoming server.

Key header fields:

• From: — the display name and address the sender chose. Can be set to anything — completely forgeable.
• Reply-To: — where replies will be directed. In phishing emails, this is often a different address than From:, designed to capture responses.
• Received: — one line per mail server hop. The bottom-most line contains the originating server's IP. Look here to find where the email actually came from.
• Message-ID: — a unique identifier generated by the sending server, formatted as <random@sendingserver.com>. The domain part reveals the actual sending mail server.
• X-Originating-IP: — some providers (Yahoo, older Gmail) add the sender's client IP address here. If present, this is the strongest link to the sender's physical location.
• DKIM-Signature: — a cryptographic signature proving the email was sent through the legitimate mail infrastructure of the stated domain. An absent or invalid DKIM signature on an email claiming to be from a major bank is a strong indicator of spoofing.
• Received-SPF: — the result of the Sender Policy Framework check: did the sending IP address match the list of authorised senders for that domain? A fail or softfail result alongside a suspicious From: address confirms spoofing.

Identifying a spoofed email: the From: header reads security@sbi.co.in; but the bottom Received: line shows an IP address geolocating to an unrelated country; the Received-SPF: result is fail; the DKIM-Signature: is absent. All four point to a forged sender address.

6.4Virtual Machine Forensics

A virtual machine is a complete computer — CPU, RAM, disk, network — that runs as a set of files on a host operating system. Attackers use VMs to sandbox malicious activity and then simply delete the VM files to erase evidence. The forensic response is to locate and mount those files.

VMware file artifacts on the host:

• .vmx — plain-text configuration file listing hardware settings, snapshot names, and network configuration
• .vmdk — the virtual disk file containing the guest OS file system
• .vmem — memory dump of the VM if it was suspended rather than shut down; treat this like a RAM dump for memory forensics
• .nvram — virtual BIOS/UEFI state
• vmware.log — activity log recording power-on/off times, snapshot operations, and network events

VirtualBox: .vbox (XML config), .vdi (virtual disk), .sav (saved state / RAM snapshot).

Hyper-V: .vhd or .vhdx (virtual disk), Virtual Machines\*.xml (config file).

Forensic approach: mount the virtual disk file using forensic software (FTK Imager, Autopsy, or kpartx/loop device on Linux) to access the guest OS file system. Then apply all standard OS artifact analysis — Windows Registry, Event Logs, Linux /var/log/, browser artifacts — exactly as if it were a physical drive. The guest OS inside a VM leaves the same artifacts as a real installation.

Deleted VMs: even if the .vmdk was deleted, the MFT entry on the host NTFS volume may persist, recording the file name, path, and size. The vmware.log file on the host and directory listings in hypervisor management databases often survive VM deletion and can confirm that a VM existed and when it was last powered on.

6.5Cloud Forensics

Cloud computing shifts control of infrastructure away from the suspect and toward a service provider, which creates both opportunities (rich server-side logs) and challenges (jurisdiction, encryption, data retention policies).

Cloud service models and their forensic implications:

• IaaS (Infrastructure as a Service) — examples: AWS EC2, Azure VMs, Google Compute Engine. The customer controls the VM and OS. Forensic images of virtual disks can be obtained from the provider with a legal request. The cloud provider maintains audit trail logs (AWS CloudTrail, Azure Activity Log) recording every API call, user action, and network event. These logs are the IaaS equivalent of security event logs.
• PaaS (Platform as a Service) — examples: Heroku, Google App Engine, Azure App Service. The provider manages the OS. No OS-level artifacts are available. Forensic data is limited to application logs, database contents, and platform access logs. Request these via legal process.
• SaaS (Software as a Service) — examples: Gmail, Dropbox, Salesforce, Microsoft 365. The provider manages everything. Forensic data comes entirely via API or legal process. Provider access logs typically record IP address, timestamp, user agent, and action type for every login and file access event.

Challenges unique to cloud forensics: data may be physically distributed across multiple countries (creating conflicting jurisdictions); data may be encrypted at rest with keys held by the provider; cloud providers may delete data faster than legal process can arrive; audit logging may not be enabled by default (the customer may need to have turned it on before the incident).

Evidence collection approaches: issue a legal hold notice to the provider as early as possible to pause deletion; use a domestic court order or MLAT for cross-border evidence; capture screenshots with a hash and timestamp as preliminary evidence; use API-based forensic collection tools (Oxygen Forensic Cloud Extractor, Cellebrite UFED Cloud) to preserve data in a forensically sound format.

On-device cloud artifacts: even when cloud data is primarily server-side, the local sync client leaves traces. Dropbox, OneDrive, and iCloud Drive sync clients create local log files and database files recording file sync history including deleted files. The browser cache may contain thumbnails of cloud documents viewed in a web interface.