Building a Threat Hunting Hypothesis Library

A threat-hunting program lives or dies on its hypotheses. Without them, “hunting” is aimless log-staring that finds nothing repeatably and produces nothing durable. With a hypothesis library — a structured, growing set of testable statements about adversary behavior — hunting becomes a repeatable process that prioritizes by risk, reuses past work, and turns every confirmed hunt into a standing detection. This guide is how to build and run that library.

Threat hunting is the human-led, proactive complement to automated detection: it searches for the adversary behavior your rules miss, and its best output is a new rule. It is the discovery front end of the detection engineering workflow, prioritized through ATT&CK mapping.

What is a threat-hunting hypothesis?

A hypothesis is a precise claim you can test against your data: “an attacker is using scheduled tasks for persistence on our domain controllers,” not “let’s look for bad stuff.” A good hypothesis names the behavior, the data source that would reveal it, and what a positive or negative result looks like. That precision is what turns hunting from an open-ended activity into a bounded, repeatable one — and what lets you measure coverage.

The library is the accumulated set of these hypotheses, with their outcomes. Over time it becomes both a map of what you have hunted (and found, or ruled out) and a backlog of what to hunt next — the same compounding asset a detection library is.

Where do good hypotheses come from?

The strongest libraries blend all five — ATT&CK for systematic coverage, intel for currency, and your own history for relevance. Prioritize the resulting hypotheses by likelihood, impact, and whether you actually collect the data to test them.

How to structure a hypothesis (the template)

Record every hypothesis in the same fields so the library is consistent and searchable:

1. Hypothesis — the specific, testable statement.
2. ATT&CK technique — the mapped technique ID.
3. Data source — the logs needed, and whether they are collected.
4. Hunt logic — the query or analytic that tests it.
5. Expected findings — what a true positive looks like vs. benign.
6. Outcome — confirmed / not found / inconclusive, with notes.
7. Action — what the result produced (a detection, a collection gap, a hardening item).

The seventh field is the point: a hunt that confirms its hypothesis should produce a standing detection, not just a closed ticket.

How a hunt becomes a detection

Run the hunt, and if the behavior is real and detectable, promote it. A hunt for encoded PowerShell becomes a permanent rule:

title: Encoded PowerShell — Promoted From Hunt H-2026-014
id: 2c9f1d83-darkpwn-illustrative
status: test
logsource:
  category: process_creation
  product: windows
detection:
  selection:
    Image|endswith: '\powershell.exe'
    CommandLine|contains: [' -enc ', ' -EncodedCommand ']
  condition: selection
falsepositives:
  - Deployment scripts (allowlist by parent/path)
level: medium
tags:
  - attack.t1059.001

How to run the hunting loop

A simple, repeatable cadence (aligned to PEAK):

1. Prepare — pick a prioritized hypothesis; confirm the data is collected; write the hunt logic.
2. Execute — run the analytic, investigate hits, separate true positives from benign.
3. Act with knowledge — record the outcome, promote a detection if warranted, file any collection or hardening gaps, and update the library.
4. Iterate — feed gaps and new intel back into the hypothesis backlog.

Common threat-hunting mistakes

• No hypotheses. Unstructured log-staring finds nothing repeatably.
• Untestable hypotheses. Naming behavior you can’t observe stalls the hunt.
• No promotion to detection. Findings that don’t become rules must be re-hunted forever.
• No record. Without outcomes tracked, the library never compounds.

Threat hunting hypothesis library checklist

1. Generate hypotheses from ATT&CK, threat intel, and incident history.
2. Record each in the consistent 7-field template.
3. Confirm the data source is collected before hunting.
4. Prioritize by risk × impact × data feasibility.
5. Run the prepare-execute-act loop on each hunt.
6. Promote confirmed hypotheses into standing detections.
7. File collection and hardening gaps the hunt reveals.
8. Track outcomes so the library compounds over time.

The takeaway

A threat-hunting hypothesis library turns hunting into a repeatable, compounding process: testable ATT&CK-driven hypotheses in a consistent template, run through a prepare-execute- act loop, with every confirmed hunt promoted into a standing detection. Continue with the detection engineering workflow and MITRE ATT&CK mapping, or browse the full Detection Engineering pillar.