DE1.6 NRT Rules — When Seconds Matter

How NRT rules execute

NRT rules differ architecturally from scheduled rules in four fundamental ways. Understanding these differences prevents the common mistake of converting a working scheduled rule to NRT and having it fail.

Execution cycle: NRT rules run approximately every 60 seconds. This is not configurable — there is no frequency setting. The engine checks for new events since the last successful execution and runs the query against only those new events. This means the lookback is dynamic — it covers exactly the period since the last run, not a fixed window.

Query scope: Because NRT queries only see events since the last run (approximately 1 minute of data), they cannot perform time-windowed aggregations. A query that counts failed sign-ins per IP over 30 minutes is meaningless in NRT — it would only see the sign-ins from the last minute. Scheduled rules aggregate over configurable windows. NRT rules detect individual events.

KQL restrictions: NRT rules do not support join, union (except with the same table), summarize, count, dcount, make-set, make-list, arg_max, arg_min, percentile, or any cross-table operator. They support where, extend, project, parse, mv-expand, and string/datetime functions. This limits NRT to single-table, single-event pattern detection.

Table support: NRT rules can query a subset of Sentinel tables. The supported tables include the major Microsoft telemetry tables (SecurityAlert, SecurityIncident, SigninLogs, AuditLogs, DeviceProcessEvents, DeviceNetworkEvents, DeviceFileEvents, DeviceLogonEvents, DeviceRegistryEvents, EmailEvents, OfficeActivity, CommonSecurityLog, Syslog, WindowsEvent) but not all custom tables or all third-party connector tables. Check the Microsoft documentation for the current supported table list before building an NRT rule.

Figure DE1.6 — NRT execution cycle. From event occurrence to automated containment in under 5 minutes. The speed advantage over scheduled rules is most significant for catastrophic-impact detections where minutes determine outcome.

NRT-worthy detections for Northgate Engineering

Not every high-severity detection justifies NRT. The three conditions must ALL be met: high confidence (very low FP rate), catastrophic impact if delayed, and single-event detection pattern (no correlation needed). At NE, the following rules justify NRT:

Ransomware pre-encryption (CHAIN-MESH Phase 7):

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20

// NRT RULE: Ransomware Pre-Encryption Indicators
// CRITICAL severity — automated device isolation on trigger
DeviceProcessEvents
| where FileName in~ ("vssadmin.exe", "wbadmin.exe", "bcdedit.exe", "wmic.exe")
| where ProcessCommandLine has_any (
    "delete shadows",          // Shadow copy deletion
    "delete catalog",          // Backup catalog deletion
    "recoveryenabled no",      // Recovery mode disabled
    "shadowcopy delete",       // WMI shadow copy deletion
    "delete systemstatebackup" // System state backup deletion
)
| where InitiatingProcessAccountName !in ("SYSTEM", "LOCAL SERVICE")
// Exclude system-initiated — legitimate backup operations run as SYSTEM
| extend AlertContext = strcat(
    "Ransomware indicator: ", FileName, " executed by ",
    InitiatingProcessAccountName, " on ", DeviceName,
    " | Command: ", ProcessCommandLine
)
// Entity mapping: Host → DeviceName, Account → InitiatingProcessAccountName
// Process → FileName + ProcessCommandLine

This rule fires on a single event — no aggregation, no join. The confidence is high: non-SYSTEM processes deleting shadow copies is almost always malicious (legitimate backup operations run as SYSTEM). The impact is catastrophic: ransomware encryption is in progress. The NRT detection fires within 1-4 minutes, and the automation rule triggers device isolation via playbook — stopping encryption before it completes.

LSASS memory access by non-system process:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14

// NRT RULE: LSASS Credential Dump Detection
// CRITICAL severity — indicates active credential theft
DeviceProcessEvents
| where FileName =~ "lsass.exe"
    or ProcessCommandLine has_any (
        "sekurlsa", "mimikatz", "procdump",
        "comsvcs.dll", "MiniDump", "lsass"
    )
| where InitiatingProcessFileName !in~ (
    "svchost.exe", "lsass.exe", "csrss.exe",  // System processes
    "MsMpEng.exe", "SenseIR.exe"                // Defender processes
)
// Entity mapping: Host → DeviceName, Account → InitiatingProcessAccountName
// Process → InitiatingProcessFileName + InitiatingProcessCommandLine

Known C2 beacon command patterns:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

// NRT RULE: Cobalt Strike Beacon Detection
// HIGH severity — fileless beacon activation
DeviceProcessEvents
| where ProcessCommandLine has_any (
    "IEX (New-Object Net.WebClient).DownloadString",
    "-nop -w hidden -encodedcommand",
    "powershell -ep bypass -nop -w hidden",
    "[System.Convert]::FromBase64String"
)
| where InitiatingProcessFileName in~ ("powershell.exe", "pwsh.exe", "cmd.exe")
// Entity mapping: Host → DeviceName, Account → AccountName, IP → RemoteIP (if available)

NRT operational considerations

Alert volume management: NRT rules trigger on ANY row returned — there is no threshold setting. If the query returns 10 events in a 1-minute cycle, it creates 10 alerts (or 10 events within one alert, depending on configuration). Ensure the query’s where filters are precise enough that false positives do not overwhelm the Critical alert queue. An NRT rule with a 10% FP rate generating 5 alerts per day means 0.5 false Critical alerts per day — each one interrupting the analyst. Over a month, that is 15 unnecessary interruptions at the highest priority level.

Testing before NRT deployment: Run the query as a scheduled rule at 5-minute frequency for 14 days first. Measure the TP/FP rate. If the TP rate exceeds 90% and the daily alert volume is manageable (under 5 alerts per day), convert to NRT. If not, keep it as a scheduled rule and tune until it meets the NRT confidence threshold.

Fallback pattern: Deploy the NRT rule for single-event detection AND a scheduled rule for the same technique with correlation context. The NRT fires first (within minutes) for immediate containment. The scheduled rule fires later (within the hour) with enriched context (what did the user do before and after the event) for investigation. The NRT catches it fast. The scheduled rule explains it fully.

Troubleshooting: NRT issues

“NRT rule deployed but no alerts fire.” Three common causes: (1) the query uses unsupported operators (join, summarize) that fail silently, (2) the query references a table not in the NRT-supported table list, or (3) the where filters are too restrictive and no individual events match. Test: run the same query in Advanced Hunting with | take 100 against the last hour. If it returns results there but not in NRT, the issue is likely unsupported operators.

“NRT rule fires too often.” The where filters need tightening. NRT has no threshold — every matching event generates an alert. Add exclusions: service accounts, SYSTEM processes, known-good applications. If the event type is legitimately high-volume (sign-in events, process creation events), NRT is the wrong rule type — convert to a scheduled rule with a threshold.

“NRT alerts lack context for investigation.” Expected. NRT detects the event but cannot join with other tables for context. Build a companion scheduled rule that fires on the same technique with full correlation (join with identity data, prior activity, device context). The NRT provides the fast alert. The scheduled rule provides the investigation context. Both contribute to the same incident via entity-based alert grouping (DE1.9).

References used in this subsection

• Microsoft Sentinel NRT rules documentation
• Course cross-references: DE1.3 (frequency selection), DE1.5 (severity — NRT = Critical), DE1.10 (automation for NRT response), DE8 (ransomware NRT rule build), DE9 (testing methodology for NRT candidacy)