Threat Hunting
Threat Hunting tests proactive, hypothesis-driven investigation in QRadar rather than alert triage. You are expected to form a hypothesis, query events and flows, pivot across evidence, use threat intelligence, and document the result, including a negative one.
Hunting model
- Hypothesis: a specific, testable behavior, e.g., a service account authenticating to many hosts.
- Scope: time range, assets, identities, and network zones.
- Query: use AQL in Log Activity or Network Activity; aggregate first, then inspect raw records.
- Enrich: asset weight, vulnerabilities, threat-intelligence matches, reference sets.
- Decide: escalate to an offense, tune a rule, or record no finding.
QRadar capabilities
AQL supports SELECT, FROM events or flows, WHERE, GROUP BY, ORDER BY, and LAST n HOURS or DAYS. Saved searches make hunts repeatable. Reference sets hold watchlist indicators and can be populated from searches. Threat-intelligence feeds and the offense threat-intelligence view add context. Pivoting from an offense to its events and flows is often the fastest path to scope.
Worked example: Hypothesis: a compromised backup account is moving laterally. Query events for username svc_backup, group by destinationip, count failures and successes, LAST 24 HOURS. The baseline shows two destinations; today shows 18. Pivot to flows for those destinations, check asset criticality and threat-intel reputation, then inspect raw authentication events. Reasoning: aggregation exposed the anomaly; raw events confirmed it; asset context set severity. Open an offense and document the query.
Traps
- Hunting only when an offense already exists.
- Starting with a broad query and drowning in raw events.
- Ignoring asset and vulnerability context.
- Treating no threat-intel match as proof of benign activity.
- Not saving the query or documenting negative findings.