Attack surface reduction rules are behavior-based policies in Microsoft Defender Antivirus that block specific actions commonly abused by malware, such as Office documents launching child processes, scripts running obfuscated code or untrusted programs reading credentials from the LSASS process. In Windows security, they sit between signature-based antivirus and application control: they do not decide whether a file is malicious, but whether a risky behavior is allowed at all.
Each rule targets one technique, has its own identifier and can be set independently to block, audit, warn or off. Because legitimate software sometimes performs the same actions, deploying the rules is as much a testing and exclusion exercise as a security decision.
How attack surface reduction rules work
The rules are enforced by the Defender Antivirus engine in real time, so they require Defender Antivirus to be the active antivirus product with real-time protection enabled. When a monitored action occurs, such as WINWORD.EXE trying to start powershell.exe, the engine evaluates the rule and either stops the action or logs it.
Every rule is identified by a GUID and receives one of four states. The state determines whether users notice anything and whether administrators get usable evidence before enforcing.
| State | Value | Effect on the action | Typical use |
|---|---|---|---|
| Not configured or disabled | 0 | Action allowed, nothing logged | Rule not in scope |
| Block | 1 | Action stopped, event logged | Production enforcement |
| Audit | 2 | Action allowed, event logged | Testing impact before blocking |
| Warn | 6 | User sees a prompt and may unblock | Gradual rollout for some rules |
Blocked and audited events are written to the Microsoft-Windows-Windows Defender/Operational log, with event ID 1121 for blocks and event ID 1122 for audits. With Microsoft Defender for Endpoint, the same events appear centrally in the security portal with reporting and advanced hunting.
Important rules and what they stop
Microsoft groups a few rules as standard protection rules that have minimal compatibility impact and can usually be blocked immediately. The rest should go through an audit phase. The table lists widely used rules.
| Rule | Technique it blocks | Compatibility risk |
|---|---|---|
| Block credential stealing from LSASS | Memory reads of the LSASS process | Low |
| Block abuse of exploited vulnerable signed drivers | Loading of known vulnerable drivers | Low |
| Block persistence through WMI event subscription | WMI-based persistence | Low |
| Block all Office applications from creating child processes | Macro droppers starting programs | Medium |
| Block Win32 API calls from Office macros | Macros calling system functions | Medium |
| Block execution of potentially obfuscated scripts | Encoded or packed scripts | Medium |
| Block executable files unless they meet prevalence, age or trusted list criteria | Rare, new executables | High |
| Block process creations from PSExec and WMI commands | Lateral movement tools | High on managed fleets |
The prevalence-based rule and the PSExec and WMI rule are the most likely to break management tools and internal software, so they deserve the longest audit period. The ransomware protection rule relies on cloud-delivered protection and also needs careful testing.
Comparison with related Windows protections
Attack surface reduction is a family name in Microsoft documentation that also covers several separate features. The rules are only one of them, and they complement rather than replace the others.
| Control | What it decides | Main difference |
|---|---|---|
| Attack surface reduction rules | Whether a risky behavior may occur | Behavior-based, per technique |
| Microsoft Defender Antivirus | Whether a file or process is malicious | Detection-based, signatures and cloud |
| Exploit protection | How processes resist memory exploits | Mitigations such as DEP and CFG |
| Controlled folder access | Which apps may modify protected folders | Ransomware-focused file protection |
| Smart App Control and App Control for Business | Which code may run at all | Allow-list application control |
| Credential Guard | Whether secrets can be read from memory | Isolation through virtualization-based security |
A layered configuration is typical: Credential Guard isolates credentials, while the LSASS rule adds a second barrier on devices where virtualization-based security cannot run.
Deploying and managing the rules
The rules can be configured through Microsoft Intune, Group Policy, Configuration Manager or PowerShell. Locally, Add-MpPreference with the -AttackSurfaceReductionRules_Ids and -AttackSurfaceReductionRules_Actions AuditMode parameters sets a rule to audit, and Get-MpPreference shows the current state.
- Inventory the environment: identify macro-heavy business processes, management agents and line-of-business software.
- Enable all relevant rules in audit mode and collect events for at least two to four weeks, longer for monthly processes.
- Analyze audit events and add narrowly scoped per-rule exclusions for files or folders that are genuinely required.
- Switch to block in rings, starting with IT pilot devices, then broader groups.
- Monitor block events and keep a fast path for users to report broken workflows.
The rules are available on Windows 10, Windows 11 and supported Windows Server versions. Central reporting and advanced hunting require Defender for Endpoint licensing, while basic enforcement works with Defender Antivirus alone.
Common pitfalls
Most problems with attack surface reduction rules come from deployment shortcuts rather than from the rules themselves. The rules are precise, but they assume that administrators know which business software relies on unusual behavior, and that assumption often fails in older environments.
- Third-party antivirus as primary: when Defender runs in passive mode, the rules do not enforce.
- Broad exclusions: excluding whole folders such as user profiles removes most of the protection.
- Skipping audit: enforcing the Office child process rule blindly can stop add-ins and document workflows.
- Conflicting policies: Group Policy and Intune settings applied together can produce unexpected states.
- Ignoring warn mode limits: warn mode is not supported for every rule and depends on the client.
A further misconception is that the rules replace patching or macro restrictions. They block typical follow-up actions of an attack, but a determined attacker can choose techniques outside their scope, so the rules work best as one layer in a defense-in-depth design together with updates, least privilege and application control.
The short version
Attack surface reduction rules are like house rules for programs. Instead of trying to recognize every burglar, the house simply forbids certain actions: a spreadsheet may not open a command window, and an unknown program may not read the password vault.
Most normal software never needs those actions, so blocking them stops many attacks at an early step. The work lies in finding the few business tools that do need them and making careful exceptions.
Where it makes a difference
An accounting firm with 300 Windows 11 laptops enables all rules in audit mode through Intune. After four weeks, the logs show that an old invoicing add-in for Excel triggers the Office child process rule, while no legitimate software triggers the LSASS or obfuscated script rules.
The team adds a single file exclusion for the add-in and switches the rules to block in two rings. Three months later, a phishing email delivers a document whose macro tries to start PowerShell to download a loader. The action is blocked with event ID 1121, the user sees a notification, and the incident ends without any malware reaching the disk.