Building Threat Hunt Hypothesis Framework
When to Use
- When proactively hunting for indicators of building threat hunt hypothesis framework in the environment
- After threat intelligence indicates active campaigns using these techniques
- During incident response to scope compromise related to these techniques
- When EDR or SIEM alerts trigger on related indicators
- During periodic security assessments and purple team exercises
Common Misconfigurations & Verification
- Unfalsifiable hypotheses. "Find evil" or "detect APTs" can't be tested. Scope every hypothesis to a specific ATT&CK technique + a named data source + an observable (e.g., "T1059.001: Empire stagers appear as 4104 events containing
FromBase64String+WebClient"). - Assuming coverage that doesn't exist. Hunting T1059.001 with Script Block Logging (4104) disabled, or relying on Sysmon EID 1/3 that was never deployed, yields false negatives that look like clean results. Verify ingestion first with
| tstats count where index=* by sourcetypeand check each source's last-seen timestamp. - No baseline. Without a frequency baseline every result looks anomalous. Build the normal-activity baseline before judging outliers.
- Timezone/clock skew across DCs breaks multi-source correlation — normalize everything to UTC and confirm event time vs index time gaps.
- Verify the hunt can actually catch the thing: emit a benign atomic test matching the hypothesis (e.g., request a Kerberos SPN ticket, or run an
-enccommand) and confirm the query returns your test event end-to-end. - Document negatives correctly: record what coverage existed at hunt time — absence of evidence is only meaningful where logging was confirmed present.
Prerequisites
- EDR platform with process and network telemetry (CrowdStrike, MDE, SentinelOne)
- SIEM with relevant log data ingested (Splunk, Elastic, Sentinel)
- Sysmon deployed with comprehensive configuration
- Windows Security Event Log forwarding enabled
- Threat intelligence feeds for IOC correlation
Workflow
- Formulate Hypothesis: Define a testable hypothesis based on threat intelligence or ATT&CK gap analysis.
- Identify Data Sources: Determine which logs and telemetry are needed to validate or refute the hypothesis.
- Execute Queries: Run detection queries against SIEM and EDR platforms to collect relevant events.
- Analyze Results: Examine query results for anomalies, correlating across multiple data sources.
- Validate Findings: Distinguish true positives from false positives through contextual analysis.
- Correlate Activity: Link findings to broader attack chains and threat actor TTPs.
- Document and Report: Record findings, update detection rules, and recommend response actions.
Key Concepts
| Concept | Description |
|---|---|
| TA0001 | Initial Access |
| TA0003 | Persistence |
| TA0008 | Lateral Movement |
| TA0010 | Exfiltration |
Tools & Systems
| Tool | Purpose |
|---|---|
| CrowdStrike Falcon | EDR telemetry and threat detection |
| Microsoft Defender for Endpoint | Advanced hunting with KQL |
| Splunk Enterprise | SIEM log analysis with SPL queries |
| Elastic Security | Detection rules and investigation timeline |
| Sysmon | Detailed Windows event monitoring |
| Velociraptor | Endpoint artifact collection and hunting |
| Sigma Rules | Cross-platform detection rule format |
Common Scenarios
- Scenario 1: Intelligence-driven hunt based on APT campaign report
- Scenario 2: ATT&CK coverage gap analysis driving hypothesis creation
- Scenario 3: Anomaly-driven hypothesis from UEBA alert investigation
- Scenario 4: Situational awareness hunt based on industry sector threats
Output Format
Hunt ID: TH-BUILDI-[DATE]-[SEQ]
Technique: TA0001
Host: [Hostname]
User: [Account context]
Evidence: [Log entries, process trees, network data]
Risk Level: [Critical/High/Medium/Low]
Confidence: [High/Medium/Low]
Recommended Action: [Containment, investigation, monitoring]