The hypothesis-driven hunting model
Unstructured hunting — 'explore the data and see what looks odd' — is an expensive way to feel productive. Hypothesis-driven hunting starts with a threat model: given your environment, your industry, and the threat actors likely targeting you, which ATT&CK techniques are most probable and least covered by existing detections?
A hypothesis is a falsifiable statement about attacker behaviour in your environment. 'Attackers who have compromised a contractor identity will use it to enumerate IAM permissions before lateral movement' is a hypothesis. 'Something weird is happening with identities' is not.
For each hypothesis, define the data sources that would evidence the behaviour, the query that operationalises the search, and the threshold above which you'd treat a result as a finding. Write this down before you run the query — it's the difference between a hunt and a fishing trip.
Building a hunt hypothesis backlog
Source hypotheses from four places: (1) MITRE ATT&CK techniques with no coverage in your detection catalogue, (2) CTI reporting on threat actors targeting your sector, (3) post-incident reviews from the last 12 months, (4) red team findings. Prioritise by probability × impact.
Run a hypothesis backlog review monthly. Hypotheses that produce findings become detection candidates. Hypotheses that consistently produce nothing over three hunt cycles are deprioritised in favour of new ones.
- ATT&CK coverage gap analysis run and exported
- CTI feeds reviewed for sector-relevant actor TTPs
- PIR outputs from last 12 months reviewed for hunt candidates
- Red team findings mapped to hunt hypotheses
- Hypothesis backlog prioritised by probability × impact
Hunting in the ManySignal entity graph
The entity graph is the primary hunting surface. Graph traversal queries let you ask questions like: 'Which identities authenticated to a new device AND accessed a sensitive data source within the same hour AND have no prior history of that access pattern?' — without writing multi-JOIN SQL across three tables.
Temporal queries let you look at how entity behaviour changed over time. Comparing an identity's current 7-day behaviour profile against its 90-day baseline surfaces drift that is invisible in per-event queries.
-- Hunt: identities with first-ever access to S3 bucket
-- containing "backup" or "archive" in the last 7 days
SELECT
actor_identity,
target_resource,
MIN(event_time) as first_access,
COUNT(*) as access_count
FROM events
WHERE class_uid = 3005 -- API Activity
AND operation IN ('GetObject','ListObjects')
AND target_resource ILIKE '%backup%'
OR target_resource ILIKE '%archive%'
AND event_time > NOW() - INTERVAL '7 days'
GROUP BY actor_identity, target_resource
HAVING MIN(event_time) > (
SELECT COALESCE(MAX(prior_event_time), '1970-01-01')
FROM events e2
WHERE e2.actor_identity = events.actor_identity
AND e2.target_resource = events.target_resource
AND e2.event_time < NOW() - INTERVAL '7 days'
)
ORDER BY first_access DESC;Converting hunt findings to detections
Every hunt finding that represents genuine attacker behaviour should become a detection. Write the detection in YAML, add the test fixtures based on the hunt evidence, backtest against 30 days of production data, and promote through the standard pipeline.
The hunt-to-detection pipeline is the compounding return on hunting investment. Each hunt cycle adds detections that cover the next cycle's hypotheses automatically — reducing hunt burden over time as the detection catalogue grows.
Measuring hunt programme effectiveness
Track four metrics per quarter: hypotheses tested, findings produced, findings converted to detections, and MITRE coverage delta (techniques newly covered vs prior quarter). A hunt programme that is not growing coverage is not compounding.
Also track mean time from hunt finding to detection promotion. If it exceeds two weeks, the detection engineering pipeline is the bottleneck — not the hunting itself.
Key takeaways
- Hypothesis-driven hunting produces detections; unstructured exploration produces feelings of productivity.
- A hypothesis is falsifiable: data sources, query, and threshold defined before running.
- Source hypotheses from ATT&CK gaps, CTI, PIR outputs, and red team findings.
- The entity graph enables cross-dimension temporal queries that are impractical in log search.
- Every confirmed hunt finding should become a detection — this is the compounding return.
- Track coverage delta quarterly; a programme not growing coverage is not compounding.