Roll Out Windows ASR Rules in Audit Mode Before Enforcement

TL;DR — Put Attack Surface Reduction rules into audit mode first with PowerShell or Intune/GPO, then watch Microsoft Defender Operational events for a few days before switching individual rules to block. The most common failure is enabling rules directly in block mode and breaking developer tools, installers, or macro-driven workflows without having the event data to explain why. Reading time: ~5 min

Goal

When you are done, your Windows endpoints will have a defined set of Microsoft Defender ASR rules enabled in audit mode, event logging will show what would have been blocked, and you will have a repeatable path to switch only the low-noise rules to block mode.

Prerequisites

• Local administrator rights on a test Windows machine, or equivalent rights through your endpoint management platform
• Microsoft Defender Antivirus present and active on the endpoint; check with:

Get-MpComputerStatus | Select-Object AMServiceEnabled, AntivirusEnabled, RealTimeProtectionEnabled

• PowerShell 5.1+ or PowerShell 7+ running elevated; check with:

$PSVersionTable.PSVersion

• Windows 10/11 or Windows Server with Defender ASR support
• A list of the ASR rule GUIDs you intend to trial; if you do not already have one, use the example set in this article
• Access to Event Viewer on the endpoint, or centralized collection from Microsoft-Windows-Windows Defender/Operational
• If you deploy via policy: access to your management tool. For Group Policy, you need a GPO editor; for Intune, you need permission to create or edit endpoint security policies

Steps

Step 1: Confirm Defender is the active AV and ASR-capable

Run:

Get-MpComputerStatus | Format-List AMServiceEnabled,AntivirusEnabled,RealTimeProtectionEnabled,IoavProtectionEnabled,BehaviorMonitorEnabled

You should see True for Defender protection fields, for example:

AMServiceEnabled          : True
AntivirusEnabled          : True
RealTimeProtectionEnabled : True
IoavProtectionEnabled     : True
BehaviorMonitorEnabled    : True

Step 2: Choose the rules to trial in audit mode

Start with a conservative set that commonly provides value without immediately breaking developer workflows. In an elevated PowerShell session, define this exact list:

$RuleActions = @{
  "D4F940AB-401B-4EFC-AADC-AD5F3C50688A" = "AuditMode" # Block all Office apps from creating child processes
  "3B576869-A4EC-4529-8536-B80A7769E899" = "AuditMode" # Block Office apps from creating executable content
  "75668C1F-73B5-4CF0-BB93-3ECF5CB7CC84" = "AuditMode" # Block Office apps from injecting code into other processes
  "26190899-1602-49E8-8B27-EB1D0A1CE869" = "AuditMode" # Block Office communication apps from creating child processes
  "BE9BA2D9-53EA-4CDC-84E5-9B1EEEE46550" = "AuditMode" # Block executable content from email client and webmail
  "01443614-CD74-433A-B99E-2ECDC07BFC25" = "AuditMode" # Block executable files from running unless they meet prevalence, age, or trusted list criterion
}

You should have a PowerShell variable named $RuleActions with six GUID/action pairs.

Step 3: Apply those ASR rules in audit mode with PowerShell

Run this exact command:

Add-MpPreference -AttackSurfaceReductionRules_Ids $RuleActions.Keys -AttackSurfaceReductionRules_Actions $RuleActions.Values

Then confirm what Defender stored:

Get-MpPreference | Select-Object -ExpandProperty AttackSurfaceReductionRules_Ids
Get-MpPreference | Select-Object -ExpandProperty AttackSurfaceReductionRules_Actions

You should see the six GUIDs and six action values. On current Windows builds, audit mode is stored as action 2.

Step 4: If you deploy by policy, set the same rules there instead of local PowerShell

Use one of these exact paths.

For Group Policy:

Computer Configuration → Administrative Templates → Windows Components → Microsoft Defender Antivirus → Microsoft Defender Exploit Guard → Attack surface reduction → Configure Attack surface reduction rules

Set the policy to Enabled, then enter one rule per line in this format:

D4F940AB-401B-4EFC-AADC-AD5F3C50688A=2
3B576869-A4EC-4529-8536-B80A7769E899=2
75668C1F-73B5-4CF0-BB93-3ECF5CB7CC84=2
26190899-1602-49E8-8B27-EB1D0A1CE869=2
BE9BA2D9-53EA-4CDC-84E5-9B1EEEE46550=2
01443614-CD74-433A-B99E-2ECDC07BFC25=2

For Intune, use your provider dashboard path for endpoint security ASR rules and set each selected rule to Audit rather than Block.

You should see the policy apply on the endpoint after a refresh.

Step 5: Force policy refresh and verify effective settings

If you used Group Policy, run:

gpupdate /force

Then verify effective settings:

Get-MpPreference | Format-List AttackSurfaceReductionRules_Ids,AttackSurfaceReductionRules_Actions

You should see the intended GUIDs present with action 2 for audit mode.

Step 6: Generate a harmless test event and confirm logging works

Open Event Viewer at this exact path:

Event Viewer → Applications and Services Logs → Microsoft → Windows → Windows Defender → Operational

Or query recent ASR-related events directly:

Get-WinEvent -LogName "Microsoft-Windows-Windows Defender/Operational" -MaxEvents 50 |
  Where-Object { $_.Id -in 1121,1122,5007 } |
  Select-Object TimeCreated, Id, LevelDisplayName, Message |
  Format-List

You should see either configuration change events (5007) after applying policy, or ASR audit events (1121) once a rule condition is hit.

Step 7: Watch audit events for a few days, then promote low-noise rules to block

To review only ASR audit hits:

Get-WinEvent -LogName "Microsoft-Windows-Windows Defender/Operational" |
  Where-Object { $_.Id -eq 1121 } |
  Select-Object TimeCreated, Message |
  Format-List

A typical message shape looks like:

TimeCreated : 10/30/2026 09:14:22
Message     : Attack surface reduction auditing event
              Rule ID: D4F940AB-401B-4EFC-AADC-AD5F3C50688A
              Rule name: Block all Office applications from creating child processes
              File Path: C:\Program Files\Microsoft Office\root\Office16\WINWORD.EXE
              Target Commandline: C:\Windows\System32\cmd.exe /c powershell -ExecutionPolicy Bypass ...
              User: CONTOSO\jdoe

When a rule is clean enough to enforce, switch only that rule from audit (2) to block (1):

Add-MpPreference -AttackSurfaceReductionRules_Ids "D4F940AB-401B-4EFC-AADC-AD5F3C50688A" -AttackSurfaceReductionRules_Actions Enabled

You should then see future hits for that rule as block events (1122) instead of audit events (1121).

Verify it works

Run all three checks.

1. Effective policy on the endpoint:

Get-MpPreference | Format-List AttackSurfaceReductionRules_Ids,AttackSurfaceReductionRules_Actions

Expected: your selected GUIDs are present, and actions are 2 for audit mode or 1 for any rule you intentionally promoted to block.

1. Defender operational log contains ASR events:

Get-WinEvent -LogName "Microsoft-Windows-Windows Defender/Operational" -MaxEvents 100 |
  Where-Object { $_.Id -in 1121,1122,5007 } |
  Select-Object TimeCreated, Id, Message

Expected: 5007 after config changes, 1121 for audit hits, 1122 only for rules you switched to block.

1. Optional per-rule summary for triage:

Get-WinEvent -LogName "Microsoft-Windows-Windows Defender/Operational" |
  Where-Object { $_.Id -eq 1121 } |
  ForEach-Object {
    if ($_.Message -match 'Rule ID:\s*([A-F0-9-]{36})') { $matches[1] }
  } |
  Group-Object | Sort-Object Count -Descending | Select-Object Count, Name

Expected: a count by rule GUID so you can see which rules are noisy before enforcement.

Common pitfalls

Local PowerShell settings get overwritten by GPO or MDM

Mistake: you test with Add-MpPreference, but the device is also managed by Group Policy or Intune.

Symptom: the rule list changes back after gpupdate, reboot, or MDM sync; Event ID 5007 appears repeatedly.

Fix: set the same GUID/action values in the authoritative policy source, not only locally.

You enabled block mode first and broke developer tooling

Mistake: using Enabled or action 1 on first rollout for rules that hit Office, script launchers, or generated executables.

Symptom: builds, installers, macro-driven tasks, or helper processes fail with little user-facing detail; Defender log shows Event ID 1122.

Fix: change the affected rule back to audit with action 2, review 1121 events, then add exclusions only where justified.

You are reading the wrong event log

Mistake: checking only Windows Security logs or your EDR console summary.

Symptom: you think ASR is not firing because you see no useful events.

Fix: query Microsoft-Windows-Windows Defender/Operational directly for IDs 1121, 1122, and 5007.

Another antivirus product is primary

Mistake: Defender is installed but not the active antivirus engine.

Symptom: Get-MpComputerStatus shows AntivirusEnabled : False or protection fields are off; ASR settings do not behave as expected.

Fix: confirm Defender is the active AV on that endpoint before testing ASR, or use the controls provided by your active endpoint protection stack.

You trialed too many rules at once and cannot tell what is noisy

Mistake: enabling a large ASR set across all endpoints on day one.

Symptom: too many 1121 events to triage, and no clear path to enforcement.

Fix: start with a small rule set on a pilot group, then expand after reviewing per-rule event counts.

You forgot that exclusions reduce protection

Mistake: adding broad path exclusions like C:\Dev\* to quiet audit noise.

Symptom: audit volume drops, but you have also carved out a large blind spot.

Fix: use the smallest possible exclusion scope, prefer signer or process-specific exceptions where your management tool supports them, and document every exception before promoting a rule to block.

This article was written by an AI system and published pending human review. Verify anything you intend to act on.