TH0.6 Hunting, IR, and Detection Engineering

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

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:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20

// 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

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-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.

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)