Attack surface reduction (ASR) rules in Windows have become a cornerstone of modern security in corporate environments. They are part of Microsoft Defender Antivirus and Microsoft Defender for Endpoint. Their purpose is to eliminate all the points where malware typically infiltrates systems: unusual scripts, suspicious macros, unknown executables, abuse of system tools, and so on. When properly configured, they make your network much more difficult to compromise.
However, implementing ASR rules correctly isn't simply a matter of setting everything to "Block" mode and calling it a day. There are prerequisites, different deployment methods (Intune, GPO, MDM, PowerShell, Configuration Manager), operating modes (auditing, warning, blocking), and a number of rules with GUIDs and very specific behaviors. We explain everything below.
What is ASR in Windows and why should you use it?
When we talk about the attack surface in Windows, we're referring to all the points where an attacker could execute code or gain persistence: Office macros, downloaded executables, scripts, drivers, system tools, and much more. Microsoft Defender 's attack surface reduction rules target precisely these abuse vectors, limiting risky behavior without relying solely on traditional signature-based antivirus software.
ASR rules focus on typical malware behavior patterns. Examples include launching suspicious child processes from Office, running obfuscated scripts, launching executables downloaded via JavaScript/VBScript, and maliciously using vulnerable signed drivers. Some legitimate applications may do similar things, but the idea is that these cases are in the minority and can be managed with well-defined exclusions.
Using ASR means that your organization offers fewer opportunities for attackers to rely on tools that already exist on your systems (PowerShell, WMI, PsExec, Office, etc.).
It's important to ensure that Microsoft Defender Antivirus is active . It won't work if it's in passive or disabled mode if you want to take advantage of ASR rules. It must be the primary antivirus on your system. Additionally, real-time protection must be enabled on all devices.
Another critical aspect is Cloud-based Protection ( or Cloud-Delivery Protection). Several rules require the cloud to determine whether a file is frequently targeted, trusted, or ransomware-like. Without connectivity to Defender's cloud services, you'll lose much of the potential of Advanced Ransomware Review (ASR), especially for rules like executables based on prevalence or advanced ransomware protection. To maintain this capability, it's essential to review the security settings in Windows 11 and related updates.
ASR Rules Operating Modes
Each attack surface reduction rule is configured with a specific mode or state. This determines its behavior on the device. These states are key to designing a deployment strategy without disrupting business applications.
The codes accepted by Microsoft Defender for ASR rules are as follows: 0 for disabled/not configured , 1 for Block mode, 2 for Audit mode, and 6 for Warning mode. These same values are used in GPO, MDM, Configuration Manager, and the Defender CSP, so it's important to be familiar with them.
- Mode Block (0). This is the method that actually prevents the action on the computer. When a block rule detects behavior that matches its pattern (for example, Word trying to launch PowerShell), it stops the operation and can display a notification to the user depending on the configuration. This is the mode you want to use once you have thoroughly tested the rule in your environment.
- Audit Mode (2). It's your best ally for testing: it doesn't block behavior, but it logs events that let you see what would have been stopped if the rule were in block mode. This information appears in the Event Viewer, in Defender for Endpoint, and in advanced queries (for example, by filtering DeviceEvents by ActionType that starts with "Asr"). From there, you decide which applications you need to exclude.
- Mode Warning (6). It offers an intermediate experience. The rule blocks the content but displays a dialog box to the user indicating that it is potentially dangerous, allowing them to unblock it for 24 hours. After that time, the block is reactivated.
Types of ASR rules and recommended classification
Microsoft groups attack surface reduction rules into two main categories: standard protection rules , which are recommended to be enabled almost always, and other rules that usually require a more careful testing cycle (plan > audit > block/warn).
Standard protection rules include, among others, blocking the abuse of exploited, vulnerable signed drivers , preventing credential theft from LSASS, and blocking persistence through WMI event subscriptions. These typically have a low impact on the end user, making them good candidates for early activation, at least in audit mode.
The remaining ASR rules cover behaviors such as child processes from Office , execution of obfuscated scripts, use of remote tools such as PsExec and WMI to create processes, unsigned processes from USB, creation of WebShell on servers, calls to Win32 APIs from Office macros, or even extra protection against ransomware through client and cloud heuristics.
Each rule has a unique GUID that serves as an identifier in GPO, Intune (OMA-URI custom profiles), MDM, and PowerShell.
Some rules have important peculiarities: not all respect the global exclusions of Microsoft Defender Antivirus or the Indicators of Compromise (IOCs) of Defender for Endpoint, and in some cases, they only allow exclusions per rule. Additionally, some rules may not be visible in the Intune interface for new profiles but may still be active and configurable via CSP, Add-MpPreference, or previously created templates.
Methods to enable and configure ASR in Windows
One of the great advantages of ASR rules is that they can be configured through multiple management methods , allowing them to adapt to both small businesses without Intune and large organizations with MDM and Configuration Manager, while also maintaining a healthy network infrastructure.
The recommended approach for modern enterprise environments is to use Intune or Microsoft Configuration Manager , as they allow for centralized and consistent administration, resolving conflicts between GPOs and startup scripts. However, they can also be managed using traditional Group Policy, CSP MDM, or directly with PowerShell on specific machines.
In Intune, the preferred approach is the Endpoint Security Policy for Attack Surface Reduction. Another alternative within Intune is to use Endpoint Protection device configuration profiles . If you need even finer control, you can use a custom Intune profile with an OMA-URI.
In generic, non-Intune-based MDM scenarios, CSP Defender is also used with the AttackSurfaceReductionRules route for states and AttackSurfaceReductionOnlyExclusions for global exclusions. With Microsoft Configuration Manager, you can create an Exploit Guard policy under the Endpoint Protection node. By choosing Attack Surface Reduction, you select which rules will run in blocking or audit mode.
Finally, it should be mentioned that PowerShell offers a direct mechanism to activate, deactivate, or audit specific rules.
Global and rule exclusions in ASR
A critical element in preventing your environment from breaking is properly managing file and folder exclusions that you don't want ASR rules to evaluate. If a resource is excluded, even if malicious behavior is detected according to a rule, its execution will not be prevented.
In Intune, there are two main approaches:
- Global exclusions of only attack surface reduction (AttackSurfaceReductionOnlyExclusions), which apply to all ASR rules destined for a device when there is at least one policy configuring them. They are useful for highly controlled routes.
- Exclusions by rulewhere each rule configuration that is set to a value other than "Not configured" offers the possibility of defining its own excluded routes.
It's important to note that not all rules support file and folder exclusions, and some also disregard exclusions from Microsoft Defender Antivirus or Defender for Endpoint Indicators of Compromise (IOCs). In such cases, if a rule is particularly problematic, the best strategy is to fine-tune it in audit mode and, if it's impossible to work with it, disable it or set it to warning mode, depending on the level of risk you're willing to take.
In addition to Intune and CSP, exclusions can be managed from Group Policy Objects (using the specific route exclusion policy for ASR) or from PowerShell with `AttackSurfaceReductionOnlyExclusions`. As a general rule, the more granular and closer to the rule the scope of the exclusion , the better for your overall security posture.
Combination of directives and conflict resolution
In environments with multiple configuration sources (Intune, Configuration Manager, GPO, CSP), conflicts between attack surface reduction policies are common . Microsoft has introduced a merge behavior to simplify this scenario on managed devices.
The idea is that, for a given device, a superset of ASR configuration is built based on the applicable policies. Non-conflicting options are combined, while conflicting settings are excluded from the combined policy and therefore not applied. This behavior affects policies originating from device configuration profiles, endpoint security policies, and Defender-related security baselines.
A similar process occurs with device control and USB identifier management . Lists of devices allowed or blocked by identifiers, classes, or instances are combined into a single list by configuration type, eliminating duplicates. If the same device appears in both allow and block lists, the practical result at the endpoint is that the more restrictive option (block) is applied, even though the policy combination does not directly merge the two lists.
In cases where GPO and MDM coexist, the documentation specifies that when there is a direct conflict over the same configuration, Group Policy takes precedence over MDM. This necessitates close coordination between security and systems teams to avoid overlapping and prevent surprises in production.
Preliminary assessment: audit mode, warning and recommendations
The safest way to introduce ASR into your organization is to follow a phased assessment process . Microsoft recommends starting by running all possible rules in Audit mode. This allows you to observe the real impact on your environment before moving to Block or Warn.
From Microsoft Defender Vulnerability Management, you can open the security recommendation associated with each rule and review the estimated user impact. See what percentage of devices would be affected if you enable that rule in block mode. This analysis gives you clues about prioritization and which rules might cause the most disruption.
With the audit data collected (whether from the Defender XDR portal, advanced search, or the Event Viewer itself), you can identify line-of-business applications that trigger ASR events and decide whether they should be excluded by path, treated as a one-off exception, or simply not activated for that specific group of devices.
Warning mode is especially useful for organizations that want to increase security without completely locking users out. Users receive a notification when a rule blocks something, with the option to temporarily unblock it. This behavior allows you to measure how often the unblocking option is used. Then, with that information, you can adjust exclusions, provide user training, or create permanent policies.
ASR event and alert monitoring
Once ASR rules are in place, you need visibility into what's happening : what's being blocked, what's being audited, how many alerts are being generated, and on which devices. Defender for Endpoint and Windows offer several ways to achieve this.
At the portal level, Microsoft Defender XDR allows you to view alerts, notifications, and events related to ASR . Many rules generate system notifications when they operate in Block mode. Certain rule and status combinations can trigger alerts that appear in the console, especially when the cloud blocking level is set to High or High+.
Advanced search in Defender (Kusto Query Language) is another key tool . For example, filtering DeviceEvents with ActionTypes starting with "Asr" gives you a clear view of all the rules being triggered, on which devices, and in what mode. This is how you detect abuse patterns, repeated attempts, or potential misconfigurations.
If you don't have advanced licenses, you can always use the Windows Event Viewer . Microsoft provides XML templates (such as cfa-events.xml) that allow you to create custom views for events and attack surface reduction rules. Typical events include 5007 (configuration changes), 1121 (event triggered in blocking mode), and 1122 (event triggered in audit mode).
Note that it is Defender for Endpoint that generates the engine version field associated with these attack surface reduction events, not the operating system itself. This reinforces the need for a well-maintained Defender integration.
With all of the above, attack surface reduction rules in Windows become a very powerful tool for limiting the malware's playing field. By combining good policy design , progressive deployment in audit and warning mode, fine-grained exclusions, and proper monitoring from Defender for Endpoint or the Event Viewer, you can significantly harden your Windows systems. And all without the need for third-party solutions.