Attack surface reduction rules without breaking a business application

Attack surface reduction rules block specific behaviours rather than specific files. Office applications creating child processes, scripts launching downloaded executables, credential theft from LSASS, executable content arriving by email — these are the mechanics that most commodity attacks depend on, and blocking the mechanic blocks the whole class.

They are among the highest-value endpoint controls available, and they have a deserved reputation for breaking things. Both statements are true, and the second is entirely manageable if you deploy them in the right order.

The threat these rules address

Most endpoint compromise follows a small number of patterns:

• A document arrives, the user enables macros, the macro spawns a process that downloads a payload.
• A script interpreter runs obfuscated content that pulls an executable from the internet.
• An executable runs from a USB device.
• A process reads LSASS memory to harvest credentials — the attack discussed in protecting LSASS.
• A legitimate signed Windows binary is used to execute something it was not intended to.

Signature-based detection catches the known payloads. ASR rules block the technique regardless of the payload, which is what makes them valuable against things nobody has seen before.

Exposure: the rules, and which ones are contentious

Microsoft maintains the rule set, and it changes, so work from the current reference rather than a list in an article. What is stable is the shape of the risk, and the rules group into three categories by how likely they are to cause trouble.

Low risk in most estates. Blocking credential stealing from LSASS. Blocking executable content from email and webmail. Blocking untrusted and unsigned processes running from USB. Blocking persistence through WMI event subscription. Blocking abuse of vulnerable signed drivers. Most organisations can deploy these with little disruption.

Moderate risk, depends on the estate. Blocking Office applications from creating child processes, injecting into other processes, or creating executable content. These break legitimate Office automation, which a surprising number of finance and operations teams depend on. Blocking JavaScript and VBScript from launching downloaded executable content.

High risk, needs real investigation. Blocking all Office applications from creating child processes where a business application drives Office programmatically. Blocking process creations originating from PSExec and WMI commands — this one frequently breaks remote management and software deployment tooling, including some legitimate administration workflows. Blocking executables unless they meet a prevalence, age or trusted list criterion, which catches internally developed and rarely used software.

The high-risk rules are the ones that make the difference against a determined attacker and the ones most likely to stop someone’s month-end process. That tension is the whole subject.

Assessment: audit mode is not optional

Every rule supports four states: not configured, audit, block, and warn, where warn lets the user override the block.

Audit mode records what the rule would have blocked and blocks nothing. This is the entire deployment strategy and it is why ASR deployments succeed or fail.

1. Deploy every rule you are considering in audit mode, to the whole estate or a representative sample.
2. Leave it for a full business cycle. A month, covering month-end. The rules that catch you out are the ones that fire during a quarterly process, and a two-week audit will not see them.
3. Analyse the audit events, by rule and by application.

The analysis is the work. For each audit event, decide: is this the attack pattern the rule exists to stop, or is it a legitimate application doing something unusual? The answer decides whether you block, exclude, or leave the rule in audit.

Defender for Endpoint provides a report view for this, and the events are also in the Windows Defender operational log on each device:

# ASR audit and block events on a device.
Get-WinEvent -LogName 'Microsoft-Windows-Windows Defender/Operational' -MaxEvents 200 |
    Where-Object { $_.Id -in 1121, 1122 } |
    Select-Object TimeCreated, Id, Message |
    Format-List

Where an estate-wide picture is needed, advanced hunting across the Defender data is a better tool than per-device log collection.

Hardening: the deployment sequence

1. Enable the low-risk rules in block mode early. The cost is small and the benefit is immediate. Do not wait for a full audit programme to deploy the LSASS credential-theft rule.
2. Everything else in audit mode, across the estate.
3. Analyse for a full cycle, per rule.
4. Move rules to block individually, starting with the ones that produced no legitimate audit events. One rule at a time, so any problem is attributable.
5. Use exclusions sparingly and specifically. Exclude a file or path, per rule where the product supports it, rather than disabling the rule for everyone. An exclusion is a permanent hole, so it needs an owner and a review date.
6. Consider warn mode for rules where you want the protection but cannot rule out a legitimate case. The user can override, you get the telemetry, and you find the remaining cases without blocking anyone.
7. Re-audit new rules as Microsoft adds them. A new rule deployed straight to block is the same mistake as before, made later.

Deploy through one management channel. ASR rules can be set through Intune endpoint security policy, Group Policy, PowerShell and Configuration Manager, and setting them in more than one place produces exactly the conflicts described in Intune policy conflicts. Pick one and keep to it.

Detection

Block events are security events and should be treated as such. A rule firing in block mode means either an attack was stopped or a legitimate process was interrupted, and both need somebody to look.

• Alert on block events, grouped by rule and process, so a spike is visible.
• Watch for a new application generating blocks, which usually means a legitimate change somebody did not tell you about.
• Review exclusions periodically, with the owner. Exclusions accumulate and each one is a gap in a control you deployed deliberately.

Validation

• Confirm the rules are actually applied on devices, not merely assigned. Check the effective configuration on a sample of machines.
• Confirm a rule blocks what it should, using a safe, approved test in a controlled environment.
• Confirm your business-critical applications still work — specifically the ones using Office automation, scripts, or remote execution tooling, tested by the people who use them.
• Confirm the events reach your monitoring. A rule blocking silently, with nobody seeing the event, is half a control.

Rollback

Set the rule back to audit, or to not configured. It takes effect on the next policy refresh, which is fast but not instantaneous — a user blocked from doing their job will feel the interval.

That latency is the practical argument for the one-rule-at-a-time approach: when something breaks, you know which rule to change, and you change one setting rather than unpicking a bundle. Deploying twelve rules to block simultaneously and then having a month-end process fail leaves you guessing under pressure.

Honest limits

ASR rules reduce the techniques available to an attacker on the endpoint. They do not prevent a user entering credentials into a phishing page, they do not protect a server that is not running Defender, and they are not a substitute for patching or for the privileged access design in administrative tiering.

They also depend on Microsoft Defender Antivirus being the active antivirus. Where a third-party product is in use and Defender is in passive mode, check what actually applies rather than assuming the rules are in force — this is a common gap in estates that adopted a third-party product and then deployed ASR policy anyway.

Verification and limits

ASR rule states including audit, block and warn, the per-rule exclusion capability, the deployment channels and the Defender operational log event IDs for audited and blocked operations were checked against current Microsoft documentation on 20 September 2026. The risk categorisation of rules and the deployment sequence are my own judgement, offered as a starting point rather than as Microsoft guidance.

Nothing here was deployed or tested for this article. Rules in block mode can stop legitimate business processes — deploy in audit mode, analyse a full business cycle, move one rule at a time, and confirm Defender Antivirus is actually active on the targets. The rule set and per-rule behaviour change; work from the current Microsoft reference rather than any list.

References

• Attack surface reduction rules overview
• Attack surface reduction rules reference
• Enable attack surface reduction rules
• Attack surface reduction rules deployment