2.4 Next-Generation Protection and EDR Configuration

Next-Generation Protection and EDR Configuration

Introduction

ASR rules (subsection 2.3) block categories of malicious behavior. Next-generation protection goes further — it identifies and blocks specific malicious files, processes, and network connections using a combination of signature matching, behavioral analysis, machine learning, and cloud-delivered intelligence. EDR (Endpoint Detection and Response) captures the detailed telemetry that populates your investigation timelines and powers Advanced Hunting queries.

This subsection teaches you to configure both the preventive layer (Microsoft Defender Antivirus and its cloud-connected capabilities) and the detection layer (EDR settings, custom detection rules, indicators of compromise, alert tuning, and deception). Together, these configurations determine what your SOC sees in the alert queue and what the automated investigation engine acts on.

The distinction matters operationally: prevention stops threats before they generate alerts (reducing your workload). Detection identifies threats that bypass prevention (generating the alerts you investigate). A well-configured MDE deployment has strong prevention that blocks the majority of threats automatically, leaving the SOC to focus on the sophisticated attacks that require human investigation.

Microsoft Defender Antivirus: the prevention engine

Microsoft Defender Antivirus is the built-in antivirus engine on Windows. It is not a separate product from MDE — it is the prevention layer within MDE. When you hear “next-generation protection,” this is what it refers to. The engine includes several protection capabilities that require deliberate configuration to operate at full effectiveness.

Cloud-delivered protection sends suspicious file metadata (not the file itself, unless sample submission is enabled) to Microsoft’s cloud service for rapid classification. The cloud service compares the file against a global threat intelligence database updated in real time across all MDE tenants worldwide. Cloud protection can classify a file as malicious within milliseconds — far faster than waiting for a signature update. This capability must be enabled (Settings → Endpoints → Advanced features → Cloud-delivered protection). Without it, the antivirus relies only on locally cached signatures, which are hours to days behind the cloud intelligence.

Behavior monitoring watches process behavior in real time. Rather than checking a file’s hash against a known-malicious list, behavior monitoring observes what the file does after execution: does it inject code into another process? Does it modify registry keys associated with persistence? Does it encrypt files rapidly? Does it establish outbound connections to unusual destinations? Behavior monitoring catches malware that has never been seen before (zero-day) because it recognizes malicious patterns regardless of the specific executable. This must be enabled and should never be disabled, even temporarily.

Real-time protection scans files as they are accessed, created, or downloaded. It intercepts file operations before they complete, blocking malicious files before they can execute. Real-time protection uses a combination of signature matching (known threats) and heuristic analysis (files that behave like known threat categories). Disabling real-time protection — even temporarily for “testing” — creates a window where malware can execute unchecked. If a third-party application requires real-time protection to be disabled, that application has a security problem that should be addressed rather than accommodated.

Sample submission controls whether suspicious files are sent to Microsoft for deep analysis (detonation in a sandboxed environment). When enabled, files that trigger heuristic detection but are not definitively classified are uploaded to the cloud for analysis. The analysis results are then distributed to all MDE tenants, improving global protection. The privacy consideration is that file content leaves your environment. For most organizations, the security benefit outweighs the privacy concern — but organizations in regulated industries (government, defense, healthcare) should review this with their compliance team. The options are: send all samples automatically, send only PE (Portable Executable) files, do not send any, or prompt the user.

Potentially Unwanted Application (PUA) blocking detects and blocks applications that are not malware but are undesirable in enterprise environments — adware, browser toolbars, cryptocurrency miners, and bundled software installers. PUA blocking is configured separately from malware protection and is disabled by default. Enable it in audit mode first, then block mode, using the same phase approach as ASR rules.

EDR configuration

The EDR (Endpoint Detection and Response) engine is what makes MDE an investigation platform rather than just an antivirus. EDR captures the detailed telemetry that populates DeviceProcessEvents, DeviceNetworkEvents, DeviceFileEvents, and all other Device tables in Advanced Hunting. It also generates the alerts that appear in the Defender XDR incident queue.

EDR in block mode is a critical configuration that many organizations overlook. When a third-party antivirus is installed as the primary protection, Microsoft Defender Antivirus runs in passive mode — it monitors but does not actively block. EDR in block mode adds a safety net: even when Defender Antivirus is passive, the EDR engine can block malicious artifacts that it detects through behavioral analysis. This means that if the third-party antivirus misses a threat, MDE’s EDR engine can still block it. Enable EDR in block mode whenever a third-party antivirus is the primary protection: Settings → Endpoints → Advanced features → EDR in block mode.

Tamper protection prevents malware from disabling Microsoft Defender Antivirus or modifying its configuration. Sophisticated attackers routinely attempt to disable endpoint protection as one of their first actions after gaining access — they modify registry keys, stop services, or delete configuration files. Tamper protection blocks these modifications even if the attacker has local administrator access. Enable tamper protection in the Defender portal or via Intune. It should always be enabled in production environments.

Custom detection rules

Custom detection rules extend MDE’s built-in detection capabilities with your own KQL-based detections. A custom detection rule is a scheduled KQL query that runs against the Advanced Hunting data at a configured frequency. When the query returns results, MDE generates alerts and can automatically take response actions.

Custom detection rules are configured in the Defender portal under Hunting → Custom detection rules → Create. The creation process requires a KQL query (the detection logic), a frequency (every 1 hour, 3 hours, 12 hours, or 24 hours), alert settings (title, severity, category, MITRE ATT&CK technique), and optionally, automated response actions (isolate device, restrict app execution, collect investigation package).

1
2
3
4
5
6
7
8

// Example custom detection: encoded PowerShell from Office applications
DeviceProcessEvents
| where Timestamp > ago(1h)
| where InitiatingProcessFileName in~ ("winword.exe", "excel.exe", "powerpnt.exe")
| where FileName =~ "powershell.exe"
| where ProcessCommandLine has_any ("-enc", "-encodedcommand", "-e ")
| project Timestamp, DeviceName, AccountName,
    InitiatingProcessFileName, ProcessCommandLine

This query detects the exact attack chain from Module 1.4 — Office applications spawning encoded PowerShell. As a custom detection rule running every hour, it generates an alert within 60 minutes of the behavior occurring. The alert includes the device name, user, and full command line, giving the investigating analyst immediate context.

Detection rule best practices. Always include a time filter matching the rule frequency (ago(1h) for hourly rules, ago(24h) for daily rules). Use has over contains for performance — rules that run slowly may miss events between executions. Test the query manually in Advanced Hunting before creating the rule to verify it returns the expected results and does not produce false positives. Set the severity appropriately — not every custom detection is High severity. Use the MITRE ATT&CK technique mapping to classify the detection, which helps analysts understand the attack context when they triage the alert.

Indicators of Compromise (IoCs)

Indicators allow you to define specific entities (file hashes, IP addresses, URLs, domains, and certificates) that MDE should allow, block, or alert on across all onboarded devices. Indicators are your mechanism for translating threat intelligence into endpoint-level protection.

File hash indicators block or allow specific files by their SHA-256, SHA-1, or MD5 hash. When you identify a malicious file during an investigation, adding its hash as a block indicator prevents it from executing on any device in your organization. This is faster than waiting for an antivirus signature update and more precise than an ASR rule.

IP and URL indicators block or alert on network connections to specific destinations. When you identify a C2 server IP during an investigation (subsection 1.4’s DeviceNetworkEvents query), adding it as a block indicator instructs MDE’s network protection to block all connections to that IP from every onboarded device. This provides endpoint-level blocking that works even when the device is off the corporate network and outside your firewall’s reach.

Domain indicators operate similarly to URL indicators but match any URL under the specified domain. Blocking malicious-phishing.com blocks all URLs on that domain regardless of path.

Certificate indicators block or allow executables signed with specific certificates. If an attacker signs their malware with a stolen or fraudulent code-signing certificate, blocking that certificate prevents all executables signed with it from running — even if the specific file hashes have not been identified yet.

Indicators are managed in Settings → Endpoints → Indicators. Each indicator has an action (Allow, Alert only, Alert and block, Block), a scope (all devices or specific device groups), and an expiration date (optional — use for temporary blocks during active incidents, permanent for known-bad infrastructure).

1
2
3
4
5
6
7
8
9

// Verify indicator effectiveness — check if blocked IPs are still being contacted
DeviceNetworkEvents
| where Timestamp > ago(7d)
| where RemoteIP in ("203.0.113.47", "198.51.100.22")
| summarize ConnectionAttempts = count(),
    BlockedCount = countif(ActionType == "ConnectionBlocked"),
    AllowedCount = countif(ActionType == "ConnectionSuccess")
    by RemoteIP, DeviceName
| order by AllowedCount desc

If AllowedCount is greater than zero for a blocked indicator IP, investigate why — the device may not have received the indicator policy (offline, network issues), or the connection may be using a path that bypasses network protection (specific port, protocol, or application).

Alert tuning and suppression

MDE generates thousands of alerts per month in a typical enterprise. Not all alerts require investigation — some are known false positives, some are benign true positives (authorized security testing), and some are low-value detections that consume analyst time without improving security posture. Alert tuning reduces noise so analysts can focus on alerts that matter.

Alert suppression silences specific alert types based on conditions you define. For example, if your IT team runs a legitimate script that triggers “Suspicious PowerShell command line” alerts every night, you can suppress that alert when the initiating process matches the specific script path on the specific devices where it runs. Suppression rules are configured in Settings → Endpoints → Alert suppression. Each rule specifies the alert title (or pattern), the conditions (device group, file name, path, user), and the action (hide alert, resolve automatically).

Alert tuning adjusts the sensitivity of built-in detections. If a specific detection generates too many false positives, you can tune it by adding exclusions (similar to ASR exclusions) that prevent the detection from firing on specific legitimate processes. Tuning is finer-grained than suppression — it modifies the detection logic rather than hiding the output.

The operational principle: tune aggressively. A SOC that receives 500 alerts per day with a 90% false positive rate is less effective than one that receives 100 alerts per day with a 50% false positive rate. Both SOCs see the same 50 real threats — but the first SOC buries them in 450 distractions. Module 1.7 (SOC Workflow) covered the alert fatigue problem. Tuning and suppression are the primary tools for solving it.

Deception rules

Deception rules are a newer MDE capability that deploys decoy accounts, devices, or files designed to attract attacker activity. When an attacker interacts with a decoy — attempting to authenticate with a decoy account, accessing a decoy file share, or scanning a decoy device — MDE generates a high-fidelity alert because legitimate users have no reason to interact with decoys.

Deception rules are configured in Settings → Endpoints → Deception rules. You define the decoy type (account, device, or file), the decoy properties (name, location, apparent value), and the alert settings. Decoys are most effective when they appear valuable — a decoy account named svc-backup-admin placed in the same OU as real service accounts, or a decoy file share named Finance-Confidential on a server where real finance shares exist.

The advantage of deception is signal quality. Every other detection type (behavioral, signature, custom rules) has a false positive rate. Deception alerts have an inherently near-zero false positive rate because there is no legitimate reason for anyone to interact with a decoy. If an analyst sees a deception alert, they can be confident that an attacker is active in the environment. This makes deception alerts the highest priority in any triage queue.

Knowledge check