Is attack surface reduction part of Windows?
Attack surface reduction was originally a feature of the suite of exploit guard features introduced as a major update to Microsoft Defender Antivirus, in Windows 10, version 1709. Microsoft Defender Antivirus is the native antimalware component of Windows. However, the full attack surface reduction feature-set is only available with a Windows enterprise license. Also note that some Microsoft Defender Antivirus exclusions are applicable to attack surface reduction rule exclusions. See Attack surface reduction rules reference - Microsoft Defender Antivirus exclusions and attack surface reduction rules.
Do I need to have an enterprise license to run attack surface reduction rules?
The full set of attack surface reduction rules and features is only supported if you have an enterprise license for Windows 10 or Windows 11. A limited number of rules may work without an enterprise license. If you have Microsoft 365 Business, set Microsoft Defender Antivirus as your primary security solution, and enable the rules through PowerShell. Using attack surface reduction without an enterprise license isn't officially supported and you won't be able to use the full capabilities of attack surface reduction.
Is attack surface reduction supported if I have an E3 license?
Yes. Attack surface reduction is supported for Windows Enterprise E3 and above.
Which features are supported with an E5 license?
All of the rules supported with E3 are also supported with E5.
E5 adds greater integration with Defender for Endpoint. With E5, you can view alerts in real-time, fine-tune rule exclusions, configure attack surface reduction rules, and view lists of event reports.
What are the currently supported attack surface reduction rules?
Attack surface reduction currently supports all of the rules below.
What rules to enable? All, or can I turn on individual rules?
To help you figure out what's best for your environment, we recommended that you enable attack surface reduction rules in audit mode. With this approach, you can determine the possible effect to your organization. For example, your line-of-business applications.
How do attack surface reduction rules exclusions work?
For attack surface reduction rules, if you add one exclusion, it affects every attack surface reduction rule.
Attack surface reduction rules exclusions support wildcards, paths, and environmental variables. For more information on how to use wildcards in attack surface reduction rules, see configure and validate exclusions based on file extension and folder location.
Be aware of the following items about attack surface reduction rules exclusions (including wildcards and env. variables):
- Most attack surface reduction rules exclusions are independent from Microsoft Defender Antivirus exclusions. However, Microsoft Defender Antivirus exclusions do apply to some attack surface reduction rules. See Attack surface reduction rules reference - Microsoft Defender Antivirus exclusions and attack surface reduction rules.
- Wildcards can't be used to define a drive letter.
- If you want to exclude more than one folder, in a path, use multiple instances of
\*\to indicate multiple nested folders (for example,
- Microsoft Endpoint Configuration Manager supports wildcards (* or ?).
- If you want to exclude a file that contains random characters (automated file generation), you can use the '?' symbol (for example,
- Attack surface reduction exclusions in Group Policy don't support quotes (the engine natively handles long path, spaces, etc., so there's no need to use quotes).
- Attack surface reduction rules run under NT AUTHORITY\SYSTEM account, so environmental variables are limited to machine variables.
How do I know what I need to exclude?
Different attack surface reduction rules have different protection flows. Always think about what the attack surface reduction rule you're configuring protects against, and how the actual execution flow pans out.
Example: Block credential stealing from the Windows local security authority subsystem Reading directly from Local Security Authority Subsystem (LSASS) process can be a security risk, since it might expose corporate credentials.
This rule prevents untrusted processes from having direct access to LSASS memory. Whenever a process tries to use the OpenProcess() function to access LSASS, with an access right of PROCESS_VM_READ, the rule specifically blocks that access right.
Looking at the above example, if you really had to create an exception for the process that the access right was blocked, adding the filename along with full path would exclude it from being blocked and after allowed to access LSASS process memory. The value of 0 means that attack surface reduction rules ignore this file/process and not block/audit it.
How do I configure per-rule exclusions?
For information about configuring per-rule exclusions, see Test attack surface reduction rules.
What are the rules Microsoft recommends enabling?
We recommend enabling every possible rule. However, there are some cases where you shouldn't enable a rule. For example, we don't recommend enabling the Block process creations originating from PSExec and WMI commands rule, if you're using Microsoft Endpoint Configuration Manager (or, System Center Configuration Manager - SCCM) to manage your endpoints.
We highly recommend you that you read each rule-specific information and/or warnings, which are available in our public documentation. spanning across multiple pillars of protection, like Office, Credentials, Scripts, E-Mail, etc. All attack surface reduction rules, except for Block persistence through WMI event subscription, are supported on Windows 1709 and later:
- Block abuse of exploited vulnerable signed drivers
- Block executable content from email client and webmail
- Block all Office applications from creating child processes
- Block Office applications from creating executable content
- Block Office applications from injecting code into other processes
- Block execution of potentially obfuscated scripts
- Block Win32 API calls from Office macro
- Use advanced protection against ransomware
- Block credential stealing from the Windows local security authority subsystem (lsass.exe)
- Block process creations originating from PSExec and WMI commands
- Block untrusted and unsigned processes that run from USB
- Block executable files from running unless they meet a prevalence, age, or trusted list criteria
- Block Office communication applications from creating child processes
- Block Adobe Reader from creating child processes
- Block persistence through WMI event subscription
Is Local security authority subsystem enabled by default?
The default state for the attack Surface Reduction rule "Block credential stealing from the Windows local security authority subsystem (lsass.exe)" changes from Not Configured to Configured and the default mode set to Block. All other attack surface reduction rules remain in their default state: Not Configured. Additional filtering logic has already been incorporated in the rule to reduce end user notifications. Customers can configure the rule to Audit, Warn or Disabled modes, which overrides the default mode. The functionality of this rule is the same, whether the rule is configured in the on-by-default mode, or if you enable Block mode manually.
What are some good recommendations for getting started with attack surface reduction?
Test how attack surface reduction rules impact your organization before enabling them by running attack surface reduction rules in audit mode for a brief period of time. While you're running the rules in audit mode, you can identify any line-of-business applications that might get blocked erroneously, and exclude them from attack surface reduction.
Larger organizations should consider rolling out attack surface reduction rules in "rings," by auditing and enabling rules in increasingly broader subsets of devices. You can arrange your organization's devices into rings by using Intune or a Group Policy management tool.
How long should I test an attack surface reduction rule in audit mode before enabling it?
Keep the rule in audit mode for about 30 days to get a good baseline for how the rule operates once it goes live throughout your organization. During the audit period, you can identify any line-of-business applications that might get blocked by the rule, and configure the rule to exclude them.
I'm making the switch from a third-party security solution to Defender for Endpoint. Is there an "easy" way to export rules from another security solution to attack surface reduction?
In most cases, it's easier and better to start with the baseline recommendations suggested by Defender for Endpoint than to attempt to import rules from another security solution. Then, use tools such as audit mode, monitoring, and analytics to configure your new solution to suit your unique needs.
The default configuration for most attack surface reduction rules, combined with Defender for Endpoint's real-time protection, protects against a large number of exploits and vulnerabilities.
From within Defender for Endpoint, you can update your defenses with custom indicators, to allow and block certain software behaviors. attack surface reduction also allows for some customization of rules, in the form of file and folder exclusions. As a general rule, it's best to audit a rule for a period of time, and configure exclusions for any line-of-business applications that might get blocked.
Does attack surface reduction support file or folder exclusions that include system variables and wildcards in the path?
Yes. For more information on excluding files or folders from attack surface reduction rules, see Excluding files and folders from attack surface reduction rules and for more information on using system variables and wildcards in excluded file paths, seeConfigure and validate exclusions based on file extension and folder location.
Do attack surface reduction rules cover all applications by default?
It depends on the rule. Most attack surface reduction rules cover the behavior of Microsoft Office products and services, such as Word, Excel, PowerPoint, and OneNote, or Outlook. Certain attack surface reduction rules, such as Block execution of potentially obfuscated scripts, are more general in scope.
Does attack surface reduction support third-party security solutions?
attack surface reduction uses Microsoft Defender Antivirus to block applications. It is not possible to configure attack surface reduction to use another security solution for blocking at this time.
I have an E5 license and enabled some attack surface reduction rules in conjunction with Defender for Endpoint. Is it possible for an attack surface reduction event to not show up at all in Defender for Endpoint's event timeline?
Whenever a notification is triggered locally by an attack surface reduction rule, a report on the event is also sent to the Defender for Endpoint portal. If you're having trouble finding the event, you can filter the events timeline using the search box. You can also view attack surface reduction events by visiting Go to attack surface management, from the Configuration management icon in the Defender for Cloud taskbar. The attack surface management page includes a tab for report detections, which includes a full list of attack surface reduction rule events reported to Defender for Endpoint.
I applied a rule using GPO. Now when I try to check the indexing options for the rule in Microsoft Outlook, I get a message stating, 'Access denied'.
Try opening the indexing options directly from Windows 10 or Windows 11.
Select the Search icon on the Windows taskbar.
Enter Indexing options into the search box.
Are the criteria used by the rule, "Block executable files from running unless they meet a prevalence, age, or trusted list criterion," configurable by an admin?
No. The criteria used by this rule are maintained by Microsoft cloud protection, to keep the trusted list constantly up to date with data gathered from around the world. Local admins don't have write access to alter this data. If you're looking to configure this rule to tailor it for your enterprise, you can add certain applications to the exclusions list to prevent the rule from being triggered.
I enabled the attack surface reduction rule, 'Block executable files from running unless they meet a prevalence, age, or trusted list criterion'. After some time, I updated a piece of software, and the rule is now blocking it, even though it didn't before. Did something go wrong?
This rule relies upon each application having a known reputation, as measured by prevalence, age, or inclusion on a list of trusted apps. The rule's decision to block or allow an application is ultimately determined by Microsoft cloud protection's assessment of these criteria.
Usually, cloud protection can determine that a new version of an application is similar enough to previous versions that it doesn't need to be reassessed at length. However, it might take some time for the app to build reputation after switching versions, particularly after a major update. In the meantime, you can add the application to the exclusions list, to prevent this rule from blocking important applications. If you're frequently updating and working with new versions of applications, you may opt instead to run this rule in audit mode.
I recently enabled the attack surface reduction rule, 'Block credential stealing from the Windows local security authority subsystem (lsass.exe)', and I'm getting a large number of notifications. What is going on?
A notification generated by this rule doesn't necessarily indicate malicious activity; however, this rule is still useful for blocking malicious activity, since malware often targets lsass.exe to gain illicit access to accounts. The lsass.exe process stores user credentials in memory after a user has logged in. Windows uses these credentials to validate users and apply local security policies.
Because many legitimate processes throughout a typical day are calling on lsass.exe for credentials, this rule can be especially noisy. If a known legitimate application causes this rule to generate an excessive number of notifications, you can add it to the exclusion list. Most other attack surface reduction rules generate a relatively smaller number of notifications, in comparison to this one, since calling on lsass.exe is typical of many applications' normal functioning.
Is it a good idea to enable the rule, 'Block credential stealing from the Windows local security authority subsystem (lsass.exe)', alongside LSA protection?
Enabling this rule doesn't provide additional protection if you have LSA protection enabled as well. Both the rule and LSA protection work in much the same way, so having both running at the same time would be redundant. However, sometimes you may not be able to enable LSA protection. In those cases, you can enable this rule to provide equivalent protection against malware that target lsass.exe.