Every intrusion has a quiet stretch. The attacker holds a foothold, the endpoint agent is writing logs, and nobody has asked those logs a question yet. Mandiant's M-Trends 2025 puts the global median dwell time at 11 days, and 57% of intrusions in 2024 were first reported by an outside party — the logs were already there, and nobody had asked them anything.
Threat hunting is the discipline of asking. This article is a field guide to doing it properly in an enterprise: writing hypotheses that can actually be tested, running them against your telemetry, converting findings into Sigma rules that compile to any SIEM, and measuring the program by outcomes instead of activity. The industry data says most programs are struggling — the 2026 SANS Threat Hunting Survey found the share of teams rating themselves "very mature" halved in a single year. The fix is not more tooling. It is methodology.
#Quick Answer: What is hypothesis-driven threat hunting?
Hypothesis-driven threat hunting is the proactive search for attacker activity based on a testable statement about how an adversary would behave in your specific environment — for example, "an attacker is using living-off-the-land binaries to move laterally between our build servers." The analyst collects relevant telemetry, tests the hypothesis against it, and converts the result into a reusable detection, typically a Sigma rule, whether or not malicious activity is found.
#Why Enterprise Hunt Programs Stall
The 2026 SANS Threat Hunting Survey, summarized by Intel471, is sobering reading. The top barriers were data quality or quantity (50.2%), skilled staff (45%), and budget constraints (42%). Teams report that hunting works in pockets but is not repeatable across teams, with outcomes depending heavily on which analyst runs the hunt. Maturity self-assessments clustered toward the middle, while the share rating themselves "very mature" — meaning hypothesis-based hunting — halved from 18.5% in 2025 to 9% in 2026.
Formal methodology is eroding too: only 37% of organizations reported using clearly defined threat hunting methodologies in 2026, down from 46% in 2025. SANS expected interest in AI-assisted hunting to rise; instead, intent to invest in AI for hunting fell from 48% to 39.2%, and the top planned improvement was simply adding more investigative staff. As SANS concluded, threat hunting remains stubbornly dependent on human judgment.
The pattern behind these numbers is one I see constantly: teams buy telemetry, stand up a SIEM, and then treat hunting as something senior analysts do when they have spare time. Spare time never arrives. A hunt program without a methodology, a schedule, and a definition of done is not a program — it is a hobby. The sections below build the program properly: hypothesis, data, analysis, conclusion, and operationalization.
#The Hunt Loop: From Hypothesis to Tested Detection
A mature hunt follows a loop, and frameworks like TaHiTI formalize it. The loop has five stages, and the discipline is in executing all five rather than stopping at three.
First, form the hypothesis. It should derive from threat intelligence, knowledge of your environment, or a gap in existing detections — never from a vague feeling. Second, identify the data sources that could confirm or refute it, and verify the telemetry actually exists before you start. Hunts die most often at this stage, when the analyst discovers the logs they assumed were collected were never onboarded. Third, collect and analyze: write the queries, establish a baseline of normal, and look for the specific behavior the hypothesis predicts. Fourth, reach a conclusion, which has four possible outcomes: the behavior is present and malicious, present and benign, absent, or untestable because the data does not exist. Fifth, operationalize: write the detection, file the coverage gap, or document the negative confirmation.
The fourth outcome deserves emphasis. A hunt that cannot be run because of missing telemetry is not a failed hunt — it is a telemetry requirement, and feeding those requirements back to the logging pipeline is one of the highest-value outputs a hunt program produces. Equally, a negative confirmation ("we tested for this technique across the estate and found nothing, with the telemetry to prove it") is a success, not a waste of time. It validates detection adequacy and narrows the attacker's remaining options.
#Writing Hypotheses That Can Be Tested
A testable hypothesis has four components: the actor or technique, the environment-specific condition, the expected observable, and the telemetry that would show it. Consider the difference. A weak hypothesis: "Attackers might be in our network." An untestable hypothesis: "A nation-state is targeting us." A testable hypothesis: "An intruder with access to our build servers is using living-off-the-land binaries such as certutil or bitsadmin to stage payloads, which would appear as anomalous child processes of those binaries in our EDR telemetry over the last 90 days."
Good hypotheses come from three sources. Threat intelligence gives you techniques attributed to actors targeting your sector — start with the MITRE ATT&CK technique, then localize it to your environment. Detection gaps give you hypotheses for free: every technique in your coverage matrix with no detection is a hypothesis waiting to be tested ("we have no detection for credential dumping on our jump hosts; if it happened, we would see it in these logs"). Environment knowledge gives you the most distinctive hunts: the legacy VPN concentrator, the OT bridge, the SaaS admin consoles nobody monitors. Attackers prize stealth, and the 2026 SANS survey notes adversaries are prizing stealth over speed — which means your hypotheses should target quiet techniques, not noisy ones.
Write the hypothesis down before you query. This is not bureaucracy; it is what makes the conclusion falsifiable. A hunt that starts with a query and ends with "found some weird stuff" cannot confirm or refute anything, and it cannot be repeated by the next analyst.
#Sigma Rules: Write Once, Hunt Everywhere
Findings should not live as one-off SIEM queries. They should become Sigma rules — the open, SIEM-agnostic detection format that lets you write a detection once and compile it to Splunk, Elastic, Microsoft Sentinel, QRadar, Chronicle, and dozens of other backends. The Sigma community had contributed over 15,000 rule entries and modifications to the main repository by mid-2025, making it the de facto standard for sharing detections, much as MITRE ATT&CK became the standard for sharing adversary behavior.
A Sigma rule is YAML describing what to match, not how a specific SIEM queries. The anatomy is straightforward: logsource scopes the rule to a platform, product, or category; detection holds named selections and a condition combining them with boolean logic; field modifiers like |contains, |startswith, and |re keep matching readable and portable; and tags map the rule to MITRE ATT&CK techniques for coverage reporting. The modern toolchain — pySigma and the Sigma CLI, rewritten in 2023 — compiles this YAML into backend-native queries, so detection engineers iterate once and deploy everywhere. That portability is decisive during SIEM migrations, multi-SIEM estates, and M&A integrations.
Two practices separate working Sigma programs from rule graveyards. First, normalize fields before or at compile time: if your endpoint logs say process.command_line but the SIEM stores CommandLine, solve it with field mappings rather than per-rule hacks. Second, run a base template and linting — title, id, status, logsource, detection, false positives, level — with pre-commit checks, and keep rules in a detection-as-code repository. Start with five to ten high-fidelity rules, compile them, push to the SIEM, and build a shadow pipeline that recompiles nightly and diffs against production to catch drift. When AI agents enter the SOC workflow, the same Sigma corpus becomes the ground truth they must not hallucinate past — detections as code, reviewed like code.
#From Hunt Findings to Production Detections
A hunt finding is raw material; a production detection is a product. The promotion path needs a gate, or the SIEM fills with noisy rules that analysts learn to ignore — which is how hunting's credibility dies.
The gate I use has four checks. First, validate against history: run the candidate rule over 30–90 days of telemetry and count the hits. If the true-positive-to-noise ratio is poor, tune the selection or narrow the scope before it ever alerts. Second, establish the false-positive baseline in writing: document what benign activity triggers the rule and how the triage analyst distinguishes it. Third, define the response: every production rule ships with a runbook entry — severity, first three investigation steps, and escalation criteria. Fourth, set a review date. Detections decay as environments change; a rule without an owner and a review cadence is a future false positive.
Not every hunt finding becomes an alert. Some become telemetry requirements (we need this log source). Some become hunt playbooks (run this quarterly). Some become threat intel (this technique is active in our sector). We keep our hunt notes and prior findings indexed with enterprise semantic search over pgvector so that each new hypothesis is checked against what we already tested — nothing kills analyst morale like re-running last quarter's hunt because nobody remembered it. And as AI-assisted analysis enters the hunt workflow, the OWASP Top 10 for LLM applications is worth a read before you let a model summarize raw telemetry.
#Measuring the Hunt Program Without Theater
Hunt metrics must reflect outcome value, not activity volume. Counting hunts per month rewards volume over quality; counting hours measures effort, not results; counting data queried encourages broad fishing over targeted hypothesis testing. These are the metrics of hunting theater.
The right metrics measure outcome distribution and downstream impact: confirmed negatives per period with the telemetry basis documented, coverage gaps identified and routed to remediation, detection improvements delivered to detection engineering, and escalations with positive findings. Practitioner guidance converges on a healthy distribution of roughly 40% negative confirmations, 30% coverage gaps, 20% detection improvements, and 10% presence confirmations. A program that only produces presence confirmations is not testing rigorously enough to generate negatives; a program that never identifies coverage gaps is not pushing its telemetry requirements hard enough.
Report these quarterly to leadership in plain language: what we hunted, what we proved absent, what gaps we found and closed, and which detections the hunts produced. That is the story that justifies the headcount — and the 43.5% of teams planning to add investigative staff will need exactly this story to get the budget.
#Frequently Asked Questions
What is the difference between threat hunting and detection engineering?
Threat hunting is the proactive, hypothesis-driven search for undetected attacker activity in your telemetry. Detection engineering is the discipline of building, testing, and maintaining the automated rules that fire alerts. Hunting feeds detection engineering: a successful hunt ends with a validated detection (often a Sigma rule) promoted into production monitoring, plus documented coverage gaps and negative confirmations.
How do Sigma rules work with different SIEMs?
Sigma rules are written once in an open YAML format that describes what to match, independent of any SIEM's query language. The pySigma toolchain and Sigma CLI compile that YAML into backend-native queries — Splunk SPL, Elastic Lucene, Sentinel KQL, and many others. You maintain one detection-as-code repository and deploy compiled rules to each platform, with field mappings handling schema differences at compile time.
How often should an enterprise run threat hunts?
A sustainable cadence is one to two focused hunts per analyst per month, each scoped to a single hypothesis and time-boxed to a few days. More important than frequency is the loop: every hunt must end with a documented conclusion and an operational output (detection, gap, or negative confirmation). Quarterly, review outcome distribution — roughly 40% negatives, 30% gaps, 20% detection improvements, 10% positives — to check the program is testing rigorously.
What skills does a threat hunter need?
The core skills are adversary tradecraft (MITRE ATT&CK fluency), log analysis across endpoint, network, identity, and cloud telemetry, and query languages for your SIEM. Increasingly valuable: detection-as-code practices (Sigma, version control, testing) and enough statistics to distinguish signal from noise when baselining. The 2026 SANS survey found skilled staff the second-biggest barrier at 45%, so structured hypotheses and reusable Sigma rules matter — they let junior analysts execute senior-quality hunts.
#Sources and Further Reading
- 2026 SANS Threat Hunting Survey — Intel471 — maturity, barriers, methodology adoption, and AI trends.
- What Threat Hunting Actually Controls — SC World — hunt program metrics and the outcome-distribution model.
- Sigma: A Universal Detection Rule Language — Zenodo — Sigma format history, pySigma toolchain, and community growth past 15,000 contributions.
- Mandiant M-Trends 2025 — global median dwell time of 11 days and 57% of 2024 intrusions reported by outside parties.