Threat Hunting: Working From a Hypothesis Instead of an Alert

Alert triage is reactive: a tool decides something is suspicious and a human investigates. Threat hunting is the opposite — a human forms a hypothesis about what an attacker might be doing, then goes looking for evidence, whether or not anything fired. It exists because detection coverage is always incomplete, and the gaps are exactly where a competent attacker lives.

Where hypotheses come from

A hunt without a hypothesis is browsing logs, which produces nothing reliably. Good hypotheses have three common sources.

Threat intelligence. A report describes a technique used against organizations like yours. The hypothesis writes itself: are we seeing this behaviour, and would we have detected it if we were? This is the operational level of intelligence doing its job, as described under the intelligence cycle.

Known detection gaps. Control validation shows which techniques produce no alert — the outcome of the testing under adversary emulation. Anything in the "telemetry present, no rule" category is a hunting target, because the data exists and nothing is watching it.

Environmental knowledge. Something you know about your own estate that an attacker would find attractive — a service account with excessive rights, a segment with weak monitoring, a legacy system everyone forgot. Hunt around it.

A usable hypothesis is specific enough to test. "Is there malware on the network" is not; "is any workstation making regular outbound connections to a newly registered domain" is.

Running a hunt

Define the hypothesis and the data. State what behaviour you are looking for and which sources would contain it. If the data does not exist, the hunt ends there — and that finding, a missing log source, is more valuable than most hunt results.

Query and reduce. Aggregate before inspecting. Counts by host, distinct destination counts, connection interval variance — the techniques under data analysis for security analysts. Hunting is mostly a data reduction exercise: turn millions of events into a few dozen worth looking at.

Investigate outliers. Most will be legitimate and unusual, which is itself useful — you are learning what normal looks like, and that knowledge is what makes the next hunt faster.

Act on the outcome. If you find something, it becomes an incident and follows the response process. If you do not, you still produce output.

Finding nothing is a result

The most commonly misunderstood point, and the one that determines whether a hunting programme survives its first quarter.

A hunt that finds no compromise produces three things worth having. A new detection, because if the query was good enough to hunt with, it is usually good enough to run continuously — converting hunts into rules is how the programme compounds. A documented gap, where the hunt could not be completed because a log source was missing or retention too short. And environmental knowledge, recorded so the next analyst does not re-investigate the same benign anomaly.

Measuring a hunting team by compromises found is the mistake. Measure detections created, gaps closed, and coverage added — the framing under security metrics, where activity counts mislead and capability measures do not.

What it requires

Data. Endpoint process and command-line telemetry, authentication events, network flow records, DNS queries and proxy logs, with enough retention to look backwards — ninety days is a reasonable floor, because indicators frequently surface weeks after the activity.

Tooling you can query freely. A search interface over that data, which is usually the SIEM, plus the ability to pull data out for analysis the console cannot do.

Time. This is the constraint that actually blocks most programmes. Hunting requires uninterrupted analyst time, and an analyst carrying the alert queue does not have any. Dedicated, protected time is the difference between a hunting programme and a hunting aspiration.

Skill. Hunters need to know attacker behaviour, the environment, and how to query data. The second is the hardest to hire and the easiest to develop internally.

Common failure modes

Hunting for indicators rather than behaviour — searching for known-bad hashes is a matching exercise a tool should already be doing, and it finds only what is already known. Hunt for techniques, which change far more slowly.

Not writing anything down, so the same benign anomaly is investigated every quarter. Not converting successful hunts into detections, so the work does not accumulate. And treating it as ad hoc — a hunt that happens when someone has a quiet afternoon is not a programme.

Exam angles

Define threat hunting as proactive, hypothesis-driven searching for threats that evaded existing detection, distinct from reactive alert triage. Know that hypotheses derive from threat intelligence, known detection gaps and environmental knowledge. Recognize that a hunt finding nothing still produces new detections, identified data gaps and environmental baselines, and that sufficient telemetry with adequate retention plus protected analyst time are the prerequisites.