ASR rules reference - Microsoft Defender for Endpoint (original) (raw)

Attack surface reduction (ASR) rules target risky software behavior on Windows devices that attackers commonly exploit through malware (for example, launching scripts that download files, running obfuscated scripts, and injecting code into other processes). For more information about ASR rules, see Attack surface reduction (ASR) rules overview.

This article is a technical reference for ASR rules that provides the following information:

Important

Some information in this article relates to a prereleased product which may be substantially modified before it's commercially released. Microsoft makes no warranties, expressed or implied, with respect to the information provided here.

Operating system support for ASR rules

ASR rules are a Microsoft Defender Antivirus feature that's available on any edition of Windows that includes Microsoft Defender Antivirus (for example, Windows 11 Home). You can configure ASR rules locally using PowerShell or Group Policy.

The following table describes the operating system support for ASR rules in Microsoft Defender for Endpoint, which provides centralized management, reporting, and alerting through Microsoft Intune, Microsoft Configuration Manager, and the Microsoft Defender portal:

Rule name Windows 11 or later Windows 10 Windows Server 2019 or later Windows Server 2016* Windows Server 2012 R2*
Standard protection rules
Block abuse of exploited vulnerable signed drivers (Device) Y 1709 or later Y Windows Server 1803 (SAC) or later Y
Block credential stealing from the Windows local security authority subsystem Y 1803 or later Y Y Y
Block persistence through WMI event subscription Y 1903 or later Windows Server 1903 (SAC) or later N N
Other ASR rules
Block Adobe Reader from creating child processes Y 1809 or later Y Y Y
Block all Office applications from creating child processes Y 1709 or later Y Y Y
Block executable content from email client and webmail Y 1709 or later Y Y Y
Block executable files from running unless they meet a prevalence, age, or trusted list criterion Y 1803 or later Y Y Y
Block execution of potentially obfuscated scripts Y 1709 or later Y Y Y
Block JavaScript or VBScript from launching downloaded executable content Y 1709 or later Y N N
Block Office applications from creating executable content Y 1709 or later Y Y Y
Block Office applications from injecting code into other processes Y 1709 or later Y Y Y
Block Office communication application from creating child processes Y 1709 or later Y Y Y
Block process creations originating from PSExec and WMI commands Y 1803 or later Y Y Y
Block rebooting machine in Safe Mode Y 1709 or later Y Y Y
Block untrusted and unsigned processes that run from USB Y 1709 or later Y Y Y
Block use of copied or impersonated system tools Y 1709 or later Y Y Y
Block Webshell creation for Servers n/a n/a Exchange servers only Exchange servers only N
Block Win32 API calls from Office macros Y 1709 or later n/a n/a n/a
Use advanced protection against ransomware Y 1803 or later Y Y Y

* Supported ASR rules in Windows Server 2016 and Windows Server 2012 R2 require onboarding using the modern unified solution package. For more information, see New Windows Server 2012 R2 and 2016 functionality in the modern unified solution.

Deployment method support for ASR rules

Although Defender for Endpoint supports ASR rules, you need a separate service to deploy the rules to devices. The supported methods for deploying ASR rules are described in the following table.

Rule name Intune Configuration Manager MDM CSP Centralized Group Policy
Standard protection rules
Block abuse of exploited vulnerable signed drivers (Device) Y N Y Y
Block credential stealing from the Windows local security authority subsystem Y 1802 or later Y Y
Block persistence through WMI event subscription Y N Y Y
Other ASR rules
Block Adobe Reader from creating child processes Y N Y Y
Block all Office applications from creating child processes Y 1710 or later Y Y
Block executable content from email client and webmail Y 1710 or later Y Y
Block executable files from running unless they meet a prevalence, age, or trusted list criterion Y 1802 or later Y Y
Block execution of potentially obfuscated scripts Y 1710 or later Y Y
Block JavaScript or VBScript from launching downloaded executable content Y 1710 or later Y Y
Block Office applications from creating executable content Y 1710 or later Y Y
Block Office applications from injecting code into other processes Y 1710 or later Y Y
Block Office communication application from creating child processes Y N Y Y
Block process creations originating from PSExec and WMI commands Y N Y Y
Block rebooting machine in Safe Mode Y N Y Y
Block untrusted and unsigned processes that run from USB Y 1802 or later Y Y
Block use of copied or impersonated system tools Y N Y Y
Block Webshell creation for Servers Y N Y Y
Block Win32 API calls from Office macros Y 1710 or later Y Y
Use advanced protection against ransomware Y 1802 or later Y Y

Tip

You can also configure ASR rules locally on individual devices using Group Policy or PowerShell. All ASR rules are supported by both methods on local devices.

Alerts and notifications from ASR rule actions

The following table describes the organization and local alerts that active ASR rules can generate.

Rule name EDR alerts Usernotifications
Standard protection rules
Block abuse of exploited vulnerable signed drivers (Device) N Y
Block credential stealing from the Windows local security authority subsystem[¹] N N
Block persistence through WMI event subscription Y Y
Other ASR rules
Block Adobe Reader from creating child processes[²] Y Y
Block all Office applications from creating child processes N Y
Block executable content from email client and webmail[²] Y Y
Block executable files from running unless they meet a prevalence, age, or trusted list criterion N Y
Block execution of potentially obfuscated scripts Y Y
Block JavaScript or VBScript from launching downloaded executable content[²] Y Y
Block Office applications from creating executable content N Y
Block Office applications from injecting code into other processes[¹] N Y
Block Office communication application from creating child processes N Y
Block process creations originating from PSExec and WMI commands N Y
Block rebooting machine in Safe Mode N N
Block untrusted and unsigned processes that run from USB Y Y
Block use of copied or impersonated system tools N Y
Block Webshell creation for Servers N N
Block Win32 API calls from Office macros Y N
Use advanced protection against ransomware Y Y

¹ This ASR rule doesn't support Warn mode.

² This ASR rule in Block or Warn mode has the following extra requirements in the cloud protection level in Microsoft Defender Antivirus:

ASR rule details

Standard protection rules

Block abuse of exploited vulnerable signed drivers (Device)

Local apps with sufficient privileges can exploit vulnerable signed drivers to gain access to the operating system kernel. Vulnerable signed drivers enable attackers to disable or circumvent security solutions, eventually leading to system compromise.

This ASR rule prevents apps from saving vulnerable signed drivers on the computer. It doesn't prevent loading existing drivers already on the computer.

Note

Note

If you enabled Local Security Authority (LSA) protection (recommended, along with Credential Guard):

This ASR rule helps prevent credential stealing by locking down the Local Security Authority Subsystem Service (LSASS). LSASS authenticates users who sign in on Windows computers. Typically, Credential Guard in Windows prevents attempts to extract credentials from LSASS.

Many processes make unnecessary calls to LSASS for access rights that aren't needed. This activity generates considerable ASR rule noise, but doesn't block functionality. For example, Google Chrome updates unnecessarily access LSASS, because passwords are stored in LSASS on the device. Activating this ASR rule on the device blocks Chrome updates from accessing LSASS, but doesn't block Chrome from updating. These ASR rule events are good because the Chrome software update process shouldn't access LSASS.

For information about the types of rights that are typically requested in process calls to LSASS, see Process Security and Access Rights.

Some organizations can't enable Credential Guard because of compatibility issues with custom smartcard drivers or other programs that load into the LSA. In these cases, attackers can use tools like Mimikatz to scrape cleartext passwords and NTLM hashes from LSASS.

If you can't enable LSA protection and/or Credential Guard, you can configure this rule to provide equivalent protection against malware that targets lsass.exe.

Note

Block persistence through WMI event subscription

This ASR rule prevents malware from abusing WMI to get persistence on devices.

Fileless threats use various tactics to stay hidden, to avoid being seen in the file system, and to gain periodic control. Some threats can abuse the WMI repository and event model to stay hidden.

Note

Other ASR rules

Block Adobe Reader from creating child processes

This ASR rule prevents attacks by blocking Adobe Reader from creating processes.

Malware can download and launch payloads and break out of Adobe Reader through social engineering or exploits. By blocking Adobe Reader from generating child processes, malware that attempts to use Adobe Reader as an attack vector is prevented from spreading.

Note

Block all Office applications from creating child processes

This rule blocks Office apps from creating child processes. Office apps include Word, Excel, PowerPoint, OneNote, and Access.

Creating malicious child processes is a common malware strategy. Malware that abuses Office as a vector often runs VBA macros and exploit code to download and attempt to run more payloads. However, some legitimate line-of-business apps might also generate child processes for benign purposes. For example, spawning a Command Prompt or using PowerShell to configure registry settings.

Note

This rule is enforced only if Office is installed in the %ProgramFiles% or %ProgramFiles(x86)% locations (By default, C:\Program Files and C:\Program Files (x86)).

Block executable content from email client and webmail

This rule blocks email opened with Microsoft Outlook, Outlook.com, and other popular webmail providers from propagating the following file types:

Note

Block executable files from running unless they meet a prevalence, age, or trusted list criterion

This ASR rule blocks executable files (for example, .exe, .dll, or .scr, from launching). Launching untrusted or unknown executable files can be risky, as it's not initially clear if the files are malicious.

Note

Block execution of potentially obfuscated scripts

This ASR rule detects suspicious properties within an obfuscated script.

Script obfuscation is a common technique that both malware authors and legitimate applications use to hide intellectual property or decrease script loading times. Malware authors also use obfuscation to make malicious code harder to read, which hampers close scrutiny by humans and security software.

Note

Block JavaScript or VBScript from launching downloaded executable content

This ASR rule prevents scripts from launching potentially malicious downloaded content. Malware written in JavaScript or VBScript often acts as a downloader to fetch and launch other malware from the internet. Although not common, line-of-business apps sometimes use scripts to download and launch installers.

Note

Block Office applications from creating executable content

This ASR rule prevents Office apps (for example, Word, Excel, and PowerPoint) from being used as a vector to save malicious components to disk. These malicious components can survive a computer reboot and persist on the system. This rule defends against this persistence technique by:

Block Office applications from injecting code into other processes

This ASR rule blocks code injection attempts from Office apps into other processes. Attackers might attempt to use Office apps to migrate malicious code into other processes through code injection, so the code can masquerade as a clean process. There are no known legitimate business purposes for using code injection.

Note

Block Office communication application from creating child processes

This ASR rule prevents Outlook from creating child processes, while still allowing legitimate Outlook functions. This ASR rule protects against:

Note

This rule has limited exclusion support. For details, see File and folder exclusions for ASR rules.

This rule is enforced only if Office is installed in the %ProgramFiles% or %ProgramFiles(x86)% locations (By default, C:\Program Files and C:\Program Files (x86)).

Block process creations originating from PSExec and WMI commands

Important

If you use Microsoft Configuration Manager, don't use other available deployment methods to enable this rule on managed devices. The Configuration Manager client relies heavily on WMI.

This ASR rule blocks processes created through PsExec and WMI from running. PsExec and WMI can remotely execute code. Malware can use PsExec and WMI for command and control, or to spread network infections.

Block rebooting machine in Safe Mode

This ASR rule prevents commonly abused commands like bcdedit and bootcfg from restarting Windows computers in Safe Mode. In Safe Mode, many security products are disabled or run with limited functionality. Safe Mode allows attackers to further launch tampering commands, or execute and encrypt all files on the machine.

Safe Mode is still manually accessible from the Windows Recovery Environment.

Block untrusted and unsigned processes that run from USB

This ASR rule prevents unsigned or untrusted executable files (for example, .exe, .dll, or .scr) from running from USB removable drives, including SD cards.

This ASR rule doesn't block the files from being copied from the USB drive to disk. It blocks the copied files from running from disk.

Block use of copied or impersonated system tools

This ASR rule blocks the propagation and use of executable files identified as copies (duplicates or imposters) of Windows system tools. Some malicious programs might try to copy or impersonate Windows system tools to avoid detection or gain privileges. Allowing such executable files can lead to potential attacks.

Block Webshell creation for Servers

This ASR rule blocks web shell script creation on Windows servers running Microsoft Exchange. A web shell script is a crafted script that allows an attacker to control the compromised server. A web shell script might include the following functionality:

Note

Block Win32 API calls from Office macros

Office Visual Basic for Applications (VBA) enables Win32 API calls. This ASR rule prevents VBA macros from calling Win32 APIs. Malware can abuse this capability, such as calling Win32 APIs to launch malicious shellcode without writing anything directly to disk.

Most organizations don't require Win32 API calls from VBA macros, even if they use macros in other ways.

Use advanced protection against ransomware

Note

This ASR rule provides an extra layer of protection against ransomware. It uses both client and cloud heuristics to determine whether a file resembles ransomware. This rule doesn't block files that have one or more of the following characteristics:

This rule doesn't just block files with a bad reputation. Instead, the rule errs on the side of caution and also blocks files that don't yet have a positive reputation. Typically, blocks on benign, unknown files by this rule eventually resolve themselves. The file's reputation and trust values incrementally increase as non-problematic usage increases.

If blocks on benign, unknown files don't resolve in a timely manner, you can configure a per-ASR rule exclusion for this rule or use the Allow action for an indicator of compromise (IoC).

Related content