In this section

TH0.6 Hunting, IR, and Detection Engineering

3-4 hours · Module 0 · Free

Operational Objective

Hunting, incident response, and detection engineering are three distinct disciplines that share tools, data sources, and analysts — but differ in trigger, method, and output. Organizations that confuse them under-invest in each. This subsection defines the boundaries, the handoffs, and the feedback loops that make the three disciplines a self-reinforcing system rather than three names for the same activity.

Deliverable: A clear operational model for where hunting starts and stops relative to IR and detection engineering, and how the three disciplines feed each other in a mature security operation.

⏱ Estimated completion: 20 minutes

Three disciplines, one data lake

The tools overlap. Sentinel is the workspace for detection engineering (analytics rules), hunting (hunting queries), and incident response (incident investigation). KQL is the query language for all three. The Defender XDR portal serves all three. An analyst may write a detection rule in the morning, investigate an incident in the afternoon, and run a hunt campaign on Friday.

The overlap is why organizations confuse them — if the same person uses the same tool to query the same data, what is the difference? The difference is trigger, method, and output.

What triggers each

// Incident source distribution — which disciplines are producing findings?
SecurityIncident
| where TimeGenerated > ago(180d)
| extend IncidentSource = case(
    tostring(AdditionalData) has "Scheduled", "Detection Rule (Automated)",
    tostring(AdditionalData) has "Fusion", "Fusion/ML Correlation",
    tostring(AdditionalData) has "NRT", "Near Real-Time Rule",
    "Built-in / Other")
| summarize
    IncidentCount = count(),
    AvgSeverity = avg(case(
        Severity == "High", 3,
        Severity == "Medium", 2,
        Severity == "Low", 1, 0))
    by IncidentSource
| sort by IncidentCount desc
// If 100% of incidents come from detection rules, your triad has one active leg
// Incidents discovered by hunting appear as manually created incidents
//   or do not appear here at all (they may be in hunt records, not Sentinel)
// The gap between what rules find and what exists = hunting surface

Expand for Deeper Context

Detection engineering is triggered by planning. The detection engineer reads a threat report, identifies a technique, writes a KQL query to detect it, tests the query, and deploys it as an analytics rule. The trigger is proactive but the result is reactive — the rule sits and waits for the technique to occur.

Incident response is triggered by an alert. Something fired — a detection rule, a user report, an external notification. The IR analyst investigates: what happened, how far did it spread, what data was affected, how do we contain it. The trigger is reactive. The investigation is reactive. The output is a resolved incident.

Hunting is triggered by a hypothesis. The hunter suspects that a specific threat technique may have occurred in the environment without triggering any alert. They formulate the hypothesis, query historical data, analyze results, and confirm or refute the hypothesis. The trigger is proactive and the investigation is proactive — no alert fired, no incident exists. The hunter goes looking.

The triggers define when each discipline activates. Detection engineering activates during planning cycles. IR activates when something goes wrong. Hunting activates on a schedule — dedicated time, protected from the alert queue, applied to a prioritized backlog of hypotheses.

The following query shows how your incidents are currently triggered — which tells you which disciplines are active in your organization:

What each produces

Detection engineering produces rules. Analytics rules in Sentinel, custom detection rules in Defender XDR, alert policies in Defender for Office 365. These are the automated layer — they fire when the pattern matches.

IR produces findings. Evidence timelines, scope assessments, containment actions, root cause analysis, lessons learned, IR reports. These document what happened and how the organization responded.

Hunting produces three things simultaneously. First: findings — evidence of compromise or confirmation of absence (both valuable). Second: detection rules — every successful hunt produces at least one new rule that automates the detection going forward. Third: environmental understanding — baselines, patterns, and contextual knowledge that improves both IR analysis and detection rule tuning.

The detection rule output is what makes hunting self-reinforcing. Each hunt that produces a detection rule moves a technique from the known-unknown layer to the known-known layer. The detection gap shrinks. The next hunt can focus on a different technique because the previous one is now automated.

Figure TH0.6 — The capability triad. Detection engineering produces rules. IR investigates when rules fire. Hunting finds what rules miss and produces new rules. Each discipline's output feeds the other two.

The six handoff points

The triad works through explicit handoffs. When these handoffs are informal or missing, the disciplines operate in silos and the reinforcing cycle breaks.

1. Detection → IR: A detection rule fires an alert. The IR analyst triages, investigates, and resolves. This handoff is well-established in most SOCs — it is the core of the incident management workflow.

2. IR → Detection: During investigation, the analyst discovers a technique the attacker used that was not detected by any rule — or was detected late. The technique becomes a detection engineering backlog item. This handoff is common in mature programs but often informal — it happens through conversation rather than a tracked backlog item.

3. Detection → Hunting: The detection engineer maps coverage to ATT&CK and identifies techniques with no rules. Those techniques become hunt hypotheses: "We have no detection for T1098.003 — are there unauthorized application permission grants in the last 90 days?" This handoff is the primary input for TH3 (ATT&CK Coverage Analysis).

4. Hunting → Detection: A hunt validates that a technique occurs in the environment. The hunting query, now tested against real data and tuned for the environment's noise level, becomes a detection rule. This handoff is the hunt-to-detection pipeline — the mechanism that makes hunting self-funding.

5. IR → Hunting: An incident reveals that the attacker was in the environment for 15 days before the rule fired. The IR findings raise a question: did the attacker compromise other accounts during those 15 days that we have not yet detected? The question becomes a hunt hypothesis: "Using the IOCs from INC-NE-2026-0405, search all authentication data for the 15 days before detection for evidence of additional compromised accounts." This handoff converts a reactive investigation into a proactive search for wider scope.

6. Hunting → IR: A hunt discovers evidence of compromise. The hunter escalates to IR with an evidence package: what was found, what data sources were queried, what the indicators are, what the initial scope assessment suggests. The hunt becomes an incident. This handoff is the moment hunting delivers its highest-value output — an intrusion discovered before any automated detection caught it.

Where this course sits in the Ridgeline curriculum

The Ridgeline training platform teaches all three disciplines through separate courses, and the courses are designed to connect:

Mastering KQL provides the query language foundation that all three disciplines share. You cannot write detection rules, investigate incidents, or run hunt campaigns without KQL proficiency.

SOC Operations teaches detection engineering — building analytics rules, deploying detection-as-code, managing the detection lifecycle. It also covers the operational framework that all three disciplines operate within.

Practical Incident Response teaches investigation — following the attacker's evidence trail across Windows endpoints and M365 cloud services, from initial compromise through containment and reporting. The Six-Step Investigation Method (what to look for → where to find it → how to extract → how to interpret → what it proves → what to do next) is the investigation methodology.

Practical Threat Hunting in Microsoft 365 — this course — teaches the proactive complement. Where IR follows the evidence after an alert fires, hunting follows hypotheses before any alert exists. The Hunt Cycle (hypothesize → scope → collect → analyze → conclude → convert) is the hunting methodology. The detection rules that hunting produces feed back into the SOC Operations detection lifecycle. The compromises that hunting discovers escalate into the IR methodology.

The learner who completes all four courses can operate across the full triad — building detections, investigating incidents, and hunting for threats that no rule has caught. That combination is the complete security operations capability.

Try it yourself

Exercise: Trace a real handoff in your organization

Pick a recent closed incident in your Sentinel workspace. Answer these questions:

Detection → IR (handoff 1): Which detection rule triggered the incident? Was the rule a built-in Defender XDR detection or a custom analytics rule?

IR → Detection (handoff 2): During the investigation, did the analyst discover any technique the attacker used that was NOT detected by any rule? If yes, was a detection engineering backlog item created? If not, the handoff failed — the gap persists.

IR → Hunting (handoff 5): Did the investigation raise any questions about wider scope — other accounts, other time windows, other systems that may have been affected but were not included in the original alert? If yes, was a hunt conducted to answer those questions? If not, the wider scope remains unknown.

If handoffs 2 and 5 did not happen, your triad is operating as a single discipline (IR) with no feedback into detection improvement or proactive hunting. That is the gap this course and the broader Ridgeline curriculum address.

⚠ Compliance Myth: "Threat hunting is just incident response without an alert"

The myth: Hunting and IR are the same thing. If the analyst is querying data and looking for threats, they are doing IR. Hunting is just a buzzword for proactive investigation.

The reality: Hunting and IR share tools and data sources but differ in trigger, method, scope, and output. IR is triggered by an alert and scoped to a specific incident — the investigation follows the evidence of a known compromise. Hunting is triggered by a hypothesis and scoped by the hunter — the investigation explores a threat category across the environment without evidence that a compromise has occurred. IR produces incident findings and containment actions. Hunting produces findings, detection rules, and environmental understanding. Confusing them leads to under-investment in both: the SOC "hunts" only when investigating incidents (IR) and never conducts structured, hypothesis-driven campaigns against the unknown-known layer.

Extend this model

Some organizations add a fourth discipline to the triad: threat intelligence. TI provides the external context — what attackers are doing to organizations like yours — that feeds hypothesis generation for hunting and technique identification for detection engineering. The SOC Operations course (Module S12) covers TI operations in depth, including the TI-to-detection pipeline and TI-driven hunting. For this course, TI is treated as an input to hunting rather than a separate discipline, but in organizations with dedicated TI analysts, the four-discipline model (TI → Detection Engineering → Hunting → IR → TI) creates an even tighter reinforcing loop.

📋 Operational Artifact — Capability Triad Quick Reference

Detection Engineering: Trigger = planning. Output = rules. Measures = technique coverage, rule efficacy, false positive rate.

Incident Response: Trigger = alert. Output = findings + containment. Measures = MTTD, MTTR, containment time, recurrence rate.

Threat Hunting: Trigger = hypothesis. Output = findings + rules + understanding. Measures = hunts completed, hypotheses validated, detections created, incidents discovered through hunting.

Six handoffs: DE→IR (rule fires, analyst investigates). IR→DE (investigation gap → detection backlog). DE→Hunting (coverage gap → hunt hypothesis). Hunting→DE (hunt query → detection rule). IR→Hunting (incident scope → proactive search). Hunting→IR (hunt discovery → incident escalation).

If any handoff is missing: The discipline that should receive the output is operating without input from the discipline that should provide it. Identify which handoffs exist in your organization and which are informal or absent.

References Used in This Subsection

MITRE ATT&CK Techniques referenced: T1098.003 (Additional Cloud Roles)
Course cross-references: Mastering KQL (KQL foundation), SOC Operations Module S12 (TI operations), Practical IR (Six-Step Investigation Method)

Decision point

You have time for one hunt this quarter. Do you hunt for the threat in the latest advisory or for the gap in your ATT&CK coverage matrix?

Hunt the coverage gap. Advisories describe threats that are CURRENT but may not target NE. Coverage gaps describe techniques that COULD target NE and would succeed undetected. The coverage gap hunt produces a detection rule (closing the gap permanently). The advisory-driven hunt produces a point-in-time assessment (confirming the specific threat is not present today). Both are valuable — but the coverage gap hunt has a longer-lasting impact because it produces a permanent detection improvement.

A hunt query returns 200 results. You have 4 hours remaining in the hunt window. You can investigate 20 results thoroughly or review all 200 superficially. Which approach produces better hunt outcomes?

Review all 200 — you might miss a critical finding in the 180 you skip.

Investigate 20 thoroughly. A superficial review of 200 results produces 200 'looked at it, seemed okay' assessments that provide no investigative value and no documentation for future reference. A thorough investigation of 20 results produces: confirmed findings (true positives requiring remediation), confirmed benign patterns (documented baselines for future comparison), and inconclusive results (flagged for monitoring). Prioritise the 20 by: highest anomaly score, highest-value assets involved, and highest-risk users involved. Document why the remaining 180 were not investigated and recommend a follow-up hunt with refined query criteria to reduce the result set.

Investigate 20 — but only if they are from the most recent 24 hours.

Neither — refine the query first to reduce the result set below 50.

You understand the detection gap and the hunt cycle.

TH0 showed you what detection rules fundamentally cannot catch. TH1 gave you the hypothesis-driven methodology that closes that gap. Now you run the hunts.

10 complete hunt campaigns — from hypothesis through KQL execution through finding disposition, each campaign based on a real TTP
70 production hunt queries — every one mapped to MITRE ATT&CK and tested against realistic telemetry
Advanced KQL for hunting — UEBA composite risk scoring, retroactive IOC sweeps, and hunt management metrics
Hypothesis-Driven Hunt Toolkit lab pack — 30 days of realistic M365 and endpoint telemetry with multiple attack patterns seeded in
TH16 — Scaling hunts across a team — the operating model for a production hunt program

Unlock the full course with Premium See Full Syllabus

← Previous Next →