Attack surface reduction rules: move from audit mode to block safely

Attack surface reduction (ASR) rules move safely from audit to block when you run them in rings: put every non-standard rule in Audit mode on a small pilot group, read the audit events in the ASR rules report or advanced hunting, add narrow per-rule exclusions for the legitimate line-of-business apps they catch, and then switch rules to Block (or Warn) one at a time, starting with the rule that fired least. The three standard protection rules can usually go straight to Block. Repeat the same audit, exclude and block cycle for each wider ring until every Windows device is covered.

Who this is for and what you will have

This guide is for endpoint and security administrators who manage Windows devices with Microsoft Intune and Microsoft Defender for Endpoint and want to enforce ASR rules without a wave of help desk tickets when a finance macro or a vendor updater stops working. It also notes the Group Policy and PowerShell equivalents for environments that don't use Intune.

At the end you will have:

• A ring plan and a list of champions who see each change first.
• An Intune Attack surface reduction policy with the standard protection rules in Block and the remaining rules in Audit.
• Advanced hunting queries that rank audited detections by rule, file and device.
• Per-rule exclusions for the legitimate apps that trigger rules.
• Rules moved to Block or Warn per ring, with a way to check the effective state on any device.

ASR rules harden the device itself. They complement identity controls such as Conditional Access device compliance, which the zero trust remote access architecture covers from the network and identity side.

How ASR rules work

ASR rules are a Microsoft Defender Antivirus feature that targets behavior attackers commonly abuse: Office apps creating child processes, scripts launching downloaded executables, obfuscated scripts, code injection and credential theft from LSASS. Legitimate software sometimes does the same things, which is why most rules need testing first.

Rule modes

Every rule has a mode, set by name in Intune or by a numeric code in Group Policy, the Policy CSP and PowerShell:

Warn mode needs Windows 10 version 1809 or later and Defender Antivirus platform 4.18.2008.9 and engine 1.1.17400.5 or later. On older Windows versions a rule in Warn mode behaves as Block. Warn mode isn't available in Configuration Manager, and two rules don't support it: Block credential stealing from the Windows local security authority subsystem and Block Office applications from injecting code into other processes. Microsoft also documents that from platform version 4.18.26060 the Unblock option requires administrator approval, and that Unblock is meant for temporary suppression, not as a substitute for an exclusion.

Standard protection rules and the rest

Microsoft groups the rules into two categories:

Two exceptions apply to the standard rules. If Configuration Manager manages your devices, test Block persistence through WMI event subscription in Audit mode first, because the Configuration Manager client relies heavily on WMI. And if LSA protection is already enabled, the LSASS rule adds nothing and the Defender portal shows it as not applicable.

Prerequisites

• Microsoft Defender Antivirus in active mode. ASR rules don't run when Defender Antivirus is in passive mode, passive mode with EDR in block mode, limited periodic scanning, or off. Real-time protection must be on.
• Cloud-delivered protection enabled and able to reach the Defender Antivirus cloud service. Several rules depend on it, including Block executable files from running unless they meet a prevalence, age, or trusted list criterion, Block execution of potentially obfuscated scripts and Use advanced protection against ransomware.
• Current Defender components. Platform, engine and security intelligence should be no more than two versions behind the latest; Microsoft notes that staying current reduces ASR false positives.
• Licensing for reporting. ASR rules themselves don't need Microsoft 365 E5, but the ASR rules report and device timeline need Defender for Endpoint Plan 2 or Defender for Business, and advanced hunting needs Defender for Endpoint Plan 2. Without them, audit data exists only in each device's Event Viewer.
• Intune Plan 1 for endpoint security policies, and devices onboarded to Defender for Endpoint so reporting works regardless of how the rules were deployed.
• Report access: the Defender XDR Unified RBAC permission Security operations \ Security data \ Security data basics (read), or the Entra ID Security Reader, Global Reader or Security Administrator role.

Step 1: Plan rings and champions

Microsoft's deployment guide uses rings, and you can usually reuse the rings you already have for Windows updates. Before you touch policy:

1. Pick the first business unit. Smaller is easier to manage, but a unit with a broad mix of software, shared folders, scripts and Office macros surfaces more issues early.
2. Name champions. These are technically comfortable users who tolerate occasional disruption and have a direct channel to report problems.
3. Inventory line-of-business apps and how each unit uses them. Rules are harder to deploy where unsigned, internally developed apps and scripts are common, so note which tools are unsigned.
4. Assign roles: who gathers reports, who approves exclusions, and who investigates real blocked threats.
5. Disable conflicting rules. Before testing, turn off any related rules already in Block or Warn mode elsewhere, and avoid configuring the same rule in both Group Policy and Intune. By default Group Policy wins over MDM unless MDMWinsOverGP is set through the ControlPolicyConflict Policy CSP.

Step 2: Deploy the audit policy with Intune

1. In the Microsoft Intune admin center, go to Endpoint security > Attack surface reduction and select Create policy.
2. For Platform, select Windows. For Profile, select Attack Surface Reduction Rules.
3. On Configuration settings, set the three standard protection rules to Block and every other rule you intend to use to Audit.
4. Leave Attack surface reduction only exclusions empty for now. You will add exclusions from data, not guesses.
5. Assign the policy to a Microsoft Entra device group for ring 1. Defender for Endpoint management supports device objects only, so user groups don't work.

If you manage endpoint security from the Defender portal instead, the same policy type is under Endpoint security policies > Windows policies with the Attack surface reduction rules template.

For a single lab device, or where Intune isn't available, PowerShell sets the same modes locally. Add-MpPreference adds rules without overwriting existing ones; Set-MpPreference replaces the whole list. Policy from Intune, Configuration Manager or Group Policy overwrites local settings at startup.

# Run elevated. 2 = Audit. Office child processes, obfuscated scripts, JS/VBS launching downloads
Add-MpPreference -AttackSurfaceReductionRules_Ids d4f940ab-401b-4efc-aadc-ad5f3c50688a,5beb7efe-fd9a-4556-801d-275e5ffc04cc,d3e037e1-3eb8-44c8-a917-57927947596d -AttackSurfaceReductionRules_Actions AuditMode,AuditMode,AuditMode

Other MDM tools use the ./Vendor/MSFT/Policy/Config/Defender/AttackSurfaceReductionRules OMA-URI with a string of GUID=mode pairs separated by | and no spaces. In Group Policy, the settings are under Computer configuration > Administrative templates > Windows components > Microsoft Defender Antivirus > Microsoft Defender Exploit Guard > Attack Surface Reduction.

Step 3: Read the audit data

Let the audit policy run long enough to cover the work your pilot users actually do, including month-end tasks and any scripts that run on a schedule. Then review the data in three places.

The ASR rules report

In the Defender portal, go to Reports > Endpoints > Attack surface reduction rules (https://security.microsoft.com/asr). On the Detections tab, change the Rules filter from Standard protection to All; the default only shows the three standard rules. Add the Blocked/Audited? filter and choose Audited. The table shows the detected file, source app, device, user and publisher. The table lists a limited number of detections, so use Export for the full set. The Configuration tab shows each device's rule states, which is how you confirm the policy actually landed.

Advanced hunting

Advanced hunting keeps 30 days of raw data in the DeviceEvents table. ASR events there are throttled to unique processes per hour, so treat counts as relative, not exact. Start with a ranking of audited rules:

DeviceEvents
| where Timestamp > ago(30d)
| where ActionType startswith "Asr" and ActionType endswith "Audited"
| summarize Events = count(), Devices = dcount(DeviceId) by ActionType
| order by Events asc

Rules at the top of that list, with few events on few devices, are your first candidates for Block. For a noisy rule, find out which files and parent processes cause the events. This example uses the Office child process rule's action type:

DeviceEvents
| where Timestamp > ago(30d)
| where ActionType == "AsrOfficeChildProcessAudited"
| extend Fields = parse_json(AdditionalFields)
| summarize Events = count(), Devices = dcount(DeviceId) by FileName, FolderPath, InitiatingProcessFileName, RuleId = tostring(Fields.RuleId)
| order by Events desc

Each rule has its own audited and blocked action types listed in the ASR rules reference, for example AsrObfuscatedScriptAudited, AsrScriptExecutableDownloadAudited and AsrPsexecWmiChildProcessAudited.

Event Viewer

On a device without Plan 2, open Applications and Services Logs > Microsoft > Windows > Windows Defender > Operational. ASR uses these event IDs:

Windows Event Forwarding can centralize these events if you don't have Defender reporting.

Step 4: Add exclusions the narrow way

For each detection, decide whether the behavior is legitimate and required. If it is, add an exclusion. Microsoft's guidance is that an exclusion is better than turning a rule off or sending it back to Audit, but excluded files run with no events recorded, so keep exclusions as specific as possible.

There are three ASR-relevant exclusion types:

Prefer per-rule exclusions. In the Intune policy, after you set a rule to Audit, Block or Warn, an ASR only per rule exclusions field appears under it; enter the full path to the executable, such as %ProgramFiles%\Contoso\Updater\update.exe. Use a file path rather than a folder where you can. Paths support system environment variables and wildcards, but not user environment variables, and a wildcard can't define a drive letter.

Don't rely on antivirus exclusions for ASR. Several rules ignore antivirus file and folder exclusions, including Block credential stealing from the Windows local security authority subsystem, Block persistence through WMI event subscription, Block Office applications from injecting code into other processes and Block process creations originating from PSExec and WMI commands.

Two more details:

• Exclusions apply when the app or service starts. A running update service keeps triggering the rule until it restarts.
• If Disable Local Admin Merge is enabled, per-rule and local ASR exclusions don't apply in some configurations, so check that setting if an exclusion seems to be ignored.

Step 5: Switch rules to block or warn

With exclusions in place for ring 1:

1. Change one rule, the one with the fewest audited events, from Audit to Block in the policy. Use Warn instead for rules where you expect occasional legitimate use and want users to be able to proceed while you collect data.
2. Watch blocked events and listen to champions for a few days.
3. Refine exclusions, then move the next rule.

This query shows what is being blocked, plus warn overrides for rules that record them, such as AsrAbusedSystemToolWarnBypassed:

DeviceEvents
| where Timestamp > ago(7d)
| where ActionType startswith "Asr" and (ActionType endswith "Blocked" or ActionType endswith "WarnBypassed")
| summarize Events = count(), Devices = dcount(DeviceId) by ActionType, FileName, InitiatingProcessFileName
| order by Events desc

When ring 1 is stable, expand to the next ring by repeating the same sequence: Audit, review, exclusions, Block, review again, and disable or return problem rules to Audit only as a last resort.

Verify the configuration on a device

Run this on a device, from Microsoft's troubleshooting guidance, to list each configured rule and its mode:

$p = Get-MpPreference;0..([math]::Min($p.AttackSurfaceReductionRules_Ids.Count,$p.AttackSurfaceReductionRules_Actions.Count)-1) | % {[pscustomobject]@{Id=$p.AttackSurfaceReductionRules_Ids[$_];Action=$p.AttackSurfaceReductionRules_Actions[$_]}} | Format-Table -AutoSize
(Get-MpPreference).AttackSurfaceReductionOnlyExclusions

An action of 1 is Block, 2 is Audit and 6 is Warn. In the Defender portal, the device page's Effective settings tab shows each setting's value and the source that configured it, and the Configuration tab of the ASR report shows the same per device.

Troubleshooting

A rule that should block does nothing. Check the mode first; rules often stay in Audit after testing or get reset by a script. Then confirm Defender Antivirus is in active mode with real-time protection on. Office-related rules such as the child process and injection rules are only enforced when Office is installed under %ProgramFiles% or %ProgramFiles(x86)%.

The Group Policy setting is ignored. Quotation marks, leading or trailing spaces and extra characters aren't supported in ASR values in Group Policy. Check the GUIDs for stray characters, and remember that Intune and Group Policy conflicts follow the precedence described in Step 1.

The LSASS rule logs huge numbers of events. This is expected. Many processes open LSASS with more rights than they need; the rule blocks memory access, not the process. Microsoft notes that most of these events are safe to ignore and that you can move this rule to Block without a long audit.

An app is blocked by "Block use of copied or impersonated system tools". The rule can also treat legitimate third-party executables running from non-default paths as system-tool-like. If the file is legitimate, add a per-rule exclusion for it.

Users see no notification on some blocks. Some rules don't raise user notifications, and for others notifications and EDR alerts depend on the cloud protection level. The email, Adobe Reader and JavaScript or VBScript rules only show pop-ups at the High, High plus or Zero tolerance cloud protection level.

An exclusion still doesn't help. Restart the excluded service or app. If the rule still fires, collect diagnostics with the MDE Client Analyzer in verbose mode (MDEClientAnalyzer.cmd -v) or MpCmdRun.exe -GetFiles, and report false positives through the Microsoft Security Intelligence submission form.

Checklist

• Defender Antivirus active, real-time and cloud-delivered protection on, components current.
• Rings, champions and an app inventory defined; conflicting GPO and MDM settings removed.
• Standard protection rules in Block; other rules in Audit for ring 1 through an Intune device-targeted policy.
• Audit data reviewed in the ASR report, advanced hunting and, where needed, Event Viewer.
• Per-rule exclusions, as specific as possible, for each legitimate detection.
• Rules switched to Block or Warn one at a time, starting with the quietest.
• Rule state verified with Get-MpPreference and the report's Configuration tab before each new ring.
• A recurring review of blocked events and exclusions after rollout.

References

• ASR rules deployment guide
• Plan your ASR rules deployment
• Test your ASR rules deployment
• Enable your ASR rules deployment
• ASR rules overview
• ASR rules reference
• Configure ASR rules and exclusions
• ASR rules report
• Monitor ASR rule activity
• Attack surface reduction events in Windows Event Viewer
• Troubleshoot ASR rules