Threat hunting
When it applies
You suspect activity that evaded detections, or you want to proactively look for a specific technique/actor. Hunting assumes breach and searches telemetry for evidence, rather than waiting for an alert.
Why it works
Detections encode what you already anticipated; hunting finds what you didn't. Framing a falsifiable hypothesis around an ATT&CK technique focuses the search on data that would prove or disprove compromise, and every confirmed pattern becomes a new detection — so coverage grows.
Method
- Form a hypothesis: specific and testable — "an adversary is using WMI for lateral movement (T1047)", not "find bad stuff".
- Pick the telemetry: which data source records it (process create, network, auth, cloud audit), and confirm it's actually being collected.
- Search with technique, not IOC: behavioural queries — rare parent/child process pairs,
regsvr32/rundll32with network egress, service installs, anomalous logon patterns. - Reduce with stack-counting/frequency analysis: sort by rarity — outliers surface fast in a sea of normal (long-tail analysis).
- Pivot on hits: from a suspicious process → its network, parent, the host's auth history; build
the timeline. Escalate to
defense-incident-responseif confirmed. - Operationalise: turn every true finding into a detection (
defense-detection-engineering), and record the hunt (hypothesis, data, result) even when negative.
Gotchas
- A negative hunt is only meaningful if the telemetry existed — "found nothing" with no logs is not "clean".
- IOC-only hunting rots as infrastructure rotates; hunt behaviour.
- Hunting in production EDR can tip off an active adversary — coordinate with IR.
Verify success
Each hunt has a stated hypothesis, the data it examined, and an outcome (found / not found / no telemetry), and true findings produced both an IR handoff and a new detection.
References
MITRE ATT&CK; the PEAK / TaHiTI hunting frameworks; Sqrrl hunting maturity model.