Attack surface reduction rules are one of the few Windows hardening controls that stop real intrusion techniques without a new agent or a new license: the capability ships inside Defender Antivirus on Windows 10 1709 and later, Windows 11, and Windows Server 2019 and newer. Most environments still run a large chunk of the rule set in audit mode two or three years after first enabling it, and the reason is rarely cost. It is the fear of walking in on a Monday to find several thousand users can no longer open a mail merge attachment, or that a finance macro built in 2014 has stopped working with no owner left to fix it. What follows is a staged path from audit telemetry to a defensible block-mode rollout: how to group the rule set by what it actually stops, where the audit events land and how to size the real noise, how to rank rules for a first enforcement wave, how to scope exclusions so they do not quietly disable the protection they were meant to patch around, which deployment channel to use, and how to confirm the policy you pushed is the policy actually running on the endpoint.
Group the rule set by what it actually blocks
The published attack surface reduction rules are easier to reason about once you stop treating them as one undifferentiated list and sort them by the technique they interrupt. Four groupings cover almost all of them.
Office and email child-process rules
This group stops the most common initial-access chain: a document or email attachment spawning something that was never meant to run. Block all Office applications from creating child processes (GUID D4F940AB-401B-4EFC-AADC-AD5F3C50688A) and Block Office applications from creating executable content (3B576869-A4EC-4529-8536-B80A7769E899) sit here, along with the narrower Block Office communication application from creating child processes (26190899-1602-49E8-8B27-EB1D0A1CE869) aimed at Teams and Outlook add-in abuse.
Script, macro and obfuscation rules
These target the second stage, after a document has already delivered a payload. Block execution of potentially obfuscated scripts (5BEB7EFE-FD9A-4556-801D-275E5FFC04CC), Block JavaScript or VBScript from launching downloaded executable content (D3E037E1-3EB8-44C8-A917-57927947596D), and Block Win32 API calls from Office macros (92E97FA1-2EDF-4476-BDD6-9DD0B4DDDC7B) fall in this bucket. They are also the group most likely to catch legitimate internal tooling, because plenty of line-of-business automation is built on exactly the same primitives attackers use.
Credential theft and lateral-movement rules
This is the group with the best benefit-to-breakage ratio in most environments. Block credential stealing from the Windows local security authority subsystem (9E6C4E1F-7D60-472F-BA1A-A39EF669E4B2) stops LSASS memory access, the technique behind most Mimikatz-style dumping. Block process creations originating from PSExec and WMI commands (D1E49AAC-8F56-4280-B9BA-993A6D77406C) and Block persistence through WMI event subscription (E6DB77E5-3DF2-4CF1-B95A-636979351E5B) interrupt the lateral movement and persistence steps that follow initial access.
Removable media and untrusted execution rules
Block untrusted and unsigned processes that run from USB (B2B3F03D-6A65-4F7B-A9C7-1C7EF74A9BA4) and Use advanced protection against ransomware (C1DB55AB-C21A-4637-BB3F-A12568109D35) close off execution paths that rarely have a legitimate business reason to exist on a managed endpoint, which is why they tend to generate the lowest audit volume of the whole set.
| Category | Typical audit volume | Typical breakage source |
|---|---|---|
| Office child process and content | Moderate to high | Legacy macros, mail merge add-ins, PDF converters called from Office |
| Script and obfuscation | Moderate | Internal PowerShell and VBScript automation, RMM agents |
| Credential theft and lateral movement | Low | Legitimate remote administration tools using PSExec-like invocation |
| Removable media and untrusted execution | Low | Vendor USB installers, field technician media |
Where audit telemetry lands and how to size real-world noise
Locally, every audit-mode match writes to the Microsoft-Windows-Windows Defender/Operational event log. Event ID 1121 is a block, 1122 is an audit hit that would have blocked, and 1129 is a warn-mode interstitial. That log is fine for a single laptop but useless for sizing fleet-wide impact.
For anything past a handful of machines, pull the data from Microsoft Defender for Endpoint’s advanced hunting instead. The DeviceEvents table carries an ActionType field that starts with “Asr” and ends in Audited, Blocked or Warned, and AdditionalFields includes the rule identifier. A starting query looks like this:
- DeviceEvents
- | where Timestamp > ago(30d)
- | where ActionType startswith “Asr”
- | summarize Hits = count() by ActionType, FolderPath, InitiatingProcessFileName
- | order by Hits desc
Run the window across at least thirty days, not seven. A shorter window misses month-end billing runs, quarterly close macros, and payroll jobs that only fire on specific dates, and those are exactly the events that generate angry tickets if you flip to block without seeing them first. Group by FolderPath and InitiatingProcessFileName before you group by device count, because a rule with ten thousand raw audit events might trace back to three distinct file-and-process combinations run by one build server, not a fleet-wide problem.
That collapse step, from raw event volume down to a small number of unique root causes, is the same deduplication problem vulnerability management teams already solve at the scanner layer, where the same underlying flaw shows up as dozens of near-identical findings across tools. Platforms that automate that collapse before a human ever triages a result, SITEY among them, apply the same logic to scanner output that you are applying here to ASR audit data: collapse to a unique cause first, count impact second.
Ranking rules by benefit-to-breakage ratio for the first wave
Sort the audit results two ways at once: by how many distinct legitimate processes triggered the rule, and by how central the technique is to real attack chains. Rules with zero or near-zero audit hits over your sizing window and high coverage of a documented attacker technique, LSASS credential access, PSExec-style lateral movement, obfuscated script execution, untrusted USB execution, belong in wave one. They carry almost no measured breakage risk and close off techniques mapped directly to MITRE ATT&CK entries such as OS credential dumping and remote services abuse.
Wave two is for rules with moderate hit counts once you have applied targeted exclusions and watched the environment for another two weeks with no new failures. Office child-process and macro Win32 API rules usually land here, since they touch business logic that took years to build and nobody wants to own breaking.
Hold the highest-hit rules back until the exclusion list is proven stable, meaning no new audit hits for that specific rule across a full business cycle including any month-end or quarter-end processing. Flipping a rule with three hundred outstanding audit sources to block on a single change window is how ASR projects get rolled back and never revisited.
The same math underlies a risk-scoring phase in vulnerability management: sort first by exploitability and blast radius, sort second by the operational cost of the fix. An autonomous vulnerability management platform such as SITEY runs that scoring automatically against exploit availability, asset criticality and CVSS; applying the same two-axis logic by hand to ASR audit counts and ATT&CK coverage gets a security team to a defensible wave-one list without needing a scoring engine of its own. See how that scoring phase works in the attack surface management module for a fuller picture of how exposure gets ranked before remediation.
Exclusions done right, scoped to a rule, not applied globally
A structural fact trips up most first deployments: Defender’s AttackSurfaceReductionOnlyExclusions list is not scoped per rule. Every path or process added there is exempted from every enabled ASR rule at once, not only the one that flagged it during audit. There is no native control-plane setting that limits an exclusion to a single rule GUID.
The practical response is discipline outside the tool, not a feature inside it. Keep every exclusion entry mapped one to one against the specific rule and audit event that justified it in your own change record, even though Defender itself will not remember that connection six months later. Scope the exclusion as tightly as the false positive allows: a specific executable path and, where the tooling supports it, a specific parent process combination, never a whole folder such as C:ProgramData or C:Users*AppDataLocalTemp. A folder-level exclusion silences the rule for anything an attacker later drops in that same folder, which defeats the point of enabling the rule in the first place.
Add and review exclusions with PowerShell rather than editing the registry by hand:
- Add-MpPreference -AttackSurfaceReductionOnlyExclusions “C:PathTolegit_tool.exe”
- (Get-MpPreference).AttackSurfaceReductionOnlyExclusions
Put a quarterly review on the calendar for the exclusion list specifically. Applications get patched, replaced or retired, and an exclusion written to accommodate a 2022 accounting macro is dead weight, and a live gap, if the underlying process was retired in 2024 and nobody removed the line. Tracking exclusions through to a documented closure date belongs in the same lifecycle discipline used for any other security exception; the vulnerability lifecycle module covers that closure-tracking pattern in more depth for exceptions raised elsewhere in a security program.
Deployment paths: GPO, registry and PowerShell, and how conflicts resolve
Four channels can set ASR rule state, and they do not always agree with each other when more than one targets the same device.
Group Policy sets rules under Computer Configuration, Administrative Templates, Windows Components, Microsoft Defender Antivirus, Microsoft Defender Exploit Guard, Attack Surface Reduction, as a list of GUID equals state pairs, where 0 is off, 1 is block, 2 is audit and 6 is warn.
Registry edits land under HKLMSOFTWAREPoliciesMicrosoftWindows DefenderWindows Defender Exploit GuardASRRules, one REG_SZ value per rule GUID holding the state number, with exclusions under the sibling ASROnlyExclusions key. GPO and Intune both write here under the hood, so reading it directly is the reliable way to check what state is actually applied on a given machine.
Intune delivers the same settings through the Attack Surface Reduction Rules profile under Endpoint Security, backed by the Defender configuration service provider, and is the right channel for hybrid and cloud-only fleets and for staging rules to a pilot group before a wider push.
PowerShell, via Add-MpPreference or Set-MpPreference with the AttackSurfaceReductionRules_Ids and AttackSurfaceReductionRules_Actions parameters, suits a canary device or a lab machine, but sets local, unmanaged state that the next GPO refresh or Intune sync will overwrite, since policy-managed values always take precedence over locally set ones. A device that appears to revert from block back to audit on its own was almost certainly locally tested and then resynced against policy.
When a device is targeted by both GPO and Intune, check the tenant-wide MDM and GPO precedence setting in Intune before assuming which one wins. That setting governs ADMX-backed policies, and ASR’s Intune profile is CSP-based rather than ADMX-backed, so on a hybrid-joined pilot device, verify the outcome directly rather than infer it from documentation.
Measuring enforcement coverage across the fleet, not assuming policy equals state
A policy assignment is a statement of intent, not a confirmation that the intent landed. The Attack Surface Reduction Rules report under Reports, Endpoints in Microsoft 365 Defender breaks down configured state per rule per device: block, audit, warn, off, not configured, or no data. “No data” usually means an onboarding gap or a licensing mismatch and is worth chasing down rather than treated as background noise, since it hides devices that may not be enforcing anything at all.
Third-party antivirus coexistence and tamper protection are the two most common causes of silent drift between the policy pushed and the state actually running. A device running Defender in passive mode alongside another AV product shows a policy assignment without functional enforcement, and that distinction rarely surfaces in a summary report. Cross-check a sample of devices directly, either by querying (Get-MpPreference).AttackSurfaceReductionRules_Ids and Actions remotely, or by reading the registry keys above through your management tooling, rather than trusting the console’s cached rollup during the first weeks of a rollout.
Trusting an assignment status as proof a control is working is the same mistake a vulnerability program makes when it closes a finding because a patch ticket was marked done, not because the fix was re-tested against the original vulnerable condition. Platforms that automate that retest step, SITEY included, re-check the specific finding on the specific asset instead of trusting the deployment record, and the same discipline holds here: query the device, do not read the policy. Once enforcement is confirmed rather than assumed, mapping which ASR rules satisfy which framework control, CIS Benchmark hardening items, ISO 27001 Annex A malware protection controls, or PCI DSS anti-malware requirements, is a documentation exercise worth doing once and keeping current; the compliance mapping module covers how that control-to-framework mapping is maintained as frameworks and rule sets both change over time.
Re-verify weekly during the active rollout window and monthly once the fleet has settled into steady state. ASR enforcement is not a project with an end date; new rules get published, existing rules get renumbered or merged, and endpoints get reimaged with defaults that do not match policy until the next sync cycle runs.
About SITEY
SITEY is an autonomous vulnerability management platform. It discovers, validates, prioritizes, remediates and re-tests vulnerabilities through an eight-phase automated pipeline, unifying output from 17 integrated scanners. SITEY is self-hosted: it runs in your own infrastructure and your findings are stored there. Outbound connections are limited to licence activation and the optional services you enable, such as an AI provider, CVE enrichment and patch catalogues. Pricing is 599 USD per month or 5,999 USD for a perpetual lifetime license. See pricing or how the platform works.