Sign In
In this section

TH1.6 Converting Hunts to Detection Rules

3-4 hours · Module 1 · Free
Operational Objective
A hunt that does not produce a detection rule is a hunt that must be repeated. The Convert step is what makes hunting self-funding — the query you used to find the threat today becomes the analytics rule that detects it automatically tomorrow. This subsection teaches the conversion process: adapting a hunting query for scheduled execution, setting appropriate thresholds, configuring alert grouping, and deploying through your detection engineering pipeline.
Deliverable: The ability to convert a validated hunt query into a production-ready Sentinel analytics rule, including threshold calibration, entity mapping, and incident creation configuration.
⏱ Estimated completion: 30 minutes

The query is already written

This is the part that detection engineers undervalue about hunting: the hunt already did the hard work. The query has been written, tested against real data, tuned against the environment's noise level, and validated by a human analyst who examined every result. Converting that query to a detection rule is not starting from scratch — it is deploying a pre-validated detection.

Compare this to the normal detection engineering workflow: the engineer reads a threat report, writes a query based on theoretical understanding of the technique, deploys the rule, and then discovers over the following weeks that the false positive rate is unacceptable because the query matches legitimate activity patterns the engineer did not anticipate. Tuning cycles begin. The rule is disabled, modified, re-enabled, modified again. Weeks pass before the rule is stable.

// Hunt query producing results:
SigninLogs
| where TimeGenerated > ago(1h)
// ... core hunting logic producing suspicious sign-ins ...
| project
    TimeGenerated,
    UserPrincipalName,
    IPAddress,
    tostring(LocationDetails.countryOrRegion),
    AppDisplayName,
    RiskLevelDuringSignIn
// Add entity mapping for Sentinel incident creation:
| extend
    AccountUPNSuffix = tostring(split(UserPrincipalName, "@")[1]),
    AccountName = tostring(split(UserPrincipalName, "@")[0])
// Map: Account entity → UserPrincipalName
// Map: IP entity → IPAddress
// These mappings enable automatic entity linking in incidents
// Exclusions from hunt [ID] analysis:
| where IPAddress !in (knownVPNIPs)
// Exclude corporate VPN egress IPs — hunt analysis confirmed
// these produce false positives for travel users
| where UserPrincipalName !in (excludedServiceAccounts)
// Exclude service accounts with known multi-IP auth patterns
Expand for Deeper Context

The hunting workflow compresses this cycle. The hunter already ran the query against real data. The results that were legitimate are known — the hunter analyzed them, enriched them, and documented them. The exclusions needed to avoid those false positives are known from the hunt analysis. The detection rule can be deployed with informed thresholds and exclusions from day one.

What changes between a hunt query and a detection rule

The hunt query and the detection rule share the same core KQL logic. But several parameters must be adapted for scheduled, unattended execution.

Time window. The hunt query typically examined a 30-day window. The detection rule runs on a schedule — every 5 minutes, every hour, every 24 hours. The rule's lookback window must match the frequency: a rule running every hour should look back 1–2 hours (with overlap to avoid gaps), not 30 days. The baseline computation (if the rule uses behavioral comparison) may need a separate logic flow — either computing the baseline on each run (expensive) or using a saved function or watchlist for the baseline.

Thresholds. The hunt query may have returned all users with new IPs. The detection rule needs a threshold that separates "worth alerting on" from "noise." The hunt analysis tells you what this threshold should be. If the hunt found that users with new IP + new country produced 28 results, of which 25 were VPN changes and 3 were suspicious, a rule that alerts on new IP + new country + a second indicator (MFA registration, inbox rule, or elevated risk score) will produce 3 alerts instead of 28. The hunt data provides the precision the rule needs.

Entity mapping. Sentinel analytics rules should map entities — account, IP, host, URL — so that incidents automatically link to the correct entity in the Defender XDR entity pages. The hunt query may not have explicit entity mapping because the hunter was working interactively. Add extend statements that map fields to Sentinel entity types:

Alert grouping. Multiple detections for the same user within a time window should group into a single incident rather than creating separate incidents. Configure the analytics rule with entity-based alert grouping on the account entity, with a grouping window that matches the technique's expected activity pattern (4–24 hours for most authentication-based detections).

Severity. The hunt analysis tells you the severity. A rule that fires on 3+ correlated indicators is high severity. A rule that fires on a single indicator requiring enrichment is medium or informational. Match the rule's severity to the confidence model from TH1.4.

The conversion workflow

Step 1: Extract the core query. From the hunt query chain, identify the query (or combination of queries) that most cleanly identifies the technique. This is usually the step 2 or step 3 query from TH1.3 — the indicator or enrichment query that narrowed to suspicious results.

Step 2: Adapt the time window. Replace the hunt's ago(30d) with the detection rule's lookback window. If the rule runs every hour, use ago(1h30m) — the extra 30 minutes provides overlap to avoid timing gaps.

Step 3: Add exclusions. From the hunt analysis, the analyst identified legitimate patterns that produced false positives: known VPN IP ranges, specific user groups who legitimately travel, service accounts with expected high-volume authentication patterns. Add these as explicit exclusions with comments explaining why each exclusion exists:

Step 4: Add entity mapping and severity. Map account, IP, and other entities. Set severity based on the confidence model.

Step 5: Deploy through detection engineering process. If your organization uses detection-as-code (PR-based deployment from SOC Operations Module S2), submit the rule as a pull request with the hunt ID in the description. If deployment is manual, create the analytics rule in the Sentinel portal with a naming convention that traces back to the hunt: HUNT-TH4-001: Authentication from IP not in 30-day baseline with MFA registration.

Step 6: Monitor for 14 days. Even with hunt-informed tuning, the first 14 days of production execution may reveal edge cases the hunt did not encounter. Monitor the rule's alert volume and false positive rate. Tune if needed.

What to do when the query is too complex for a scheduled rule

Some hunt queries — particularly those using behavioral baselines with make-series or multi-table joins across large time windows — may exceed the execution constraints of a scheduled analytics rule (query timeout, row limits, compute quota). Three options:

Simplify the rule, keep the hunt. Deploy a simpler version of the rule that catches the most obvious variants of the technique, and continue hunting periodically for the subtle variants the simplified rule misses. The rule handles the base case; hunting handles the edge cases.

Use a Sentinel function or watchlist for baselines. Pre-compute the baseline in a saved function that runs daily, storing results in a watchlist. The detection rule joins against the watchlist rather than computing the baseline on every run. This separates the expensive baseline computation from the real-time detection query.

Deploy as a Sentinel hunting query rather than an analytics rule. Sentinel's built-in hunting queries run on-demand or on a schedule via hunting bookmarks. They do not create incidents automatically but flag results for analyst review. This is a middle ground between manual hunting and full automated detection — the query runs without human intervention, but the results require human analysis.

HUNT QUERY → DETECTION RULE CONVERSION HUNT QUERY 30-day window Manual, interactive ADAPTATION Time window → schedule-matched lookback Thresholds → hunt-informed, data-backed Exclusions → from hunt false positive analysis Entity mapping + severity + alert grouping DETECTION RULE 1-hour lookback, automated Permanent, 24/7 coverage What you hunted today, you detect automatically tomorrow. The technique moves from the known-unknown layer to the known-known layer permanently.

Figure TH1.6 — Hunt query to detection rule conversion. The core KQL logic is preserved. Time window, thresholds, exclusions, and entity mapping are adapted for unattended scheduled execution.

Try it yourself

Exercise: Convert a hunt query to a detection rule

Take the step 2 query from the TH1.3 exercise (new IP baseline comparison). Adapt it for a Sentinel analytics rule:

1. Time window: Change from ago(30d) to ago(1h30m) for the detection window. Keep the baseline at ago(37d) to ago(7d) — or move the baseline to a watchlist if the computation is too expensive.

2. Threshold: Based on your hunt results, how many new-IP sign-ins per user in a 1-hour window would warrant an alert? Add a `where` clause filtering to only users exceeding that threshold.

3. Exclusions: From your hunt analysis, which IPs or users produced false positives? Add explicit exclusions.

4. Entity mapping: Add AccountName and AccountUPNSuffix extensions for Sentinel entity mapping.

5. Deploy: Create the analytics rule in your Sentinel workspace in report-only mode for 14 days. Monitor false positive rate before enabling alert creation.

This rule is the tangible output of your hunting exercise — a permanent detection that did not exist before the hunt.

⚠ Compliance Myth: "The hunt query can be deployed as a detection rule without modification"

The myth: The query worked in the hunt, so it will work as a scheduled rule. Just copy-paste it into an analytics rule and enable it.

The reality: Hunt queries and detection rules have different execution contexts. A hunt query runs interactively with a 30-day window and human review of results. A detection rule runs unattended every hour and creates incidents automatically. Without adapting the time window, thresholds, exclusions, and entity mapping, the rule will either fire on every legitimate event (creating hundreds of false-positive incidents) or time out on execution (producing no alerts at all). The conversion step is mandatory. It is also fast — 30–60 minutes — because the hunt already did the analytical work that normally takes days of tuning.

Extend this workflow

If your organization uses detection-as-code — storing analytics rules in a Git repository and deploying through CI/CD (covered in SOC Operations Module S2) — the hunt-to-detection conversion integrates naturally. The converted rule is submitted as a pull request with the hunt ID in the commit message, linking the detection rule permanently to the hunt that produced it. The PR description includes the hunt hypothesis, the false positive analysis, and the threshold justification. This traceability means any future question about why the rule exists, why the threshold is set at that level, or why specific exclusions are configured can be answered by reading the linked hunt record. Without detection-as-code, maintain this traceability through consistent naming: prefix hunt-derived rules with HUNT- followed by the campaign and sequence number.

📋 Operational Artifact — Detection Rule Conversion Checklist

Converting Hunt [ID] Query [#] to Analytics Rule

☐ Core KQL extracted from hunt query chain

☐ Time window adapted: lookback = [frequency × 1.5]

☐ Thresholds set from hunt analysis: [threshold value, justification]

☐ Exclusions added from hunt false positive analysis: [list]

☐ Entity mapping configured: Account, IP, Host, URL as applicable

☐ Severity set: [H/M/L/Info] based on confidence model

☐ Alert grouping: entity-based, [N]-hour window

☐ Rule naming: HUNT-[campaign]-[sequence]: [description]

☐ ATT&CK technique mapped in rule metadata

☐ Deployed in report-only for 14-day validation

☐ False positive rate reviewed after 14 days

☐ Promoted to production / tuned further

References Used in This Subsection

Decision point

Your hunt found a confirmed threat. The finding should become a detection rule. Do you build the rule yourself or hand it to the detection engineering team?

Hand it to the detection engineering team with a complete handoff: the KQL query, the entity mapping, the expected FP patterns you observed during the hunt, the severity recommendation, and the suggested response action. The hunter's expertise is in hypothesis generation and data exploration. The detection engineer's expertise is in rule optimization, FP management, and production deployment. The handoff template ensures the detection engineer has everything they need to build a production-quality rule without re-investigating the finding.

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.
© 2026 Ridgeline Cyber Defence™ Ltd. Content may not be reproduced or redistributed. Worked artifacts may be adapted for use within your organization.

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 →