Module 17 · Threat Hunting Operationalised — Hypotheses, Pivots, Dashboards

What threat hunting is

Proactive search for adversary presence based on hypothesis, not alert. The defender assumes a sophisticated attacker may already be present and searches for traces that current detection rules would miss.

The hunt cycle

1. Hypothesis: state what you’re looking for. “Adversaries may be using WMI for lateral movement.”
2. Data sources: identify what telemetry would show it. EDR process events, Windows Event 4688, Sysmon EID 1.
3. Query: write the query against SIEM / EDR.
4. Refine: investigate results; filter known-good; narrow to suspect.
5. Investigate: pivot from anomalies to determine if real or benign.
6. Document: hunt report — hypothesis, query, findings, residual gaps.
7. Detection engineering: convert successful hunt into an alert rule.

Hypothesis sources

• MITRE ATT&CK: pick a technique not covered by current detections; hunt for evidence.
• Threat intelligence: new IOCs / TTPs from external feeds; hunt your data.
• Recent incidents: a campaign hit a peer; check if you’re affected.
• Anomalies: a single weird event; expand into hunting for similar.
• Red team output: red team’s TTPs; hunt for them in your data.

A worked hunt — WMI lateral movement

# Splunk query — process creation events with WMI signatures
index=sysmon EventCode=1
| search Image="*\\WmiPrvSE.exe" OR ParentImage="*\\WmiPrvSE.exe"
| stats count by ComputerName, User, CommandLine, ParentImage
| where count < 10  # rare events more likely interesting

# Expand to network movement
index=sysmon EventCode=3 ParentImage="*\\WmiPrvSE.exe"
| stats count by ComputerName, DestinationIp, DestinationPort, User

# Investigate matches: which user, what was the destination, was it expected?

The pivot mindset

One anomaly leads to questions. Practitioners pivot through related data:

• Suspect process → parent process → parent’s full lineage.
• Suspect connection → destination → other workloads connecting to same destination.
• Suspect file → file hash → other hosts with same hash.
• Suspect user → user’s other recent activity.

Each pivot expands or narrows the investigation. The hunter’s value is asking the right next question.

Dashboards that support hunting

• Rare process executions — processes seen first time in the last 24 hours.
• External destinations by uniqueness — destinations connected to by only one host.
• Outbound data volume per host — sudden spikes suggesting exfiltration.
• Privileged account activity patterns — outside-normal hours, unusual sources.
• Service account behaviour — interactive logon from a service account is high-signal.

The output — what a hunt produces

1. Hunt report (whether or not findings).
2. Detection-engineering ticket if hunt found gap (add a Sigma rule).
3. Incident ticket if hunt found real adversary presence.
4. Visibility-gap ticket if hunt revealed missing telemetry.
5. Refined dashboards as part of the SOC’s standard view.

Hunt scoping

• Time-boxed: 2-3 days per hunt.
• Single hypothesis per hunt.
• Specific data sources, not “look everywhere”.
• Pre-defined success criteria.

Hunt metrics

Common failure modes

• “Hunt” without hypothesis — just browsing data; produces nothing.
• Hunt findings not converted to detections; same gap remains.
• Hunting demanded without dedicated time; nobody has 2 days.
• Reports not shared; team-wide learning doesn’t compound.

Key takeaways

• Hunting is hypothesis-driven proactive search; complement to alerting.
• Hypothesis sources: ATT&CK gaps, TI, incidents, anomalies, red-team output.
• Cycle: hypothesise → query → refine → investigate → document → engineer detections.
• Pivot mindset: each finding generates the next question.
• Time-box hunts (2-3 days); single hypothesis per hunt.
• Metrics: hunts/quarter, detections produced, visibility gaps, ATT&CK coverage.