Threat Hunting vs Detection Engineering: How Each Feeds the Other

Many security operations teams fund threat hunting and detection engineering as separate functions, then find the same manual hunt being rerun every quarter because nothing it proved ever reached production alerting. The two disciplines look at the same telemetry and often share people, but they produce different things on different clocks: hunters produce answers to questions nobody has automated yet, and detection engineers produce tested, owned, maintained alerting logic. This guide compares them on outputs, cadence, skills and metrics, describes the threat model and failure modes of each, and sets out how to run the hand-off so hunts become detections and detection gaps become hunts. It is written for SOC managers, hunt leads and detection engineers deciding how to organise, staff and measure both. The mechanics of hunting and of rule writing are covered in the linked guides and are not repeated here.

Key takeaways

• Short answer: threat hunting searches for activity your detections do not yet catch; detection engineering turns behaviour you can reliably recognise into tested, owned alerting. Hunting explores, detection engineering productionises.
• The outputs differ, so the metrics must differ. A hunt's value is a proven or disproven hypothesis, a data gap or a detection candidate; a detection's value is precision, coverage and time to detect over months of operation.
• The hand-off is the product. PEAK's hierarchy of detection outputs (reports, dashboards, analytics in code, signatures and rules) gives the vocabulary, but someone must own acceptance of each candidate into the detection backlog.
• Each feeds the other. Hunts seed the detection backlog; documented blind spots, noisy rules that had to be suppressed and coverage gaps seed the hunt backlog.
• Small teams can do both with one group of people if hunting time is ring-fenced and every hunt ends with a decision on what, if anything, becomes automated.

The short answer

SURGe's PEAK framework defines hunting as any manual or machine-assisted process intended to find security incidents that automated detection has missed. NIST SP 800-53 Rev. 5 makes it a control in its own right, RA-10 Threat Hunting. Detection engineering has no single standard definition, but the practice is consistent across the field: each detection is treated as a product with a documented goal, tested logic, an owner, measured quality and a retirement path. Palantir's Alerting and Detection Strategy (ADS) framework was created because alerts were reaching production without documentation or peer review, which led to alert fatigue and wasted engineering effort.

Put simply, hunting asks "is this happening, and would we see it?"; detection engineering asks "now that we know what it looks like, how do we catch it every time without drowning the SOC?". The Threat Hunting Guide and the Detection Engineering Guide cover each discipline in depth.

Side-by-side comparison

Threat hunting: threat model, operating model and where it breaks

Threat model. Hunting assumes an adversary is already inside and has avoided existing alerting: through valid accounts (for example T1078.004 Valid Accounts: Cloud Accounts), built-in tools, or techniques for which no rule exists or the data is not collected. MITRE's 2020 paper on TTP-based hunting argues that filtering data by known adversary techniques works because the technology an adversary operates on constrains what it can do after compromise. Hunting therefore targets behaviour, not just indicators that change with every campaign.

Operating model in words. A hunt team keeps a risk-ranked backlog of abstracts, picks one, writes a testable hypothesis, checks the data exists, explores it, and closes with a written record. In PEAK the phases are Prepare, Execute and Act with Knowledge; in TaHiTI they are Initiate, Hunt and Finalise. TaHiTI's finalise step hands results to incident response, security monitoring, threat intelligence and vulnerability management. TaHiTI also advises using a use case framework such as MaGMa so hunters do not spend time on activity existing detection already covers, which is a direct dependency on the detection engineering inventory.

• Controls that make hunting work: retained, searchable telemetry covering the hunt window, a hunt record template, queries in version control, peer reproduction of results, and ring-fenced analyst time.
• Where it breaks: hunting without the data, so every hunt ends "inconclusive"; hunts that are really indicator sweeps; findings documented but never handed over; and hunters measured on incidents found, which rewards luck rather than coverage. PEAK's metrics guidance warns that counting hunts performed measures effort, not impact.

Detection engineering: threat model, operating model and where it breaks

Threat model. Detection engineering assumes adversaries will reuse techniques that the organisation has already seen, studied or prioritised, and aims to catch them automatically at scale. Its main enemy is not only the attacker but also decay: log sources change schema, parsers break, exclusions grow, and a rule that worked last year silently stops matching.

Operating model in words. Engineers take backlog items, research the behaviour and its benign look-alikes, confirm the data and fields exist, write the rule in a portable or native format, test it against true positive and baseline data, run it silently in staging, then promote it with response guidance and an owner. The community Detection Engineering Maturity Matrix describes the path from Defined (ad hoc, reactive, little documentation, no backlog) through Managed to Optimized, where almost all detection logic is tested automatically and work is prioritised from threat intelligence and subject matter expert input.

• Controls that make detection engineering work: detection as code (pull requests, review, CI tests, staged deployment), ADS style documentation including blind spots and validation steps, log health monitoring, and per-rule quality metrics. See the Detection as Code Guide.
• Where it breaks: coverage measured by mapping rather than testing; backlog fed only by vendor content and compliance requirements, never by what hunters found in this environment; and suppression used to fix noise, which quietly creates blind spots nobody records.

The hand-off: from hunt finding to production detection

PEAK's guidance on turning hunts into detections asks two questions after every hunt: can I reliably find this activity, and would I trust a result enough to send it to a SOC analyst as an alert? If yes, the output is analytics in code or a signature or rule; if not, a scheduled report or a dashboard. PEAK prefers rules to code and dashboards to reports, allows several outputs from one hunt, and advises revisiting lower outputs as experience grows. The live Threat Hunting Guide describes the four levels; the gap most teams have is not the vocabulary but the contract between the two teams.

A detection candidate package

Ask hunters to hand over a candidate, not a query. A workable package mirrors the ADS sections so the engineer starts with most of the documentation already written:

Acceptance rules

• Acceptance owner: one named person on the detection side accepts, rejects or defers each candidate within an agreed period (for example two weeks), with the reason recorded on the hunt record.
• Not every finding should alert: PEAK's own example is that alerting every time PowerShell runs would be a bad detection. Rejected candidates become scheduled reports, dashboards or future hunt topics, not lost work.
• Shared repository: hunting queries and production rules can live in the same version-controlled repository with different status values, so a hunting query's history follows it into production. Community projects such as the OTRF ThreatHunter-Playbook show the pattern: detection logic in notebooks, validated against pre-recorded datasets.
• Reverse flow: detection engineers send blind spots, rules retired for noise and techniques they cannot alert on precisely back to the hunt backlog. These are the best hunting topics because the organisation already knows it cannot see them automatically.

Worked scenario

A hunter tests the hypothesis that a stolen secret is being used to add new credentials to cloud applications (T1098.001 Additional Cloud Credentials). Over 90 days of directory audit logs she finds 412 credential additions: 397 by the identity automation service principal during scheduled rotation, 11 by named administrators with change tickets, and 4 by a legacy deployment account from an IP range never seen for that account. The 4 are investigated and found to be an undocumented migration script, not an attack. The hypothesis is disproven, but the hunt proved visibility.

The candidate package recommends a rule: credential added to an application by any identity other than the rotation service principal or the administrator group, outside an approved change window. The detection engineer finds that the directory audit table drops the initiating IP for one class of event, so the rule is built on the actor identity only, the IP gap is raised as a logging ticket, and the rule runs silently for three weeks. It produces two alerts a week, both legitimate, so the engineer adds a change ticket lookup and promotes it at medium severity. The legacy deployment account goes to the identity team as a misconfiguration finding. One hunt has produced a rule, a data gap, a misconfiguration and a known-benign list, which is exactly the set of outputs PEAK's metrics guidance counts.

When to invest in each

Most organisations need detection engineering before dedicated hunting, because hunting without a working detection pipeline produces findings with nowhere to go. Hunting becomes worth a dedicated budget once the basics alert reliably and the question shifts from "do our rules work?" to "what are we still missing?".

• Small team, one SOC: one group does both. Reserve fixed hunting time (for example one analyst day a week on rotation), use intelligence-driven hunts on identity and endpoint data, and require every hunt to end with a detection decision.
• Mid-sized, partly outsourced: if a managed detection and response provider hunts for you, agree in the contract how hunt findings become detections in your own platform and who owns them; otherwise the provider's learning leaves with the provider.
• Large or high-threat organisation: separate teams with a shared backlog, the candidate package above, and joint quarterly planning. A dedicated detection engineering team without hunters tends to build what vendors and frameworks suggest; hunters without engineers tend to rediscover the same things.

Do I need a hunt team? Answer yes to most of these before funding one: priority techniques already have tested detections; at least 90 days of identity, endpoint and cloud audit data are searchable; detection engineering has capacity to accept candidates; there is a credible threat that uses valid accounts or living off the land; and leadership will accept quarters where hunts find nothing malicious. See the Threat Hunter Career Guide and the Detection Engineer Career Guide for the skills each role needs.

Building the loop: a phased approach

1. Inventory first (weeks 1 to 4): list production rules with ATT&CK technique, data source, owner and last test date. Without this, hunters cannot avoid covered ground and engineers cannot see gaps.
2. Agree the contract: adopt the candidate package, name the acceptance owner, define status values (hunting, candidate, experimental, stable, deprecated) in the shared repository.
3. Seed both backlogs from each other: take ten techniques with mapped but untested rules and make them hunts; take the last five hunt records and turn their findings into candidates.
4. Pilot one quarter: run four to six hunts, each ending in a recorded detection decision. Run every accepted candidate as a silent rule or scheduled report for two to four weeks before it alerts.
5. Test and roll back: each promoted rule has a true positive test in CI; disabling a noisy rule is a single reverted commit with the reason logged, and the rule returns to the hunt backlog as a blind spot.
6. Review jointly each quarter: candidates accepted, rejected and waiting; data gaps open; techniques with proven visibility. Reprioritise both backlogs together.

Measuring each discipline and the loop

Avoid scoring hunters on incidents found: PEAK calls this a weak indicator because hunters do not control adversary activity. The Detection Engineering Maturity Model gives a fuller staged view of the engineering side.

Where identity fits

Non-human identities are where the loop matters most. Service accounts, service principals and API keys behave regularly, which makes them ideal for baseline hunts and, once the baseline is documented, for precise anomaly rules. Hunters establish what normal looks like (source networks, logon types, target resources); engineers turn the baseline into rules with the known-benign list as exclusions. See the Detection Engineering for Non-Human Identities Guide and the Identity Threat Hunting Guide.

Framework mapping

Common failure patterns

• Hunts that never become detections: results live in a slide deck or one analyst's notebook, nobody owns acceptance, and the same hunt is repeated by hand. Fix with the candidate package and a named acceptance owner.
• Hunting what is already covered: hunters spend weeks on techniques with stable, tested rules because there is no shared inventory. TaHiTI recommends a use case framework for exactly this reason.
• Promoting hunting queries straight to alerts: a query that worked for a judgement-led hunter floods the queue. Run it silently first and choose the PEAK output level honestly.
• Suppression without a trail: noisy rules are disabled or widened with exclusions, and the blind spot is never recorded or handed back as a hunt topic.
• One budget line, two missions: the same people are asked to hunt and to clear the alert queue, and hunting stops whenever alert volume spikes. Ring-fence the time or the people.
• Metrics that reward the wrong thing: hunt count and rule count rise while precision and proven coverage do not.

Practitioner checklist

• Maintain one inventory of production rules with technique, data source, owner and last successful test.
• Give hunting and detection work a shared, version-controlled repository with clear status values.
• Require every hunt record to end with a detection decision and a recommended PEAK output level.
• Hand over findings as a candidate package aligned to the ADS sections, not as a raw query.
• Name one acceptance owner and a service level for deciding on candidates.
• Run every accepted candidate silently or as a report before it alerts, with a true positive test in CI.
• Send blind spots, retired rules and imprecise techniques back to the hunt backlog.
• Report detections created from hunts, gaps closed, proven coverage and precision, not activity counts.

Standards and references

• Splunk SURGe: Turning Hunts Into Detections with PEAK
• Splunk SURGe: PEAK Threat Hunting Metrics
• FI-ISAC NL / Betaalvereniging: TaHiTI Threat Hunting Methodology
• Palantir: Alerting and Detection Strategy Framework
• GitHub (k-bailey): Detection Engineering Maturity Matrix
• MITRE: TTP-Based Hunting
• David J. Bianco: A Simple Hunting Maturity Model
• OTRF: ThreatHunter-Playbook

Related NHI Mgmt Group resources: Threat Hunting vs Incident Response · Threat Hunting Frameworks Guide · Threat Hunt Hypothesis and Report Template · Sigma Rules Guide · Pyramid of Pain Guide