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, so that each hunt makes the next one cheaper. That compounding is the entire argument for running the loop formally rather than investigating whatever seems interesting this week.

What PEAK actually prescribes

The loop above is PEAK’s outer shape, and the framework’s more useful contribution is that it names three distinct kinds of hunt, which need different inputs and produce different outputs. Running only the first is the most common way a hunting programme plateaus.

Hypothesis-driven hunting is bounded by what you already suspect. That is a strength — it is directed, testable, and finishes — and it is also its limit: you cannot hypothesise about a technique you have never heard of. Baseline hunting has no such ceiling, which is why the two belong in rotation rather than in competition.

ABLE: making a hypothesis testable

PEAK also gives a structure for framing a hypothesis so it can actually be run. ABLE — Actor, Behaviour, Location, Evidence:

• Actor — who, if you have intelligence pointing at a specific adversary. Optional, and frequently unknown, which is fine.
• Behaviour — the specific technique or action. This is the mandatory field.
• Location — where in your environment you would see it. Domain controllers, developer workstations, the payments segment. This bounds the search and it is what most informal hypotheses omit.
• Evidence — the data source and the specific fields that would demonstrate it.

Compare “an attacker is using WMI for lateral movement” with “an attacker is using WMI for lateral movement on our domain controllers and Tier 0 servers (Location), visible as WmiPrvSE.exe spawning a process, in Sysmon Event ID 1 with parent and command line (Evidence).” The first is a topic. The second is a query, a scope, and a definition of done, and you can hand it to someone else.

Location and Evidence are the fields that convert a hunting session into a bounded piece of work. Without them a hunt has no natural end, which is how a two-hour hunt becomes a fortnight of drifting.

The baseline hunt is the underused one

Most hunting programmes are entirely hypothesis-driven, and the baseline hunt is where the genuinely novel findings tend to come from.

The method inverts the question. Instead of “is technique X present,” you ask “what does this data set normally look like, and what does not fit?” Then investigate the outliers without a prior theory about what they should be.

Concrete baseline hunts worth running on a rotation:

• Rarest process-parent pairs across the fleet. Aggregate every parent-child process relationship, sort ascending by host count. Malicious execution is rare by definition; legitimate software is not.
• Rarest signer or unsigned binaries by prevalence. Executables present on one or two hosts.
• Destinations contacted by exactly one host, which is the detection that catches slow C2 the interval analytics miss.
• Accounts that authenticated to a system class they never touch before, such as a workstation account reaching a server segment.
• Scheduled tasks and services present on a single host — persistence is usually unique.

Every one of those is a frequency analysis with no hypothesis in it. They return a short list that a person reviews, and the review generates hypotheses for the directed hunts. That is the loop that keeps a library growing rather than cycling through the same ATT&CK techniques each quarter.

A hunt that finds nothing is ambiguous

This is the most important correctness point in hunting, and it is routinely skipped.

When a hunt returns no results, there are two possible explanations, and they are indistinguishable from the output alone:

1. The behaviour is genuinely absent from your environment.
2. Your query is wrong, or the data does not contain what you assumed it does.

Reporting “not found” without ruling out the second is how a hunting programme accumulates false assurance — the most dangerous product a security function can generate, because it closes questions that were never actually answered.

The fix is to generate the behaviour and confirm your hunt logic finds it, before trusting a negative result. Atomic Red Team provides safe, scoped tests for a large share of ATT&CK techniques; a purple-team exercise covers the rest. Run the technique in a controlled way, run your hunt query, and confirm it returns the activity you just created. Only then does a subsequent empty result mean something.

This has a second benefit: it validates the whole chain — collection, parsing, field mapping, retention, and query — rather than only the query. Most failures live in that chain rather than in the logic, and they are silent everywhere else.

Record negative results with their scope and confidence. “Not found” is close to useless. “Not found across 94% of Windows endpoints over 30 days of retained Sysmon EID 1, with the query validated against an Atomic test” is a finding somebody can rely on, act on, and revisit when the coverage number changes.

How do you measure a hunting programme honestly?

Hunting attracts bad metrics, because the obvious one is wrong.

“Threats found” is the wrong measure. Most hunts find nothing, and that is the expected outcome in a reasonably defended environment. A team measured on findings will eventually produce findings — by re-reporting known-benign anomalies, or by hunting only where something is likely to turn up, which is not where the risk is.

Measure the outputs a hunt reliably produces regardless of whether an adversary was present:

• Detections promoted. Hypotheses converted into standing rules. This is the compounding output and the best single number.
• Collection gaps identified. Each one is a concrete engineering ticket, and finding them is genuinely valuable work.
• Hardening items filed. Findings that are better fixed than detected.
• Hypotheses validated with a generated test, versus assumed. This is a quality measure, and it should trend towards all of them.
• Coverage of the hypothesis backlog against your threat-scoped ATT&CK subset.
• Time from a new advisory to an answer about whether that technique is present. This is the capability leadership actually wants when an incident is in the news, and it is the one that justifies the programme in a budget conversation.

The last one is worth building explicitly toward. “A relevant advisory was published this morning and we can tell you by this afternoon whether it applies to us” is a demonstrable capability, and it is what a well-maintained hypothesis library and validated collection make possible.

Timebox every hunt. Two to four hours for a directed hunt, one day for a baseline. A hunt that overruns is usually a hunt whose Location and Evidence fields were not specific enough, and the right response is to stop, tighten the hypothesis, and re-run it — not to keep going because it feels productive. Recording the timebox and whether it was met is how a library gets better at scoping over time.

If you are a one-person security function, compress rather than skip. Keep the hypothesis statement, the Evidence field, the validation step, and the recorded outcome; drop the review workflow, the ownership fields, and the formal reporting. One properly scoped, validated two-hour hunt per fortnight compounds substantially over a year, and it is achievable alongside everything else. Ad-hoc log-staring under time pressure does not compound at all.

Common threat-hunting mistakes

• No hypotheses. Unstructured log-staring finds nothing repeatably, and produces no record anyone can build on afterwards.
• 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.
• Running only hypothesis-driven hunts. You cannot hypothesise about a technique you have never heard of; baseline hunts are where the genuinely novel findings come from.
• Omitting Location and Evidence. A hypothesis without a scope and a data source has no natural end, which is how a two-hour hunt becomes a fortnight.
• Trusting a negative result without validating the query. “Not found” and “my query is broken” produce identical output. Generate the behaviour, confirm the query catches it, and only then does an empty result mean something.
• Recording “not found” without scope or confidence. Not found across what proportion of hosts, over what retention, with the query validated how?
• Measuring the programme by threats found. Most hunts find nothing, which is the expected outcome. Measure detections promoted, collection gaps found, and time from advisory to answer.
• Not timeboxing. An overrunning hunt is usually an under-scoped hypothesis, and the right move is to stop and tighten it rather than to keep going because it feels productive.
• Treating a collection gap as a failed hunt. Discovering that you cannot answer a question is a finding with a ticket attached, and frequently a more valuable one than a clean result.

Ten hypotheses to start the library with

A library needs a first page. These are broadly applicable, testable against telemetry most organisations already collect, and each has produced findings often enough to be worth the time.

1. A process is executing from a user-writable directory — temp, downloads, or a profile path — on a host where that has not happened before.
2. An account authenticated to a system class it has never touched, such as a workstation credential reaching a server segment.
3. A scheduled task or service exists on exactly one host in the fleet. Persistence is almost always unique; legitimate software is deployed.
4. A signed binary is running from a path its vendor does not use. Legitimate software has consistent install locations.
5. An outbound destination has been contacted by exactly one host, at any volume. This is the slow-C2 hunt that timing analytics cannot see.
6. A privileged account authenticated outside its established hours or from a new source.
7. A parent-child process pair exists that appears nowhere else in the estate. Frequency analysis over process ancestry is one of the highest-yield hunts available.
8. Security tooling stopped reporting on a host that is otherwise online. Absence of telemetry is a finding, and it is the one nothing else alerts on.
9. An archive was created in a temp or staging directory on a server that does not normally produce them — the exfiltration precursor.
10. A new local administrator or a new group membership appeared without a matching change record.

Each one is a frequency or absence question rather than a signature, which is why they generalise across environments. Run them, record the results with scope and confidence, and let the outliers generate the directed hunts. That is the library bootstrapping itself.

Note how many are about rarity and how few are about known-bad. That is the general shape of productive hunting: your detections already cover what you know is bad, so the hunt’s job is to surface what is merely unusual and let a person decide. A hunt that duplicates an existing rule is a validation exercise, which is useful and is not discovery.

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.
9. Validate every hunt query by generating the behaviour before trusting a negative result.
10. Record negative results with their scope, retention, and validation status.
11. Rotate baseline hunts alongside hypothesis-driven ones so the library keeps finding the unfamiliar rather than re-testing the known.
12. Timebox each hunt, and treat an overrun as a signal to tighten the hypothesis.
13. Report detections promoted, gaps filed, and time-from-advisory-to-answer — never threats found.

The single highest-value habit on this list is item 9. A hunting programme that cannot distinguish “absent” from “my query was wrong” produces reassurance rather than knowledge, and reassurance is the one output a security function should never manufacture by accident.

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, then operationalize findings with YARA rules for incident response, or browse the full Detection Engineering pillar.