Introduction to Browser Forensics (VMware Lab)

Every click, search, and download leaves a digital footprint. While most users browse the internet unaware, forensic investigators know that browsers quietly store a wealth of information. From visited websites and saved credentials to deleted history and hidden extensions, browsers act like a personal diary of online behavior — one that can be invaluable during digital investigations.

Lab Setup

For this exercise, we shall be working with the VMWare 4N6Lab virtual machine. This preconfigured VM provides the environment needed to perform browser forensics hands-on.

You can download the VM directly from the following link:

Download 4N6Lab VM

Collecting Browser Artifacts: Open Kape from the Kape folder on your desktop.

Target Selection and Execution

Select the Source: Choose the C: drive as your target source.

Set the Destination: Create a folder named Kape_Out_Browser to store the extracted data.

Choose Browser Targets: From the list of available options, select Chrome, Edge Chromium, and Firefox.

Be sure to select Edge Chromium, not the older Edge version, since Microsoft rebuilt Edge to run on the Chromium engine.

Execute: Once all selections are complete, click Execute in the bottom-right corner to start the collection.

We will analyze the collected browser artifacts later.

Intro to Browser Forensics

Browser forensics is a critical component of digital forensic and incident response (DFIR) work. Web browsers quietly collect and store a wide range of artifacts that can serve as invaluable evidence during investigations. These include visited websites, search terms, download activity, cookies, saved form data, and more. Examining such information can help investigators uncover traces of cybercrime, insider threats, intellectual property theft, or unauthorized access attempts.

Beyond evidence collection, browser analysis offers a window into user behavior. By studying browsing history and related data, investigators can build a clearer picture of online habits, preferences, and interactions, which in turn helps reconstruct events and establish motive or intent.

Malware often leverages browsers to steal sensitive information, deliver malicious payloads, or exfiltrate data. Investigating browser artifacts can highlight suspicious extensions, unauthorized settings, or links to compromised websites, all of which serve as indicators of compromise. This makes browser forensics a valuable aid in threat hunting and attack reconstruction.

Another strength of browser forensics lies in its ability to recreate timelines. By analyzing timestamps, navigation paths, and visit patterns, investigators can map out the sequence of events leading up to or following an incident. This enables a deeper understanding of how attackers moved within a system, what they accessed, and what impact their actions had.

Browsers also store digital footprints like autofill records, saved credentials, and bookmarks. These clues often help connect users to specific accounts, services, or platforms, reinforcing findings from other sources and providing a broader context for investigations.

Finally, browser artifacts often play a key role in compliance and legal matters. Properly documented and preserved evidence ensures admissibility in court or regulatory audits, strengthening cases and supporting organizational accountability.

In short, browser forensics is indispensable to DFIR. It provides actionable intelligence, strengthens incident response, and allows investigators to attribute actions to specific users or adversaries. By uncovering hidden activity and establishing a clear narrative, browser forensics bridges the gap between technical traces and investigative insights.

Google Chrome

Google Chrome’s browsing data is stored in the user’s **AppData\\Local\\Google\\Chrome\\User Data\\Default** directory.

Chrome History Artifacts

When analyzing Google Chrome, forensic investigators can extract a variety of useful details, including:

• Websites visited within the time frame defined by Chrome’s history settings
• URL, page title, and referring site for each visit
• Frequency of visits (how many times a specific site was accessed)
• Exact date and time of each browsing session
• User account associated with the activity (since browser data is tied to individual profiles)

These artifacts provide critical insights into user behavior, web usage patterns, and timelines, making Chrome’s history one of the most revealing sources of evidence in browser forensics.

Using DB Browser for SQLite

To dig into Chrome’s history database:

• Open DB Browser for SQLite (a shortcut is usually available on your Desktop).
• Navigate to the following file location:

C:\Users\<User Name>\AppData\Local\Google\Chrome\User Data\Default

This SQLite database holds the browsing history and related data, which can be queried to reconstruct online activities during an investigation.

URLs Table

Among Chrome’s history database tables, the urls table stands out as one of the most critical for forensic analysis. It captures detailed records of every website a user has accessed, making it central to reconstructing online activity. The table stores the web address, the page title, the total number of times the site was visited, the timestamp of the most recent visit, and even a count of how often the address was manually typed into the browser’s bar.

Forensic investigators can draw significant insights from this data. By examining the urls table, they can piece together a user’s browsing history, observe patterns in online behavior, and identify visits to suspicious or malicious websites. These findings can then be cross-referenced with other browser artifacts, such as cached files, cookies, or download records, to build a more complete picture of user activity.

Because it provides such a comprehensive record of web use, the urls table is often one of the first places investigators look when analyzing browser data. Its ability to reveal not just where users have been online, but also how frequently and under what circumstances, makes it a vital component in uncovering unauthorized access, potential security incidents, or policy violations.

As seen below the table shows all URLS visited, the number of times visited, and the data of the last visit.

Keep in mind that timestamps in the urls table are stored in the WebKit time format. To make them readable, you’ll need to decode them. One of the easiest tools for this is DCode. Simply copy the WebKit time value and paste it into DCode’s input field. Once you click “Decode,” the converted, human-readable time will appear on the left panel, as shown in the example below.

Visits Table

The visits table in Chrome’s browser history database is a core source of evidence for forensic investigations because it provides fine-grained details about user navigation. While the urls table logs what sites were visited, the visits table records each specific visit, allowing investigators to trace browsing activity at a much deeper level.

This table captures critical details such as:

• The timestamp of the visit.
• The transition type, showing how the user arrived at the page (e.g., typed directly, clicked a link, or through a redirect).
• The referring visit ID, which links visits together to form a sequence of actions.

The transition field is especially important since it distinguishes between intentional user actions (like typing an address) and automated or redirected visits, which may point to suspicious behavior or malware activity.

By analyzing this table, forensic analysts can:

• Build a chronological timeline of browsing activity.
• Detect patterns that suggest malicious or abnormal usage.
• Correlate browser activity with other artifacts, such as network logs, cache, or malware traces.

In short, the visits table gives investigators the ability to reconstruct not only what sites were accessed but also how and why a user — or attacker — landed on them, making it an indispensable artifact in browser forensics.

Transition Field

The transition field in Chrome’s visits table is a key element in browser forensics, as it reveals how a user arrived at a specific webpage. Rather than only logging the fact that a page was visited, the transition field provides valuable context — was it a direct action, like typing in a URL or clicking a link, or was it the result of an indirect event, such as a redirect or automated subframe load?

This field encodes both core transition types and qualifiers, allowing analysts to reconstruct not just the browsing timeline but also the exact nature of each navigation event. With this information, investigators can identify whether a visit was intentional, automated, or part of a longer navigation chain, helping to distinguish legitimate activity from suspicious or coerced behavior.

Core Transition Types

Core transition types describe the primary method of navigation and are stored in the last 4 bits of the transition field. Common values include:

LINK (0): When the user clicks a hyperlink.

TYPED (1): When the URL is manually typed into the address bar.

AUTO_BOOKMARK (2): Visits originating from bookmarks.

AUTO_SUBFRAME (3): Automatic loads within subframes (e.g., embedded content).

FORM_SUBMIT (7): Triggered by submitting a form.

RELOAD (8): Refreshing or reloading a page.

Qualifiers

Qualifiers add another layer of detail by describing the context of the visit. They are stored in the higher bits of the transition field and may include:

CHAIN_START (8388608): Marks the beginning of a navigation chain.

CHAIN_END (16777216): Marks the end of a chain.

CLIENT_REDIRECT (33554432): Redirects triggered client-side (e.g., JavaScript, meta-refresh).

SERVER_REDIRECT (67108864): Redirects triggered by the server.

FORWARD_BACK (268435456): Navigations caused by the browser’s back or forward buttons.

Why It Matters

By combining transition types and qualifiers, forensic analysts can precisely reconstruct browsing activity — whether a user intentionally visited a site, was redirected without realizing, or repeatedly cycled through pages. This makes the transition field a powerful tool for detecting malicious redirections, phishing attempts, or automated activity hidden within otherwise normal browsing patterns.

Core Transition Types

Qualifiers

Convert core transition

SELECT id, visit_time, transition, 
transition & 0xFF AS core_transition
FROM visits;

Convert Qualifier

SELECT 
    id, 
    url, 
    visit_time, 
    visit_duration, 
    visit_duration / 1000000 AS duration_seconds, -- Convert to seconds
    (visit_duration / 1000000) / 60 AS duration_minutes, -- Convert to minutes
    (visit_duration / 1000000) % 60 AS duration_mod_seconds, -- Remaining seconds
    printf('%d:%02d', (visit_duration / 1000000) / 60, (visit_duration / 1000000) % 60) AS formatted_duration
FROM 
    visits;

Visit Duration

The visit duration field in Chrome’s browser history database records how long a user spent on a webpage during a given session. Measured in microseconds, this value helps forensic analysts assess user engagement and interaction with specific web content.

By examining visit duration, investigators can identify which sites captured the most attention, detect periods of likely inactivity, or spot unusual patterns that might point to automated browsing behavior (e.g., bots or scripted activity). When correlated with other data, such as transition types or referring visits — this field becomes a powerful tool for reconstructing user behavior and understanding the broader context of browsing activity on a system.

It’s important to note that the duration is stored in microseconds. For instance, a raw value like 1374728 in the “visit duration” field represents the length of the visit in microseconds. To interpret this meaningfully, it must be converted into a human-readable format such as hours, minutes, and seconds through straightforward calculations.

To interpret the raw value in the visit duration field, you need to convert it into a human-readable format. Here’s how:

Convert milliseconds to seconds

1374728 \, \text{ms} \div 1000 = 1374.728 \, \text{s}

So, the visit lasted about 1374.728 seconds.

Convert seconds into minutes and seconds

1374.728 \, \text{s} \div 60 \, \text{s/min} = 22.912 \, \text{min}

Which means the visit duration equals 22 minutes and 54.728 seconds (approximately).

Alternatively, you can perform the conversion directly within SQL queries, making it easier to process large datasets of browsing durations without manual calculation.

SELECT 
    id, 
    url, 
    visit_time, 
    visit_duration, 
    visit_duration / 1000000 AS duration_seconds, -- Convert to seconds
    (visit_duration / 1000000) / 60 AS duration_minutes, -- Convert to minutes
    (visit_duration / 1000000) % 60 AS duration_mod_seconds, -- Remaining seconds
    printf('%d:%02d', (visit_duration / 1000000) / 60, (visit_duration / 1000000) % 60) AS formatted_duration
FROM 
    visits;

Correlating the URLs and Visits Tables

Google Chrome records more detailed information about browsing activity than most other browsers. However, unlocking that depth of data requires correlating multiple tables within the History SQLite database.

For instance, the urls table stores key fields like the URL, page title, visit count, and the last time the site was accessed. In one example, entry ID 470 shows that the user visited a specific site four times. While the urls table only provides the last visit timestamp (last_visit_time), it doesn’t give the full picture.

To reconstruct a complete history, investigators must look at the visits table. By cross-referencing entries via the url field, analysts can determine:

• The exact timestamps of each individual visit (in WebKit time format)
• How the user reached the site (via from_visit and transition)
• The duration of each visit (visit_duration)

By combining data from both tables, forensic analysts can build a precise and chronological timeline of user browsing activity, offering deeper insights into user behavior and potential evidence of suspicious or malicious activity.

After converting the raw WebKit timestamps, we now have clear human-readable dates and times for each visit to the URL:

• 2024–04–12 02:38:57
• 2024–04–12 02:44:00
• 2024–05–07 19:14:13
• 2024–05–07 19:20:15

This demonstrates how analyzing the SQLite database directly allows us to reconstruct detailed timelines of user activity, giving investigators visibility into exactly when and how often a site was accessed.

Wrapping Up

By learning how to query the Chrome History database and convert values like timestamps, we’ve gained a deeper understanding of how browser artifacts can be used to trace online behavior. However, working directly with SQLite can be time-consuming and requires manual conversions for fields such as WebKit time and visit durations.

To streamline investigations, the next section will introduce specialized forensic tools that automatically parse and translate these artifacts into human-readable formats. These tools make browser forensics more efficient, enabling faster insights and more comprehensive reporting.

*linktree*