Microsoft Defender ASR rules: moving from Audit to Block without disrupting production

Why ASR rules matter

Attack surface reduction rules limit behaviours that attackers frequently abuse: child processes launched from Office, executable email content, obfuscated scripts, credential theft from LSASS, code injection, and misuse of PsExec or WMI.

They complement antivirus and EDR by stopping a technique before it becomes a compromise. Their effectiveness still depends on a controlled rollout because some business applications legitimately behave in ways that resemble malware.

Audit, Warn and Block serve different purposes

Audit mode simulates enforcement and records events without interrupting users. It provides no active protection, but it reveals the practical impact of each rule in the environment.

Warn enforces a supported rule while allowing a temporary override. Block prevents the action. Some rules, including LSASS credential protection and Office code-injection protection, do not support Warn.

Plan a ring-based deployment

Before changing production, confirm that Microsoft Defender Antivirus is active, real-time protection is working, and cloud-delivered protection is available. Some ASR capabilities and alerts depend on these prerequisites.

Build representative rings: a few IT workstations, a pilot group covering important business applications, and production waves. An audit period of two to four weeks often provides a useful operational sample, but it should include relevant monthly and specialized workflows.

• Ring 0: IT workstations and lab devices.
• Ring 1: pilot users from several departments and application groups.
• Ring 2: phased production deployment.
• Ring 3: servers or sensitive devices assessed separately.

Method 1 — Deploy ASR rules with Microsoft Intune

In the Intune admin center, open Endpoint security, Attack surface reduction, and create an Attack Surface Reduction Rules policy for Windows. Assign it to device groups rather than user groups.

Start the rules being evaluated in Audit mode. Avoid a single policy assigned immediately to every device: separate profiles for each ring make analysis, exceptions and the gradual move to Block easier to manage.

• Create an ASR-Audit-Pilot profile assigned only to pilot devices.
• Leave exclusions empty initially to observe real behaviour.
• Review events in Microsoft Defender XDR and collect pilot-user feedback.
• Create an ASR-Block-Pilot profile, and then expand its assignment in waves.

Method 2 — Deploy ASR rules with Group Policy

For Active Directory domain-joined devices, open Group Policy Management and create separate GPOs such as MDE-ASR-Pilot-Audit, MDE-ASR-Pilot-Block and MDE-ASR-Production-Block. Link each GPO only to the OU or security group for its ring.

In the policy editor, open Computer Configuration, Administrative Templates, Windows Components, Microsoft Defender Antivirus, Microsoft Defender Exploit Guard, Attack Surface Reduction. Enable Configure Attack Surface Reduction rules, select Show, and enter each rule GUID with value 2 to begin in Audit mode.

Validate Group Policy application

Force a policy refresh on a pilot workstation, generate a policy report, and confirm the received rules with PowerShell. The output associates each GUID with its action: 1 for Block, 2 for Audit, 5 for Not configured and 6 for Warn.

gpupdate /force
gpresult /h C:\Temp\gpresult-asr.html

$p = Get-MpPreference

0..([math]::Min(
    $p.AttackSurfaceReductionRules_Ids.Count,
    $p.AttackSurfaceReductionRules_Actions.Count
) - 1) | ForEach-Object {
    [pscustomobject]@{
        RuleId = $p.AttackSurfaceReductionRules_Ids[$_]
        Action = $p.AttackSurfaceReductionRules_Actions[$_]
    }
} | Format-Table -AutoSize

Measure events in Microsoft Defender

Advanced Hunting in Microsoft Defender XDR shows the most active rules, affected devices and processes that require investigation. Interpret the numbers carefully because ASR telemetry can group or throttle some repetitive events.

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

DeviceEvents
| where Timestamp > ago(30d)
| where ActionType startswith "Asr"
| where ActionType endswith "Audited"
| project Timestamp, DeviceName, ActionType, FileName, FolderPath,
    InitiatingProcessFileName, InitiatingProcessCommandLine,
    InitiatingProcessAccountName, AdditionalFields
| order by Timestamp desc

Classify events before creating an exclusion

An audit event is not automatically a false positive. It means the rule would have blocked a behaviour. Determine whether the behaviour is expected, necessary, properly signed and limited to a specific path.

A global exclusion permits the file or path for every ASR rule and can remove related telemetry. Use it only as a last resort. A per-rule exclusion limits the reduction in protection.

• Confirm the parent process, command line and account.
• Reproduce the action on a pilot device where possible.
• Validate publisher, hash, path and business need.
• Prefer a specific file over an entire folder.
• Document the owner, justification and review date.

Configure exclusions through Group Policy

For a global exclusion, enable Exclude files and paths from Attack Surface Reduction rules. Under Show, use the full path as the value name and 0 as the value.

With Windows 24H2 administrative templates or later, Apply a list of exclusions to specific Attack Surface Reduction rules provides a safer targeted option. Use the rule GUID as the value name and separate multiple paths with the > character. Do not add quotation marks or extra spaces to Group Policy values.

Rules requiring special attention

• PsExec and WMI: carefully test administrative tooling and Microsoft Configuration Manager, which relies heavily on WMI.
• Office child processes: review macros, add-ins and business applications that launch PowerShell, cmd.exe or other executables.
• LSASS protection: it can create substantial Audit noise and does not support Warn. A small Block pilot can sometimes be more representative.
• Office code injection: Warn is unsupported and exclusion options are limited.
• Scripts and downloaded content: verify AMSI and cloud-protection dependencies before concluding that a rule is ineffective.

Move gradually to Block mode

Start with the rule producing the fewest unexplained events. Change it from 2 to 1 in the pilot ring, monitor incidents and feedback, and then expand the group. Repeat the cycle for each rule or small, coherent rule set.

With Group Policy, do not target the same device with overlapping Audit and Block policies. In Intune, review assignments and conflicts as well. One configuration source should be authoritative for a given rule and scope.

• Audit: collect and understand.
• Exclusions: minimize and document.
• Pilot Block: validate under real conditions.
• Production Block: expand in waves and monitor.
• Review: remove exclusions that are no longer required.

The most common mistakes

• Enabling every rule in Block across production on the same day.
• Leaving rules in Audit indefinitely and assuming the environment is protected.
• Excluding an entire directory after the first event.
• Deploying the same rule with Intune and Group Policy without a clear precedence strategy.
• Missing servers, offline devices or monthly workflows during the pilot.
• Counting events without investigating process context.

Conclusion

ASR rules are among Microsoft Defender's most effective controls for reducing exposure to common attack techniques. Their deployment should be neither abrupt nor permanently left in Audit.

The right approach is to observe, explain, exclude only what is necessary, block in a pilot, and expand gradually. Intune and Group Policy both support this process when they are paired with clear deployment rings, actionable telemetry and exception governance.

• Microsoft — Configure ASR rules and exclusions ↗
• Microsoft — ASR rules and GUID reference ↗
• Microsoft — ASR rules deployment guide ↗