Threat Hunting

Hunting is the discipline of looking for what your detections would miss. That framing matters, because a hunt program that finds things your rules would have caught anyway is measuring its own redundancy.

It also sits on a boundary worth being precise about. Hunting is discovery in an environment presumed healthy; forensics is reconstruction of an incident already known to have happened. The techniques overlap heavily; the question does not.

Two modes

Hypothesis-driven. Start from a specific, falsifiable claim: “An adversary using valid stolen credentials would appear as authentication from a new ASN followed by privilege enumeration within the hour.” Then look for it. Structured, repeatable, and the mode that converts cleanly into detections.

Baseline or anomaly-driven. Start from the data: what is unusual here? Stack-count process names, look at the rare tail, examine what only happened once. Better at finding the unexpected, much worse at producing a defensible report when it finds nothing.

Most mature programs run mostly hypothesis-driven with periodic baseline sweeps. The common failure is calling unstructured log browsing “hunting” — enjoyable, occasionally lucky, and impossible to evaluate or repeat.

A hunt that produces value either way

The test of methodology is whether a hunt that finds nothing still leaves something behind. A structured hunt should produce four artifacts regardless of outcome:

1. The hypothesis, written before looking, specific enough to be wrong.
2. The data assessment — what you queried, over what window, and what you couldn’t query. This is often the most valuable output: hunts are the fastest way to discover coverage gaps, because you go looking for data you don’t routinely use.
3. The findings, including the negative result stated properly — “no evidence of X in the 90-day window, in the environments where Y is collected” is a real conclusion with real caveats.
4. The disposition — a new detection, a coverage gap ticket, a tuning change, or an explicit “nothing to do, revisit if intel changes”.

Hunts that end without disposition are the reason hunt programs get cut. The work happened; nothing downstream changed.

Where to hunt

Identity is the highest-yield surface, for the same reason it’s the highest-value log tier: most intrusions transit it. Impossible-travel patterns, authentication from new infrastructure, MFA fatigue patterns, token reuse, service accounts behaving interactively, and dormant accounts waking up. T1078 (Valid Accounts) is deliberately hard to detect with rules — legitimate credentials used legitimately-shaped — which makes it exactly the kind of thing hunting exists for. The IAM pillar is where the underlying mechanics live.

Cloud control plane is second: enumeration bursts, role assumption chains, changes to logging configuration, and new principals created outside the pipeline.

Both are places where the signal is behavioral and contextual rather than atomic — which is precisely where rules struggle and analysts do well.

Turning hunts into detections

The conversion is the point, and it needs a filter. Not every finding should become a rule: if the pattern is rare enough that a rule would produce constant false positives, the honest output is a recurring hunt rather than a detection.

A finding is a good detection candidate when the behavior is describable in logic, the telemetry supporting it is reliably available, and a defined response exists. When those hold, the finding enters the lifecycle as a normal backlog item with an unusually strong provenance: you already know the signal exists in your data, because you just found it there.

When they don’t hold, write it up as a repeatable hunt with its queries saved. A documented hunt someone can re-run quarterly is worth more than a rule that gets disabled in a month.

Measuring a hunt program

Findings-per-hunt is the wrong metric — it rewards hunting where you already look. Better signals:

• Detections created from hunt output.
• Coverage gaps identified — arguably the largest durable value.
• Time to answer a question: “Are we affected by X?” arriving from leadership is the test hunt programs actually get graded on, and the answer speed depends on data accessibility built beforehand.
• Techniques ruled out, with the caveats stated honestly.

A hunt program that has found no intrusions may be working perfectly. One that cannot answer “are we affected by this” within a day is not, regardless of what it has found.

How it looks in practice

The program’s maturity shows in its residue. Hunts start from a one-page template — hypothesis, data assessment, findings, disposition — and finish as saved artifacts: queries and notebooks committed to a repo where the next analyst can re-run them, rather than screenshots in a wiki. A cadence mixes the two modes, recurring hypothesis hunts on identity and the control plane with a periodic baseline sweep, and every disposition lands somewhere that outlives the hunt — a backlog item in the lifecycle, a coverage ticket against the pipeline, or a scheduled re-run. Frameworks like Splunk’s PEAK formalize exactly this shape; adopting one wholesale matters less than the template and the discipline of disposition. The strongest operational tell is speed on demand: the program that has rehearsed “are we affected by X?” answers it in hours.

Where this connects

Hunting consumes collection and produces intel back. Its findings feed the lifecycle and its coverage discoveries feed the pipeline. And it shares almost all of its technique with forensics while asking a different question — which is why the boundary between them blurs during a long-running compromise, and why that remains an open question in the site structure.