Investigate a phishing incident with browser artifacts

A phishing case is a sequence of questions: how did the user reach the lure, what came down the wire, and what did the attacker walk away with. Each question maps to a specific browser artifact, and the answers line up into a single chain you can hand off. The workflow below walks that chain in order, then ties it together with a timeline and IOC sweep.

Find the entry point

Start in the History database, in urls joined to visits. The phishing URL is the anchor — pull its row and read the transition type on the matching visit. A typed transition means the user entered the address themselves, usually off a lookalike domain; a link transition means they clicked through; a redirect transition means something bounced them there.

From there, walk from_visit backwards. Each visit points at the one that referred it, so following the chain takes you from the landing page back to the source — the mail-client link, the ad, the shortened URL the user actually clicked. That referrer walk is what turns "they ended up on a bad site" into "here is exactly how they got there."

Recover the payload

If the lure delivered a file, it lands in the Downloads table of the same History DB. The row gives you the saved path, the file size, and whether it was opened. To see the real source behind a redirect or a URL shortener, read downloads_url_chains: it records every hop the download passed through, so the final entry is the true origin even when the visible link was a bit.ly or a tracking redirector.

See what was typed

The Shortcuts table — omni_box_shortcuts — captures partial strings the user typed into the omnibox along with what they resolved to. In a phishing case this recovers the lookalike domain the user keyed in by hand, or a search query that led them to the lure, even when no full visit landed in history.

Assess credential and session impact

Two artifacts answer the blast-radius question:

Cookies — decrypt the values to check for live session tokens for the spoofed or downstream sites. A present, valid token tells you a session existed that an attacker could replay.
Login Data — enumerate saved credentials for the spoofed site and anything related. These are the passwords that were reachable from the compromised profile.

Together they separate "the user entered credentials into a phishing page" from "the attacker had everything the profile already stored."

Timeline the sequence

Merge the artifacts above into one chronological view. The entry visit, the redirect hops, the download start and finish, and any cookie set should line up within seconds of each other. A cookie set next to the landing-page visit pins a live session; a download timestamp right after the click confirms the lure fired. Adjacency in a sorted timeline makes the order of operations obvious. See build a browser activity timeline for the full merge-and-filter workflow.

Sweep for every touch

You now have a known-bad domain or URL. Paste it into the IOC box and match it across all artifacts at once — history, downloads, cookies, shortcuts, cache. This finds every place the indicator appears, including touches that did not surface in the linear chain: a cookie set on a second visit, a cached resource, a redirect host you had not noted. The IOC hunting workflow covers how to build and apply an indicator list.

Export for handover

Close the case with a hashed report. Export the matched rows, the timeline, and the artifact counts so the rest of the IR team gets a reproducible record with integrity hashes for chain of custody.

Every step here — parsing the History DB, decrypting cookies, building the timeline, and matching IOCs — runs entirely client-side. The profile copy never leaves the workstation, so the analysis works on an air-gapped IR box and the acquisition stays inside its original boundary. For the artifact-by-artifact reference behind this workflow, see browser forensics for incident response.