Demystifying attack surface reduction rules - Part 2

Published Apr 22 2020 08:47 AM 12.1K Views

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:


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


Not available in

Block persistence through WMI event subscription


Intune and SCCM

Block process creations originating from PSExec and WMI commands



Block Adobe Reader from creating child processes



Block Office communication application from creating child processes





#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


File & folder exclusions

Block JavaScript or VBScript from launching downloaded executable content


Not supported

Block persistence through WMI event subscription


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

Frequent Contributor

Hi @Antonio Vasconcelos, @Rob Mallicoat ,



It is not in anyone's best interest to have rules enabled in Audit mode for very long - so what we are trying to achieve is get a good set of base rules that are somewhat typical in most organizations so that these ASR and Exploit Guard rules can be added from day one to speed up the maturity/adoption/security of the solution. The way we are looking at this is twofold:

  1. Get a list of typical exclusions that can be added to ASR/ExploitGuard and add them as we enable Audit mode   
  2. Identify outliers that are typically not encountered within the first week and simply change from Audit to Enabled
  3. By this method we are effectively starting to improve from both ends of the extreme and working thru the rules to get to an adequate hardened position in a responsible manner ASAP

Just checking on some aspects of the ASR Rules?

GUID's for Rules:

The GUID’s used are just for the rule base on the client - it seems that the GUID string to reference the rules from inside Intune are different, I noticed this after creating a security baseline for Win 10 MDATP and then exporting it from Intune and realised that none of the GUID’s appear to have any match - is this due to the differences between client and Intune?


I was hoping to create a preferred benign “audit” starting point for customers, and then progressively work up more secure baselines that would act as templates for customers, now I am doubting how this might be achieved?


Strange Logs? from ExploitGuard:

Also noted that there is some curious anomalies where we are seeing a series of 7 tasks based on powershell but creating logging into “C:\ProgramData\Microsoft\Windows Defender Advanced Threat Protection\DataCollection\5999.4564940.0.4521659\fd772071-9b1d-4ce0-b9ec-96334db59905.ps1”  and this seems to represent 10% of the 10,000 logs exported via the MDATP Console - but it did very much look like some efforts of the MDATP client behavior?

The reason for highlighting this is I can see evidence of the exact same behavior in two tenants.

Question: Is this normal behaviour for the MDATP Client - if so, why do we need to now create an ASR Rule to reduce the noise?

Surely this is something that should baked into the installation by default? I am making an assumption that this is benign and can be safely ignored?


Full listing of command line entry:

powershell.exe -ExecutionPolicy Bypass -NoProfile -NonInteractive -Command "& {$OutputEncoding = [Console]::OutputEncoding =[System.Text.Encoding]::UTF8;$scriptFileStream = [System.IO.File]::Open('C:\ProgramData\Microsoft\Windows Defender Advanced Threat Protection\DataCollection\5999.4564940.0.4521659\fd772071-9b1d-4ce0-b9ec-96334db59905.ps1', [System.IO.FileMode]::Open, [System.IO.FileAccess]::Read, [System.IO.FileAccess]::Read);$calculatedHash = Get-FileHash 'C:\ProgramData\Microsoft\Windows Defender Advanced Threat Protection\DataCollection\5999.4564940.0.4521659\fd772071-9b1d-4ce0-b9ec-96334db59905.ps1' -Algorithm SHA256;if (!($calculatedHash.Hash -eq '258a27019b0ed2b15c067fe83a56c6a24738d678e9bcd0ccc159a033d2d7c898')) { exit 323;}; . 'C:\ProgramData\Microsoft\Windows Defender Advanced Threat Protection\DataCollection\5999.4564940.0.4521659\fd772071-9b1d-4ce0-b9ec-96334db59905.ps1' }"

Hope this makes sense, regards,

Dave C

@David Caddick 


#1 Please use this as a reference for using Graph API to configure ASR settings

#2 You can export the object (template that you create) and import it into another tenant (using the Graph API or an off the shelve utility to do so)

#3 ASR rules ID's are valid only for Defender AV. Intune has ID's for it's own objects. As long as the CSP gets the correct setting, it honestly doesn't matter which ID's Intune uses for it's URIs.

#4 The PowerShell FP is a know issue and it's being fixed.


As for you strategy on exclusions. All looks good. Just one extra tidbit. Don't try to apply 1 golden policy to 100% of an organization. Exceptions and edge cases will appear, and it's much simpler to have those in a separate policy item, then just trying to adapt 1 single policy for every possible scenario (exclusion, app compact, etc.).




Frequent Contributor

Thanks @Antonio Vasconcelos 


Just clarifying some feedback on Item #1


For creating the Security Baseline profile in Intune - this looks simple enough via:

But once I review the settings under Microsoft Defender it is easy to see how this can be changed to either Audit mode or Block but what I wasn't seeing is how to add the ASR Exclusion rules once they have been identified by running in Audit mode? (here there are only 10 rules)

I then went back and reread the instructions at - and realised that I needed to create a new "Endpoint Protection" profile under Device Configuration profiles (here are the full 15 rules) 


So please be aware that it looks like the ASR Rules are surfacing in two locations in Intune - and it's under the Security Baseline where it appears to be incomplete where there is no place to submit the Exclusion Files/Paths? It might be that this area is still a "Work in Progress" but the Security Baseline would appear to be a more natural home for these settings perhaps?


@David Caddick Hey!


#1 Security Baselines are just that. They should serve as a foundation for other policies/settings to be applied.

#2 Security Baselines won't sport every existing settings for a given category, including ASR rules.

#3 As with any other Security Baseline that we've released in the past (e.g. GPO), they won't provide recommendations on exclusions or custom settings. These should be part of what the Customer defines on top of the baselines.

#4 Use the Endpoint Protection ASR rules object (Preview) or create a custom policy that can be re-used wherever needed.




Regular Visitor

Hi @Antonio Vasconcelos 

Thanks for the great work!


Would this mean, that we don't need to disable all the macros in the Office Trust Center anymore, if we put all the ASR Rules in place?


Best regards



Hi all, can anyone explain why I am seeing ASR alerts in MDATP console for just about all our machines but only have rules in place on a couple of test machines?




It doesnt seem right?

Version history
Last update:
‎May 05 2020 11:34 AM
Updated by: