Custom Detection Rules in Defender XDR

Custom detection rules in Microsoft Defender XDR are user-defined KQL queries that run periodically against security data from across the Microsoft 365 ecosystem. They exist because built-in detections cannot cover every organization's unique threat landscape—specific software, custom applications, or internal policies require tailored detection logic. For example, you might want to detect when a non-admin user creates a new Azure AD role assignment, which is not covered by default rules.

Each custom detection rule is essentially a scheduled query. The Microsoft 365 Defender backend uses a scheduler to run these queries at defined intervals (every 1, 6, 12, or 24 hours). The query executes against the Advanced Hunting schema, which includes tables like DeviceProcessEvents, EmailEvents, IdentityLogonEvents, and AlertInfo. When the query returns results (i.e., rows of data), the detection engine evaluates whether the number of results exceeds a specified threshold. If it does, an alert is generated, and optionally, an automated action (playbook) can be triggered.

To create a custom detection rule: 1. Navigate to Microsoft 365 Defender > Hunting > Custom detection rules. 2. Click + Create. 3. Provide a name and description. 4. Write the KQL query in the editor. Example:

DeviceProcessEvents
| where Timestamp > ago(1h)
| where FileName == "powershell.exe" and ProcessCommandLine contains "-EncodedCommand"
| project Timestamp, AlertTitle="Suspicious PowerShell", Severity="High", Category="Malware", Recommendation="Investigate this device", EntityType="Machine", EntityId=DeviceId, EntityName=DeviceName, EntityRole="", EntitySubType=""

To verify the rule is running: Check the Custom detection rules page—the rule status should show Active. You can also use Advanced Hunting to query AlertInfo for alerts generated by your rule:

AlertInfo
| where Title contains "YourRuleName"

Custom detection rules integrate with: - Advanced Hunting: The underlying data source. The query language is KQL, and the schema is identical to Advanced Hunting. - Incidents and Alerts: Alerts generated by custom rules appear in the Incidents queue, linked to entities (users, devices). They can be triaged and managed like built-in alerts. - Automated Investigation and Response (AIR): Custom rules can trigger automated playbooks (e.g., isolate a device, disable a user account). This is configured in the rule's Actions tab. - Microsoft Sentinel: Custom detection rules can be exported to Sentinel as analytics rules, though the KQL syntax may need adjustment. - Microsoft Graph Security API: Alerts from custom rules are accessible via the API for integration with SIEMs.

The SC-200 exam expects you to:

A large financial institution wants to detect when any employee runs PowerShell with an encoded command, which is a common technique for malware execution. The SOC team creates a custom detection rule using DeviceProcessEvents. The query filters for FileName == "powershell.exe" and ProcessCommandLine contains "-EncodedCommand". The rule is set to run every 1 hour with a threshold of 1. Suppression is set to 1 hour to avoid duplicate alerts for the same device. In production, this rule generates about 50 alerts per day, but many are false positives from IT admins. The team tunes the query by excluding certain admin accounts using a join with IdentityInfo. The rule is integrated with a playbook that automatically isolates the device if the alert severity is High. Performance is manageable because the query uses a time filter and an indexed column (FileName).

A government agency needs to detect when a non-admin user adds a member to the Global Administrator role in Azure AD. The SOC creates a custom detection rule using CloudAppEvents. The query filters for ActivityType == "Add member to role" and targets the Global Administrator role. The rule runs every 6 hours (since role changes are less frequent). The threshold is 1, but suppression is set to 24 hours to avoid alerting on the same change multiple times. In production, this rule catches a malicious insider who added a backdoor account. The rule is configured to trigger a playbook that disables the new admin account and sends an email to the SOC. One challenge is that the query must exclude legitimate changes made by authorized admins—this is done by joining with a custom table of approved admin accounts.

Custom detection rules are designed for moderate scale. An organization with 10,000 devices running 20 custom rules at 1-hour frequency will have 20 queries per hour, each scanning the last hour's data. This is well within Microsoft's backend capacity. However, if you have 200 rules at 1-hour frequency, you may experience throttling. Microsoft recommends using Microsoft Sentinel for high-volume or complex detections.