Attack Surface Reduction (ASR) Rules: A Complete Technical Guide

Reading Time: 26 minutes

In this post we will deep dive into ASR (Attack Surface Reduction) Rules of Microsoft Defender and provide all the required information that a System Administrator will need to understand before deploying this amazing security measure.

Introduction to Attack Surface Reduction Rules

Attack Surface Reduction rules are a critical component of Microsoft Defender for Endpoint that help organizations prevent malware and sophisticated attacks by blocking suspicious behaviors before they can execute. These rules target common attack vectors used by malware, ransomware, and advanced persistent threats, making them an essential layer in any defense-in-depth security strategy.

Unlike traditional antivirus signatures that identify known malicious files, ASR rules focus on behavioral detection. They monitor for suspicious activities such as Office applications spawning child processes, scripts attempting to download payloads, or executable content running from unusual locations. This behavioral approach allows ASR rules to detect and block both known and unknown threats, including zero-day attacks that haven’t been seen before.

For organizations managing endpoints through Microsoft Intune, ASR rules provide a powerful and centrally managed security control that can be deployed across thousands of devices with granular configuration options. However, implementing ASR rules requires careful planning because some rules can impact legitimate business workflows if not properly tested and configured.

Understanding ASR Rule Architecture

Before diving into specific rules and their configuration, understanding how ASR rules work at the system level helps you make better deployment decisions and troubleshoot issues more effectively.

ASR rules are implemented as part of the Microsoft Defender Antivirus engine and integrate directly with Windows Defender Exploit Guard. When enabled, these rules use behavioral monitoring to observe process creation, file operations, network connections, and other system activities. When a monitored behavior matches a rule’s criteria, the rule’s configured action is triggered.

Each ASR rule is identified by a unique GUID that remains consistent across all Windows systems and deployment methods. Whether you deploy via Intune, Group Policy, PowerShell, or Configuration Manager, you’ll always reference the same GUID for a specific rule. This consistency makes it easier to manage rules across hybrid environments where different management tools might be in use.

The rules operate at the kernel level through the Windows Defender filter driver, which means they can intercept and block actions before they complete. This early intervention is what makes ASR rules effective against fast-moving threats like ransomware, which can encrypt files in seconds if not stopped immediately.

Complete ASR Rules Reference Table

The following table provides a comprehensive reference for all available ASR rules. Each rule is listed with its unique GUID identifier, official name, description of what it blocks, and the potential impact on your organization. Understanding these impacts before deployment is crucial for avoiding disruptions to legitimate business processes.

ASR Rules Complete Reference

Rule Name	Rule GUID	Description	Potential Organizational Impact
Block executable content from email client and webmail	BE9BA2D9-53EA-4CDC-84E5-9B1EEEE46550	Blocks executable files from running if they were launched from email clients (Outlook, Thunderbird) or webmail (Outlook.com, Gmail in browser)	May block legitimate executables received via email. Users accustomed to running installers directly from email will need to save files first and run from Downloads folder
Block all Office applications from creating child processes	D4F940AB-401B-4EFC-AADC-AD5F3C50688A	Prevents Office applications (Word, Excel, PowerPoint, etc.) from spawning other processes	Blocks macro-based workflows that launch external applications. Will impact users who rely on Office macros to open other programs or run scripts
Block Office applications from creating executable content	3B576869-A4EC-4529-8536-B80A7769E899	Stops Office apps from creating .exe, .dll, or other executable files	Impacts developers or power users who use Office VBA to generate executable content. Most standard Office workflows unaffected
Block Office applications from injecting code into other processes	75668C1F-73B5-4CF0-BB93-3ECF5CB7CC84	Prevents Office applications from injecting code into running processes	May affect legitimate add-ins or accessibility tools that interact with Office applications. Generally safe for most environments
Block JavaScript or VBScript from launching downloaded executable content	D3E037E1-3EB8-44C8-A917-57927947596D	Blocks scripts from executing downloaded executables	Can disrupt automated deployment scripts or legitimate software installation workflows that use JavaScript/VBScript
Block execution of potentially obfuscated scripts	5BEB7EFE-FD9A-4556-801D-275E5FFC04CC	Blocks PowerShell, JavaScript, VBScript, and batch scripts that show obfuscation characteristics	High impact – may block legitimate scripts that use encoding or compression. Requires thorough testing before enforcement
Block Win32 API calls from Office macros	92E97FA1-2EDF-4476-BDD6-9DD0B4DDDC7B	Prevents Office macros from making Windows API calls	Will break advanced VBA macros that interact with Windows systems. Standard Office macros for data processing typically unaffected
Block executable files from running unless they meet a prevalence, age, or trusted list criterion	01443614-CD74-433A-B99E-2ECDC07BFC25	Blocks execution of uncommon or newly created executables (also called “Block untrusted and unsigned processes”)	Can block legitimate custom applications or new software installations. Requires exceptions for line-of-business applications
Use advanced protection against ransomware	C1DB55AB-C21A-4637-BB3F-A12568109D35	Applies additional heuristics to detect ransomware behaviors like rapid file encryption	May trigger false positives with backup software, file compression tools, or database applications performing bulk file operations
Block credential stealing from the Windows local security authority subsystem (lsass.exe)	9E6C4E1F-7D60-472F-BA1A-A39EF669E4B2	Prevents processes from accessing LSASS memory to steal credentials	Essential for preventing credential theft. Generally low impact but may affect legitimate security tools or debugging utilities
Block process creations originating from PSExec and WMI commands	D1E49AAC-8F56-4280-B9BA-993A6D77406C	Blocks processes spawned by PSExec or WMI	High impact for IT administrators – blocks common remote administration tools. Requires exceptions for legitimate administrative workflows
Block untrusted and unsigned processes that run from USB	B2B3F03D-6A65-4F7B-A9C7-1C7EF74A9BA4	Prevents execution of unsigned executables from removable drives	Impacts portable applications and installers run from USB drives. Can frustrate users who use USB drives for software installation
Block Office communication application from creating child processes	26190899-1602-49E8-8B27-EB1D0A1CE869	Prevents Outlook from spawning child processes	May impact Outlook add-ins or integrations that launch external applications. Generally safe for most Office 365 environments
Block Adobe Reader from creating child processes	7674BA52-37EB-4A4F-A9A1-F0F9A1619A2C	Prevents Adobe Reader and Acrobat from launching other processes	Blocks PDF-based exploits effectively. May impact workflows where PDFs trigger automated actions or launch other applications
Block persistence through Windows Management Instrumentation (WMI) event subscription	E6DB77E5-3DF2-4CF1-B95A-636979351E5B	Blocks malware from using WMI events for persistence	Low impact for most organizations. May affect legitimate software that uses WMI eventing for monitoring or automation
Block abuse of exploited vulnerable signed drivers	56A863A9-875E-4185-98A7-B882C64B5CE5	Prevents exploitation of known vulnerable signed drivers (BYOVD attacks)	Generally low impact. Blocks known vulnerable drivers from loading, which shouldn’t affect legitimate operations
Block use of copied or impersonated system tools	c0033c00-d16d-4114-a5a0-dc9b3a7d2ceb	Blocks the use of executable files that are identified as copies of Windows system tools	Low impact for most organizations. May affect legitimate software that uses Windows system files directly in the Installation folder.
Block rebooting machine in Safe Mode	33ddedf1-c6e0-47cb-833e-de6133960387	Prevents the execution of certain commands to restart machines in Safe Mode.	Low impact for most organizations. Will probably not affect any machines.
Block Webshell creation for Servers	a8f5898e-1dc8-49a9-9878-85004b8a61e6	Blocks web shell script creation on Microsoft Server, Exchange Role.	Moderate Impact.

Understanding these impacts allows you to prioritize which rules to deploy first and which require more extensive testing in your environment. Rules like credential stealing protection typically have minimal impact while providing significant security benefits, making them excellent candidates for immediate deployment. Conversely, rules that block script execution or PSExec usage require careful planning and exception management.

Registry Locations for ASR Rules

Understanding where ASR rules are stored in the Windows Registry is critical for troubleshooting deployment issues and verifying that your policies have applied correctly to endpoints. However, there’s an important detail that often catches administrators by surprise: ASR rules are stored in different registry locations depending on whether they were deployed via Group Policy or Microsoft Intune. This distinction is not just a technical curiosity but has real implications for how you verify configurations and troubleshoot conflicts between different management systems.

Registry Location for Group Policy Deployment

When you deploy ASR rules through Group Policy, Windows writes the configuration to a specific branch of the registry that’s dedicated to policy-managed settings. The primary location is:

HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\Windows Defender\Windows Defender Exploit Guard\ASR

Within this path, you’ll find a master control value called ExploitGuard_ASR_Rules which is a REG_DWORD type. This value acts as a global switch that determines whether ASR rules are active on the system at all. When set to 1, the ASR engine is enabled and will process the individual rules you’ve configured. When set to 0 or if this value doesn’t exist, the entire ASR rule system is disabled regardless of what individual rules you may have configured. This master switch is the first thing to check when troubleshooting why ASR rules don’t seem to be working on a device.

The individual ASR rules themselves are stored in a subkey under this path:

HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\Windows Defender\Windows Defender Exploit Guard\ASR\Rules

When you navigate to this Rules subkey, you’ll see each ASR rule represented as a separate registry value. The value name is the rule’s GUID, and the value data contains the rule’s state as a REG_SZ string. For example, if you’ve enabled the rule to block credential stealing from LSASS in block mode, you would find a registry value named 9E6C4E1F-7D60-472F-BA1A-A39EF669E4B2 with the data set to 1. If that same rule were in audit mode, the data would be 2 instead. This individual-value approach makes it straightforward to see exactly which rules are configured and what state each one is in, since each rule has its own discrete registry entry.

Registry Location for Intune Deployment

Microsoft Intune takes a fundamentally different approach to storing ASR rule configuration in the registry. Instead of writing to the Windows Defender Exploit Guard branch, Intune uses the Configuration Service Provider architecture and writes to the Policy Manager area:

HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\Windows Defender\Policy Manager

Within this location, all of your ASR rules are consolidated into a single registry value named ASRRules. This value is also of type REG_SZ, but unlike the Group Policy approach where each rule gets its own value, this single value contains all of your ASR rules encoded in a special format. The format uses a pipe-delimited string where each rule is represented as GUID=state, with multiple rules separated by the pipe character.

For example, if you have three ASR rules configured through Intune, the ASRRules value might contain data that looks like this:

56a863a9-875e-4185-98a7-b882c64b5ce5=1|7674ba52-37eb-4a4f-a9a1-f0f9a1619a2c=2|9e6c4e1f-7d60-472f-ba1a-a39ef669e4b2=1

In this example, the first rule (blocking abuse of exploited vulnerable signed drivers) is set to block mode with state 1, the second rule (blocking Adobe Reader from creating child processes) is in audit mode with state 2, and the third rule (blocking credential stealing from LSASS) is in block mode. All of this information is packed into one registry value rather than spread across multiple individual values as with Group Policy.

This consolidated approach reflects the architectural differences between how Group Policy and modern management solutions like Intune interact with Windows. The Configuration Service Provider uses this compact format to efficiently manage settings across potentially thousands of devices while maintaining compatibility with Microsoft’s cloud-based management infrastructure.

Registry Location for manually setting through PowerShell

When you run Add-MpPreference or Set-MpPreference manually (without a management overlay like Intune or GPO) the ASR Rules are stored unter the below registry location:

HKLM\SOFTWARE\Policies\Microsoft\Windows Defender\Windows Defender Exploit Guard\ASR

• PowerShell commands interact with the Preference layer, which is usually stored in HKLM\SOFTWARE\Microsoft\Windows Defender\Exclusions or internal WMI stores, unless the device is domain-joined and receiving policy overrides.
• Crucial Distinction: If you manually create registry keys in the Policy path (HKLM\SOFTWARE\Policies\...) using PowerShell, you are effectively “spoofing” a Group Policy. Windows Defender will respect these keys as if they came from GPO, often giving them higher precedence than standard local preferences set via Set-MpPreference.

How to Verify Which Deployment Method Is Active

When you need to troubleshoot ASR rule issues on a specific device, one of your first tasks should be determining which management system actually applied the current configuration. This information helps you know where to look for policy settings and ensures you’re making changes in the right place.

The most direct method is to manually examine both registry locations. Open Registry Editor and navigate to both the Group Policy path and the Intune Policy Manager path. Whichever location contains ASR rule configuration tells you which system is actively managing those settings. If both locations have values, remember that the Intune configuration is the one actually being enforced due to policy precedence.

For a more comprehensive view, you can use Microsoft Defender’s built-in diagnostics tool. Run the following command in an elevated command prompt or PowerShell session:

"C:\Program Files\Windows Defender\MpCmdRun.exe" -GetFiles

This command generates a CAB archive containing detailed diagnostic information about Defender’s current state and configuration. Extract this CAB file and look for the file named mpregistry.txt. When you open this file, you’ll see sections labeled “Effective policy,” “System policy,” and “MDM policy.” The “Effective policy” section shows what’s actually being enforced on the device right now, while the separate MDM policy section shows Intune-applied settings and the System policy section shows Group Policy settings. This breakdown makes it immediately clear which source is providing the active configuration.

If you know the device is using Group Policy but want to identify the specific Group Policy Object that’s applying the ASR rules, use the Resultant Set of Policy tool. Run rsop.msc from the Run dialog or Start menu, navigate to Computer Configuration, expand Policies, then Administrative Templates, and drill down to the Windows Defender settings. This console shows you exactly which GPO applied each setting and can help you locate the right policy when you need to make changes.

Important Considerations for Registry-Level Management

While understanding these registry locations is valuable for verification and troubleshooting, it’s important to recognize that these are policy-managed registry keys. This designation means that any manual edits you make directly in the registry will likely be overwritten the next time the device processes policy updates. For Group Policy-managed devices, this happens during the standard policy refresh cycle, which occurs every 90 minutes by default with a random offset. For Intune-managed devices, the policy refresh happens according to the device check-in schedule.

If you need to make permanent changes to ASR rule configuration, always use your management tool of choice rather than attempting to edit the registry directly. Not only does this ensure your changes persist, but it also maintains proper documentation and audit trails in your management system. Direct registry modification should only be used for temporary testing or emergency troubleshooting scenarios where you need to quickly disable a rule that’s causing issues while you prepare a proper policy update.

Understanding the difference between GPO and Intune registry storage locations is essential knowledge for any administrator managing ASR rules in a hybrid environment. This knowledge enables you to quickly verify policy application, troubleshoot conflicts, and ensure that the security controls you think are protecting your endpoints are actually active and functioning as intended.

The Immutability of Mandated Policy: Why Local PowerShell Can’t Override GPO or Intune

When you deploy Attack Surface Reduction (ASR) rules via enterprise management tools like Intune or Group Policy (GPO), they are applied to the device as enforced Policies, not mere local preferences.

When you run Set-MpPreference or Remove-MpPreference locally via PowerShell, you are attempting to modify the Preferences layer. The Windows Defender engine is architected to check for configuration in a specific hierarchy where Policy always wins over Preference.

1. The Registry Hierarchy:
   • Policies (Higher Authority): Settings from Intune and GPO are written to the HKLM\Software\Policies\... registry keys. These are “read-only” to the local administrator’s standard configuration tools and represent the mandatory state defined by the organization.
   • Preferences (Lower Authority): PowerShell cmdlets like Set-MpPreference write to the HKLM\Software\Microsoft\Windows Defender\... keys (the non-Policy branch).
2. The “Effective” State:
   Defender merges these settings in memory, but if a value exists in the Policy key, it completely ignores the conflicting value in the Preference key. Therefore, your PowerShell command might successfully write to the Preference registry area (and return no error), but the Defender engine immediately disregards it in favor of the existing Policy setting.

In short, your local PowerShell commands are changing a “suggestion” box that the system is instructed to ignore because it has already received “orders” from Intune or GPO. To change the rule, you must modify the source policy (the GPO or Intune profile) itself.

Managing ASR Rules with PowerShell

PowerShell provides the most flexible and scriptable interface for managing ASR rules on Windows devices. Whether you’re auditing current configurations, deploying rules to standalone systems, or troubleshooting issues, PowerShell gives you direct access to the ASR rule configuration without requiring a management console.

Quick One-Liner to Display All ASR Rules and Their States

To quickly see all configured ASR rules and their current values on a system, you can use this PowerShell one-liner:

Get-MpPreference | ForEach-Object { 0..($_.AttackSurfaceReductionRules_Ids.Count-1) | ForEach-Object -Begin { $p = $_ } { [PSCustomObject]@{RuleId=$p.AttackSurfaceReductionRules_Ids[$_]; Action=$p.AttackSurfaceReductionRules_Actions[$_]} } }

This command queries the Microsoft Defender preferences and displays two arrays: one containing the rule IDs (GUIDs) and another containing their corresponding action values. While concise, this output can be difficult to interpret because it shows the data as separate arrays rather than mapping each rule to its state.

Comprehensive PowerShell Script to Map ASR Rule IDs, Names, and Values

For a more readable output that maps rule GUIDs to their friendly names and states, use this comprehensive script:

# Define ASR rule mapping with GUIDs and friendly names
$asrRules = @{
    "BE9BA2D9-53EA-4CDC-84E5-9B1EEEE46550" = "Block executable content from email client and webmail"
    "D4F940AB-401B-4EFC-AADC-AD5F3C50688A" = "Block all Office applications from creating child processes"
    "3B576869-A4EC-4529-8536-B80A7769E899" = "Block Office applications from creating executable content"
    "75668C1F-73B5-4CF0-BB93-3ECF5CB7CC84" = "Block Office applications from injecting code into other processes"
    "D3E037E1-3EB8-44C8-A917-57927947596D" = "Block JavaScript or VBScript from launching downloaded executable content"
    "5BEB7EFE-FD9A-4556-801D-275E5FFC04CC" = "Block execution of potentially obfuscated scripts"
    "92E97FA1-2EDF-4476-BDD6-9DD0B4DDDC7B" = "Block Win32 API calls from Office macros"
    "01443614-CD74-433A-B99E-2ECDC07BFC25" = "Block executable files from running unless they meet prevalence, age, or trusted list criterion"
    "C1DB55AB-C21A-4637-BB3F-A12568109D35" = "Use advanced protection against ransomware"
    "9E6C4E1F-7D60-472F-BA1A-A39EF669E4B2" = "Block credential stealing from LSASS"
    "D1E49AAC-8F56-4280-B9BA-993A6D77406C" = "Block process creations originating from PSExec and WMI commands"
    "B2B3F03D-6A65-4F7B-A9C7-1C7EF74A9BA4" = "Block untrusted and unsigned processes that run from USB"
    "26190899-1602-49E8-8B27-EB1D0A1CE869" = "Block Office communication application from creating child processes"
    "7674BA52-37EB-4A4F-A9A1-F0F9A1619A2C" = "Block Adobe Reader from creating child processes"
    "E6DB77E5-3DF2-4CF1-B95A-636979351E5B" = "Block persistence through WMI event subscription"
    "56A863A9-875E-4185-98A7-B882C64B5CE5" = "Block abuse of exploited vulnerable signed drivers"
    "c0033c00-d16d-4114-a5a0-dc9b3a7d2ceb" = "Block use of copied or impersonated system tools"
    "33ddedf1-c6e0-47cb-833e-de6133960387" = "Block rebooting machine in Safe Mode"
    "a8f5898e-1dc8-49a9-9878-85004b8a61e6" = "Block Webshell creation for Servers"
}

# State mapping for better readability
$stateMap = @{
    0 = "Disabled"
    1 = "Block"
    2 = "Audit"
    6 = "Warn"
}

# Get current ASR configuration from the device
$mpPreference = Get-MpPreference
$currentRules = $mpPreference.AttackSurfaceReductionRules_Ids
$currentActions = $mpPreference.AttackSurfaceReductionRules_Actions

# Create an array to hold our formatted results
$results = @()

# If there are configured rules, process them
if ($currentRules) {
    for ($i = 0; $i -lt $currentRules.Count; $i++) {
        $ruleId = $currentRules[$i]
        $action = $currentActions[$i]
        
        # Create a custom object for each rule with all relevant information
        $results += [PSCustomObject]@{
            RuleID = $ruleId
            RuleName = if ($asrRules.ContainsKey($ruleId)) { $asrRules[$ruleId] } else { "Unknown Rule" }
            State = if ($stateMap.ContainsKey([int]$action)) { $stateMap[[int]$action] } else { "Unknown ($action)" }
            ActionValue = $action
        }
    }
    
    # Display the results in a formatted table
    $results | Format-Table -AutoSize
    
    # Summary information
    Write-Host "`nSummary:" -ForegroundColor Cyan
    Write-Host "Total ASR Rules Configured: $($results.Count)" -ForegroundColor Green
    Write-Host "Enabled (Block): $(($results | Where-Object {$_.ActionValue -eq 1}).Count)" -ForegroundColor Green
    Write-Host "Audit Mode: $(($results | Where-Object {$_.ActionValue -eq 2}).Count)" -ForegroundColor Yellow
    Write-Host "Warn Mode: $(($results | Where-Object {$_.ActionValue -eq 6}).Count)" -ForegroundColor Yellow
    Write-Host "Disabled: $(($results | Where-Object {$_.ActionValue -eq 0}).Count)" -ForegroundColor Red
} else {
    Write-Host "No ASR rules are currently configured on this system." -ForegroundColor Yellow
}

Check also my GitHub page for the various scripts in this post.

This script provides a comprehensive view of your ASR configuration by mapping the cryptic GUIDs to human-readable rule names and translating numeric state values into descriptive text. The summary section gives you an at-a-glance view of your security posture by counting how many rules are in each state.

PowerShell Commands to Add, Modify, or Remove ASR Rules

Managing ASR rules through PowerShell uses the Add-MpPreference, Set-MpPreference, and Remove-MpPreference cmdlets. Understanding the syntax for each operation allows you to script ASR rule deployment or make quick changes during testing.

Adding a New ASR Rule

To enable a new ASR rule, use the Add-MpPreference cmdlet:

# Enable the rule to block credential stealing from LSASS in Block mode
Add-MpPreference -AttackSurfaceReductionRules_Ids 9E6C4E1F-7D60-472F-BA1A-A39EF669E4B2 -AttackSurfaceReductionRules_Actions Enabled

You can also use the numeric value instead of the text descriptor:

# Same as above but using numeric value (1 = Enabled/Block)
Add-MpPreference -AttackSurfaceReductionRules_Ids 9E6C4E1F-7D60-472F-BA1A-A39EF669E4B2 -AttackSurfaceReductionRules_Actions 1

To add a rule in Audit mode instead of Block mode:

# Enable in Audit mode to test impact before enforcement
Add-MpPreference -AttackSurfaceReductionRules_Ids 9E6C4E1F-7D60-472F-BA1A-A39EF669E4B2 -AttackSurfaceReductionRules_Actions AuditMode

Adding Multiple ASR Rules at Once

You can configure multiple rules in a single command by passing arrays to both parameters:

# Define the rules you want to enable
$ruleIds = @(
    "9E6C4E1F-7D60-472F-BA1A-A39EF669E4B2",  # Block credential stealing
    "BE9BA2D9-53EA-4CDC-84E5-9B1EEEE46550",  # Block executable content from email
    "D4F940AB-401B-4EFC-AADC-AD5F3C50688A"   # Block Office child processes
)

# Define the corresponding actions (must match the count of rule IDs)
$actions = @(1, 1, 2)  # First two in Block mode, third in Audit mode

# Apply all rules at once
Add-MpPreference -AttackSurfaceReductionRules_Ids $ruleIds -AttackSurfaceReductionRules_Actions $actions

Modifying an Existing ASR Rule

If you need to change a rule from Audit to Block mode, or vice versa, you cannot simply add it again because the rule already exists. Instead, you must first remove it and then re-add it with the new state:

# Remove the rule first
Remove-MpPreference -AttackSurfaceReductionRules_Ids 9E6C4E1F-7D60-472F-BA1A-A39EF669E4B2

# Add it back with the new state (changing from Audit to Block, for example)
Add-MpPreference -AttackSurfaceReductionRules_Ids 9E6C4E1F-7D60-472F-BA1A-A39EF669E4B2 -AttackSurfaceReductionRules_Actions Enabled

Alternatively, you can use the Set-MpPreference cmdlet to replace all ASR rules at once, though this approach requires you to specify the complete desired configuration:

# This replaces ALL ASR rules with the specified configuration
$allRuleIds = @(
    "9E6C4E1F-7D60-472F-BA1A-A39EF669E4B2",
    "BE9BA2D9-53EA-4CDC-84E5-9B1EEEE46550"
)

$allActions = @(1, 1)

Set-MpPreference -AttackSurfaceReductionRules_Ids $allRuleIds -AttackSurfaceReductionRules_Actions $allActions

Be cautious with Set-MpPreference because it will remove any rules not included in your arrays. If you only want to modify one rule while preserving others, the remove-then-add approach is safer.

Removing ASR Rules

To disable and remove a specific ASR rule:

# Remove a single rule by its GUID
Remove-MpPreference -AttackSurfaceReductionRules_Ids 9E6C4E1F-7D60-472F-BA1A-A39EF669E4B2

To remove multiple rules at once:

# Remove multiple rules
$rulesToRemove = @(
    "9E6C4E1F-7D60-472F-BA1A-A39EF669E4B2",
    "BE9BA2D9-53EA-4CDC-84E5-9B1EEEE46550"
)

Remove-MpPreference -AttackSurfaceReductionRules_Ids $rulesToRemove

To remove all ASR rules completely:

# Get all currently configured rule IDs
$currentRules = (Get-MpPreference).AttackSurfaceReductionRules_Ids

# Remove them all
if ($currentRules) {
    Remove-MpPreference -AttackSurfaceReductionRules_Ids $currentRules
}

ASR Rule States and Configuration Values

Understanding the different states an ASR rule can be in helps you implement a gradual rollout strategy that minimizes user impact while maximizing security coverage. Each state serves a specific purpose in the ASR lifecycle from testing to full enforcement.

ASR rules support four distinct states, each represented by a numeric value:

Disabled (0) – The rule is not active and will not monitor or block any behaviors. This is useful when you need to temporarily disable a rule due to compatibility issues without removing it entirely from your configuration. A disabled rule has zero performance impact and will not generate any events in the event logs.

Enabled or Block mode (1) – This is the enforcement mode where the rule actively blocks behaviors that match its criteria. When a rule is in block mode, it will prevent the action from completing and generate a block event in the Windows Defender event log. This is the state you want rules in for production environments after successful testing, as it provides active protection against threats.

Audit mode (2) – In audit mode, the rule monitors for behaviors that would be blocked but allows them to proceed. Instead of blocking, it logs an audit event that you can review to understand what would have been blocked. This is the critical testing state that allows you to evaluate the impact of a rule before enabling enforcement. You can deploy all rules in audit mode to a pilot group, collect telemetry for a few weeks, and then make informed decisions about which rules to enable based on real-world data from your environment.

Warn mode (6) – This mode displays a warning to the user when a rule would block an action but gives them the option to proceed anyway. The warning includes information about why the action is being blocked and allows the user to bypass the block if they determine the action is legitimate. Warn mode strikes a balance between security and user productivity, preventing accidental execution of threats while allowing power users to override the protection when necessary. Events are logged regardless of whether the user bypasses the warning or not.

The choice of which state to use for each rule depends on your organization’s risk tolerance, the rule’s potential impact, and your testing results. A typical progression might be: Audit mode (2 weeks) → Warn mode (1 week) → Enabled mode (production). This graduated approach gives you multiple opportunities to identify and address compatibility issues before full enforcement.

Deploying ASR Rules via Intune

Microsoft Intune provides centralized management of ASR rules across your endpoint fleet with the flexibility to target different rule sets to different groups based on risk profile, department, or device type. Deploying through Intune ensures consistent configuration and allows you to leverage reporting and compliance features.

To deploy ASR rules through Intune, you’ll create an Endpoint Security policy under the Attack Surface Reduction category.

In the configuration settings, you’ll see all available ASR rules listed by their friendly names, not their GUIDs. This makes the Intune interface more user-friendly than working directly with PowerShell or Group Policy. For each rule you want to configure, select the desired state from the dropdown: Not configured (default), Block, Audit mode, Warn, or Disabled.

A common strategy for initial deployment is to configure all rules in Audit mode for a pilot group. This allows you to gather telemetry on what would be blocked without actually impacting users. After reviewing the audit logs and identifying any false positives or compatibility issues, you can create a second policy that moves low-impact, high-value rules like credential stealing protection to Block mode while keeping potentially disruptive rules in Audit mode for further testing.

After configuring the desired rules and their states, move to the Assignments tab. Here you can target the policy to specific groups of users or devices. Using Azure AD groups allows for dynamic targeting based on device attributes, user department, or other criteria. For example, you might deploy aggressive ASR configurations to high-risk departments like Finance or HR while using more lenient settings for developers who might be legitimately running scripts and building applications.

Intune also supports exclusions, allowing you to apply a policy broadly while excluding specific groups that require different configurations. This is particularly useful when you want to enforce ASR rules organization-wide but need to exempt specific service accounts or specialized workstations.

One advantage of Intune deployment is the ability to use scope tags for delegated administration. If your organization has regional IT teams or department-specific administrators, scope tags allow them to manage ASR policies for their areas of responsibility without having access to manage the entire tenant’s security configuration.

After creating and assigning the policy, Intune will deploy the configuration during the next device check-in cycle, which typically occurs every eight hours by default but can be triggered manually through the Intune portal if you need immediate deployment for testing. You can monitor the deployment status from the policy overview page, which shows how many devices have successfully applied the configuration, how many failed, and how many are still pending.

Testing ASR Rules Before Production Deployment

Thorough testing of ASR rules is not optional but rather a critical prerequisite for successful deployment. Even rules that seem universally applicable can have unexpected impacts in environments with custom applications, specialized workflows, or legacy systems. A structured testing approach helps you identify these issues in a controlled manner rather than discovering them through production incidents.

The testing process should begin with a comprehensive audit mode deployment to a representative pilot group. This pilot group should include users from different departments, various use cases, and a mix of technical sophistication levels. The diversity ensures you capture the full range of potential impacts across your organization. Deploy all ASR rules in audit mode to this group and allow the configuration to run for at least two to three weeks to capture a complete picture of normal business operations including month-end processes, reporting cycles, and other periodic activities that might not occur daily.

During the audit phase, you’ll need to actively monitor the Windows Defender event logs for ASR audit events. These events appear in the Microsoft-Windows-Windows Defender/Operational log with Event ID 1121 for audit mode detections and 1122 for block mode detections. The event details include the rule that was triggered, the process that attempted the blocked action, and the file or resource involved. This information is crucial for understanding whether detections represent legitimate threats or false positives that need exceptions.

For organizations with Microsoft Defender for Endpoint or Microsoft 365 Defender, the advanced hunting capabilities provide a more powerful way to analyze ASR rule impacts. Using Kusto Query Language, you can query ASR events across your entire estate and identify patterns such as which applications trigger specific rules most frequently, which users are most affected, or which rules generate the most audit events. This data-driven approach helps you prioritize which rules to enable first and which require more extensive exception management.

A sample advanced hunting query to analyze ASR audit events might look like this:

DeviceEvents
| where ActionType startswith "Asr"
| where Timestamp > ago(14d)
| summarize Count = count() by ActionType, FileName, FolderPath
| order by Count desc

This query shows you the most frequently triggered ASR rules and the files involved, helping you quickly identify patterns and potential issues.

Based on your audit mode findings, create a categorization of rules into three tiers. Tier one includes rules with minimal or no audit events that can move directly to enforcement. These typically include rules like credential stealing protection or blocking vulnerable driver exploits, which target behaviors that shouldn’t occur in legitimate workflows. Tier two consists of rules with some audit events but where the triggered behaviors appear suspicious or unnecessary. These rules might move to warn mode first to give users a safety valve while you continue monitoring. Tier three includes rules with significant audit events involving legitimate business processes. These rules need either permanent exceptions or may not be suitable for your environment at all.

For tier three rules, you’ll need to implement ASR rule exclusions for specific files, folders, or processes. Intune allows you to configure these exclusions through the same Attack Surface Reduction policy. Navigate to the “Excluded files and paths” or “Excluded processes” sections and add the necessary exceptions. Document each exception with the business justification and the person who requested it. This documentation proves invaluable during security audits and helps future administrators understand why certain exceptions exist.

After implementing exclusions, retest affected rules in audit mode with a subset of users who previously experienced blocks. If the exclusions successfully allow legitimate activities while still protecting against threats, you can proceed with broader deployment. If audit events continue for legitimate activities, you may need additional exceptions or might choose to keep that rule in audit mode indefinitely.

Monitoring and Reporting on ASR Rules

Effective monitoring and reporting are essential for maintaining ASR rule effectiveness over time and demonstrating the value of your security investments to stakeholders. Without proper visibility into ASR rule performance, you cannot verify that rules are working as intended or identify emerging compatibility issues.

For organizations using Microsoft Defender for Endpoint, the built-in reporting provides comprehensive visibility into ASR rule detections, trends, and device coverage. The Microsoft 365 Defender portal includes a dedicated Attack Surface Reduction reports section that shows how many detections each rule has generated, which devices are protected, and trending data over time. This reporting helps you understand which rules are most actively protecting your environment and which might need tuning.

The Attack Surface Reduction report also breaks down detections by rule, allowing you to see if a particular rule is generating an unusual number of blocks that might indicate either an active attack campaign or a compatibility issue that needs investigation. Sudden spikes in detections for a specific rule deserve immediate attention to determine the root cause.

For organizations without Defender for Endpoint licensing, you can still implement effective monitoring using Windows Event Log collection and analysis. Configure your SIEM or log aggregation tool to collect Event IDs 1121 (Audit) and 1122 (Block) from the Microsoft-Windows-Windows Defender/Operational log. Create alerts for unusual patterns such as the same rule blocking on multiple devices simultaneously, which could indicate a coordinated attack, or frequent blocks on executive devices, which might warrant immediate investigation.

A PowerShell script can also help you collect and analyze ASR events across multiple devices. Here’s a script that queries the last seven days of ASR block events and provides a summary:

# Get ASR block events from the last 7 days
$events = Get-WinEvent -FilterHashtable @{
    LogName = 'Microsoft-Windows-Windows Defender/Operational'
    ID = 1122
    StartTime = (Get-Date).AddDays(-7)
} -ErrorAction SilentlyContinue

if ($events) {
    # Parse and group events by rule
    $summary = $events | ForEach-Object {
        $xmlData = [xml]$_.ToXml()
        $ruleId = $xmlData.Event.EventData.Data | Where-Object {$_.Name -eq 'ID'} | Select-Object -ExpandProperty '#text'
        $fileName = $xmlData.Event.EventData.Data | Where-Object {$_.Name -eq 'Path'} | Select-Object -ExpandProperty '#text'
        
        [PSCustomObject]@{
            Time = $_.TimeCreated
            RuleID = $ruleId
            BlockedFile = $fileName
        }
    } | Group-Object RuleID | Select-Object Name, Count
    
    Write-Host "`nASR Block Summary (Last 7 Days):" -ForegroundColor Cyan
    $summary | Format-Table -AutoSize
    Write-Host "`nTotal Blocks: $($events.Count)" -ForegroundColor Green
} else {
    Write-Host "No ASR block events found in the last 7 days." -ForegroundColor Yellow
}

Regular review of these reports helps you maintain the right balance between security and usability. If certain rules consistently generate false positives, you can adjust exclusions or move the rule to warn mode. Conversely, if you see rules in audit mode that are detecting threats without impacting legitimate workflows, you can confidently move them to enforcement.

Common ASR Rule Conflicts and Compatibility Issues

Understanding common compatibility issues helps you anticipate and prevent problems before they affect users. While ASR rules are designed to block malicious behaviors, some legitimate software uses patterns that resemble attack techniques, leading to conflicts that require careful management.

One frequently encountered conflict involves development tools and ASR rules that block script execution or process creation. Developers often use PowerShell scripts with obfuscation for legitimate purposes such as protecting intellectual property in deployment scripts or using encoding to handle special characters. The rule that blocks potentially obfuscated scripts will flag these legitimate uses. In development environments, you may need to either exclude common development directories from ASR rules or maintain separate ASR configurations for developer workstations that exclude problematic rules while keeping other protections in place.

Remote management tools commonly conflict with the rule that blocks process creation from PSExec and WMI commands. Many IT departments rely on these tools for remote administration, software deployment, and troubleshooting. If you enable this rule without planning for legitimate administrative use, you’ll immediately impact IT operations. The solution often involves excluding specific administrative tools or accounts from this rule while still blocking unknown or suspicious use of these techniques. Some organizations implement this rule in audit mode indefinitely for IT administrative devices while enforcing it on standard user workstations where PSExec and WMI should never be used.

Software installers, particularly those using legacy installation frameworks, sometimes trigger the rule that blocks executables from email clients or webmail. Even though this rule primarily targets malicious executables delivered via email, some vendor communications legitimately include software updates or patches as executable attachments. Training users to download these files and run them from the downloads folder rather than directly from email mitigates this issue while maintaining protection. Alternatively, you can implement application control through Windows Defender Application Control or AppLocker to allow known-good installers while keeping the ASR rule enabled for unknown executables.

Office macro-dependent workflows represent another common conflict area. Organizations that have standardized on VBA macros for data processing, report generation, or integration with other systems will find that several ASR rules impact macro functionality. The rule blocking Office applications from creating child processes prevents macros from launching external applications, while the rule blocking Win32 API calls prevents advanced macro functionality that interacts directly with Windows. For organizations that cannot eliminate macro dependencies, you’ll need to carefully scope which Office macro rules to enforce and potentially maintain exceptions for specific documents or templates that require macro functionality.

Backup and data protection software occasionally conflicts with the advanced ransomware protection rule because these tools perform rapid file operations that resemble ransomware encryption behavior. Database applications that process large numbers of files can trigger similar false positives. Monitoring audit events before enforcing this rule helps identify these legitimate applications so you can exclude them. Most major backup software vendors publish guidance on ASR rule compatibility and recommended exclusions for their products.

Troubleshooting ASR Rule Deployment

Even with careful planning and testing, ASR rule deployments sometimes encounter issues that require systematic troubleshooting. Understanding where to look for clues and what diagnostic steps to take helps you resolve problems quickly and minimize user impact.

When users report that an application or workflow suddenly stopped working after ASR deployment, your first step should be to verify that ASR rules are actually the cause. Check the Windows Defender event log for Event ID 1122 (block events) that coincide with the reported issue timeframe. The event details will show which rule blocked the action and what process was involved. This confirmation ensures you’re troubleshooting the right issue rather than assuming ASR is at fault for an unrelated problem.

If you’ve confirmed an ASR block but the event log doesn’t provide enough context to understand why the block occurred, enabling Microsoft Defender Antivirus debug logging provides more detailed information. Run the following PowerShell commands to enable debug logging:

# Enable debug logging
Set-MpPreference -MAPSReporting Advanced
Set-MpPreference -DisableRealtimeMonitoring $false

# Reproduce the issue

# Check the debug log location
Get-MpPreference | Select-Object -ExpandProperty ThreatFileHashLogging

Debug logs include detailed information about each detection, including the exact file path, the behavior that triggered the rule, and the rule’s decision-making process. This additional context often reveals the root cause of unexpected blocks.

Another common troubleshooting scenario involves rules that should be active but aren’t generating any events or blocks. This suggests the rule configuration hasn’t applied correctly to the device. Verify the registry entries we discussed earlier to confirm the rule is actually present on the device. If the registry entries are missing, check Intune policy assignment and ensure the device is included in the targeted group. Also verify that no other conflicting policies are overriding your ASR configuration.

For Intune-managed devices, the Device Configuration blade shows the status of each assigned policy including any errors encountered during application. If a policy shows as “Error” or “Not applicable,” click into the device details to see the specific error message. Common issues include licensing problems where the device doesn’t have the required Defender for Endpoint license, or conflicting policies from multiple sources attempting to configure the same settings.

Performance issues after enabling ASR rules, while rare, sometimes occur on older hardware or systems with limited resources. ASR rules run as part of the Defender filter driver and add a small amount of processing overhead to monitor system behaviors. If users report slowdowns after ASR deployment, use Performance Monitor to check for unusual CPU usage by the Windows Defender Antivirus Service. In most cases, performance impacts are minimal and may resolve themselves as the Defender smart detection algorithms learn normal system behavior patterns. If performance problems persist, you might need to exclude high-throughput applications or directories from real-time scanning while keeping ASR rules active.

Best Practices for ASR Implementation

Successful ASR rule implementation follows proven patterns that balance security effectiveness with operational stability. These best practices emerge from real-world deployments across diverse environments and help you avoid common pitfalls.

Start with a phased approach rather than attempting to enable all rules at once. Begin with rules that have minimal compatibility impact such as credential stealing protection, blocking vulnerable drivers, and blocking WMI persistence. These rules target behaviors that rarely occur in legitimate workflows but are common in attacks. After successfully deploying this first wave and confirming stability, expand to rules that target Office and script-based attacks, which may require more exception management but still provide significant security value.

Maintain different ASR configurations for different device groups based on their risk profile and use case. Executive devices, finance workstations, and systems that process sensitive data should have more comprehensive ASR coverage even if it means accepting some additional management overhead for exceptions. Developer workstations might have reduced ASR coverage for rules that conflict with development tools while maintaining full protection for non-development related threats. This risk-based approach ensures you protect your most valuable assets without unnecessarily constraining users who have legitimate needs for reduced restrictions.

Document every exception you create including the business justification, the requesting user or department, the date created, and a review date. Exceptions should not be permanent without periodic validation that they’re still necessary. Applications get updated, workflows change, and exceptions that were once essential may no longer be needed. Schedule quarterly reviews of your exception list and remove any that are no longer justified.

Implement monitoring and alerting for ASR detections so you can identify threats being actively blocked and respond appropriately. A rule that suddenly blocks the same file across multiple devices might indicate malware spreading through your environment, warranting immediate incident response. Regular review of detection patterns also helps you tune rules over time as you learn what’s normal for your environment.

Leverage Microsoft’s recommended ASR rule configurations as a starting point but adapt them to your specific environment. Microsoft publishes recommended baselines for different scenarios such as standard enterprise environments versus high security environments. These baselines provide tested combinations of rules and states that work well together, but your specific applications and workflows might require adjustments.

Communicate clearly with users about ASR rule deployment and what to do if they encounter blocks. Provide a documented process for users to request exceptions with sufficient detail about what they were trying to do and why it’s necessary for their job function. This helps prevent exception creep where users request blanket exclusions instead of targeted ones that maintain maximum protection.

Consider the impact of ASR rules on remote or disconnected devices. Some rules might behave differently when devices are off the corporate network, particularly rules related to cloud services or network resources. Test your ASR configuration with VPN-connected remote workers and truly disconnected scenarios to ensure consistent protection regardless of connection status.

Conclusion

Attack Surface Reduction rules represent one of the most effective security controls available for Windows endpoints, providing behavioral-based protection against modern threats including ransomware, credential theft, and sophisticated malware campaigns. By blocking malicious behaviors at the system level before they can cause harm, ASR rules complement traditional antivirus signatures with a proactive defense layer that catches both known and unknown threats.

Successful ASR implementation requires balancing security benefits against operational impact through careful planning, thorough testing, and ongoing management. The comprehensive reference information provided in this guide gives you the knowledge needed to deploy ASR rules confidently, troubleshoot issues effectively, and maintain protection over time as your environment evolves.

For Intune administrators, ASR rules offer centralized management with granular targeting capabilities that allow you to apply the right level of protection to each device group based on risk and use case. Combined with proper monitoring and a structured exception management process, ASR rules significantly reduce your organization’s attack surface while maintaining user productivity.

Whether you’re just beginning your ASR journey or optimizing an existing deployment, the registry locations, PowerShell commands, and best practices outlined in this guide provide a complete technical reference for managing these critical security controls. Take a methodical approach, leverage audit mode during testing, and use the detailed detection data to make informed decisions about which rules to enforce and which require exceptions.

Your investment in properly implementing ASR rules pays dividends through prevented security incidents, reduced malware cleanup costs, and protection of your organization’s most valuable data assets. The technical foundation established here empowers you to leverage ASR rules effectively as a cornerstone of your endpoint security strategy.

References and Documentation

• Understand and use attack surface reduction capabilities
• Attack surface reduction rules reference
• Attack surface reduction rules deployment overview

Other Interesting Posts

• Easily block Personal Devices Enrollment in Intune
• Join-Register-Enroll an easy demystification
• Sign-in Audit Logs – One of the hidden shiny gems