Attack Surface Reduction rules broke a line-of-business app: reading the audit events, finding the rule, and the exclusion that does not work the way you think

A line-of-business application stops working. Not with an error dialogue, not with a crash dump, not with anything in its own log file. The installer runs and reports success, then the executable it dropped simply refuses to start. Or a macro-driven Excel workbook that has run every month for six years does nothing at all when you click the button. Nobody changed the app. Somebody changed Defender.

This is what an Attack Surface Reduction rule in Block mode looks like from the user's chair. ASR - Attack Surface Reduction - is the highest-value hardening you can turn on in Microsoft Defender Antivirus for the least money. It is also the fastest way to lose a week of your life guessing which of nineteen rules killed which of four hundred applications, because the rules identify themselves by GUID and nothing else.

The problem: a rule blocks an app and never says which rule

Start with what ASR actually is, because the name is unhelpful.

Microsoft Defender Antivirus has a signature engine that asks "is this file known to be bad". ASR rules ask a completely different question: "is this behaviour one that malware overwhelmingly uses". Word spawning cmd.exe. A .js file downloading and launching an .exe. A process reading the memory of lsass.exe. Office writing an executable to disk. None of those are malicious in themselves. All of them are far more common in malware than in legitimate software.

So each ASR rule is a hard-coded behavioural block. There are nineteen documented rules. You cannot write your own. You turn each one on or off individually, and each one is addressed by a GUID.

That last part is the root of the pain. When a rule fires, Windows writes an event whose only rule identifier is that GUID. The app that died knows nothing. The user sees a toast that says an operation was blocked by their IT administrator, if they see anything at all. Your service desk gets "the finance tool is broken" and no thread to pull.

The standard failure mode is not subtle, and it is not a Microsoft bug. It is this sequence:

1. Someone reads that ASR rules are high-value and cheap. True.
2. They create an Intune Attack surface reduction policy and set every rule to Block, because Block is obviously better than Audit.
3. They assign it to All Devices.
4. Over the following two weeks, between four and twelve applications break, in ways that never mention Defender.

Microsoft's own deployment guidance is explicit about the alternative. Enable the three standard protection rules in Block mode without extensive testing - those are documented as low-impact. Every other rule goes into Audit mode first, across a pilot ring, and you read the resulting events to find out what your estate actually does before you start blocking it. Audit mode logs exactly what Block mode would have done and blocks nothing.

Why it happens: modes, precedence, and every surface that carries the setting

The five modes, and the two numbers people get wrong

Every ASR rule is set to a numeric mode. Microsoft publishes five values. Two of them look interchangeable and are not.

Note what is not in that table: 0 is not "not configured". If you have seen a runbook that says mode 0 means unconfigured, it is wrong, and the difference matters because 0 is a value Microsoft specifically flags as conflict-prone. Use 5 when you mean "leave it alone".

Warn mode has three sharp edges worth knowing before you lean on it. Two rules do not support it at all - the LSASS credential-stealing rule and the Office code-injection rule - and on any rule or Windows version that does not support Warn, the rule behaves as Block with no bypass. On unsupported Windows versions the same applies. And Microsoft documents that from platform version 4.18.26060, using the Unblock option requires administrator approval, which means Warn mode is no longer a self-service escape hatch for a standard user. Microsoft's own line on this is direct: the Unblock option is for temporary suppression and is not a durable exclusion mechanism.

The chain: what calls what, in order

Understanding where to look means understanding the order of events. From policy to blocked process, the flow is:

1. A management channel writes the rule set. That is Intune, Configuration Manager, Group Policy, or a local Set-MpPreference call.
2. The setting lands in the registry. Which key depends on the channel, and this is where most people go looking in the wrong place - see below.
3. WinDefend, the Microsoft Defender Antivirus Service, reads the configuration. Its host process is MsMpEng.exe.
4. The kernel-mode minifilter WdFilter.sys and the antimalware engine evaluate process creations, memory access and file writes against the enabled rules.
5. If a rule matches and the mode is Block or Warn, the operation is denied. If the mode is Audit, it is allowed.
6. Either way, Defender writes an event to the Microsoft-Windows-Windows Defender/Operational channel, and appends to MPLog on disk.

System files and DLLs in the flow

Only three of these matter day to day, but knowing all of them saves you from chasing a file in the wrong directory. The critical detail is that on a modern Windows 11 build the running Defender binaries do not live in C:\Program Files\Windows Defender - they live in a versioned platform folder under ProgramData that Defender updates itself monthly.

The current platform folder is the highest-numbered directory here:

Services and scheduled tasks

One service carries ASR. The short name and the display name differ, and scripts that look for the display name on a non-English build will fail, so always match on the short name.

None of those scheduled tasks drives ASR evaluation - ASR is inline and real-time, not scheduled. They are listed because "is a scheduled task broken" is a reasonable question to rule out, and the answer here is that there is no ASR scheduled task to break.

The registry, and the key most people search first by mistake

Microsoft documents the Group Policy registry surface for ASR under this parent key. Everything in the table below hangs off it.

The same tree exists without the Policies segment. That non-policy path is the effective, locally-written copy:

That GUID=mode|GUID=mode string is the Policy CSP format, and it is worth recognising because it is what you type into an Intune custom profile OMA-URI, and it is what shows up when you need to prove which policy won a conflict.

Precedence, when two things configure the same rule

Microsoft documents a clear order, and it surprises people who assume cloud beats on-premises.

• Local Set-MpPreference has the lowest precedence. Any policy-based method overwrites it at startup.
• Group Policy overwrites local settings. Where both Group Policy and MDM configure the same rule, Group Policy wins by default.
• MDM (Intune) overwrites local settings, and only beats Group Policy if MDMWinsOverGP is set to 1. There is no GPO and no cmdlet for that setting - it is Policy CSP only, via a custom profile OMA-URI at ./Device/Vendor/MSFT/Policy/Config/ControlPolicyConflict/MDMWinsOverGP.
• Configuration Manager applies through the Policy CSP, so it follows the same MDM precedence.

Within Intune, ASR rules additionally merge across policies. Non-conflicting settings from the endpoint security ASR policy, the older Endpoint protection configuration profile, and the Defender for Endpoint security baseline all combine into a superset for the device. Settings that genuinely conflict are held back - only the conflicting ones, not the whole profile.

How to verify: attributing a block to one rule and one process

This is the part that turns a week of guessing into twenty minutes. Three reads, in order: prerequisites, configured modes, then events.

Step 1: confirm ASR is even enforcing

Before you investigate a block, prove that blocks are possible. The command below reads Defender's own health state. AMRunningMode must be Normal and real-time protection must be True, or no ASR rule is doing anything regardless of its mode.

Step 2: read the configured mode of every rule

Get-MpPreference exposes the rule state as two parallel arrays: AttackSurfaceReductionRules_Ids holds the GUIDs and AttackSurfaceReductionRules_Actions holds the mode codes, positionally matched. Microsoft publishes this one-liner to zip them back together. It is the single most useful ASR command there is.

You now have GUIDs and modes. What you do not have is names. That is the next section's table.

Step 3: the Event Viewer catalog

All ASR events land in one channel. State it once, because the path is long:

Here is the full documented catalog for that channel, across all four attack surface reduction capabilities that share it. Getting these attributed correctly matters, because two of them are commonly misfiled as ASR rule events when they are not.

Rather than clicking through filters every time, import Microsoft's published custom view. It targets exactly the four ASR IDs and covers both the Operational and WHC channels.

Save that as asr-events.xml, then in Event Viewer choose Action then Import Custom View... and pick the file.

Step 4: read the event, and do not misread the two path fields

Here is a genuine 1121 from a managed Windows 11 device, identifiers left intact because there are none - every path is a Windows system binary.

Three things to take from that event.

First, ID is the rule GUID. That is your only rule identifier, and it is why you need the reference table.

Second, the two path fields are not what most people assume. Path here is svchost.exe and Process Name is lsass.exe. For this rule, Path is the process the rule acted on and Process Name is the other party in the relationship. Microsoft does not publish a field dictionary for these events, so treat the direction as something to confirm per rule rather than a rule of thumb - but do not reflexively build an exclusion around whichever path you saw first.

Third, this specific event is noise, and Microsoft says so. The LSASS rule blocks access to LSASS process memory, not process execution. When it blocks svchost.exe, that means svchost was denied a memory read, not stopped from running. Microsoft's guidance is explicit that this rule produces a large volume of audit events almost all of which are safe to ignore, that it suppresses alerts for friendly processes, and that an app which merely enumerates LSASS with no functional impact does not need an exclusion. Fifty-three of these in a fortnight on a healthy device is normal.

The complete rule reference: GUID to name to behaviour

These are the nineteen documented rules. GUIDs are copied verbatim from Microsoft's published tables - never retype one from memory, and never accept one from a blog without checking it, because a single wrong character silently produces a rule that does nothing.

The three standard protection rules first. Microsoft recommends these in Block mode without extensive testing.

Then the sixteen other rules, which Microsoft says to test in Audit mode first.

Every rule except the vulnerable-signed-drivers rule lists Microsoft Defender Antivirus as a dependency, and three rules additionally require cloud-delivered protection to be on: the prevalence rule, the obfuscated-scripts rule, and the advanced ransomware protection rule. If cloud protection is blocked at your proxy, those three do not work.

If you have Defender for Endpoint Plan 2

Everything above works on any Windows edition. With Plan 2 you can skip Event Viewer entirely and query the fleet. Microsoft's documented advanced hunting pattern for audited detections is:

Every rule has a documented pair of action types, Asr...Audited and Asr...Blocked, which means you can attribute a detection to a rule without touching a GUID. Without Plan 2, Windows Event Forwarding gets you the same coverage from the local event channel.

Log files, when the event log is not enough

Defender keeps its own verbose logs on disk. Microsoft's documented route to them is MpCmdRun.exe -GetFiles, which packages everything into a cab:

Three files inside it matter for an ASR case, and Microsoft names them: MPOperationalEvents.txt holds the same content as the Operational event log, MPRegistry.txt is a dump of every current Defender configuration value, and MPLog.txt is the verbose action log. The same support folder also holds rolling MPLog-<timestamp>.log and MPDetection-<timestamp>.log files you can read without generating a cab at all. Search MPRegistry.txt for AttackSurfaceReduction to see the rule list exactly as Defender parsed it - that is the definitive answer to "did my policy actually land".

The fix: three exclusion models, and the one that does not work how you think

You have a rule GUID and a process path. Now you need the app to work without switching the rule off. There are three exclusion mechanisms, they are frequently spoken of as one thing, and they behave differently.

The three mechanisms

1. Microsoft Defender Antivirus exclusions. The ordinary ExclusionPath, ExclusionProcess and ExclusionExtension lists. These are not honoured by every ASR rule. Microsoft publishes a per-rule table of which rules respect antivirus file and folder exclusions and which ignore them. All ASR rules do honour antivirus process exclusions.

2. Global ASR-only exclusions. The AttackSurfaceReductionOnlyExclusions setting. These apply to every ASR rule on the device. Every configuration method supports them.

3. Per-ASR-rule exclusions. Exclusions scoped to one rule GUID. Only three channels can set these: Group Policy (and its registry equivalent), Intune endpoint security policies, and endpoint security policies in the Microsoft Defender portal. Configuration Manager and the plain Policy CSP cannot.

Here is the honouring matrix for the rules most likely to break a line-of-business app. This is the table that explains why an antivirus exclusion someone added last Tuesday changed nothing.

Read the pattern. Seven of the rules that most commonly break real software ignore antivirus file and folder exclusions completely. If your remediation habit is "add an AV exclusion and move on", it will appear to work about half the time and you will never know which half.

Configuring it in Intune - the click path

ASR rules live under Endpoint security, not Configuration. The profile name matters because there are several ASR profiles and only one carries the rules.

1. Sign in to the Microsoft Intune admin center at https://intune.microsoft.com.
2. Select Endpoint security in the left navigation.
3. Select Attack surface reduction.
4. Select Create Policy.
5. For Platform, select Windows.
6. For Profile, select Attack Surface Reduction Rules. Do not pick Device Control, Exploit Protection or App and browser isolation - those are different profiles in the same policy type.
7. Select Create, name the policy, then select Next.
8. On Configuration settings, set each rule you want to Audit for the first pass. Set only the three standard protection rules to Block.
9. As soon as a rule is set to anything other than Not configured, an ASR Only Per Rule Exclusions box appears directly under that rule. This is where a per-rule exclusion goes. Enter a folder path such as C:\LOBApp or a full path and filename such as %ProgramFiles%\LOBApp\app1.exe.
10. Leave Attack Surface Reduction Only Exclusions - the global list, further down the page - empty unless you genuinely mean every rule. You can also bulk load it from a CSV whose single header row reads AttackSurfaceReductionOnlyExclusions.
11. Select Next, then on Assignments add a Microsoft Entra device group. Defender for Endpoint management supports device objects only; targeting user groups is not supported.
12. Select Next, review, then Create. Microsoft notes ASR rules become active within minutes.

If you manage endpoint security policies from the Defender portal instead, the same profile and the same settings are available at https://security.microsoft.com/policy-inventory on the Windows tab.

Configuring it in Group Policy - the click path

The GPO path is deep and the folder is named after Exploit Guard, not ASR, which is why people cannot find it.

1. Open the Group Policy Management Console on your management workstation, or gpedit.msc for a single device.
2. Expand Group Policy Objects, right-click your GPO and select Edit.
3. Navigate to Computer configuration then Administrative templates then Windows components then Microsoft Defender Antivirus then Microsoft Defender Exploit Guard then Attack Surface Reduction. On templates older than Windows 10 2004 the folder reads Windows Defender Antivirus instead of Microsoft - same location.
4. Open Configure Attack Surface Reduction rules, select Enabled, then select Show... next to Set the state for each ASR rule.
5. For each rule, enter the rule GUID as the Value name and the mode code as the Value - 0, 1, 2, 5 or 6. Repeat per rule, then OK.
6. For a global exclusion, open Exclude files and paths from Attack surface reduction rules, select Enabled and Show..., then enter the path as the Value name and 0 as the Value.
7. For a per-rule exclusion, open Apply a list of exclusions to specific attack surface reduction (ASR) rules, select Enabled and Show..., then enter the rule GUID as the Value name and the exclusions as the Value, separated by > characters - for example C:\LOBApp\app1.exe>C:\LOBApp\helper.exe.

Configuring it in PowerShell, and why it is the last resort

PowerShell supports every rule and every exclusion type, and it is the right tool for a lab device. It is the wrong tool for a managed fleet, because local settings have the lowest precedence and any policy channel overwrites them at startup. The documented syntax:

The action parameter accepts 0/Disabled, 1/Enabled for Block, 2/AuditMode, 5/NotConfigured and 6/Warn. Use Add-MpPreference to append. Set-MpPreference overwrites the entire list - both the rule set and the exclusion set - which is how a well-meant one-line fix wipes eighteen other rules. Remove-MpPreference removes specific entries.

Two exclusion behaviours that catch everyone

First, Microsoft documents that exclusions apply only when the application or service starts. Add an exclusion for a service that is already running and it keeps triggering detections until you restart it. If you add an exclusion and nothing changes, restart the process before you conclude the exclusion is wrong.

Second, wildcards and environment variables work, with limits. Wildcards cannot define a drive letter. To cross several nested folders you need repeated \*\ segments. And Microsoft warns against using user environment variables in folder and process exclusions - only system variables, or variables that resolve for the SYSTEM account, expand correctly. A path built on %USERPROFILE% will not do what you expect.

One more, if your fleet uses it: if Disable local admin merge is set to true - through Intune, the Defender CSP DisableLocalAdminMerge, the Defender portal, or the Configure local administrator merge behavior for lists GPO - then per-rule exclusions and local ASR exclusions do not apply at all. That is Microsoft's documented behaviour and it is the single most confusing failure in this whole area, because the exclusion appears in policy and does nothing on the device.

Proof it worked: a real report from a managed device

Everything above is a set of reads you would otherwise do by hand across three consoles. The companion script does them in one pass: it maps every configured GUID to its friendly name, decodes the mode, inventories the exclusions across all three mechanisms, flags rules sitting in Block mode with no retained Audit evidence, and groups recent ASR events by rule and by blocked process. It is strictly read-only - it calls Get-MpPreference, Get-MpComputerStatus, Get-Service, Get-WinEvent and registry reads, and never Set-MpPreference, Add-MpPreference or a registry write.

This is a genuine run on a managed Windows 11 device, with the hostname replaced. Nothing else is edited.

The interesting half is what it found in the exclusion and event sections. Two findings here are the whole reason the script exists.

Read the last block carefully, because it is the shape of a correct diagnosis. Fifty-three blocks, one rule, one process, and the right answer is to do nothing. The script tells you the rule name so you can reach that conclusion in a minute instead of opening a ticket with the svchost owner.

And the Block-without-Audit check on this device flagged all eight enforcing rules as having no retained 1122 event - which, read naively, looks like eight rules that skipped the audit pass. It is not, and the script says so in its own output: the log only retains eleven days, three of those are standard protection rules that Microsoft says can go straight to Block, and audit events from a rollout months ago are long gone. A heuristic that admits it is a heuristic is worth having. One that quietly reports a number is not.

The script lives at Windows-11-Scripts\defender-asr-rules-audit-block-reference\Get-AsrRuleStateReport.ps1. It needs no modules installed - Get-MpPreference and Get-MpComputerStatus ship in the box - and it runs on both Windows PowerShell 5.1 and PowerShell 7. It refuses to run non-elevated, on purpose, because the Defender registry keys and the Operational log are access-controlled and a non-elevated run produces a clean-looking report that is simply wrong.

References

Microsoft-official:

• Attack surface reduction rules overview - the rule-to-GUID table, the modes table, requirements, and the exclusion honouring matrix.
• ASR rules reference - per-rule detail, dependencies, OS support, and the advanced hunting action types.
• Configure ASR rules and exclusions - the Intune, Group Policy, Policy CSP and PowerShell procedures, and the precedence rules.
• Attack surface reduction events in Windows Event Viewer - the authoritative event ID catalog and the custom view XML.
• Troubleshoot ASR rules - the Get-MpPreference zip one-liner, the event ID filter list, and the diagnostic data collection steps.
• Test your ASR rules deployment - the Audit-first deployment sequence.
• Manage attack surface reduction settings with Microsoft Intune - the profile list, the merge behaviour, and the global versus per-rule exclusion settings.
• Defender Policy CSP - AttackSurfaceReductionRules and AttackSurfaceReductionOnlyExclusions.
• Collect Microsoft Defender Antivirus diagnostic data - the platform folder path and MpCmdRun.exe -GetFiles.

Community deep-dives, both fetched and confirmed on topic: