Skip to content

02 · Advanced Threat Hunting

SIEM alerts (Level 3 Module 5) catch what you already thought to detect. Threat hunting is the proactive discipline of looking for adversaries who evaded every existing alert — starting from a hypothesis, not a triggered rule.

1. Hunting vs. alerting

Alerting:  "Tell me when X happens" -- reactive, scales, but only catches
            known patterns.
Hunting:    "Assume X already happened undetected -- go find evidence" --
            proactive, human-led, catches what alerting missed.

A mature program needs both: hunting findings that prove valuable become new alerts (feeding back into Level 3 Module 5), continuously raising the bar for what's caught automatically.

2. The hunting process

1. Hypothesis   -- "If an attacker has a foothold, they'd likely use
                    living-off-the-land binaries for discovery"
2. Data gathering -- pull relevant logs (process creation, network, auth)
3. Analysis      -- look for the hypothesized behavior or its absence
4. Findings      -- confirmed malicious activity, a new detection gap,
                    or nothing found (still valuable -- documents coverage)
5. Feedback      -- new Sigma/SIEM rule, updated baseline, or closed hunt

3. Hypothesis-driven hunting with ATT&CK

Hypothesis: "Adversaries may be using PsExec or WMI for lateral movement,
             bypassing our RDP-focused monitoring" (T1021.002, T1047)

Hunt query (Splunk):
index=wineventlog EventCode=4688
| search CommandLine="*wmic*" OR CommandLine="*psexec*"
| stats count by host, user, CommandLine
| where count > 0

Every hunt should map to specific ATT&CK techniques not yet well-covered by existing detections (from the coverage tracking in Level 3 Module 5), prioritizing gaps over techniques already well-alerted.

4. Data-driven / baseline hunting

Instead of a specific hypothesis, look for statistical outliers against an established baseline of "normal" for your environment:

# Find processes that ran on exactly one host in the last 90 days --
# rare execution is a strong (not certain) signal of something unusual
index=wineventlog EventCode=4688 earliest=-90d
| stats dc(host) as host_count by Image
| where host_count=1
| sort host_count

# Beaconing detection: connections at suspiciously regular intervals
# (a hallmark of malware C2 checking in on a timer)
index=network
| streamstats current=f last(_time) as prev_time by src_ip, dest_ip
| eval delta=_time-prev_time
| stats stdev(delta) as jitter, avg(delta) as avg_interval by src_ip, dest_ip
| where jitter < 2 AND avg_interval > 30

5. Hunting across the kill chain

Reconnaissance:  unusual DNS queries for internal hostnames from a single host
Delivery:        rare/newly-registered sender domains in email logs
Execution:       parent-child process anomalies (Word spawning PowerShell)
C2:              long-lived connections, beaconing intervals, DNS tunneling
                 patterns (high query volume, unusual TXT record sizes)
Lateral movement: authentication to hosts a user has never accessed before
Exfiltration:    large outbound transfers to rare destinations, off-hours

6. Tooling for advanced hunting

# EDR query languages (example: CrowdStrike/Elastic-style) let hunters
# search raw telemetry beyond what's pre-indexed into alerts
process where process.name == "rundll32.exe" and
  process.command_line : "*javascript:*"

Jupyter notebooks with direct data-source access (rather than only a SIEM UI) let hunters apply statistical/ML techniques — clustering, anomaly scoring — that a standard SIEM search language can't express.

7. Documenting and operationalizing hunts

A hunt that isn't documented is a hunt that gets re-run from scratch next quarter with no institutional memory:

Hunt ID: H-2026-014
Hypothesis: Living-off-the-land lateral movement via WMI
Data sources: Windows Event Logs (Sysmon), 90-day window
Result: No malicious activity found; identified 2 legitimate admin
  scripts using WMI that should be added to a baseline allowlist
Outcome: New Sigma rule created for anomalous WMI use outside allowlist;
  ATT&CK T1047 coverage moved from "none" to "detected"

How It Actually Works: how baseline/anomaly hunting actually computes "normal," and why hunting finds what rules miss

Data-driven hunting works by building a statistical model of normal behavior per entity (per host, per user, per process) and flagging deviation, rather than matching a known-bad pattern the way a SIEM correlation rule does. Concretely, for something like process-execution frequency, a hunter (or the tooling supporting the hunt) computes a baseline distribution — mean and standard deviation of "how many distinct child processes does explorer.exe normally spawn per hour, per host" over a trailing window — and flags observations several standard deviations outside that baseline as candidates. This is a fundamentally different detection mechanism than the signature/correlation approach from Level 2–3's SIEM modules: a correlation rule can only ever catch behavior someone already characterized as bad; an anomaly baseline catches anything statistically unusual, including techniques nobody has written a rule for yet, at the cost of needing a human analyst to judge whether a given anomaly is actually malicious rather than a false positive from a legitimate but rare event (a scheduled batch job, an admin's unusual-but-authorized session).

This is the precise, mechanistic reason hunting finds things alerting doesn't: a correlation rule requires the "IF condition" to be specified before the attack happens; a hunt hypothesis (section 3) is formed after observing intelligence about a new technique (Level 3 Module 4's threat intel feeding directly into this), and is tested by an analyst manually querying historical data for the specific ATT&CK-mapped telemetry signature that technique would leave — meaning a hunt can retroactively find an intrusion that occurred before any rule existed to catch it, as long as the raw telemetry was retained (tying directly back to Level 2 Module 6's retention discussion: a hunt is only as good as how far back the index actually goes). Kill-chain-based hunting structures this further by hypothesizing at each of the seven classic stages (reconnaissance through actions-on-objective) independently, because a technique's telemetry footprint and the baseline of "normal" both differ enormously stage to stage — DNS query volume anomalies matter for command-and-control hunting in a way they're irrelevant for a privilege-escalation hunt, which looks instead at token/permission-change telemetry.

8. Checklist

  • [ ] Hunts are hypothesis-driven and mapped to specific ATT&CK techniques
  • [ ] Both hypothesis-driven and baseline/statistical hunting used
  • [ ] A "no findings" hunt still documented and counted as coverage gained
  • [ ] Confirmed findings converted into permanent detections
  • [ ] Hunt results logged for institutional memory, not re-derived each time

What's next

Module 3 looks at zero trust architecture, a design philosophy that shrinks the space an attacker can move through undetected in the first place.