Hello again and welcome to the second part in our blog series on demystifying attack surface reduction (ASR) rules. This blog post is focused on how to configure Microsoft Defender ATP ASR rules and how to work your way through exclusions.
You can follow the blog series here to read all the posts on this topic.
We went through the Whys and the What’s. Let’s cover the How’s!
#1 How can I configure/enable ASR rules?
As you might have guessed, the answer is: it depends! And that’s because there are multiple ways to configure ASR rules.
Any of these methods will work:
- Microsoft Intune
- Mobile Device Management (MDM)
- Microsoft Endpoint Configuration Manager
- Group Policy
- PowerShell
Through any of the above methods, you’ll be able to set all the possible states of an ASR rule:
- Not configured: Disable the ASR rule (equals to 0)
- Block: Enable the ASR rule (equals to 1)
- Audit: Evaluate how the ASR rule would impact your organization if enabled (equals to 2)
Regardless of the method that you choose, the principles that we’ve pointed out before still stand.
Our recommendation is to start the rule in audit mode. This will allow you to review logs and reports to analyze the rule’s impact and give you the opportunity to create any exclusions for your line-of-business apps, for example, before turning the rule on in block mode, or scrapping it entirely.
One of the easiest ways to start testing ASR rules is by leveraging the available Windows Defender PowerShell cmdlet Set-MPPreference.
But before showing you how to use the above cmdlet, let us first talk about ASR rules GUIDs.
Throughout the various configuration channels for ASR rules, you’ll notice that some of those, like GPO and PowerShell, will require you to specifically define which rule to enable (e.g. “Value name”).
The way we allow you to do so, is by referencing the actual rule Globally Unique Identifier (GUID).
The complete list of rule name to GUID mapping is available here.
Use these GUIDs when manually setting ASR rules via GPO and/or PowerShell. We’ll go through a couple of examples in this blog post.
Set-MPPreference example:
Set-MPPreference -AttackSurfaceReductionRules_Ids D3E037E1-3EB8-44C8-A917-57927947596D -AttackSurfaceReductionRules_Actions 1
The above command will enable the ASR rule, “Block JavaScript or VBScript from launching downloaded executable content”, in block mode.
You can then use the Get-MPPreference cmdlet to check the rule’s status and if it’s been successfully applied (more info about reporting and checking rules state will be available in future blog posts!).
Now let’s go to Group Policy and try to do the same as above.
Open the Group Policy Management Console, if you’re configuring this via Active Directory, or Group Policy Edit, if testing locally in an endpoint.
Navigate through Computer Configuration > Administrative Templates > Windows Components > Windows Defender Antivirus > Windows Defender Exploit Guard > Attack Surface Reduction
Note: Please be aware that Microsoft rebranded Windows Defender Antivirus to Microsoft Defender Antivirus in 20H1. Previous versions of Windows 10 will still reference *Windows Defender*.
Open the Configure Attack Surface Reduction rules policy and add the and the action value.
As for Intune and Configuration Manager, both platforms already have a built-in list of ASR rules; therefore, you don’t need to know the GUIDs, nor what each action value represents. It’s as simple as choosing which actions you want to set for the rule you want to enable.
Here is a screenshot of the ASR rules list available in Intune.
ASR rules can be found in Intune Device Configuration. Create a new profile and select Windows 10 Endpoint Protection as a platform and Endpoint Protection under profile. Attack Surface Reduction rules will be available under Microsoft Defender Exploit Guard.
A similar view can be found in Configuration Manager, within Endpoint Protection, within Endpoint Protection, Windows Defender Exploit Guard.
Please note that Microsoft brought together Intune and Configuration Manager under a unified platform that is called Microsoft Endpoint Manager.
For more information, please refer to Microsoft Endpoint Manager Overview. We also recommend you to have a look at a Ignite 2019 session, named “Endpoint security management with Microsoft Defender ATP and Microsoft Endpoint Manager”.
As of March 2020, Microsoft Endpoint Manager made available a new policy experience focused on Endpoint Security in public preview. From an ASR rules configuration perspective, there are no substantial changes, just make sure that you become acquainted with the new policy experience and configuration flows:
One last, but very important observation is that not all ASR rules are available in Configuration Manager and Intune.
You can leverage other configuration mechanisms, such as GPO, or features within Configuration Manager and Intune, such as Configuration Packages or PowerShell scripts, to enable rules that are not available in the default built-in list.
Here is the list of rules that are not available out-of-the-box in Configuration Manager and/or Intune:
|
Rule name |
GUID |
Not available in |
|
Block persistence through WMI event subscription |
e6db77e5-3df2-4cf1-b95a-636979351e5b |
Intune and SCCM |
|
Block process creations originating from PSExec and WMI commands |
d1e49aac-8f56-4280-b9ba-993a6d77406c |
SCCM |
|
Block Adobe Reader from creating child processes |
7674ba52-37eb-4a4f-a9a1-f0f9a1619a2c |
SCCM |
|
Block Office communication application from creating child processes |
26190899-1602-49e8-8b27-eb1d0a1ce869 |
SCCM |
#2 How do ASR rules exclusions work?
First, let’s start with the fact that for ASR rules — if you add one exclusion, it will affect every ASR rule! The reason for this is simple: performance and reliability. Therefore, be very cautious when adding exclusions, since they will affect all the mitigations that you have enabled.
Second, not all rules support exclusions. Since for some rules, it wouldn't make sense to allow exclusions, and for others it would be impractical to do so.
Right now, all but 2 specific rules do not support exclusions.
|
Rule name |
GUID |
File & folder exclusions |
|
Block JavaScript or VBScript from launching downloaded executable content |
D3E037E1-3EB8-44C8-A917-57927947596D |
Not supported |
|
Block persistence through WMI event subscription |
e6db77e5-3df2-4cf1-b95a-636979351e5b |
Not supported |
Please check the table here, for the latest updates and more detailed information on the ASR rules that support exclusions.
Third, ASR rules exclusions support wildcards, paths and environmental variables. However, keep in mind that ASR rules are collectively a system context component.
This means that ASR rules are not aware of user context, so it’s not possible to add user profile folders to exclusions using environmental variables. If you try to use an environment variable like %USERPROFILE% in an exclusion, the result will be “C:\Windows\System32”.
Important notes on ASR rules exclusions (including wildcards and env. variables):
#1 ASR rules exclusions are independent from Defender AV exclusions
#2 Wildcards cannot be used to define a drive letter
#3 If you want to exclude more than one folder, in a path, use multiple instances of \*\ to indicate multiple nested folders (e.g. c:\Folder\*\*\Test)
#4 Currently, Microsoft Endpoint Configuration Manager *does not* support wildcards (* or ?)
#5 If you want to exclude a file, that contains random characters (think automated file generation), you can use the ? symbol (e.g. C:\Folder\fileversion?.docx)
#6 ASR exclusions in Group Policy *do not* support quotes (the engine will natively handle long path, spaces, etc., so no need to use quotes)
#7 ASR rules run under NT AUTHORITY\SYSTEM account, so environmental variables are limited to machine variables.
As for wildcards, it’s important to understand how Microsoft Defender, overall, accepts and expects its usage. More information on how to use wildcards in ASR rules is available here.
Finally, Microsoft Defender ATP engineers made sure that OS components and several legitimate 3rd party apps play nice with ASR rules. So, several exclusions are already built in. However, we still advise customers to initially enable ASR rules in audit mode to determine any possible impact they might have on your organization.
#3 How do I know what I need to exclude?
One of the most important points to keep in mind when working with exclusions is that different ASR rules will have different protection flows.
Looking at all ASR rules events in the same way might trick you into excluding the wrong data point. Always take a step back and think about what the ASR rule you are configuring protects against, and how the actual execution flow pans out.
Here are a couple of examples of how to exclude processes or files in ASR rules.
Block credential stealing from Windows Local Security Authority
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.
The way that it works, whether in audit or block mode, is quite simple. Whenever a process tries to use the OpenProcess() function to access LSASS, with an access right of PROCESS_VM_READ, the rule will specifically block that access right (and only 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 subsequently allowed to access LSASS process memory. The value of 0 means that ASR rules will ignore this file/process and not block/audit it.
Please note that if a given process is audited or blocked by this specific ASR rule, it doesn’t necessarily mean that the process itself will crash or the application won’t work. Unfortunately, very often, developers will produce subpar code, which means that a given process might ask for PROCESS_VM_READ, when it doesn’t need it. If you want to further deep dive into this topic, we recommend you having a look at the “Interpreting Exploit Guard ASR audit alerts” blog post, from our friend Chris Jackson.
Block Office applications from creating child processes
The name of this rule says it all. The rule prevents applications such as Word or PowerPoint from launching child processes. Launching another process from an Office app is a common method used by cyber criminals to gain access to a command line or a PowerShell console and advance their attack.
Looking at the flow of this rule, it naturally makes sense to only exclude child processes that are attempting to be launched, rather than excluding WINWORD.EXE or POWERPOINT.EXE process altogether.
From the above screenshot, we can see that this ASR rule blocked WINWORD.EXE from launching another process, called cmd.exe.
Now, imagine that cmd.exe was a legitimate line-of-business app. The next step would be to add that filename along with its full path to the configuration mechanism of choice to exclude it from being blocked, and re-run the test to see if the exclusion successfully took effect.
Let us call the process we want to exclude test.exe for our next example. Simply adding test.exe (along with its full path name) into the exclusion policy will allow WINWORD.EXE to launch that application, as a child process. The value of 0 means that ASR rules will ignore this file/process and not block/audit it.
Please note that adding exclusions like cmd.exe or powershell.exe would completely compromise the security of your endpoints, since it would not block threats from leveraging Office Apps to run malicious macros, for example.
Always make sure to think twice about what you are excluding, so that you’re not diminishing your endpoint security.
That is it for our second blog post on demystifying ASR rules! We hope this is helpful and feel free to ask any questions. Stay tuned for the next one and make sure to check out all the blogs in this series here.
See you soon!
António Vasconcelos and Rob Mallicoat
Program Managers @ Microsoft Defender ATP Product Group