SC-200 Configure Detections: Defender XDR Custom Detections, Sentinel Analytics Rules, MITRE ATT&CK and Anomalies

Build a Microsoft Defender XDR custom detection when the logic is an advanced hunting query you want to run on a schedule or continuously, and a Microsoft Sentinel analytics rule when you need a Sentinel rule type such as scheduled, NRT, threat intelligence matching, machine learning or anomalies. With Sentinel onboarded to the Defender portal, both live side by side, and Microsoft now recommends custom detections for new rules that query Sentinel and Defender XDR data alike. Analytics rules remain fully supported and are what you use for Sentinel-specific features.

Scope guard: what happens after an alert exists belongs to other topics. Alert correlation and incident merging are covered with Defender XDR configuration, automation rules and playbooks in the Sentinel automation lesson, SOC optimization recommendations with the Sentinel platform lesson, and getting threat indicators into the workspace with the ingestion lessons.

A custom detection query must return a time column and the columns that identify the event and its entities: Timestamp (or TimeGenerated) always, and for Defender for Endpoint tables also DeviceId and ReportId. Timestamp sets the alert time. DeviceId and ReportId tie the alert to one event on one device, which is how the alert gets the correct device group scope and how the portal builds the process tree. Columns that only describe what happened don't identify which event it was, so they can't stand in for these.

Aggregations are the classic trap. A plain summarize count() by DeviceId keeps DeviceId but drops Timestamp and ReportId, so alerts arrive without a proper scope or process tree. Use arg_max to keep the identifying columns of one representative event, usually the most recent:

DeviceEvents
| where ActionType == "AntivirusDetection"
| summarize (Timestamp, ReportId)=arg_max(Timestamp, ReportId),
    count() by DeviceId
| where count_ > 5

Other entity types need their own identifiers if you want the rule to act on them, which the next sections cover. Write and test the query in Advanced hunting first, then choose Create detection rule from the query editor; alternatively, + Create detection rule on the Custom detection rules page opens the same wizard directly.

For Defender XDR data, each fixed frequency has a fixed lookback you cannot change; only rules based solely on Sentinel data can use a Custom frequency with its own interval. The rule ignores any wider time filter in your query, so pick the frequency whose lookback covers the window your logic needs.

With Custom, Run query every (5 minutes to 14 days) and the lookback are two separate settings, and the longest lookback allowed depends on the frequency: a rule that runs more often than hourly is limited to under 48 hours of data, while slower rules can look back much further (up to 30 days). So a query that needs the past three days of Defender data must use the 24-hour frequency, because 12 hours only looks back 48 hours. A rule that must run every 10 minutes is possible only when every table it queries is Sentinel data, through Custom.

Custom detections evaluate data by ingestion_time() and automatically deduplicate events when the lookback is longer than the frequency, so overlapping windows don't produce repeat alerts the way they can in a Sentinel scheduled rule (see ingestion delay below).

Continuous (NRT) custom detections

Continuous (NRT) runs the rule as matching events arrive, but only for a query on a single supported table using supported operators. Joins, unions and externaldata are not allowed, and neither are comments in the query. Supported tables include the main Defender XDR event tables (for example DeviceProcessEvents, DeviceRegistryEvents, DeviceFileEvents, EmailEvents) and Sentinel tables such as SigninLogs and CommonSecurityLog; check the current list on Microsoft Learn. When a query needs two tables, the usual fix is one continuous rule per table with the same filter. A watchlist join, by contrast, can't be split that way, so that logic stays on a scheduled frequency.

Continuous custom detections are not counted against the 50-rule cap on Sentinel NRT analytics rules, so they are the way to add another near-real-time detection on a supported Sentinel table when that cap is reached.

A custom detection can act automatically on the devices, files, users or emails its query returns, but each action appears only when the query outputs the column that identifies that entity.

Email actions need both columns because one message can reach many recipients: NetworkMessageId identifies the message and RecipientEmailAddress the mailbox copy to act on. Only that exact pair enables them.

Reset user authentication forces an on-premises identity to change its password at next sign-in and makes a Microsoft Entra identity sign in again.

Isolate device vs Restrict app execution

The two strongest device actions contain a threat in different ways. Isolate device cuts the device off from network applications and services while keeping its connection to Defender for Endpoint, so analysts can still run actions through the service. Restrict app execution leaves networking alone and allows only files signed with a Microsoft-issued certificate to run. Choose isolation when spread must stop; choose restriction when the device has to stay reachable on the network but no unsigned code may run.

Alert details: dynamic titles, custom details, entities and MITRE tags

The alert details step lets a custom detection put query values into the alert itself: column values in the title and description, up to 20 custom details, mapped entities and MITRE ATT&CK tactics and techniques.

• Dynamic title and description. Reference a result column by surrounding its name with double curly brackets, for example {{AccountName}}. Each field can reference up to three columns. Other bracket styles are kept as literal text.
• Custom details. Up to 20 key-value pairs per rule, surfaced on the alert. Their combined size is limited to 4 KB per alert; if an alert exceeds it, the whole custom details array is dropped from that alert rather than truncated. Long values such as command lines are the usual cause, so shorten them in the query (for example with substring()).
• Entity mapping. Tell the rule which columns hold impacted assets (devices, users, mailboxes) and related evidence, which drives correlation and the incident graph.
• Tactics and techniques. Tag the rule with the ATT&CK techniques it detects so coverage reporting is accurate.

To create or edit custom detections you need a role that allows managing security settings plus permissions for the data and devices the rule covers.

• In Defender XDR unified RBAC, the Security settings (manage) permission; or the Microsoft Entra Security Administrator role.
• The Microsoft Entra Security Operator role is enough only while Defender for Endpoint RBAC is turned off. With MDE RBAC on, the operator also needs the Manage security settings permission in the user's Defender for Endpoint role. Adding that one permission is the least-privilege fix; Security Administrator also works but grants much more.
• For rules on Sentinel data, Microsoft Sentinel Contributor on the workspace (or the unified RBAC equivalent). It does not cover Defender device data.
• Device scope. You choose whether a rule covers all devices or specific device groups, and you can only create or edit a rule for devices you have permission for. A rule scoped to all devices can be edited only by someone whose permissions cover every device group; someone whose role covers only some groups can't edit it until their role is widened.

Lifecycle on the Custom detection rules page

Each rule's page lists its triggered alerts and the actions it took. A custom detection generates at most 150 alerts per run. Results beyond that cap get no alert, so a rule that regularly reaches it is matching too broadly and should be tuned to match fewer, more meaningful results.

A Sentinel scheduled rule runs its KQL query on an interval (Run query every) over a window (Lookup data from the last), both from 5 minutes to 14 days, and the lookback must be at least as long as the interval. The interval answers "how often", the lookback "how much data". An hourly check over two days of data is every 1 hour, look up 2 days. The lookback bounds the data the rule evaluates: only records whose TimeGenerated falls inside it are seen, so where TimeGenerated > ago(3d) in a rule with a 15-minute lookback still sees 15 minutes. Start running is either Automatically (when saved) or, in preview, At specific time, a first run between 10 minutes and 30 days after creation.

• Alert threshold decides whether a run raises an alert, based on the number of query results (for example, greater than 0).
• Event grouping: Group all events into a single alert (the default) makes one alert per run summarizing every result row; Trigger an alert for each event makes one alert per row. Shape the query so each row is the unit you want analysts to triage, such as one user.
• Suppression: Stop running query after alert is generated pauses the rule for a period you set, up to 24 hours, then it resumes automatically. Use it when a rule keeps firing on an ongoing condition that responders already have in hand.

Entity mapping, custom details and alert details work as they do for custom detections; grouping alerts into incidents is a separate incident setting covered elsewhere and doesn't split or pause alerts.

Ingestion delay

Events can reach the workspace minutes or hours after they happen, and a late event can fall outside every run's TimeGenerated window. Microsoft's pattern: extend the lookback by the delay, then filter on ingestion_time() for the original interval so overlapping windows don't produce duplicates. For example, a 30-minute rule on a source that can arrive up to 10 minutes late:

// Run query every: 30 minutes
// Lookup data from the last: 40 minutes
Syslog
| where ingestion_time() > ago(30m)
| where Facility == "authpriv"

Extending the lookback alone creates duplicates; filtering on TimeGenerated instead of ingestion time doesn't fix the gap.

A near-real-time (NRT) analytics rule runs once every minute over the events ingested in the previous minute, keeping most scheduled-rule features: entity mapping, custom details, alert details and automation. It queries by ingestion time rather than TimeGenerated, with a built-in delay of about two minutes so late-arriving data within that period is still caught.

NRT rules work properly only for log sources with an ingestion delay of less than 12 hours. A source that routinely arrives a day or more late gains nothing from NRT; a scheduled rule whose lookback spans the delay, with an ingestion_time() filter, is the reliable choice. When the 50-rule NRT cap is reached, a Continuous (NRT) custom detection on a supported table is the near-real-time alternative.

Use the Microsoft Defender Threat Intelligence Analytics rule (Learn also calls it Microsoft Threat Intelligence Analytics, or matching analytics) to match your logs against Microsoft's own indicators with no query to write, and the TI map templates to match indicators you have imported yourself with a query you can edit.

Machine learning rule types

• ML Behavior Analytics rules (in preview) apply Microsoft-trained, proprietary models to sign-in data: anomalous SSH logins from Linux Syslog and anomalous RDP logins from Windows security events. You enable them; they can't be customized.
• Advanced multistage attack detection (Fusion) is a correlation engine that links low-fidelity alerts and anomalies into high-fidelity multistage incidents.
• Anomaly rules use configurable machine learning but produce anomalies, not alerts (next section).

Defender portal onboarding changes the rule list. When a Sentinel workspace is onboarded to the Defender portal (or Defender XDR incident integration is turned on), Microsoft security incident-creation rules and the Fusion rule are not available (existing Microsoft security rules are disabled automatically): Defender XDR's own correlation creates incidents instead. Scheduled, NRT, threat intelligence, ML Behavior Analytics and anomaly rules keep running. Microsoft plans to retire Sentinel in the Azure portal after 31 March 2027, so expect Defender-portal wording.

Sentinel's MITRE ATT&CK page (Microsoft Sentinel > Threat management > MITRE ATT&CK in the Defender portal; Threat management in the Azure portal, in preview) shows how many active detections cover each ATT&CK technique and how coverage would change if more were enabled.

• Active coverage counts enabled scheduled and NRT rules by default, under the tactics and techniques configured on each rule.
• Simulated coverage: the Simulated rules menu adds detections that are available but not configured, such as rule templates, so you can see the gaps enabling them would close. It shows possibility, not active protection.
• The page reads each rule's MITRE ATT&CK field on its general settings. A rule that alerts correctly but has no technique selected adds nothing to the matrix; the fix is to edit the rule and select the tactic and technique (for example Persistence / Scheduled Task/Job). Only that field on the rule itself feeds the matrix.

SOC optimization recommendations also suggest coverage improvements, but they are covered with the Sentinel platform lesson; the ATT&CK page is the technique-by-technique view.

Anomaly rules are built-in machine learning detections whose results are written to the Anomalies table; they never raise alerts or create incidents by themselves. You use anomalies as context in hunting and investigation, or as input to your own analytics rules.

• Built-in rules can't be edited or deleted. Their Edit option only switches the rule between Production and Flighting (test) mode.
• To tune one, duplicate it. The copy is named with " - Customized", starts disabled and in Flighting, and its parameters and threshold can be changed. Run it alongside the original and compare results.
• One customized copy per built-in rule. You can't create a second.
• Only one version runs in Production. Switching the customized copy to Production automatically switches the original to Flighting.
• Comparing versions. Anomalies from both versions carry the original rule's ID as AnomalyTemplateId, so you can query them side by side in the Anomalies table.