Hunting: Proactive, Hypothesis-Driven Detection

What is it?

Threat hunting is the deliberate search for adversary activity that no alert fired on. It starts from a hypothesis — a specific, testable claim about how an attacker might be operating — and looks for evidence that confirms or refutes it, rather than waiting for a detection rule to trigger.

Why it matters

Alerts only catch what someone already wrote a rule for. Skilled adversaries operate in the gaps between rules. Hunting is how a Tier-2 team finds the intrusion that was never alerted on — and, as a by-product, turns each successful hunt into a new detection so the gap closes.

Where you see it

Hunts run over the same data lakes as detection — SIEM, EDR telemetry, network and DNS logs — but read them with a question in mind rather than a rule. The hunt itself lives in a documented hypothesis, the queries run, and the outcome recorded for the next analyst.

What normal looks like

Most hunts end without finding an intrusion — and that is a success, not a failure, because a well-scoped hunt that finds nothing raises confidence that a specific technique is not present. A hunt that 'always finds something' is usually poorly scoped, not unusually effective.

What suspicious looks like

A hunt surfaces suspicion when evidence matching the hypothesis appears and survives the search for an innocent explanation. The finding is not 'this looks odd' but 'this matches the predicted attacker behaviour and no benign process accounts for it'.

How analysts investigate

Follow the loop: state a hypothesis, decide what evidence would confirm or refute it, query the data, and then — crucially — actively look for a benign explanation before concluding. End every hunt with an outcome: a detection built, a lead escalated, or a documented 'not present, at this confidence'.

Common beginner mistakes

Hunting without a hypothesis — running queries at random and calling any anomaly a finding.
Stopping at the first match without searching for the benign explanation that would dismiss it.
Treating a hunt that found nothing as wasted time, instead of recorded, reusable assurance.

What you will be able to do

Explain how proactive hunting differs from alert-driven detection.
State the hunt loop: hypothesis → pivot → competing explanations → confidence → outcome.
Treat a well-scoped hunt that finds nothing as a successful, recorded outcome.

Tier-1 waits for the queue; Tier-2 also goes looking. Hunting is the discipline of looking well: not wandering the data hoping to trip over something, but forming a precise claim about attacker behaviour and testing it the way a scientist tests a hypothesis.

  HYPOTHESIS   'An attacker is using scheduled tasks for persistence'
      |
      v  what would confirm / refute it?
  PIVOT       task-creation events by non-admin accounts
      |
      v  correlate with parent process, user, time
  JUDGE       competing explanation? -> confidence -> outcome

The hunt loop. The last step — actively seeking a benign explanation — is what separates a hunt from a guess.

Worked example — one turn of the loop

Hypothesis: 'an attacker is using scheduled tasks for persistence.' Before reading on, decide: what single result would confirm it, and what result would refute it?

The answer: it is confirmed by a task-creation event by a non-admin from a user-writable path; it is refuted if there are no such creations, or if every one maps to a known software deployment. Only after writing both do you query — and, crucially, before concluding, you look for the benign explanation. That final step is the whole difference between a hunt and a guess.

Recap

Hunting is proactive and hypothesis-driven, not a reaction to an alert.
The loop ends only because you decided in advance what would confirm and refute it.
A completed hunt that finds nothing is recorded assurance, not wasted time.