Hypothesis-Driven Hunting Design
What this domain tests
This domain tests whether you can turn adversary knowledge into a falsifiable hunt. A strong hypothesis names the behavior, environment, telemetry, expected observables, and success criteria before querying.
Core rules
- Use a testable form: If [behavior] occurs in [scope], then [data source] should show [observable], because [mechanism].
- Derive hypotheses from threat model gaps, ATT&CK coverage, incident lessons, and intelligence. Prioritize techniques with credible risk and available telemetry.
- Define population, time window, expected benign patterns, required fields, and pass or fail criteria. A hunt without a failure condition is only exploratory search.
- Hunt at procedure level where possible. Hunting for T1059 broadly is weaker than testing a specific PowerShell parent-child and command-line pattern.
- Distinguish a hunt from a production detection. A hunt tests and validates; a detection is repeatable and maintained.
Worked example
Hypothesis: If an adversary uses T1053.005 to persist through schtasks, then Windows Security 4688 and Task Scheduler operational 106 should show schtasks.exe /create with a task name outside the standard software-update baseline, especially when the parent is an Office process. Reasoning: the technique mechanism is task creation, so process creation plus task-scheduler events provide independent confirmation. Scope is domain-joined workstations over seven days. Success is an unexplained task creation with corroborating file or network activity. Failure after the defined scope is documented as no evidence, not as proof of absence.
Traps that cost marks
Treating a query as a hypothesis, omitting success criteria, ignoring benign base rates, and hunting only known IOCs. Another trap is unbounded scope that cannot be completed or evaluated.