Security · Security Operations
Threat Hunting
Proactively searching telemetry for adversary activity that automated detections have missed, driven by hypotheses rather than alerts.
Overview
Hunting starts from a hypothesis grounded in adversary behaviour, the environment's specific weaknesses, or fresh intelligence: 'if an adversary were abusing OAuth application consent for persistence, what would that look like in our audit logs?'
Successful hunts produce more than findings, each one should end in a new detection, a tuned control, a documented data gap, or a validated absence.
How it works
- 01Frame the hypothesis in terms of observable data, not intent, so it can be proved or disproved.
- 02Establish what normal looks like first; without a baseline, everything is anomalous and nothing is actionable.
- 03Pivot across entities, user, device, IP, process, token, to build a full picture rather than a single suspicious event.
- 04Record the hunt: question, data sources, queries, outcome, and follow up actions.
Sequence
- 1Hypothesis
- 2Data selection
- 3Investigation
- 4Pivot
- 5Validate
- 6Respond or improve detection
Layer model
Security considerations
- Hunt where telemetry is richest: identity, EDR, DNS and cloud audit logs.
- Feed every confirmed technique back into detection engineering so the same hunt is not repeated manually.
- Treat data gaps as findings with owners and deadlines.
IT vs OT
IT hunting focuses on identity, endpoints and cloud. OT hunting focuses on process anomalies, engineering workstation activity and protocol misuse, with passive collection only. Cross link to OT Atlas where the techniques diverge.
IT Atlas covers Information Technology. Operational Technology is covered separately at otatlas.ai.
