Hypothesis Generation — Three Sources of Hunt Ideas

A hunt without a hypothesis is a fishing expedition — you look at data and wait for something suspicious to catch your eye. Hypothesis-driven hunting is more efficient and more effective: you have a specific question, a predicted answer, and a test. This lesson covers the three reliable sources of hunt hypotheses and how to structure each into a testable hunt.

Source 1: Threat Intelligence

The richest source of immediately actionable hunt hypotheses is published threat intelligence about techniques used by adversaries targeting your sector.

Reading a CTI Report for Hunt Hypotheses

When a new threat actor report drops:

1. Find the techniques section (ATT&CK mapping or procedural examples)
2. For each technique: “Do I have telemetry for this? Do I have a rule? Should I hunt for it?”
3. Write a hypothesis for techniques with telemetry but no detection rule

Example — excerpt from a fictional threat actor report:

“The actor uses scheduled tasks for persistence, creating them via the at.exe command (now deprecated but still functional) to avoid triggering detections for schtasks.exe. at.exe task creation is rarely logged by modern detection tools.”

Hunt hypothesis:

“I believe this actor or copycats may have used at.exe for persistence on Windows hosts in our environment in the past 90 days. If so, I expect to find Sysmon Event 1 (process creation) for at.exe with arguments indicating task creation, or Windows Event 4698 (Scheduled Task Created) with task creator at.exe.”

Hypothesis Template from CTI

Technique: [ATT&CK ID — name]
Actor: [actor name or "unknown"]
CTI Source: [report title, organization, date]
Predicted evidence: [specific log event + field values]
Time scope: [e.g., past 90 days]
Asset scope: [e.g., Windows workstations]

Sources for CTI-Driven Hypotheses

Source 2: Anomaly Detection

Anomaly-driven hypotheses start with statistical outliers in your own data, then generate a possible attack explanation.

The Anomaly → Hypothesis Pipeline

Statistical outlier found
       │
       ▼
Is there a business explanation?  → YES: Document, update baseline
       │
       NO
       ▼
What attack technique could explain this behavior?
       │
       ▼
Hunt hypothesis: "This anomaly is caused by [technique]"

Common Anomaly Signals

Process anomalies:

# Processes with unusual parent-child relationships
index=sysmon EventCode=1
| stats count by Image, ParentImage
| where count < 3   # rare combinations
| sort count

Find process pairs that appear fewer than 3 times in 30 days — these are rare combinations that may represent LOLBin abuse or novel attack paths.

Account anomalies:

# User accounts accessing resources outside their normal peer group
index=windows EventCode=4624 LogonType=3
| stats dc(ComputerName) as unique_hosts by TargetUserName
| where unique_hosts > 20   # accessing more hosts than typical
| sort -unique_hosts

An account accessing 50+ unique hosts is a Kerberoasting or lateral movement candidate.

Time anomalies:

# Process execution outside business hours for a specific user
index=sysmon EventCode=1
| eval hour=strftime(_time, "%H")
| where hour >= 0 AND hour <= 5   # midnight to 5am
| stats count by User, Image
| sort -count

Source 3: Situational Awareness

Sometimes the hunt hypothesis comes not from your data but from what’s happening in the world: a peer organization was breached using technique X, a zero-day was published, a red team found a gap.

External Events → Internal Hypotheses

The “Assume Breach” Hypothesis

Periodically generate hypotheses from the assumption that a breach has already occurred and ask: “If we were compromised two weeks ago, what would I expect to see in the data?”

This generates inside-out hypotheses:

• “If an attacker had domain admin, they would have run DCSync — is there 4769 Mimikatz-style ticket requests?”
• “If data was exfiltrated, there would be large outbound transfers — are there hosts with >500MB outbound to external IPs?”
• “If persistence was established, it would appear in scheduled tasks, Run keys, or WMI subscriptions”

Crown Jewel Analysis

For each crown jewel asset, map the attack paths to it:

Crown Jewel: Customer PII database (db-pii-prod-01)

Attack paths:
1. Compromise DB admin account → direct DB access
   → Hunt: lateral movement to db-pii-prod-01 from non-admin hosts
   
2. Compromise application server → pivot to database
   → Hunt: unusual connections FROM app servers TO db-pii-prod-01
   
3. Compromise DBA workstation → RDP to database server
   → Hunt: Event 4624 Type 10 (RemoteInteractive) to db-pii-prod-01

4. Abuse database service account → T1078 credential reuse
   → Hunt: svc-db account activity outside normal application hosts

Each path becomes a testable hypothesis. Crown jewel analysis ensures hunts prioritize your most critical assets.