Threat Hunting, Explained: Hypotheses, Telemetry and the Pyramid of Pain

TL;DR — Alerting asks “what did my rules catch?” Threat hunting asks “what would I see if an attacker were here, and can I prove they aren’t?” — a fundamentally different discipline: hypothesis-driven, assumption-challenging, and measured by coverage rather than volume. Its founding mental model, David Bianco’s Pyramid of Pain (2013), explains why hunting at the top of the indicator pyramid (tools, behaviors, TTPs) hurts adversaries in ways hash- and IP-blocking never will. This is the proactive complement to the detection-as-code workflow: detections industrialize what hunting discovers, and hunting finds what detections have been missing.

Every security program eventually confronts the same uncomfortable asymmetry: attackers only need to evade your detection once, while your rules must be right every time. Mature programs respond not by writing more rules in blind hope but by deliberately going looking for what slipped past — with hypotheses, telemetry and a tolerance for finding nothing. That discipline is threat hunting, and it’s the rare security function whose null results are valuable: a well-scoped hunt that comes back clean is a real (if temporary) statement about your environment.

The Pyramid of Pain: Why Hunting Beats Blocking

David Bianco’s Pyramid of Pain, introduced in a March 2013 blog post, ranks indicators by how much they cost the adversary when you act on them:

The insight that powers threat hunting sits in that gradient: everything below “artifacts” is cheap for attackers to change, so blocking there is a treadmill. Hunting flips the economics. When you search for behaviors — “any process that dumped credentials,” “any OAuth grant outside our baseline,” “any DNS tunneling pattern” — you’re operating where evasion costs the adversary real work, because behaviors are what their operations are made of. It’s the same shift we keep meeting on this site: from chasing artifacts (the certificate, the hash, the IP) to verifying the underlying behavior.

What a Hunt Actually Is

A hunt is a scoped investigation with four moving parts:

1. A hypothesis. One falsifiable sentence: “If an attacker obtained service credentials, we would see unusual authentication patterns from new source systems,” or “Living-off-the-land execution in our fleet would appear as signed binaries spawning unexpected children.”
2. A data plan. Which telemetry answers it — auth logs, process telemetry, flow data, cloud audit trails — and whether you actually collect it (the hunt’s first finding is often “we’re blind here”).
3. An analytics pass. Frequency analysis, baselining, stacking (group by rare field values), graph expansion from a seed — simple queries asking unusual questions, not exotic tooling.
4. A disposition. Every hunt ends in one of three documented outcomes: malicious (incident), benign-but-interesting (tuning data), or clean (coverage assertion with an expiry date). All three feed the detection backlog; none is wasted.

Contrast that with alert triage, which starts from a firing rule and works backward. Hunting starts from the attacker’s assumed position and works forward. Both consume the same telemetry; only one of them questions whether the telemetry answers questions you haven’t asked yet. In practice the handoff between them is where programs succeed or stall: an alert triage that closes tickets without ever asking “what rule would have caught this earlier, and does it exist?” produces no new hunting material, and a hunt team whose dispositions never reach the detection backlog produces reusable nothing. The disciplines share a spine — falsifiable questions over data — and the organizations that treat them as one continuous loop, rather than two departments, are the ones whose detection coverage actually compounds.

Hunting Is Not Penetration Testing

Because both practices “think like the attacker,” they get conflated constantly. They are opposites in posture. Penetration testing and red teaming inject an attacker into your environment from outside, under a defined scope and rules of engagement, and their product is a vulnerability list. Hunting assumes an attacker may already be inside — no injection, no scope in the offensive sense — and its product is knowledge about your telemetry and your blind spots. A pentest answers “could someone get in?”; a hunt answers “would we know if they had?” The labs culture we described in learning by breaking builds the first instinct; hunting operationalizes the second, and mature programs deliberately run both because each keeps the other honest: red team exercises that hunts never detect prove the hunts are theater, and hunts that regularly find what tests missed prove the tests are too narrow.

The Hunting Maturity Model

Bianco (later at Sqrrl, whose threat-hunting framework popularized the practice) also gave the field its maturity ladder, HM0 through HM4 — from “no hunting, purely reactive” through “occasional data-driven investigation” up to “process-driven, hypothesis-led hunting feeding automation and detection engineering.” The ladder matters because it makes the progression honest:

• HM0–HM1: you rely on alerts and intel feeds; “hunting” is ad-hoc searching after incidents.
• HM2–HM3: regular hunts over decent telemetry, increasingly guided by intel and ATT&CK technique hypotheses, producing new detections from findings.
• HM4: hunting is a scheduled program with a backlog, hypotheses tracked like research questions, and every hunt’s output measured — including the clean results, which become time-bound assertions (“no evidence of X in Y as of date”).

The climb is a telemetry story before it is a talent story. HM4 organizations aren’t staffed by wizards; they’re staffed by ordinary analysts whose kernel telemetry, time-aligned logs and normalized schemas make hypotheses cheap to test. Maturity is measured in how many interesting questions you can ask per week.

Running Hunts That Produce Detections

1. Mine three sources for hypotheses: threat intel relevant to your sector, your own incident history (what would have caught it earlier?), and ATT&CK techniques mapped against your telemetry gaps.
2. Time-box ruthlessly. A hunt is two to five sessions, not a career. If the data can’t answer the hypothesis, that’s the deliverable — file the telemetry gap, close the hunt, move on.
3. Stack and baseline before you exotic-query. The highest-yield hunts are embarrassingly simple: rare values of common fields, first-seen patterns, deviations from per-asset baselines.
4. Convert every finding. Malicious → incident plus a candidate detection. Benign → tuning rule so it never wastes another hunt. Clean → a dated coverage note and a re-hunt reminder. This conversion loop is what separates hunting from browsing logs — and it’s why hunting belongs upstream of the Sigma pipeline, not beside it.
5. Track hunt coverage like a portfolio. A simple matrix of techniques hunted × data sources used exposes your blind spots better than any dashboard of alerts fired.

Key Takeaways

• Threat hunting is hypothesis-driven, proactive investigation — the complement to alerting, measured by coverage and falsifiable clean results, not volume.
• The Pyramid of Pain (Bianco, 2013) explains the economics: blocking low-level indicators (hashes, IPs) is trivially evaded; hunting behaviors and TTPs forces expensive adversary change.
• A hunt has four parts — hypothesis, data plan, analytics, disposition — and always ends in a documented outcome that feeds the detection backlog.
• The Hunting Maturity Model (HM0–HM4) makes progression honest: maturity is mostly a telemetry and process story, not a hiring miracle.
• Hunt findings convert to detections; detection gaps convert to hunts. Running only one side of that loop is the most common program-design mistake.

FAQ

What is threat hunting?
The proactive, hypothesis-driven search for adversary activity that existing detections have missed — distinct from alert triage, which reactively investigates what rules already caught.

What is the Pyramid of Pain?
David Bianco’s 2013 model ranking indicators by attacker cost when blocked: hashes and IPs are trivial to rotate; tools and behaviors (TTPs) are expensive to change — so defensive effort at the top of the pyramid hurts more.

How is hunting different from monitoring?
Monitoring asks “what fired?” Hunting asks “what would we see if we were compromised, and can we disprove it?” — the former trusts your rules, the latter audits them.

What makes a good hunting hypothesis?
One falsifiable sentence tied to observable telemetry: a technique, an asset class, and the signal its execution would leave. “Look for bad stuff” is not a hypothesis.

Do clean hunts have value?
Yes — a scoped clean result is a dated coverage assertion, provided you document the scope, the data, and when the assertion should be re-tested. Undated clean results are just vibes.

How do we start with a small team?
One scheduled hunt per week over the telemetry you already trust, each ending in a documented disposition and at least one detection-backlog item. Consistency beats sophistication — the calendar habit matters more than the tooling, because hunting compound interest comes from the backlog of documented coverage assertions accumulating month over month.

References

1. David Bianco — The Pyramid of Pain (2013)
2. Wikipedia — Threat hunting (hypothesis-driven practice)
3. MITRE — ATT&CK (technique-driven hunt hypotheses)
4. threathunting.net — community resources and hunting loops
5. Elastic Security Labs — hunt research and telemetry techniques

Current as of September 2026. Educational reference — scope every hunt to environments you are authorized to investigate.

Published by Hmmnm

Hands-on cybersecurity tutorials, CVE breakdowns, and guided learning paths — written and lab-tested by the Hmmnm team.

Learning Paths · About Hmmnm · Editorial policy