How I Set Up and Monitor Attack Surface Reduction (ASR) Rules
Introduction Attack Surface Reduction (ASR) is a vital cybersecurity strategy that reduces how attackers can exploit vulnerabilities in your environment. In Microsoft Defender for Endpoint (MDE), ASR uses behavior-based rules to proactively block potentially malicious activities at both the system and application levels.
ASR helps prevent compromise by targeting known attack vectors without heavily impacting productivity. It does this by applying predefined rules designed to block risky actions like script execution, process creation, and driver abuse.
In this blog post, I’ll walk through how I set up ASR rules, monitor their effectiveness, and build a baseline policy.
Category:
Block executable content from Office apps
Prevents Office applications like Word, Excel, PowerPoint, and OneNote from writing untrusted or unsigned executables and script files (e.g., .exe, .ps1, .vbs) to disk. This helps stop attacks before malware gets a chance to run.
Block Office apps from creating child processes
Blocks Office apps from launching other processes such as PowerShell or Command Prompt — techniques often used to disable security tools or run additional payloads.
Block Office apps from injecting code
Stops Office apps from injecting malicious code into trusted, signed processes — a classic technique for evading detection by hiding inside whitelisted apps.
Block Win32 API calls from Office macros
Prevents macros from making dangerous system-level calls via the Win32 API. This blocks attackers from running in-memory or fileless malware through VBA.
Block Adobe Reader from creating child processes
Similar to the Office rule, this blocks Adobe Reader from launching additional tools or payloads — a method seen in many document-based attacks.
Block executable files unless they meet trust criteria
This rule blocks new or unknown executable files from running unless they’re signed, trusted, or commonly seen in Microsoft’s reputation data. It’s designed to stop polymorphic malware, which often uses repacked or rebased binaries to avoid detection. This aggressive rule is ideal for high-security environments and should be excluded on development systems to avoid false positives.
Block untrusted and unsigned processes from USB
Prevents unsigned or untrusted executables from running directly off USB drives. It also blocks such files from being copied to disk, reducing the risk of USB-based malware delivery.
Block abuse of exploited vulnerable signed drivers
This rule prevents attackers from using signed but vulnerable drivers to gain kernel-level access. It blocks any such driver written to disk from being loaded by processes, reducing the risk of deep system compromise.
Use advanced protection against ransomware
This aggressive rule blocks drivers and executables that lack sufficient trust or reputation based on Microsoft’s telemetry. While it may generate some false positives, it’s highly effective in preventing ransomware and is best suited for high-security environments. Consider exclusions for developer tools or build systems if needed.
Block process creations from PsExec and WMI
Stops PsExec and WMI commands from launching child processes — a technique often used by attackers to move laterally across networks after initial compromise.
Block credential stealing from LSASS
Prevents tools and techniques that attempt to extract credentials from the LSASS process, which is a common method used in post-exploitation phases.
Block persistence through WMI event subscription
Blocks attackers from using WMI event subscriptions to maintain persistence across system reboots — a stealthy and hard-to-detect method.
Block use of copied or impersonated system tools
Prevents attackers from using renamed or relocated versions of legitimate Windows tools (like cmd.exe, powershell.exe, or wscript.exe) to evade detection. This rule blocks execution unless the tool runs from its original system location.
Block Webshell creation for Servers
Stops attackers from writing malicious webshells (e.g., .aspx, .php) to server directories — a common method to gain persistent remote access and control over compromised servers.
Block rebooting machine in Safe Mode
Prevents malware or unauthorized users from rebooting a system into Safe Mode, where many security controls (e.g., endpoint protection) may not run. This protects against techniques used to disable defenses during startup.
Controlled Folder Access (CFA)
Controlled Folder Access (CFA) ensures only trusted applications can access specific folders, helping to protect against ransomware. It requires Microsoft Defender Antivirus real-time protection.
In my environment, I enable CFA only on backup servers to provide targeted protection without overwhelming support resources. As an MSP, managing many customers with limited time makes CFA a bit challenging to roll out across all systems. However, I believe enabling it on backup servers provides a strong layer of defense where it matters most.
Default protected folders include:
-
C:\Users\<username>\Documents -
C:\Users\Public\Documents -
C:\Users\<username>\Pictures -
C:\Users\Public\Pictures -
C:\Users\<username>\Videos -
C:\Users\Public\Videos -
C:\Users\<username>\Music -
C:\Users\Public\Music -
C:\Users\<username>\Favorites
Operating Modes
Operating Modes ASR rules support four modes: Block, Audit, Warn, and Disabled. I typically start in Audit mode to monitor impact, then move to Block as confidence grows.
Reporting
When an ASR Rule is being hit you can find the event logs in two different ways.
- Event viewer. Go to Eventvwr.exe –> Application and Services Logs –> Microsoft –> Windows –> Windows Defender–> Search for event log 1121
2. Reporting Go to portal.office.com –> Security –> Attack Surface Reduction rules
In here you can see which ASR rules are being hit. You can also filter on specific ASR Rules and export the file namens and paths to and csv to add to your exclusions.
Baseline Policy Strategy
When rolling out MDE, it’s best to define a starting baseline. You can begin in Audit mode for visibility, but I usually start with minimal and safe in block mode after that work my way to block the rest of the rules.
Some rules are “Not Configured” on older OS versions like Server 2012R2/2016 due to incompatibility. For example, Webshell creation is relevant only to Exchange Servers.
Category
Caution = Use with caution blocking this without monitoring can break things for example “Block process creations originating from PSExec and WMI commands” will break SCCM.
Monitor = Monitor first then block
Safe = Safe to block in most environments
Minimal (standard protection rules) = Are the minimum set of rules which Microsoft recommends you always enable,
| Rule | Catogory | BYOD | Managed Workstation | 2012R2\2016 | 2019\2022 |
|---|---|---|---|---|---|
| Block execution of potentially obfuscated scripts | Monitor | n/a | Audit | Audit | Audit |
| Block Win32 API calls from Office macros | Monitor | n/a | Audit | not configured | not configured |
| Block executable files from running unless they meet a prevalence, age, or trusted list criterion | Caution | n/a | Audit | Audit | Audit |
| Block Office communication application from creating child processes | Monitor | n/a | Audit | Audit | Audit |
| Block all Office applications from creating child processes | Monitor | n/a | Audit | Audit | Audit |
| Block Adobe Reader from creating child processes | Safe | n/a | Audit | Block | Block |
| Block credential stealing from the Windows local security authority subsystem | Minimal | n/a | Block | Block | Block |
| Block JavaScript or VBScript from launching downloaded executable content | Safe | n/a | Block | not configured | Block |
| Block Webshell creation for Servers | Exchange Only | n/a | n/a | Exchange Only | Exchange Only |
| Block untrusted and unsigned processes that run from USB | Safe | n/a | Audit | Block | Audit |
| Block persistence through WMI event subscription | Minimal | n/a | Audit | not configured | Block |
| [PREVIEW] Block use of copied or impersonated system tools | Monitor | n/a | Audit | Audit | Audit |
| Block abuse of exploited vulnerable signed drivers (Device) | Minimal | n/a | Audit | Block | Block |
| Block process creations originating from PSExec and WMI commands | Caution | n/a | Audit | Audit | Audit |
| Block Office applications from creating executable content | Safe | n/a | Audit | Block | Block |
| Block Office applications from injecting code into other processes | Caution | n/a | Block | Audit | Block |
| [PREVIEW] Block rebooting machine in Safe Mode | Monitor | n/a | Block | Block | Block |
| Use advanced protection against ransomware | Caution | n/a | Audit | Audit | Audit |
| Block executable content from email client and webmail | Safe | n/a | Audit | Block | Block |
Conclusion
Depending on the environment, I start with a baseline policy and adjust as needed. Most exclusions I apply are for third-party line-of-business (LOB) applications that require specific behaviors. With thoughtful planning and ongoing monitoring, ASR rules can significantly reduce your attack surface while maintaining system stability.
Sources
Microsoft Defender for Endpoint in Depth | Security | Paperback