What is ASR (Attack Surface Reduction) and how does it protect your devices?

When you start delving into Windows security and everything Microsoft Defender has to offer, the term ASR (Attack Surface Reduction) It appears time and time again. And that's no coincidence: we're talking about a set of rules and techniques that aim to stop attacks before they even have a chance to start.

In a context of increasingly sophisticated threatsWith ransomware, obfuscated scripts, credential theft, and fileless attacks, ASR rules have become a key component of preventative defense. The problem is that they are often seen as something "magical" and complicated, when in reality they have a fairly clear logic if explained calmly.

What is ASR (Attack Surface Reduction) and what problem does it solve?

Attack Surface Reduction, or reduction of the attack surfaceASR is an approach that involves minimizing all points through which an attacker could enter, move, or execute code within an environment. In the specific case of Microsoft, ASR is implemented through rules that control high-risk endpoint behaviors: script execution, Office macros, processes launched from USB drives, WMI abuse, etc.

In practical terms, the Microsoft Defender ASR rules for endpoint These are policies that say: “certain things that are typical of the malware They won't be allowed, even though legitimate applications sometimes do them too. For example, Word Boot PowerShell, which a script downloaded from the Internet launches an executable or one process attempts to inject code into another.

The underlying idea is to reduce the number of paths an attack can take to compromise the system. Fewer available paths, less surface areaThis fits perfectly with the Zero Trust model: we assume that at some point there will be a breach, so we reduce the "blast radius" of the incident as much as possible.

It is important to differentiate here between two concepts that are often mixed up: on the one hand, the reducing the attack surface as a general strategy (removing unnecessary services, closing ports, removing redundant software, limiting permissions, etc.), and on the other hand, the Microsoft Defender ASR Ruleswhich are a very specific subset of that strategy, focused on the endpoint and software behaviors.

The attack surface: physical, digital, and human

When we talk about an organization's attack surface, we are referring to all the points where an attacker can get involvedDevices, applications, online services, user accounts, APIs, internal networks, external clouds, etc. It's not just a technical issue; human error also comes into play.

In the digital section we find websites, servers, databasesendpoints, cloud services, and enterprise applicationsEvery misconfigured service, every unnecessarily open port, every unpatched software application can be an entry point for an exploit. That's why many companies rely on EASM (External Attack Surface Management) tools that automate the discovery of exposed assets and vulnerabilities.

On the physical surface, the following come into play on-premise servers, workstations, network devices, and terminalsHere, the risk is mitigated with physical access controls, cameras, cards, locks, enclosed racks, and hardware Reinforced. If anyone can access the data center with a USB drive, it doesn't matter how good your security policy is.

The third leg is the surface associated with the social engineering and the human factorPhishing emails, pretexting calls, watering hole websites, or simple employee errors that lead to downloading malicious content. That's why reducing the attack surface also involves training and awareness, not just technology.

ASR as a pillar of preventative security and Zero Trust

In a Zero Trust model we assume that the network is already compromised or will beAnd what we're aiming for is to prevent the attacker from easily escalating or gaining privileges. ASR Rules fit perfectly here because they put barriers against the most exploited attack vectors, especially at the endpoint.

The ASR rules apply the principle of minimum privilege applied to behaviorIt's not just about what permissions an account has, but what actions a specific application can perform. For example, Office can still edit documents without issue, but it can no longer launch background processes or create executables on disk freely.

This type of behavioral control is especially powerful against polymorphic threats and fileless attacksAlthough malware constantly changes its signature or hash, most still need to do the same things: run scripts, inject code into processes, manipulate LSASS, abuse WMI, write vulnerable drivers, etc. ASR focuses precisely on these patterns.

Furthermore, the rules can be executed in different modes: blocking, auditing, or warningThis allows for a phased adoption, starting by observing its impact (audit mode), then notifying the user (warning), and finally blocking it mercilessly once exclusions have been adjusted.

Prerequisites and compatible operating systems

To get the most out of ASR rules in Microsoft Defender, it's important to have a solid foundation. In practice, you need to Microsoft Defender Antivirus should be your primary antivirus.running in active, not passive, mode, and with real-time protection turned on.

Many rules, especially the more advanced ones, require having Cloud-Delivered Protection Active and connectivity with Microsoft cloud services. This is key for features that rely on reputation, prevalence, or heuristics in the cloud, such as the "executables that do not meet prevalence, age, or trusted list criteria" rule or the "advanced ransomware protection" rule.

Although the ASR rules do not strictly require a license Microsoft 365 E5, yes it is Having E5 or equivalent licenses is highly recommended. If you want to have the advanced management, monitoring, analysis, reporting, and workflow capabilities integrated into Microsoft Defender for Endpoint and the Microsoft Defender XDR portal.

If you're working with licenses like Windows Professional or Microsoft 365 E3 without those advanced features, you can still use ASR, but you'll have to rely more on Event viewer, Microsoft Defender Antivirus logs, and proprietary solutions monitoring and reporting (event forwarding, SIEM, etc.). In all cases, it is essential to review the list of OS supportedbecause the different rules have minimum requirements for Windows 10/11 and server versions.

ASR rule modes and pre-assessment

Each ASR rule can be configured in four states: not configured/disabled, block, audit, or warningThese states are also represented with numeric codes (0, 1, 2 and 6 respectively) that are used in GPO, MDM, Intune and PowerShell.

Mode Block Activates the rule and directly stops the suspicious behavior. The mode Audit It logs events that would have been blocked, but lets the action continue, allowing you to assess the impact on business applications before tightening security.

Mode Warning (Warn) is a sort of middle ground: the rule behaves like a blocking rule, but the user sees a dialog box indicating that content has been blocked and is given the option to unlock temporarily for 24 hoursAfter that period, the same pattern will be blocked again unless the user allows it again.

Warning mode is only supported from Windows 10 version 1809 (RS5) and laterIn previous versions, if you configured a rule in warning mode, it would actually behave as a block rule. Additionally, some specific rules do not support warning mode when configured via Intune (although they do support it via Group Policy).

Before reaching the point of locking, it is strongly recommended to use audit mode and rely on the Microsoft Defender Vulnerability ManagementHere you can see the expected impact of each rule (percentage of affected devices, potential impact on users, etc.). Based on the audit data, you can decide which rules to activate in blocking mode, in which pilot groups, and what exclusions you need.

ASR rules by type: standard protection rules and other rules

Microsoft classifies ASR rules into two groups: on the one hand, the standard protection rulesThese are the ones that are almost always recommended to be activated because they have very little impact on usability, and on the other hand, the rest of the rules that usually require a more careful testing phase.

Among the standard protection rules, the following stand out, for example: “Block the abuse of exploited vulnerable signed controllers”, “Block the theft of credentials from the local security authority subsystem (lsass.exe)” o “Block persistence through WMI event subscriptions”These point directly to common techniques of privilege escalation, defense evasion, and persistence.

The remaining rules, while very powerful, are more likely to conflict with enterprise applications that make heavy use of scripts, macros, child processes, or remote administration tools. This includes all those that affect Office, Adobe Reader, PSExec, remote WMI, obfuscated scripts, execution from USB, WebShells, etc.

For each rule, Microsoft documents a Intune name, possible name in Configuration Manager, unique GUID, dependencies (AMSI, Cloud Protection, RPC…) and types of events generated in advanced search (for example, AsrObfuscatedScriptBlocked, AsrOfficeChildProcessAuditedetc.). These GUIDs are the ones you will need to use in GPO, MDM, and PowerShell to enable, disable, or change the mode.

Detailed description of the main ASR rules

ASR rules cover a very wide range of attack vectorsBelow is a summary of the most relevant ones and what exactly each one blocks, based on official references and practical experience.

Block the abuse of vulnerable, exploited signed drivers

This rule prevents an application with sufficient privileges from write signed but vulnerable drivers to disk that attackers can then load to gain access to the kernel and disable or bypass security solutions. It doesn't block the loading of vulnerable drivers that were already present, but it does cut off one of the typical ways to introduce them.

It is identified by the GUID 56a863a9-875e-4185-98a7-b882c64b5ce5 and generates events of type AsrVulnerableSignedDriverAudited y AsrVulnerableSignedDriverBlocked in Microsoft Defender's advanced search.

Prevent Adobe Reader from creating child processes

The purpose of this rule is to prevent Adobe Reader serves as a springboard to download and launch payloads. It blocks the creation of secondary processes from Reader, protecting against PDF exploits and social engineering techniques that rely on this viewer.

Your GUID is 7674ba52-37eb-4a4f-a9a1-f0f9a1619a2cand can generate events AsrAdobeReaderChildProcessAudited y AsrAdobeReaderChildProcessBlockedIt depends on Microsoft Defender Antivirus being operational.

Prevent all Office applications from creating child processes

This rule prohibits Word, Excel, PowerPoint, OneNote, and Access generate secondary processesIt's a direct way to stop many macro-based attacks launched by PowerShell. CMD or other system tools to execute malicious code.

The associated GUID is d4f940ab-401b-4efc-aadc-ad5f3c50688aIn real-world scenarios, some legitimate business applications also use this pattern (for example, to open a symbol of the system or apply changes to the Registry), so it is essential to test it first in audit mode.

Block LSASS credential theft

This rule protects the process lsass.exe against unauthorized access from other processes, reducing the attack surface for tools like Mimikatz, which attempt to extract hashes, plaintext passwords, or Kerberos tickets.

He shares a philosophy with Microsoft Defender Credential GuardIf you already have Credential Guard enabled, the rule adds little, but it's very useful in environments where you can't enable it due to incompatibilities with drivers or third-party software. Your GUID is 9e6c4e1f-7d60-472f-ba1a-a39ef669e4b2.

Block executable content from email clients and webmail

Here we enter a rule very much in line with phishing attacks. What it does is prevent... executables, scripts, and compressed files downloaded or attached from email and webmail clients run directly. It applies primarily to Outlook, Outlook.com, and popular webmail providers, and is especially useful in combination with other email protections and with the secure browser settings.

Your GUID is be9ba2d9-53ea-4cdc-84e5-9b1eeee46550 and generates events such as AsrExecutableEmailContentAudited y AsrExecutableEmailContentBlockedIt is especially useful in combination with other email protections.

Prevent executables from running if they do not meet prevalence, age, or trust list criteria.

This rule blocks the execution of binaries (.exe, .dll, .scr, etc.) that are not frequent enough, old enough, or reliable According to Microsoft's cloud reputation data, it is very powerful against new malware, but can be vulnerable in environments with a lot of in-house or unusual software.

The GUID is 01443614-cd74-433a-b99e-2ecdc07bfc25 And it explicitly depends on Cloud Protection. Again, it's a clear case of the rule that it's best to start in audit mode and then gradually implement blocking.

Block the execution of potentially obfuscated scripts

Obfuscated code is commonplace for both attackers and, sometimes, legitimate developers. This rule analyzes suspicious features in obfuscated PowerShell, VBScript, JavaScript, or macro scripts and blocks those with a high probability of being malicious.

Your GUID is 5beb7efe-fd9a-4556-801d-275e5ffc04cc It uses AMSI (Antimalware Scan Interface) and cloud protection to make its decision. This is one of the most effective rules against modern script-based campaigns.

Prevent JavaScript or VBScript from launching downloaded executables

This rule focuses on the typical downloader pattern: a A script in JS or VBS downloads a binary file from the internet and executes it.What ASR does here is prevent that exact step of launching the downloaded executable.

Your GUID is d3e037e1-3eb8-44c8-a917-57927947596dIt also relies on AMSI and is especially crucial in scenarios where older technologies or scripts are still being used in the browser or on the desktop.

Prevent Office applications from creating executable content

Another common technique is to use Office to write malicious components to disk that persist after a restart (for example, a persistent executable or DLL). This rule prevents Office from saving or accessing that type of executable content to launch it.

The GUID is 3b576869-a4ec-4529-8536-b80a7769e899 It relies on Microsoft Defender Antivirus and RPC. It is very effective at breaking macro-based infection chains that download persistent payloads.

Prevent Office applications from inserting code into other processes

This prevents Office from using techniques of process injectionThis involves injecting code into other processes to disguise malicious activity. Microsoft is unaware of any legitimate business uses for this pattern, so it's a fairly safe rule to enable in most environments.

Your GUID is 75668c1f-73b5-4cf0-bb93-3ecf5cb7cc84However, specific applications that conflict with this rule have been documented, so if noise appears in the environment, it is advisable to check compatibility.

Prevent Office communication applications from creating child processes

Primarily aimed at Outlook and other Office communication products, this rule blocks the creating secondary processes from the email clientmitigating attacks that exploit vulnerabilities in Outlook rules, forms, or malicious emails to execute code.

Your GUID is 26190899-1602-49e8-8b27-eb1d0a1ce869 and helps to close a very attractive vector for targeted phishing campaigns.

Block persistence through WMI event subscriptions

Many "fileless" threats rely on WMI to achieve persistence without leaving clear traces on disk. This rule blocks the creation of malicious WMI event subscriptions that could relaunch code whenever a condition is met.

Your GUID is e6db77e5-3df2-4cf1-b95a-636979351e5b and it does not allow exclusions of files or folders, precisely to prevent them from being abused.

Block processes created from PSExec and WMI commands

PsExec and WMI are legitimate remote administration tools, but they are also constantly used for lateral movement and malware propagationThis rule prevents processes originating from commands PSExec or WMI are executed, reducing that vector.

The GUID is d1e49aac-8f56-4280-b9ba-993a6d77406cIt's one of those rules where coordination with administrators and operations teams is key to avoid disrupting legitimate remote management processes.

Block safe mode reboots initiated by commands

En safe modeMany security solutions are disabled or severely limited. Some ransomware abuses commands such as bcdedit or bootcfg to reboot in safe mode and encrypt without much resistance. This rule eliminates that possibility, allowing continued access to safe mode only through the manual recovery environment.

Your GUID is 33ddedf1-c6e0-47cb-833e-de6133960387 and generates events such as AsrSafeModeRebootBlocked o AsrSafeModeRebootWarnBypassed.

Block unsigned or untrusted processes from USB

Here, a classic entry point is controlled: the USB drives and SD cardsWith this rule, unsigned or untrusted executables run from these media are blocked. This applies to binaries such as .exe, .dll, .scr, etc.

The GUID is b2b3f03d-6a65-4f7b-a9c7-1c7ef74a9ba4 and it is especially useful in environments where there is a risk of uncontrolled USB use.

Block the use of copied or spoofed system tools

Many attacks attempt to copy or imitate Windows system tools (such as cmd.exe, powershell.exe, regsvr32.exe, etc.) to masquerade as legitimate processes. This rule blocks the execution of executables identified as copies or imposters of these tools.

Your GUID is c0033c00-d16d-4114-a5a0-dc9b3a7d2ceb and produces events such as AsrAbusedSystemToolBlockedIt is a good complement to other application control techniques.

Block the creation of WebShell on servers

WebShells are scripts specifically designed for to give the attacker remote control over a serverallowing it to execute commands, upload files, exfiltrate data, etc. This rule, aimed at servers and roles like Exchange, blocks the creation of these malicious scripts.

The GUID is a8f5898e-1dc8-49a9-9878-85004b8a61e6 and it is designed to specifically harden exposed servers.

Block Win32 API calls from Office macros

Probably one of the most effective rules against macro malwareIt blocks Office VBA code from importing and calling Win32 APIs, which is commonly used to load shellcode into memory, manipulate processes, access memory, etc.

Your GUID is 92e97fa1-2edf-4476-bdd6-9dd0b4dddc7b and it relies on AMSI. In practice, it nips in the bud many malware templates in Word and Excel that rely on these calls to execute arbitrary code.

Use of advanced ransomware protection

This rule adds an additional layer of protection based on customer and cloud heuristics to detect behavior consistent with ransomware. It takes into account factors such as reputation, digital signature, or prevalence to decide whether a file is more likely to be ransomware than a legitimate program.

Your GUID is c1db55ab-c21a-4637-bb3f-a12568109d35And although it tries to minimize false positives, it tends to err on the side of caution so as not to miss a real cipher.

Configuration methods: Intune, MDM, Configuration Manager, GPO, and PowerShell

Attack surface reduction rules can be configured in several ways depending on how you manage your device fleet. Microsoft's general recommendation is to use enterprise-level management platforms (Intune or Configuration Manager), since their policies take precedence over GPO or local PowerShell configurations when the system starts.

With Microsoft Intune You have three approaches: the ASR-specific endpoint security policy, device configuration profiles (Endpoint Protection), and custom profiles using OMA-URI to define rules by GUID and state. In all cases, you can add file and folder exclusions directly or import them from a CSV file.

In environments generic MDMs CSP is used ./Vendor/MSFT/Policy/Config/Defender/AttackSurfaceReductionRules To define an array of GUIDs with statuses, separated by vertical bars. For example, you can combine several rules by assigning 0, 1, 2, or 6 depending on whether you want to disable, block, audit, or warn. Exclusions are managed with the CSP. ./Vendor/MSFT/Policy/Config/Defender/AttackSurfaceReductionOnlyExclusions.

With Microsoft Configuration Manager You can create policies for Windows Defender Exploit Guard focused on “Attack surface reduction”, select which rules you want to block or audit and deploy them to specific collections of devices.

La Group policy It allows you to configure ASR via administrative templates by navigating to the Microsoft Defender Antivirus and "Attack Surface Reduction" nodes. There, you enable the "Configure attack surface reduction rules" policy and enter the GUIDs with their corresponding status. An additional GPO allows you to define file and path exclusions.

Lastly, PowerShell It's the most direct and useful way for one-off tests or automation scripts. Cmdlets like Set-MpPreference y Add-MpPreference They allow you to enable, audit, warn, or disable individual rules, as well as manage the exclusion list with -AttackSurfaceReductionOnlyExclusionsHowever, if there is a GPO or Intune involved, their settings take precedence.

Exclusions, policy conflicts, and notifications

Almost all ASR rules allow exclude files and folders This prevents the blocking of legitimate applications that, by design, exhibit malware-like behavior. It's a powerful tool, but it must be used with surgical precision: overly broad exclusions can leave serious vulnerabilities.

When conflicting policies are applied from MDM and Intune, the configuration of Group directive takes priority If it exists. Furthermore, ASR rules support a policy merging behavior: a superset is constructed with the non-conflicting configuration, and conflicting entries are omitted for that device.

Each time a rule is triggered in block mode, the user sees a system notification explaining that an operation has been blocked for security reasons. These notifications can be customized with company details and contact information. For some rules and statuses, EDR alerts and internal notifications are also generated and visible in the Microsoft Defender portal.

Not all rules respect the Microsoft Defender antivirus exclusions Nor do they consider the indicators of compromise (IOCs) configured in Defender for Endpoint. For example, the LSASS credential theft blocking rule or the Office code insertion blocking rule do not take certain IOCs into account, precisely to maintain their robustness.

ASR Event Monitoring: Portal, Advanced Search, and Event Viewer

Monitoring is key to ensuring ASR isn't a black box. Defender for Endpoint provides detailed reports of events and blockages related to ASR rules, which can be consulted both on the Microsoft Defender XDR portal and through advanced search.

Advanced search allows you to launch consultations about the table DeviceEventsfiltering by action types that begin with "Asr". For example, the basic query DeviceEvents | where ActionType startswith 'Asr' It shows you ASR-related events grouped by process and by hour, as it is normalized to a single instance per hour to reduce volume.

In environments without E5 or without access to these capabilities, there is always the option of reviewing the Windows logs in Event ViewerMicrosoft provides custom views (such as the cfa-events.xml file) that filter relevant events, with identifiers such as 5007 (configuration changes), 1121 (rule in blocking mode) and 1122 (rule in audit mode).

For hybrid deployments, it's quite common to forward these events to a SIEM or centralized logging platform, correlate them with other indicators and trigger custom alerts when certain rules start generating too many events in a specific segment of the network.

Reducing the attack surface beyond ASR: strategies, technologies and challenges

Although ASR rules are a very important component, reducing the attack surface as a global strategy goes far beyond the endpoint. It involves map all assets and entry pointsEliminate unnecessary services, segment networks, apply strict access controls, harden systems, maintain secure configurations, and protect the cloud and APIs.

Organizations typically start with a complete inventory of devices, software, accounts and connectionsNext, unused services and applications are identified and uninstalled, network ports are closed, and features that don't add value are disabled. This simplifies the environment and reduces the number of "doors" that need monitoring.

The part of access control It is critical: application of the principle of least privilege, strong passwords, multi-factor authentication, rapid revocation of access when someone changes roles or leaves the organization, and monitoring of suspicious login attempts.

In the cloud, the attack surface grows with each new service, API, or integration. Misconfigurations in storageExcessively broad roles, orphaned accounts, or insecure default values ​​are common problems. This is where regular configuration audits, encryption of data at rest and in transit, virtual network segmentation, and continuous permission reviews come into play.

To support all of this, technologies such as asset discovery and mapping tools, vulnerability scanners, access control systems, configuration management platforms, and network security tools (firewalls, IDS/IPS, NDR, etc.). Solutions like SentinelOne, for example, combine endpoint protection, behavioral analysis, and automated response to further reduce the effective attack surface.

The challenges are many: complex dependencies between systemsThe presence of legacy applications that don't support modern measures, the rapid pace of technological change, resource limitations, and the perennial conflict between security and productivity all contribute to this challenge. Finding the right balance requires a deep understanding of the business and prioritizing critical assets and processes.

Given this context, ASR rules become one of the most effective tools for limiting the attacker's playing field at the endpoint. Well-planned (starting with auditing), fine-tuned with precise exclusions, and carefully monitored, they prevent a user error, a single exploit, or a malicious USB drive from automatically escalating into a critical incident, helping to maintain a smaller, more manageable, and, above all, more effective attack surface. much harder to exploit.