In most tenants I work with, the built-in rules in Microsoft Defender XDR give you a decent baseline, but they rarely catch everything that actually matters. Every organization has its own attack patterns, risky tools or insider threats that the standard detections just don't cover. Custom detection rules fill that gap. You take a KQL hunting query that has proven itself and turn it into an automated detection and response rule that fires on fresh data without anyone reviewing it manually. Getting from a one-off hunting query to a detection rule you can trust in production has a few gotchas, though, and you should know them up front.

A detection rule always starts as an advanced hunting query

In practice I always begin in the Microsoft Defender portal → Hunting → Advanced hunting. First you build a KQL query that pinpoints the suspicious activity as precisely as you can while keeping false positives low. The query must return at least the columns Timestamp, ReportId and a key entity such as DeviceId or AccountObjectId. If any of these are missing, the wizard won't let you continue.

Here's an example I come across a lot: suspicious child processes started by Office macros. You can run this query against the DeviceProcessEvents table (you need Defender for Endpoint P1/P2 and Security Administrator or unified RBAC permissions):

DeviceProcessEvents
| where InitiatingProcessFileName =~ "WINWORD.EXE"
| where FileName has_any ("certutil.exe", "mshta.exe", "powershell.exe")
| project Timestamp, DeviceId, ReportId, FileName, InitiatingProcessCommandLine

Paste it into Microsoft Defender portal → Hunting → Advanced hunting and test it. When you're happy with the results, click Create detection rule right from the results view. That opens the rule wizard, which checks for the required columns, and you can only move on once they're all there.

The rule configuration sets frequency, trigger behavior and automated actions

The next step is scheduling. You decide how often the rule runs (anywhere from every 5 minutes to every 24 hours), whether it triggers per event or in aggregate, and which automated actions, if any, you attach. From experience, I always start production rules as alert-only and add automation such as device isolation or disabling a user only after a learning phase. Aggressive actions tied to a noisy rule can cause real trouble, and sometimes worse than that.

One mistake I see often is a rule that's far too broad, for example one that fires on every Powershell.exe launch. Keep your query as specific as you can, otherwise your analysts drown in alerts. For the available options and limitations, read the Custom Detection Rules documentation and the overview of custom detections carefully. Watch the entity you select in particular. If you leave out DeviceId, device-based automations won't be available.

Practical tip: Before a rule goes to production, scope it to a test group (high-value endpoints or IT users, for instance) and watch the alerts closely so you can adjust the thresholds.

Tuning cuts the noise so the relevant alerts stand out

Custom detection rules can do a lot, but without care they get noisy. In the beginning, most rules produce more alerts than you'd expect. Tighten the query with additional filters (limiting it to specific command lines, say) or use alert suppression in the rule wizard. Suppression can, for example, mute duplicate alerts per device for an hour, which helps enormously with rules that cover a lot of ground.

To keep improving my rules, I review the alerts in Defender and run targeted queries in advanced hunting to find patterns in the false positives.

All your rules sit together in the Defender portal

You'll find every rule under Hunting → Custom detection rules in the Defender portal. That page shows each rule's status, its recent alert count and whether it needs tuning. You can disable, clone or edit rules in place, so there's no need to start over. In larger organizations I consider a naming standard and a short write-up for each rule mandatory, so the team knows what a detection covers when a real incident hits.

The diagram below shows how a hunting query becomes an automated response through a custom detection rule. Follow the arrows to see the flow:

flowchart TD
    A["Advanced hunting query"] --> B["Create detection rule"]
    B --> C["Rule configuration"]
    C --> D["Rule evaluates data"]
    D --> E["Alert generated"]
    E --> F["Automated response (optional)"]

Figure: Flow from advanced hunting query to automated response in Defender XDR

I recommend custom detections, but only with careful tuning

For building detection that adapts to your environment in Microsoft 365 and Azure, custom detection rules are one of the most effective tools you have. They pair the flexibility of KQL with automated action, and that pays off if you're willing to spend time on tuning and ongoing maintenance. Combined with unified incidents and automation, they let you build threat detection that matches the risks your organization actually faces. My advice is to run a handful of well-tuned rules rather than a long list of noisy ones, and to keep checking what they mean in practice for your SOC team.