Threat hunting is what you do once you accept that your alerts are incomplete. Not broken, incomplete: an EDR fires on the behavior somebody already described in a rule, and an attacker who stays outside those descriptions remains invisible for as long as nobody goes looking. A hunt is that deliberate look, driven by a question rather than a queue. This guide covers the process, the techniques that actually surface something, and one full hunt with the queries written out. HackerDNA's proactive threat hunting chapter runs the same workflow against log data in a browser tab, no SIEM license involved.
The gap is measurable. In the SANS 2025 Threat Hunting Survey, 76% of respondents reported living-off-the-land techniques in nation-state intrusions, and 49% saw them in ransomware cases, up from 42% the year before. Living off the land means the intruder used PowerShell, WMI and scheduled tasks: the same binaries your administrators touch every day, which is precisely the traffic that signature-based detection handles worst.
TL;DR: Threat hunting is a proactive search through security telemetry for attacker activity that automated detection missed. You start with a hypothesis about how an intrusion would look in your logs, query for it, and triage what survives. Most hunts find nothing malicious, and that is fine: a hunt that produces a new detection rule or exposes a blind spot in your logging has paid for itself.
What Is Threat Hunting?
Threat hunting is the practice of proactively searching security data for attacker activity that automated detection missed. Rather than waiting for an alert, the hunter forms a hypothesis about how a specific intrusion would appear in the available telemetry, queries for that pattern, and then either confirms it, rules it out, or discovers that the data needed to answer the question was never collected.
That third outcome is the one nobody advertises, and it is the most common result on a young hunting program. You hypothesize that an attacker created a scheduled task for persistence, go looking for scheduled task creation events, and find that the audit policy pushing them was never enabled outside the domain controllers. You did not catch an intruder. You did find that 4,000 workstations are dark for one of the most heavily used persistence techniques in the wild, which is worth more than another closed alert.
Three things separate hunting from monitoring. Hunting is human-led, so the query comes from an analyst's reasoning instead of a rule engine. It is hypothesis-driven, meaning you decide what you are looking for before you look. And it assumes compromise: the working premise is that something is already inside and your job is to prove or disprove it, not to wait for confirmation.
A hunt has exactly three honest endings. You find malicious activity and hand it to incident response. You find nothing and convert the query into a scheduled detection so the same ground is covered automatically next time. Or you find you cannot answer the question, and the deliverable is a logging gap with a ticket attached.
Threat Hunting vs Incident Response vs Threat Intelligence
These three get used interchangeably in job postings, and they are genuinely different activities that happen to share a data set.
| Threat hunting | Incident response | Threat intelligence | |
|---|---|---|---|
| What starts it | A hypothesis you chose | A confirmed or suspected incident | A collection requirement |
| Assumption | Something may be here, unproven | Something is here, proven | Someone out there targets organizations like ours |
| Main output | Detections, visibility gaps, occasionally a lead | Containment, eradication, recovery | Reporting on actors, tooling and behavior |
| Clock pressure | None, it is scheduled work | Severe, measured in minutes | Moderate, tied to reporting cycles |
They feed each other in a loop. Intelligence tells you which techniques a relevant actor favors, which becomes your hunting hypothesis. The hunt occasionally finds something real, which becomes an incident. The incident produces artifacts that go back into intelligence. If your organization has no intelligence function, the free MITRE ATT&CK knowledge base substitutes well enough to get started, and mapping an intrusion's phases onto the cyber kill chain helps you decide which stage you have the least coverage on.
The Five Steps of a Threat Hunt
What are the steps of a threat hunt? Choose a hypothesis, decide which telemetry would prove or disprove it, query and reduce the results to a reviewable set, triage what survives, and turn the outcome into something permanent such as a detection rule or a logging change.
- Pick a hypothesis narrow enough to fail. "Is there malware on the network" is not a hypothesis, it is anxiety. "An attacker has established persistence on our Windows fleet using scheduled tasks that run from a user-writable directory" is testable, and you know in advance what the answer looks like.
- Decide what data would answer it, before you query anything. Write down the event sources and fields you need. This is where most hunts die quietly, and finding that out on paper in five minutes beats finding it out after two hours of query tuning.
- Query, then reduce. The first query always returns too much. Reduction is the actual skill: filter known-good by signing certificate and parent process rather than by file name, aggregate instead of listing, and get to a set small enough that a human can look at every row.
- Triage the survivors. Pivot on each remaining item: what process created it, what did that process do next, which account, which host, is the same thing present elsewhere. Most rows will resolve to an unusual but legitimate admin script, and each one you clear should be written down so the next hunt does not re-examine it.
- Make the result permanent. Convert the query into a scheduled detection, file the visibility gap, and document what "normal" turned out to look like. A hunt you cannot repeat is a hobby.
Step five is where hunting programs succeed or stall. A team that hunts weekly and automates nothing runs the same five queries forever and slowly stops finding anything, because the ground they cover never expands.
Threat Hunting Techniques That Actually Find Things
Four techniques cover almost everything a working hunter does. They are not equally useful, and the one most beginners start with is the weakest.
Stack counting, the workhorse
Also called frequency analysis or long tail analysis. You take a field, count how often each distinct value appears across the environment, and sort ascending. Malicious activity is rare by definition, so it collects at the bottom of that list. Run it against process command lines, scheduled task actions, service binary paths, parent-child process pairs, or user agent strings.
The reason it works so well is that it needs no prior knowledge of the threat. You are not asking "is this bad", you are asking "is this unusual here", which is a question your data can answer on its own. In practice this is where roughly half of all genuine hunt findings come from.
Baselining and outlier detection
Build a picture of normal for a specific behavior, then look for deviation from it. Which accounts normally authenticate to the finance file server, and which one did so for the first time last Tuesday at 03:00. How much DNS traffic does a typical workstation generate per hour, and which host is producing eight times that with unusually long subdomain labels. That second example is textbook DNS exfiltration, and the DNS Tunneling Detective lab gives you a capture to practice it on.
Searching for known indicators
Take hashes, IP addresses and domains from an intelligence report and sweep your historical data for them. This is the easiest technique and the least valuable one, because of what David Bianco called the Pyramid of Pain: hashes and IP addresses sit at the bottom, and an attacker changes them trivially. Behaviors and TTPs sit at the top and are expensive to change. An indicator sweep tells you whether you were hit by that exact campaign, on that exact infrastructure, which is a narrower question than it first appears.
Run indicator sweeps because they are cheap, but do not build a program on them. If the only thing your hunt team does is paste IOCs into a search bar, you have automated intelligence consumption, not hunting.
Model-assisted hunting
Use a statistical or machine learning model to surface candidates a human then reviews: clustering similar command lines, scoring domain names for randomness, flagging rare parent-child process combinations. The SANS 2025 survey was blunt that the effect of AI-based techniques on actually uncovering threat actors remains limited so far. Treat these models as a way to sort a haystack, not as a detection.
A Real Hunt, Start to Finish
Here is one hunt written out completely, so the abstractions above have something to attach to.
The hypothesis
An adversary with code execution on a workstation has created a scheduled task for persistence, executing a payload from a user-writable path. In ATT&CK terms that is T1053.005, Scheduled Task, which maps to the Execution, Persistence and Privilege Escalation tactics. It is a good starting hypothesis because it is extremely common, and because legitimate scheduled tasks are stable enough that the anomalies stand out.
The data
Two sources answer this. Windows Security event 4698 records scheduled task creation, and Sysmon event ID 1 records process creation, which catches schtasks.exe being invoked. Check both, because tasks registered through the COM interface or PowerShell's Register-ScheduledTask never touch schtasks.exe and would be invisible if you only looked at process creation.
One prerequisite that catches everyone: raw Windows 4688 events do not include the process command line unless you enable ProcessCreationIncludeCmdLine_Enabled through Group Policy. Without it, every command-line hunt in your environment silently returns nothing useful. Verify this before the hunt, not during it.
The queries
Stack counting on task creation, in Microsoft Defender XDR advanced hunting (KQL):
DeviceProcessEvents
| where Timestamp > ago(30d)
| where FileName =~ "schtasks.exe"
| where ProcessCommandLine has "/create"
| summarize Hosts = dcount(DeviceName), Runs = count()
by ProcessCommandLine
| order by Runs ascThe same idea in Splunk, against Sysmon data:
index=sysmon EventCode=1 Image="*\\schtasks.exe"
| search CommandLine="*/create*"
| stats count AS runs, dc(ComputerName) AS hosts,
values(ParentImage) AS parents BY CommandLine
| sort runs ascRead from the top of the output, where the rarest command lines are. A command line that appears once, on one host, is not proof of anything, but it is where you spend your attention.
The triage
Four questions decide whether a row is worth escalating. What is the parent process: a task created by cmd.exe whose grandparent is winword.exe is a different story from one created by your configuration management agent. Where does the task's binary live: C:\Windows\System32 is unremarkable, C:\Users\Public and %APPDATA% are not. Which account created it, and does that account normally administer that host. And when: task creation at 03:14 on a machine whose user badges in at 09:00 is worth a phone call.
Expect false positives, and expect them to be interesting. Software deployment tools, backup agents and installers all create odd-looking scheduled tasks. Every one you clear should end up in a documented allowlist, because the value of a hunt compounds only if the next run starts where this one stopped.
The output
Suppose you found nothing malicious. You still ship three things: a scheduled detection that fires on scheduled task creation where the action path sits under a user-writable directory, a written baseline of the twelve task command lines that are normal in your estate, and a ticket for the four subnets where 4698 events never arrived. Run the same hunt next quarter and it takes twenty minutes instead of a day.
Threat Hunting Frameworks and the Maturity Model
Two pieces of published thinking are worth your time. The rest of the framework literature is vendor positioning.
PEAK
Developed by Splunk's SURGe research team, PEAK stands for Prepare, Execute, and Act with Knowledge. Prepare is topic selection, research and planning. Execute is the data work. Act is documentation, automation and communication, and knowledge flows through all three: you use it before the hunt, generate more during it, and act on it afterwards.
PEAK's more useful contribution is naming three hunt types explicitly. Hypothesis-driven hunts test a specific claim. Baseline hunts characterize what normal looks like in an area you have never examined. Model-assisted hunts use algorithms to generate candidates. Teams that only run the first type end up hunting the same handful of well-documented techniques repeatedly, because those are the only ones they can phrase a hypothesis about.
The Hunting Maturity Model
David Bianco's Hunting Maturity Model grades a program on five levels:
- HMM0, Initial: the organization relies on automated alerting. Analysts resolve alerts. No hunting happens.
- HMM1, Minimal: telemetry is centrally collected and analysts can search history for indicators pulled from reports. This is the first level where hunting exists at all.
- HMM2, Procedural: the team routinely runs hunt procedures published by others, with minor modifications.
- HMM3, Innovative: the team creates its own procedures rather than borrowing them.
- HMM4, Leading: every successful hunt gets operationalized into automated detection, which frees analysts to develop new techniques.
Be honest about where you sit. A great many teams that describe themselves as HMM3 are running borrowed queries on a schedule, which is HMM2, and the jump from HMM1 to HMM2 is worth far more than the label. The distinction that matters at HMM4 is automation: if successful hunts are not becoming detections, the team is doing manual labor that scales linearly with headcount.
Threat Hunting Tools Worth Your Time
You do not need a threat hunting platform. You need query access to telemetry that is actually good, which is a data problem wearing a tooling costume. Fix collection first, then worry about the interface.
- Sysmon for Windows endpoint telemetry. Free, and it produces the process creation, network connection and DNS query events that most of the hunts in this article depend on. Start from a maintained configuration such as Olaf Hartong's modular config rather than writing your own, or you will collect either nothing or everything.
- Velociraptor for hunting across endpoints at scale. Its VQL query language lets you ask a question of thousands of machines at once and get answers back in minutes, which is the closest thing to a superpower on this list.
- Sigma for writing detection logic once and converting it to your SIEM's query syntax. Pair it with Hayabusa or Chainsaw to run Sigma rules directly against Windows event log files during an investigation.
- Zeek for network telemetry. It turns traffic into structured connection, DNS, HTTP and TLS logs, which is far more hunt-friendly than full packet capture you have no time to open. Wireshark still earns its place for the last mile, once a Zeek log has told you which single connection is worth opening.
One opinion worth stating plainly: skip the commercial "threat hunting platform" category until you have run hunts manually for six months. Those products assume you already know which questions to ask, and buying one before you do leaves you with an expensive dashboard nobody opens.
For technique reference, ATT&CK is the map everyone shares. The v19 release on 28 April 2026 brought Enterprise to 15 tactics, 222 techniques and 475 sub-techniques, and split the old Defense Evasion tactic into Stealth and Defense Impairment. If you built hunt coverage tracking against the previous tactic list, that split is worth an afternoon of remapping: rundll32.exe abuse, for instance, now sits under Stealth as T1218.011.
How to Become a Threat Hunter
How do you become a threat hunter? Most hunters come from SOC analysis, incident response or systems administration rather than straight from education. The hiring bar is the ability to reason about how an operating system behaves normally, plus enough query fluency to test that reasoning against real data.
Four capabilities carry the role, roughly in order of how often they are the limiting factor:
- Operating system internals. You cannot spot an abnormal parent-child process relationship without knowing what the normal one is. Windows process ancestry, service and scheduled task mechanics, and the Linux equivalents matter more than any tool.
- Query languages. KQL, SPL or Elasticsearch's query syntax, whichever your employer runs. Aggregation is the part to master, not filtering.
- Attacker technique knowledge. Enough offensive familiarity to predict what an intruder would try next. Hunters who have escalated privileges on a box by hand write noticeably better hypotheses than those who have only read about it.
- Writing. Hunts that go undocumented cannot be repeated, and a hunt report is the artifact management sees. This is the skill most technically strong candidates neglect.
The staffing situation is in your favor. 61% of organizations in the SANS 2025 survey named skilled staffing shortages as the primary barrier to their hunting programs, while the share fully outsourcing hunting fell from 37% to 30% as more teams built the capability in house. If you are mapping out the route into a defensive role, our SOC analyst career guide covers the entry path that most hunters take first.
Frequently Asked Questions
Is threat hunting the same as penetration testing?
No. A penetration test simulates an attacker to find exploitable weaknesses before a real one does. Threat hunting searches your own telemetry for evidence that an attacker is already present. One is offensive and forward-looking, the other is defensive and retrospective. They complement each other well, and a red team exercise makes an excellent hunt trigger, since you know activity exists and can measure whether your hunts find it.
How often should you run threat hunts?
Cadence matters less than consistency. A common working pattern is one scheduled hunt per week with a defined hypothesis and a written outcome, plus ad hoc hunts triggered by intelligence reports about relevant actors. Small teams often start monthly. What breaks programs is treating hunting as spare-time work, since it is always the first thing dropped when alert volume rises.
Do you need a SIEM to start threat hunting?
You need centralized, searchable telemetry, which a SIEM provides but is not the only way to get. Teams hunt effectively with Elastic, with an EDR's own query interface such as Defender advanced hunting, and with Velociraptor querying endpoints directly. Sysmon logs collected into any searchable store are enough to begin. Data quality beats tooling every time.
What counts as a successful hunt if you find nothing?
Finding no adversary is the expected result of most hunts. A hunt succeeds if it produces one of three durable outputs: a new automated detection, a documented baseline of normal behavior for the area examined, or an identified gap in logging coverage. A hunt that produces none of those three failed, whether or not it found an intruder.
Legal and Ethical Considerations
Critical reminder: hunt only within systems your organization owns or has written authorization to examine, and confirm the scope in writing before you query. Threat hunting is defensive work, but it involves reading detailed records of what identifiable employees did on company systems, which is regulated activity in most jurisdictions.
Two specifics matter more here than in offensive security. Under the GDPR and comparable privacy regimes, endpoint and authentication telemetry is personal data, so hunting programs need a documented lawful basis, a retention period, and access controls proportionate to how revealing that data is. Involve your privacy or legal team when you design collection rather than after a hunt surfaces something awkward about a named employee.
The second is evidence handling. The moment a hunt turns up genuine attacker activity, it stops being a hunt and becomes an incident, and your next action can destroy evidence. Do not log into the suspect host to look around, do not delete the scheduled task you found, and do not tip off an active intruder. Hand it to incident response with your query, your results and your timestamps, and let the process that is designed to preserve evidence take over.
Your Next Steps in Threat Hunting
Threat hunting rewards curiosity about normal far more than knowledge of exotic attacks. The hunters who consistently find things are the ones who know what their environment does on an average Tuesday, because that is the only baseline that lets an anomaly announce itself.
Start with one hypothesis this week rather than a program next quarter. Pick a technique you believe is likely against your organization, write down which log source would show it, and run a stack count on the relevant field. You will probably discover a data gap on the first attempt, and that is a genuine finding, not a wasted afternoon.
For hands-on repetitions, the SOC analyst and blue team course works through log sources and SIEM design, query languages, Windows telemetry, Sigma detection engineering and a full chapter on proactive hunting. It runs in the browser with no lab environment to build, and the free tier needs no credit card.
