TH1.6 Converting Hunts to Detection Rules

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.

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:

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

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

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 authentication anomalies. Add these as explicit exclusions with comments explaining why each exclusion exists:

1
2
3
4
5
6

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

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.

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.

References Used in This Subsection

• Microsoft. “Create Custom Analytics Rules in Microsoft Sentinel.” Microsoft Learn. https://learn.microsoft.com/en-us/azure/sentinel/detect-threats-custom
• Microsoft. “Map Data Fields to Entities in Microsoft Sentinel.” Microsoft Learn. https://learn.microsoft.com/en-us/azure/sentinel/map-data-fields-to-entities
• Course cross-references: SOC Operations S2 (detection-as-code pipeline), TH1.4 (confidence model for severity assignment)