Building a threat hunt hypothesis

Building a Threat-Hunt Hypothesis

When to Use

• You are starting a proactive, hypothesis-driven hunt rather than responding to an alert.
• You need to turn a vague concern ("are we seeing living-off-the-land abuse?") into a testable, scoped statement with clear data requirements.
• You want a repeatable plan that produces either a detection, a gap, or a confident negative.

Do not use this as an incident-response trigger — if you already have a confirmed alert, pivot to investigation/IR, not hypothesis generation.

Prerequisites

• Knowledge of your environment's telemetry (EDR, Sysmon, proxy, DNS, auth logs) and retention.
• Familiarity with ATT&CK to anchor the behavior you intend to hunt.

Workflow

Step 1: Pick a behavior, not a tool

Anchor on an adversary behavior (an ATT&CK technique/sub-technique) you have reason to expect given your threat model, not a specific product alert.

Step 2: Write a testable hypothesis

Use the form: "If [actor behavior], then I expect to observe [evidence] in [data source]."

If an adversary uses WMI for lateral movement (T1047), then I expect to observe
wmiprvse.exe spawning command interpreters on hosts that do not normally do so,
in Sysmon process-creation (Event ID 1).

Step 3: Map to data and logic

Confirm the data source exists and is retained, then define the concrete query/detection logic and what "normal" looks like (baseline) so anomalies stand out.

python scripts/analyst.py plan --technique T1047 --datasource "Sysmon EID1" --window 14d

Step 4: Set scope and success criteria

Define the host/time scope, the threshold for "interesting," and the three possible outcomes: finding (→ IR), detection gap (→ engineering), or confident negative (documented).

Step 5: Record and hand off

Capture the hypothesis, queries, and outcome so it becomes a repeatable, version-controlled hunt — successful logic becomes a detection rule.

Validation

• The hypothesis is falsifiable and names a specific data source that actually exists.
• A baseline of "normal" is defined so results are interpretable.
• Each outcome has a defined next action (IR, detection engineering, or documented negative).

Pitfalls

• Hunting for a tool name instead of a behavior, missing variants.
• Writing a hypothesis you cannot test with available telemetry.
• No baseline, so every result looks suspicious (or nothing does).

References

• See references/api-reference.md for the hunt-plan generator.
• MITRE ATT&CK and the PEAK framework (linked in frontmatter).