DE1.5 NRT Rules and Defender XDR Custom Detections

Section 1.1 introduced NRT rules and their architectural constraints. This section teaches both NRT and Defender XDR custom detections at the depth you need to decide when each is the right tool — and how both complement the scheduled rules that form the foundation of your detection program.

Estimated time: 45 minutes.

NRT rules in depth

Section 1.1 covered the NRT architecture: hardcoded 1-minute frequency, 2-minute execution delay, ingestion_time() instead of TimeGenerated, no join/let/union/summarize. This section teaches the design decisions you make when choosing NRT for a specific detection.

The latency decision

The question is not "would faster detection be nice?" — it always would. The question is: does the attacker complete a critical action in the time between scheduled rule executions? If the answer is yes, NRT is necessary. If the answer is no, scheduled is sufficient and gives you the full KQL language.

Detections that typically warrant NRT:

Ransomware pre-encryption indicators. Shadow copy deletion (vssadmin delete shadows), boot configuration tampering (bcdedit /set {default} recoveryenabled No), mass file renames with ransomware extensions, Windows Defender real-time protection disabled. These events precede encryption by seconds to minutes. The detection value drops to near zero once encryption starts — you needed the alert before the encryption, not after.

Credential dumping. LSASS memory access by an unauthorized process, SAM database extraction, DCSync replication requests. Once the attacker has the credential material, the detection still matters for containment but the window for prevention has closed.

Active C2 beaconing to confirmed infrastructure. When your threat intelligence identifies a specific C2 domain or IP as actively used in a campaign targeting your industry, the first beacon is the signal. Waiting 5 minutes means the attacker has established the channel and potentially received instructions.

Security tool tampering. Defender service stops, Sysmon uninstalls, event log clearing. The attacker is actively degrading your visibility. Detecting this in 2 minutes means you can restore the tool before the attacker completes their objective under reduced coverage.

What the query restrictions mean in practice

NRT rules can't use join, let, union, or summarize. This isn't a temporary limitation — it's an architectural constraint. NRT rules execute against the events ingested in the preceding minute. Cross-table joins and aggregations require scanning data across longer time windows, which is incompatible with the 1-minute execution model.

In practice, this means NRT rules detect specific events, not patterns. A scheduled rule detects "5 failed logins followed by a success" (a pattern requiring summarize). An NRT rule detects "vssadmin.exe executed delete shadows" (a specific event requiring only where filters). The detection hypothesis determines which rule type is appropriate.

How NRT handles time differently

Understanding the ingestion_time() vs TimeGenerated distinction is critical for designing NRT rules correctly. A scheduled rule uses TimeGenerated — when the event occurred at the source. If an event was generated at 10:00:00 but ingested at 10:02:30, a scheduled rule with a lookback including 10:00:00 captures it. An NRT rule uses ingestion_time() — it only sees events that were ingested in the preceding minute. The same event generated at 10:00:00 and ingested at 10:02:30 would be picked up by the NRT execution at 10:03 (which looks at events ingested between 10:02 and 10:03).

This is why NRT rules have a 2-minute built-in delay instead of the 5-minute delay for scheduled rules. The ingestion-time approach already accounts for source-to-workspace latency because it queries on arrival time, not generation time. The 2-minute buffer handles internal processing overhead within the Sentinel pipeline itself.

The practical implication: NRT rules work well on data sources with fast ingestion (Defender for Endpoint, most M365 connectors — typically under 2 minutes). They work poorly on data sources with slow ingestion (some third-party syslog connectors, cloud app telemetry during peak load). Microsoft documents that NRT rules should only be used on log sources with less than 12 hours of ingestion delay, but in reality, if your data source has more than 5 minutes of latency, NRT provides no meaningful advantage over a 5-minute scheduled rule.

Here is the NRT shadow copy deletion rule with the full configuration context:

// NRT rule — shadow copy deletion
// Detects vssadmin.exe deleting volume shadow copies
// Excludes known installer processes that reset shadows during updates
DeviceProcessEvents
| where FileName =~ "vssadmin.exe"
| where ProcessCommandLine has "delete shadows"
| where InitiatingProcessFileName !in~ ("msiexec.exe", "setup.exe", "ccmexec.exe")
| extend AlertSeverity = "High"
| project TimeGenerated, DeviceName, AccountName,
    FileName, ProcessCommandLine, InitiatingProcessFileName,
    InitiatingProcessCommandLine, AlertSeverity

Every line is a where filter or a project/extend — no joins, no aggregation. The !in~ exclusion handles the three most common legitimate processes that interact with shadow copies during software installation or SCCM patching. The project statement includes InitiatingProcessFileName and InitiatingProcessCommandLine so the analyst can immediately see what launched vssadmin — the parent process is the critical context for determining whether this is a legitimate admin action or an attacker.

Operational constraints revisited

30-alert cap per execution. If your NRT rule matches more than 30 events in a single minute, you get 29 individual alerts plus a 30th summary. This matters for noisy rules — a poorly scoped NRT rule can hit the cap and lose individual event detail. NRT rules should be precise enough that 30 matches in a minute would indicate a genuine mass event, not normal operations.

50-rule workspace limit. Plan your NRT allocation carefully. Most production programs run 3 to 5 NRT rules. If you're approaching 50, you're using NRT for detections that don't need sub-minute latency.

Use project aggressively. NRT alerts have size limits. Include only the fields the analyst needs — entity mapping columns, the process chain, the critical context. Don't return entire table rows.

Defender XDR custom detections

Defender XDR custom detections are a separate detection engine from Sentinel analytics rules. They run KQL queries against Defender's Advanced Hunting tables — a different table set from the Log Analytics workspace tables that Sentinel queries. The key distinction is not just the tables — it's the automated response actions.

Where Defender custom detections run

Defender custom detections query the Advanced Hunting tables in the Defender portal: DeviceProcessEvents, DeviceFileEvents, DeviceNetworkEvents, DeviceLogonEvents, EmailEvents, EmailAttachmentInfo, IdentityLogonEvents, CloudAppEvents, and others. These tables contain deep telemetry from Defender for Endpoint, Defender for Office 365, Defender for Identity, and Defender for Cloud Apps.

Some of these tables overlap with Sentinel. SigninLogs in Log Analytics and IdentityLogonEvents in Advanced Hunting contain related but not identical authentication data. DeviceProcessEvents in Advanced Hunting contains the same endpoint telemetry that flows to Sentinel through the Defender for Endpoint connector. The data is available in both places — what differs is what you can do when the detection fires.

The automated response advantage

When a Defender custom detection fires, it can trigger automated response actions that Sentinel analytics rules cannot:

Isolate the device — network isolation that cuts the device off from everything except the Defender service. The machine stays online for investigation but can't communicate with the attacker's infrastructure or spread laterally.

Collect investigation package — automatically initiates forensic evidence collection from the device: running processes, network connections, persistence mechanisms, autostart entries, scheduled tasks.

Run antivirus scan — triggers a full scan on the device immediately.

Restrict app execution — blocks all non-Microsoft-signed executables on the device.

Quarantine file — removes a specific file from the device and places it in quarantine.

These response actions are the reason you'd create a Defender custom detection alongside a Sentinel scheduled or NRT rule for the same threat. The Sentinel rule generates the alert and populates the investigation workflow. The Defender custom detection triggers the automated containment. Both fire on the same attack, but they serve different operational purposes.

Here is what the shadow copy deletion detection looks like as a Defender custom detection:

// Defender XDR custom detection — shadow copy deletion
// Same detection logic, different engine, different response
// Must include Timestamp, DeviceId, ReportId for Defender
DeviceProcessEvents
| where FileName =~ "vssadmin.exe"
| where ProcessCommandLine has "delete shadows"
| where InitiatingProcessFileName !in~ ("msiexec.exe", "setup.exe", "ccmexec.exe")
| project Timestamp, DeviceId, DeviceName, ReportId,
    AccountName, FileName, ProcessCommandLine,
    InitiatingProcessFileName

Create this custom detection via PowerShell using the Microsoft Graph Security API:

# Deploy a Defender custom detection with auto-response
$detection = @{
    displayName = "Shadow Copy Deletion — Ransomware Pre-Encryption"
    isEnabled   = $true
    severity    = "high"
    period      = "PT1H"
    detectionAction = @{
        alertTemplate = @{ impactedAssets = @(@{
            "@odata.type" = "#microsoft.graph.security.impactedDeviceAsset"
        })}
        responseActions = @(
            @{ "@odata.type" = "#microsoft.graph.security.isolateDeviceResponseAction" }
            @{ "@odata.type" = "#microsoft.graph.security.collectInvestigationPackageResponseAction" }
        )
    }
}
# The isolateDevice + collectInvestigationPackage actions fire
# automatically when the detection matches — no analyst required

The automated response is the key differentiator. When this detection fires, the device is isolated and the forensic package is collected before an analyst even sees the alert. For ransomware pre-encryption indicators where every minute of delay means more encrypted file shares, the automated containment is what prevents the blast radius from expanding.

The query logic is nearly identical to the NRT version. The critical difference is the project statement: Defender custom detections require Timestamp, DeviceId, and ReportId for device-based tables. If you project these away, the "Create detection rule" button in the portal is grayed out. These columns are how Defender identifies the unique event and the impacted asset for automated response actions.

The frequency options for Defender custom detections differ from Sentinel: every hour, every 3 hours, every 12 hours, every 24 hours, or continuous (near-real-time). No 5-minute option, no 15-minute option. For high-severity endpoint detections, continuous or hourly frequency with device isolation as the response action is the standard configuration.

When to use which

The decision framework:

Use Sentinel scheduled when the detection requires cross-table joins, aggregation, behavioral baselines, or time-series analysis. Most detections fall here. The full KQL language enables the complex correlation that distinguishes sophisticated detection engineering from simple event matching.

Use Sentinel NRT when the attacker completes a critical action within 5 minutes and the detection logic can be expressed as a filter chain. Shadow copy deletion, LSASS access, C2 beaconing, security tool tampering. Reserve NRT for the 3-5 detections where sub-minute latency changes the outcome.

Use Defender XDR custom when you need automated response actions on the endpoint or mailbox. Device isolation, investigation package collection, file quarantine. Also use Defender custom detections when the detection is purely endpoint or email-based and doesn't need cross-family correlation with Sentinel data.

Use multiple engines for time-critical threats. The ransomware detection exists as both an NRT rule in Sentinel (fast alert for the SOC) and a Defender custom detection (automatic device isolation). Both fire. Each serves a different operational purpose.

A note on the Defender portal migration

Microsoft is requiring all Sentinel customers to migrate to the Defender portal by March 2027. In the unified portal, your Sentinel analytics rules and Defender custom detections coexist in the same interface. The detection engines remain separate — Sentinel rules query Log Analytics tables, Defender custom detections query Advanced Hunting tables — but the incident queue is unified. This convergence makes the multi-engine approach more practical: you manage both detection types from one portal and see their alerts in one queue.