Threat hunting is what alerts can't do.

Why waiting for the alert has a ceiling

Most security operations are reactive by design. A rule matches, an alert fires, an analyst triages it, and incident response begins from there. That model works well against attacks with an established signature, rule or behavioural fingerprint already built into the detection stack, and every SOC needs it.

It fails, by construction, against an adversary who never produces a match. An attacker who knows what common rules look for, uses the administration tools already installed across the estate, and moves slowly enough to stay under the thresholds those rules are tuned to, generates activity that matches nothing. The absence of an alert is not the absence of an adversary. That gap is not a tooling failure a better product will close. It is structural, and threat hunting is the discipline built to work inside it.

What separates hunting from triage

The clearest distinction is where each activity starts. Triage starts from an alert: a rule has fired, and an analyst decides whether it matters. A hunt starts from a hypothesis, built from threat intelligence, a past incident or unusual behaviour in the environment, and works through the available telemetry to prove or disprove it. Hunting operates on the explicit assumption that an adversary may already be present: assume breach as a working posture, not a worst-case scenario.

That is why browsing SIEM dashboards in the hope that something looks wrong is not hunting. A hunt has a specific, testable target. For example: an attacker is using malicious Office documents to run PowerShell on user workstations, which would show up as PowerShell (MITRE ATT&CK T1059.001) launched by an Office application. That statement can be proved or disproved against real data, which is what makes it a hypothesis rather than a hunch. Mature programmes use ATT&CK to frame hypotheses like this one, mapping suspected attacker behaviour to known tactics and techniques so that every hunt has a defined target rather than an open-ended search.

PEAK: a repeatable structure for a hunt

Ad hoc hunting, a skilled analyst digging because something feels off, produces real findings. It does not scale, and it does not build a capability that survives that analyst moving on. The PEAK framework, published by Splunk's SURGe research team in 2023, gives hunting the kind of repeatable structure that detection engineering gives rule-writing. The name stands for Prepare, Execute, and Act with Knowledge: three phases, with knowledge running through all of them.

Knowledge is the thread through all three: threat intelligence, knowledge of the business, the hunter's own experience, and the findings of earlier hunts, including the one in progress.

PEAK also distinguishes three kinds of hunt. A hypothesis-driven hunt tests a specific supposition, like the PowerShell example above. A baseline hunt establishes what normal behaviour looks like and searches for deviations from it. A model-assisted hunt, which PEAK calls M-ATH, uses machine learning models of known-good or known-malicious behaviour to surface candidates for a hunter to investigate. Framing hunts this way is what turns "we did some threat hunting last quarter" into a programme with a record that can be reviewed.

What a hunt produces, whatever it finds

The output of a hunt is never just a list of findings, and that is what makes hunting worth the investment even when a hunt finds no active threat. Every hunt ends in one of three outcomes.

A confirmed hypothesis goes to incident response, and usually produces new or refined detection logic, so the SIEM catches the same behaviour automatically next time. A disproved hypothesis produces documented assurance: this technique was looked for, on these systems, over this period, and was not found. That is worth having, provided it is written down with its scope and date.

The third outcome deserves equal weight: the hunt shows that the telemetry needed to test the hypothesis does not exist. "We cannot test for this technique because we do not collect the log source that would show it" is not a failure. It is the hunt doing exactly what it is supposed to do.

A hunt that shows you cannot test for a technique is not a failed hunt. It is a blind spot found before an attacker finds it.

Confirmed findings and missing telemetry are where hunting hands over to detection engineering: a confirmed pattern becomes a rule, and a missing log source becomes an onboarding decision with an owner. It is the same handover a purple-team finding has to survive, and the discipline that makes it hold, a detection or a documented reason why not, is set out in Every red-team finding should become a detection.

Where to begin

A hunt run once proves something about one moment and starts going stale immediately. The programmes that get lasting value hunt on a cadence, prioritised against the organisation's actual risk and current threat intelligence rather than whichever technique looked interesting that week. Four habits make that practical.

Alerts catch what you already knew to look for. Hunting is how you find out what you did not.

A SOC that only does the first is only ever as good as its rule library, and a rule library is, by definition, one step behind the technique nobody has written a rule for yet.