Hunt IOCs across browser artifacts

You arrive with a list — known-bad domains from a feed, C2 URLs from a sandbox detonation, a leaked credential, a session token pulled from a proxy log. The question is always the same: did any of this touch the host? The IOC panel answers it by highlighting every match across every artifact at once, instead of making you search each table by hand.

Paste your indicators

Drop the indicators into the IOC panel, one per line. Each line is an independent matcher, so a list can mix types freely:

Domains — evil-update.example, a phishing or known-bad host.
URL fragments — a C2 path, a campaign query string, a redirector.
Tokens — a specific session-id or auth value you are tracing.
Identities — a leaked email address or username.
File names — the binary that came down in a download.

There is no special syntax to learn. A line is just a substring to look for, which is why the same box handles a full URL and a bare username equally well.

How matching works

Matching is plain case-insensitive substring over the visible cell text of every table. That is a deliberate choice: it is simple and predictable, with no regex surprises, no anchoring, no escaping. If the string appears anywhere in a row's displayed text, the row matches.

The trade-off is the usual one for substring matching — a short or generic indicator will over-match. Paste the registrable domain or a distinctive path fragment rather than a two-letter string, and the hits stay meaningful.

Read the hits

Once indicators are in, the results surface in three places at once:

Highlighted rows in every artifact table — history, cookies, cache, downloads — and in the unified timeline. The same indicator lights up wherever it landed, so a domain that shows up in both history and a cookie reads as one finding across two artifacts.
Per-table hit count — how many rows matched in each table, so you see at a glance whether the action is in history, the cache, or cookies.
Global hit total — the headline number across everything loaded. Zero is itself an answer: the indicator did not touch this profile.

Use the show only matches toggle to collapse each table down to the matching rows. On a daily-driver profile of tens of thousands of rows, that turns a needle-in-haystack scan into a short, reviewable list.

Seed indicators from the Overview

You do not always arrive with a list. The Overview panel ranks the top domains in the loaded profile, and clicking one adds it straight to the IOC set. That makes the panel work the other way round too: start from what the host talked to most, promote the suspicious ones to indicators, and watch them light up across the timeline. It is a fast way to build a working hypothesis when the lead is "this host looks off" rather than a named threat.

Why the unified timeline matters here

A table tells you an indicator was present. The timeline tells you when and next to what. Because matches highlight in the unified timeline as well, a hit on a C2 domain sitting one second from a download, or a leaked email next to a login event, reads as a sequence rather than two unrelated rows. See build a unified browser activity timeline for how that view is assembled and how it normalises timestamps across browsers.

Hand it off

When the hunt is done, export the HTML report. It carries the IOC list and the hit totals along with the artifacts, so the recipient sees not just the matches but exactly what was searched for and how many times each indicator landed. That context is what makes the report defensible in a browser-led incident response handover rather than a screenshot.

Everything runs client-side. The indicator list, the artifacts, and the report never leave the machine — nothing is uploaded — which keeps a sensitive IOC feed and a sensitive acquisition inside the same boundary.