The Hypothesis as Unit of Work — What Makes a Hunt Hypothesis Testable

A hunt is only as good as its hypothesis. The best hunt tools, the most complete telemetry, and the most experienced analyst produce noise if the hypothesis is vague, non-testable, or targeting something you cannot measure. The hypothesis is the unit of work — treat it with the same rigor as production code.

The Five-Property Hypothesis Test

Before running a single query, evaluate the hypothesis against all five criteria:

Hypothesis: "There might be malware in our environment from recent nation-state activity"

Specific?        NO — no named TTP, no actor, no behavioral target
Testable?        NO — 'malware' could be anything
Falsifiable?     NO — no result can prove there ISN'T malware
Time-bounded?    NO — no data window specified
Data-supported?  N/A — can't evaluate without specificity

Result: Anti-pattern. Don't hunt this. Refine it.

Hypothesis: "APT29 has been observed targeting organizations in our sector using 
             OAuth phishing (T1528). We hypothesize that an adversary has stolen 
             OAuth tokens from M365 users in our environment between 2024-07-01 
             and 2024-09-01, which would appear as MailItemsAccessed events from 
             unusual locations in the Unified Audit Log."

Specific?        YES — named TTP (OAuth token theft), named data source (UAL)
Testable?        YES — query UAL for MailItemsAccessed from unusual geolocations
Falsifiable?     YES — if no such UAL events exist, hypothesis is refuted for this window
Time-bounded?    YES — 2024-07-01 to 2024-09-01
Data-supported?  YES (if UAL is enabled and retained for 90 days — validate first)

Result: Valid hunt hypothesis. Proceed to data validation.

Hypothesis Types

Type	Description	Example
TTP-based	Targets a specific adversary behavior	”Living-off-the-land via certutil download”
Actor-based	Driven by known adversary profile	”APT41 using ProxyLogon against OWA”
Baseline deviation	Statistical outlier from normal	”Host with 10× normal outbound connections”
Data source anomaly	Gap or inconsistency in telemetry	”Host in scope with no Sysmon data”
Threat intelligence-driven	CTI report → specific TTP query	”Post-T1566.002 BOT reports → hunt for related T1059”

The F3EAD Hunt Loop

                        ┌──────────────────┐
                        │   CTI REPORT     │
                        │ (APT29 campaign) │
                        └────────┬─────────┘
                                 │ FIND: what TTP is relevant to us?
                                 ▼
                        ┌──────────────────┐
                        │   HYPOTHESIS     │
                        │ (T1528, 90 days) │
                        └────────┬─────────┘
                                 │ FIX: what data shows this TTP?
                                 ▼
                        ┌──────────────────┐
                        │   HUNT (QUERY)   │
                        │ UAL MailItemsAcc │
                        └────────┬─────────┘
                                 │ FINISH: confirm or refute
                                 ▼
                    ┌────────────┴──────────────┐
                    │                           │
              TP FOUND                    NULL RESULT
                    │                           │
                    ▼                           ▼
             EXPLOIT + ANALYZE           DOCUMENT COVERAGE
             (IOCs, ATT&CK chain)       (this TTP, this window = clean)
                    │                           │
                    └───────────┬───────────────┘
                                │ DISSEMINATE
                                ▼
                       CTI deliverable or
                       detection rule + null journal
                                │
                                │ Next hypothesis generated
                                ▼
                       (loop back to FIND)

Hypothesis Quality vs. Hunt Outcome

A well-formed hypothesis that produces a null result is a success. A poorly-formed hypothesis that produces results is a trap.

Hypothesis A (poor): "Check if anything bad is happening in our logs"
→ Hunt produces 10,000 results → analyst can't process → no action
→ Hunt produces 0 results → analyst concludes "we're clean" (overconfident)
→ No detection rule possible → no journal entry meaningful
→ Both outcomes are useless

Hypothesis B (high quality): "An adversary using ProxyLogon (CVE-2021-26855) 
would generate IIS log entries with specific HTTP error codes (400, 500) 
against the /ecp/default.flt endpoint from external IPs, appearing in 
IIS access logs from our Exchange servers between 2024-01-01 and 2024-03-31."
→ Hunt produces 0 results → meaningful: Exchange not targeted via ProxyLogon 
   in this window, given this telemetry coverage
→ Hunt produces 3 results → investigate each, confidence in finding is high
   because hypothesis was specific
→ Detection rule: directly derivable from hypothesis criteria

Retrieval Practice

A threat hunter proposes the hypothesis: 'APT actors may be using our network.' Identify all five quality failures and rewrite it as a valid hypothesis.

Reveal answer

Quality failures: (1) Not specific — no named TTP, no named actor, no behavioral pattern. (2) Not testable — 'APT actors' could use any of hundreds of techniques. (3) Not falsifiable — no result can prove APT actors are NOT using our network. (4) Not time-bounded — no data window. (5) Not data-supported — no telemetry source identified. Rewrite: 'APT41 has been observed using web shells installed via CVE-2024-XXXX on internet-facing application servers. We hypothesize that if our web server was exploited via this CVE, we would find unusual POST requests to /uploads/ or /admin/shell.php in IIS access logs, or new file creation events in the web root via Sysmon Event 11, between 2024-06-01 and 2024-09-01.' This version is specific (APT41, CVE, web shell), testable (IIS logs, Sysmon Event 11), falsifiable (no matching log entries = refuted), time-bounded (3-month window), and data-supported (IIS logs + Sysmon = available).

Retrieval Practice

What is the 'hunt debt' problem and how do hunt journals prevent it?

Reveal answer

Hunt debt: the accumulation of untracked, undocumented hunt work that causes repeated effort — the same hypothesis is hunted multiple times because no one recorded the first run, or a null result is interpreted as confirmation of safety when the data coverage was actually inadequate. Hunt journals prevent this by making every hunt run a permanent record: the hypothesis, the data source and time window, the queries, the findings (including nulls), and the coverage limitations. A journal entry that says 'hunted T1528 against UAL, 2024-Q3, HQ tenant only, null result, branch office UAL not enabled' tells the next analyst exactly what was covered and what wasn't — preventing both repeat work and false confidence from the null result. Hunt debt is most dangerous after team turnover: the new analyst re-runs hunts already done, or (worse) stops running hunts already done because 'we checked this.' The journal is the institutional memory.