Enable Attack Surface Reduction (ASR) Rules in Microsoft Defender

Attack Surface Reduction rules are a set of built-in behavioral blocks in Microsoft Defender Antivirus that target the specific techniques attackers use most: Office documents spawning child processes, scripts downloading executables, credential theft from LSASS, and abuse of vulnerable signed drivers. They require no additional license for the core protection, no new agent, and no infrastructure — they are arguably the highest-value free hardening available on a Windows fleet, and one of the fastest ways to neutralize the macro-based and script-based initial access that commodity malware still relies on.

Prerequisites

• Microsoft Defender Antivirus must be the active AV with real-time protection on — ASR rules do not function when a third-party AV puts Defender into passive mode.
• Rules are deployed via Intune (Endpoint security > Attack surface reduction), GPO (Computer Configuration > Administrative Templates > Windows Components > Microsoft Defender Antivirus > Microsoft Defender Exploit Guard > Attack Surface Reduction), or PowerShell (Set-MpPreference / Add-MpPreference).
• Reporting is where licensing matters: the rules work with plain Defender AV, but fleet-wide visibility into audit and block events requires Defender for Endpoint. Without it, plan to collect Event IDs 1121 (block) and 1122 (audit) from the Microsoft-Windows-Windows Defender/Operational log via your SIEM.

Start with the low-friction rules

A subset of rules almost never breaks anything legitimate and can go straight to block in most environments:

• Block credential stealing from LSASS — hugely valuable, and complementary to LSA Protection/Credential Guard covered elsewhere on this site.
• Block Office applications from creating child processes — kills the classic malicious-macro chain (Word spawning cmd/PowerShell).
• Block Office applications from creating executable content, and from injecting code into other processes.
• Block execution of potentially obfuscated scripts, and block JavaScript/VBScript from launching downloaded executable content.
• Block abuse of exploited vulnerable signed drivers — cuts off the BYOVD technique used to disable security tooling.
• Block persistence through WMI event subscription.

Handle the noisy rules carefully

• Two rules cause most real-world friction: Block process creations originating from PSExec and WMI commands (breaks MECM/ConfigMgr client operations — do not enable it on MECM-managed fleets) and Block executable files unless they meet prevalence, age, or trusted list criteria (flags niche line-of-business software).
• Rules touching USB (Block untrusted and unsigned processes that run from USB) and email (Block executable content from email client and webmail) are usually safe but deserve an audit pass in environments with unusual workflows.

Rollout method

• Set every rule to Audit mode fleet-wide and collect events for two to four weeks.
• Review hits: legitimate business processes triggering a rule get targeted per-rule exclusions (path or certificate based), not a disabled rule.
• Flip the clean rules to Block in rings — pilot group, then departments, then everyone. Keep the problematic rules in audit until their exclusions are proven.
• Use Warn mode selectively where you want users to be able to self-unblock with an audit trail, such as the prevalence-based executable rule on developer machines.
• Re-review quarterly: new rules ship over time, and exclusions accumulate — prune ones no longer needed.

ASR rules will not stop a determined targeted attacker on their own, but they cheaply eliminate the initial-access techniques behind a large share of ransomware incidents. If your fleet runs Defender and these rules are not enabled, this belongs at the top of the to-do list — it is a First-tier control with Third-tier impact.