Detection vs Hunting — When Rules Aren't Enough

Detection rules are efficient but backward-looking — they catch what you already know to look for. Sophisticated attackers study your detection posture and operate in the gaps. Threat hunting is the discipline of actively searching for the attacks that your rules haven’t caught yet.

Why Detection Rules Have a Ceiling

Every rule is written from something the defender already knows:

• A past incident
• A threat intelligence report
• An emulation test result
• A community-contributed Sigma rule

This means every rule describes the past. A novel technique, a new tool variant, or an attacker who has specifically researched your detection posture can operate in complete silence.

The detection ceiling is the set of techniques that fall below your rule threshold:

• Behaviors that are too similar to normal admin activity to rule on
• Techniques that require more data than a single event (require aggregation over time)
• Attacker tradecraft deliberately designed to stay under detection thresholds (low-and-slow, living off the land)

Hunting is the discipline of working below that ceiling.

The Hunting Mindset

Hunting requires a different operating mode than alert triage:

A good hunter is comfortable with ambiguity — most hunts end with “no evidence of compromise, baseline documented” rather than “attacker found.” That null result is still valuable: it establishes a baseline that future hunts can compare against.

When Is Hunting the Right Tool?

Hunt when:

• Threat intel reports a new technique being used by actors targeting your sector
• You detect a breach at another org in your industry and want to check for similar IOCs/TTPs
• Baseline drift is observed (something changed, but no alert fired)
• A red team report identified a technique your detection program doesn’t cover
• You want to establish baseline behavior for a new system before writing detection rules

Don’t hunt when:

• You have active alerts that need triage — hunting is proactive, not a substitute for triage
• You don’t have the data source the hunt requires (hunting without the right logs is noise)
• The hunt hypothesis is too broad (“hunt for all malware”) — scope it first

Dwell Time and the Hunting Opportunity

Day 0: Attacker gains initial access (phishing email opened)
Day 1-3: Reconnaissance — net user, whoami, AD enumeration (LOLBins, no alerts)
Day 4-7: Persistence — scheduled task created via Task Scheduler GUI (no process creation alert)
Day 8-15: Credential access — Kerberoasting via LDAP (network traffic, no Sysmon alert)
Day 16: Lateral movement detected — first obvious alert fires

MTTD: 16 days
Hunting opportunity: Days 1–15 — all this behavior left traces a hunter could find

The attacker’s dwell time is your hunting window. Every day of dwell time is a day of artifact accumulation: event logs, registry entries, scheduled task files, authentication records. Hunting retroactively through this data surfaces the compromise days or weeks before automated detection would catch it.

The Hunt Lifecycle

1. HYPOTHESIS
   ↓ "APT actors targeting our sector use WMI for lateral movement"

2. PREPARE
   ↓ Identify data sources, define scope, document baseline

3. EXECUTE
   ↓ Build and run search queries, collect candidate evidence

4. ANALYZE
   ↓ Triage candidates: FP / suspicious / confirmed malicious

5. ACT
   ↓ If malicious: incident response
   ↓ If suspicious: escalate for investigation
   ↓ If null: document baseline, retire hypothesis

6. IMPROVE
   ↓ Convert high-confidence finding to Sigma rule
   ↓ Update coverage matrix
   ↓ Feed back to threat intel

Steps 2–5 are formalized in the PEAK and TaHiTI frameworks (next lessons).