Key takeaway: A hunt is an experiment. It states what an attacker would do, where the evidence would appear, and what result would disconfirm the idea — then produces either a finding or a new detection.
Why Unstructured Searching Fails
An analyst with spare time opens the log platform and starts looking around. Some queries return odd results, most look normal, and after three hours nothing conclusive has emerged.
The work was not wasted exactly, but it was not repeatable, it cannot be handed to someone else, and there is no way to know what was covered. Next month the same analyst may search the same places or entirely different ones, and neither outcome is measurable.
The absence of a hypothesis means there is no definition of success or failure, so there is no way to accumulate coverage over time.
The Structure That Works
A hunt has four parts written down before any query runs.
The claim. A specific statement about attacker behaviour in your environment. Not “look for lateral movement” but “an attacker with a foothold on a workstation would use WMI to execute a process on a server, appearing as a wmiprvse.exe child process on the target.”
The data. Which log source contains that evidence, and confirmation that it is actually collected. Hunts frequently end here, and that is a valuable result — discovering that the necessary telemetry does not exist is more useful than a failed search.
The query. The specific search, recorded so it can be rerun and adapted.
The disconfirming result. What output would mean the hypothesis is not supported. Without this, any result can be rationalised into suspicion.
Where Hypotheses Come From
| Source | Example claim |
|---|---|
| Technique framework | “Scheduled task persistence exists on servers” |
| Recent intelligence | “This actor’s archiving pattern appears before exfiltration” |
| Your own incidents | “The technique used in March is present again” |
| Environment knowledge | “Someone has direct database access outside the app tier” |
| Anomaly in normal work | “This service account authenticated from a new subnet” |
Prior incidents are the most productive source and the most neglected. Techniques used against you once are disproportionately likely to recur, and hunting for them is guaranteed relevant to your environment rather than to a generic threat landscape.
Environment knowledge produces hypotheses no external feed could suggest, because they depend on knowing what your systems should never do.
What a Hunt Should Produce
The most common outcome is no compromise found, and that is the expected result. A hunt that finds nothing still produces value if it produces an artefact.
Every hunt should end in one of three things: a confirmed finding that becomes an incident, a new detection rule so the question is answered automatically from now on, or a documented telemetry gap that becomes a logging improvement.
A hunt ending with none of those was not structured well enough. Converting the query into a scheduled detection is the highest-value output, because it means the hunt never needs repeating manually — the question is now answered continuously.
Making It Sustainable
Record every hunt with its hypothesis, data source, query and outcome. Over a year that record shows coverage across techniques and identifies where nobody has looked.
Allocate time deliberately rather than treating hunting as what happens when the alert queue is empty, because the queue is never empty. A fixed allocation produces a programme; spare capacity produces nothing.
The Bottom Line
Write the hypothesis, the data source and the disconfirming result before querying anything. End every hunt with a finding, a new detection or a documented telemetry gap, and keep a record so coverage accumulates rather than resetting each time.
