The single least useful instruction you can give a hunter is "go look for evil." It sounds like guidance, and it isn't — because the search space is enormous, the time is finite, and the only way to know whether you've found nothing or whether you've missed something is to have been specific about what you were looking for in the first place. The IOC list does not save you here. IOC-driven hunting is search, not hunting. It tells you whether a known-bad signal is present in your environment; it cannot tell you whether a not-yet-known adversary technique is being used against you right now.
What follows is the loop I've been running, in some form, since eCTHPv2 first put a methodology around what until then had been instinct. It is not original. It is not glamorous. It is the version I can defend in an interview and run on a Tuesday afternoon.
The loop, in one paragraph
A hunt starts with a hypothesis — a claim about adversary behaviour in your environment that is specific enough to be wrong. You translate that hypothesis into a question against telemetry you actually have. You run the query, interpret the results, and end the hunt with one of three outcomes: a finding (something to investigate and/or remediate), a detection (you've discovered a repeatable signal worth productionising as a rule), or a documented dead end (you've ruled out the hypothesis at the current visibility level). Then you do the next one.
What makes a hypothesis worth chasing
Three properties. A good hunting hypothesis is specific, falsifiable, and grounded in your data.
Specific means it names a behaviour, not a category. "Lateral movement" is a category. "Service-creation events spawned from a parent process that wrote the service binary within the previous 60 seconds, on hosts that have not seen new service installations in 90 days" is specific. The first is unhuntable. The second is one query.
Falsifiable means you can imagine the result that would make you stop. "Look for suspicious PowerShell" can run forever because suspicious has no ceiling. "Look for encoded PowerShell parent-child chains on workstations outside the IT OU" has an end state: zero results, or some results that you triage.
Grounded in your data is the one hunters skip when they're new. You can have the world's best hypothesis about DNS tunnelling, but if you don't collect DNS query logs at sufficient resolution to see beaconing intervals, you don't have a hunt — you have a budget request. Acknowledge the gap, write it down as a visibility deficit, and pick a different hypothesis for this shift.
Hunts are the cheapest way to discover what your telemetry can't tell you. Treat every "I can't see that" as a deliverable, not a failure.
Where the hypotheses come from
In rough order of how often they fire, in my experience:
- ATT&CK technique gaps. Take your current detection coverage map. Pick a technique with telemetry but no rule. Hypothesise that it's happening, then go look.
- Threat intel reports about peers. A piece of public reporting about an adversary targeting your industry is a hypothesis generator. Read it once for the story, then read it again with a pen, pulling out behaviours rather than indicators.
- Anomaly reports from the SIEM itself. UEBA-style top-N reports — most uncommon parent-child process pairs this week, rarest signed-in countries per user, services started outside maintenance windows. Anomaly isn't badness, but it's hypothesis fuel.
- Recent incidents — yours or someone else's. Every IR engagement ends with a list of "we got lucky we noticed this." Each one is a hypothesis worth running against your other estate.
- Architecture changes you didn't initiate. New SaaS integrations, freshly federated tenants, new VPN concentrators. Each shifts the attack surface; each deserves a hunt.
The interview answer
Senior hiring panels keep asking the same question in different phrasings: walk me through a hunt you ran. The answer they're listening for has a particular shape, and it doesn't begin with the tool you used. It begins with the hypothesis. The structure I use:
- Trigger. What made me run this hunt now, rather than later. Threat report, audit gap, recent incident, scheduled coverage review.
- Hypothesis. Stated in one sentence, specific to a behaviour and a scope.
- Data sources. What telemetry was available, and what would have helped that wasn't.
- Query strategy. Broad-to-narrow, anchored on what should be rare in a healthy environment.
- Result. Findings, detections born from the hunt, or a documented null result with the visibility gap that closed the hunt early.
- What I'd do next. Always. A hunt that doesn't generate the next hunt is half a hunt.
That last point is the one interviewers care about most and candidates skip most often. Senior threat-hunting roles aren't looking for someone who can run a query; they're looking for someone who runs the loop. The loop is the job.
A worked example
Trigger: a public report on an adversary using PowerShell download-and-execute through legitimate cloud storage providers.
Hypothesis: PowerShell processes on user workstations making outbound network connections to consumer cloud storage domains, on hosts whose normal baseline includes no such traffic.
Data sources: MDE
DeviceProcessEvents for the PowerShell parent
chain; DeviceNetworkEvents for the outbound
connection; IdentityInfo to scope to the user
workstation OU rather than the engineering laptop pool that
legitimately moves files through cloud storage all day.
Query strategy: start with PowerShell processes that have
network egress to any of a small list of well-known consumer
storage domains, joined to host metadata to exclude the
engineering OU. Narrow to processes whose command line
contains Invoke-WebRequest, iwr,
Invoke-Expression, or iex. Look at
the time-of-day distribution; most of what survives this
far is administrative scripting and is heavily clustered in
the morning. Anything outside that cluster gets a closer
look.
Result, that particular Tuesday: no live finding, but a new rule for PowerShell-to-consumer-cloud-storage on workstations outside the engineering OU, with a one-hour reporting window and Medium severity. The hunt didn't find evil; it produced a detection that will catch it if it shows up next week. That is also a successful hunt.
What threat hunting is not
Three things, briefly, because each of them comes up in interviews:
- It is not IOC scanning. Looking for a list of known-bad domains against your DNS logs is a useful operational task. It is not a hunt.
- It is not alert triage. Working a queue of pre-existing alerts is investigation. Hunting starts before the alert exists.
- It is not exhaustive search. A hunt is scoped, time-boxed, and ends in a written outcome. "Looking around for an afternoon" is not a hunt; it's a hobby.
Closing
The reason this framing matters is operational, not philosophical. A team that hunts on hypothesis builds two things at once: a steady inflow of new detections, and a running map of where their telemetry isn't yet good enough. A team that hunts on IOCs builds neither. The first team gets better month over month. The second team holds steady, which in defensive security is the same thing as falling behind.
For the longer DFIR pieces — full case walk-throughs with artefacts and timelines — I publish on InsightLayer. For anything else, the email is on the resume page.