Custom Detection Rules in Defender XDR

What it is

Built in detections cannot know your environment. A custom detection rule in Microsoft Defender XDR turns a hunting query into a rule that runs on a schedule, raises alerts when the query returns results, and can take response actions automatically. It is the main way a detection engineer creates detections for Defender data such as devices, email, identities and cloud apps.

How it works

Creating a rule

The usual process has four steps, which also appear as a wizard in the portal.

1. Build and tune the query in advanced hunting, until it returns the results you want.
2. Select Create detection rule from the query editor.
3. Enter the rule details: the name, how often it runs, and the alert details, such as title, severity, category and the MITRE techniques.
4. Choose the response actions and the scope, then save the rule.

Query requirements

For a query to work as a custom detection it must return certain columns so the alert can be tied to events and entities.

• A Timestamp column.
• A ReportId column, which identifies the event.
• Columns that identify the affected entity, such as DeviceId (or a similar device column), a user or mailbox column, or the identifiers needed for the actions you want.

Using arg_max(Timestamp, ReportId) in a summarised query is a common way to keep the latest event for each entity while preserving the required columns. A rule can also map extra columns to the alert, so analysts see useful details.

Run frequency

How often the rule runs depends on the frequency you choose.

The least frequent run is every 24 hours, so a one day time filter covers all new data for that frequency. Choose the frequency that fits how fast you must detect. A detection that needs a join between two tables, for example network events joined to process events, must use a scheduled frequency and cannot be continuous. If an hour of delay is acceptable, running every hour and keeping the join in one rule is the right answer, and splitting it into two single table continuous rules would not be able to correlate the events.

Alert details and grouping

Each rule defines the alert that it creates: the title, description, severity, category, MITRE ATT&CK techniques and recommended actions. You can use dynamic fields from the query results in the title and description. Alerts from a custom detection join Defender XDR's incident correlation, so related alerts are grouped into one incident.

Response actions

A rule can take automatic actions on the entities it finds. They depend on the kind of entity.

For a custom detection that matches the messages of a phishing campaign, the available automatic actions on the messages are soft delete, hard delete or move. Isolating a device, collecting a package or marking a user as compromised act on devices or users and not on the messages themselves.

Scope

The scope decides which devices the rule applies to. You can run it on all devices or only on selected device groups. If you have configured Microsoft Sentinel scoping, include the SentinelScope column in the query so alerts are visible to scoped analysts.

Managing rules

In Custom detection rules you can view every rule, with its last run, status and the number of alerts. You can:

• Edit the query, frequency, actions or scope.
• Turn a rule on or off without deleting it.
• Run it now to test.
• Delete a rule that is no longer needed.

A rule that fails repeatedly shows an error and may be switched off automatically, so check the status after changing a query. Use clear names and tags so you know who owns each rule, and review noisy rules regularly. Tuning options, such as an exclusion in the query, remove false positives without disabling the whole rule.

Defender XDR custom detections compared with Sentinel analytics rules

When Sentinel is onboarded to the Defender portal, advanced hunting can query both sets of tables, so one KQL query can join Defender tables with Sentinel tables.

A worked scenario

A hunter finds a pattern of process creation followed by outbound connections to rare destinations, which suggests beaconing. The query joins DeviceNetworkEvents to DeviceProcessEvents, so continuous frequency is not possible. The team accepts a delay of an hour, so the rule is set to run every hour. The query keeps the latest event per device with arg_max so it returns Timestamp, ReportId and DeviceId. The rule raises a high severity alert mapped to a command and control technique, and its action isolates the device. It is scoped to servers only, and an analyst later adds an exclusion for a known monitoring tool.