2.5.1. Custom Detection Rules in Defender XDR

💡 First Principle: A custom detection is an advanced hunting query promoted to a schedule. Because it runs inside Defender XDR, it can do something a SIEM rule can't do natively: take response actions on the very devices, users, files, and emails it finds, the moment it finds them.

You create one in two ways: run a query in advanced hunting and select Create detection rule, or start from the custom detections list. The wizard then asks for alert details, enrichment, actions, and scope. Microsoft recommends that the query return specific columns, and entity mapping and response actions depend on them:

• Timestamp (or TimeGenerated for Sentinel data) to time-stamp the alert.
• For Defender for Endpoint tables, DeviceId and ReportId from the same event; for other Defender tables, Timestamp and ReportId.
• At least one strong entity identifier for automatic mapping, such as DeviceId, AccountObjectId, AccountSid, AccountUpn, or RecipientEmailAddress.

Don't filter on Timestamp to limit the window; the service applies the lookback for you. Aggregations should keep the identifying columns, commonly with arg_max(Timestamp, ReportId).

Frequency sets both cadence and default lookback:

Continuous frequency requires a simple query: one supported table, no joins or unions, and generally available columns only. When first saved, a rule checks the past 30 days of data. Each run creates at most 150 alerts.

Alert details include a unique name, title and description (which can reference up to three result columns as {{ColumnName}}), severity, category, and MITRE ATT&CK techniques. Enrichment maps entities (automatic for Defender data, manual for Sentinel data) and adds up to 20 custom details. Actions are what make custom detections distinctive: on devices, isolate, collect an investigation package, run an antivirus scan, start an automated investigation, or restrict app execution; on files, allow or block, or quarantine; on users, mark as compromised (raising Entra ID user risk to high), disable, or reset authentication; on email, move to a folder or soft- or hard-delete. Scope limits device-based checks to selected device groups.

Managing rules happens on the custom detections page: edit (changes take effect at the next run), turn off, run on demand, and review each rule's run history and triggered alerts. Permissions follow the data: Security Administrator or Security Operator (with manage security settings) for Defender data, and Sentinel Contributor for Sentinel data. Microsoft now recommends custom detections as the primary way to build new rules across both Defender XDR and Sentinel data.

⚠️ Exam Trap: "Automatically isolate any device where this hunting query finds a match" is a custom detection rule with the Isolate device action, not a Sentinel analytics rule (which would need a playbook) and not a saved hunting query (which doesn't run on a schedule).

Reflection Question: A detection query summarizes events by DeviceId and returns only DeviceId and a count. Why can't it be saved as a custom detection rule that isolates devices, and how would you rewrite the summarize line to fix it?