Microsoft Secure Tech Accelerator
Apr 03 2024, 07:00 AM - 11:00 AM (PDT)
Microsoft Tech Community
Demystifying attack surface reduction rules - Part 1
Published Apr 14 2020 10:54 AM 258K Views

Hey everyone! António and Rob here!

 

For the past few years, we’ve been working closely with many of our customers, assisting them in their journeys toward adopting the full Microsoft Defender ATP stack. Throughout these relationships, we’ve answered innumerable questions about Microsoft Defender ATP attack surface reduction (ASR) rules.

 

We’ve decided to compile all the major ones into a blog series and share it with the broader world.

In this multi-part series blog post, we’ll hopefully cover many, if not all, of your questions about ASR rules, and how to successfully adopt them in your organization.

 

Let's start with the Why and the What!

 

#1 What is the difference between ASR and ASR rules?

ASR and ASR rules are two different things. Attack surface reduction, or ASR, is an umbrella term for all the built-in and cloud-based security features Windows 10 offers that help to minimize the surface of attack, or areas of entry, for an attacker. It’s what you would call a HIPS (Host Intrusion Prevention System) solution, in industry lingo. In Microsoft Defender ATP, ASR includes the following:

  • Attack surface reduction rules
  • Hardware based isolation
  • Application control
  • Exploit protection
  • Network protection
  • Web protection
  • Controlled folder access
  • Network firewall

You can learn about all these capabilities in our documentation. You’ll see in this list that ASR rules are one of the features under the attack surface reduction umbrella.

 

#2 Why do I need ASR rules?

Attack surface reduction rules help close off many of the common entry points used by malware and ransomware, preventing attacks from ever reaching the point where AV and EDR solutions would detect them.

 

It’s not about trusting or not trusting certain kinds of activity; it’s about not allowing specific actions that we know to be commonly associated with malicious activity.

 

This of course does not mean you don’t need other endpoint solutions. The idea is to provide security and monitoring at each layer. Why give malware and exploits even an inch (or a centimeter) of your endpoints’ surface area before you let your corporate users in to start being productive.

 

A very good analogy is the liquids restrictions when entering a checkpoint at an airport. It’s not about whether the security personnel trust you or not. There is just the general, and mandatory, rule that no liquids above a certain volume are allowed. As you can understand, this minimizes the risk of, or even mitigates against, certain types of attacks.

 

In essence, ASR rules are here to help you reduce the attack surface of an endpoint by minimizing the places where your organization might be vulnerable to cyberthreats and attacks.

 

#3 Why were ASR rules created?

ASR rules were created so that enterprises can secure their endpoints along with protections that work alongside Microsoft Defender ATP, Microsoft Defender antivirus, and Endpoint Detection and Response (EDR), to provide a robust endpoint solution that gives security admins the control and visibility they need.

 

#4 What kinds of protection do they offer?

ASR rules offer a broad range of built-in rules to secure your endpoint, covering areas like Office applications (think macros, DDE’s, etc.) subversion or leverage, but also things like Webmail, script, WMI, LSASS, and much more.

 

#5 What are the specific requirements for enabling ASR rules?

Yes, the requirements are the following:

  • Computers running Windows 10, versions 1709 and later,  Windows Server version 1803 (Semi-Annual Channel or later) and Windows Server 2019
  • Windows 10 Pro/Enterprise/Education
  • Microsoft Defender antivirus must be active (cannot be in passive mode!)
  • Some rules require cloud-delivered protection to be enabled

Although ASR rules do not require an E5 license, with E5 you’ll gain enhanced optics and data insights, thanks to the power of the Microsoft Cloud.

 

For more information on the differences between E3 and E5 for ASR rules, please refer to Attack surface reduction features across Windows versions

 

In future parts of this blog, we will cover the different reporting mechanisms and you’ll be able to see the exact benefits of E5 for ASR rules.

 

#6 What are the available rules? And, are they available in all Windows versions?

As of now, we provide you a total of 15 rules. Spanning across multiple pillars of protection, like Office, Credentials, Scripts, E-Mail, etc.

 

All ASR rules, except for Block persistence through WMI event subscription, are supported on Windows 1709 and later.

 

ASR rules

E-mail and Webmail

Block executable content from email client and webmail

Microsoft Office

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 Win32 API calls from Office macros

Block Office communication application from creating child processes

Executables and Scripts

Block JavaScript or VBScript from launching downloaded executable content

Block execution of potentially obfuscated scripts

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

Use advanced protection against ransomware

3rd Party Apps

Block Adobe Reader from creating child processes

Windows Credentials

Block credential stealing from the Windows local security authority subsystem

Windows Management Interface (WMI)

Block process creations originating from PSExec and WMI commands

Block persistence through WMI event subscription (Requires Windows 10 version 1903)

Device Control

Block untrusted and unsigned processes that run from USB

 

 

#7 What rules to enable? All!? Or can I turn on individual rules?

No, you don’t need to enable all ASR rules. You can turn on rules individually to meet your needs.

To help you figure out what’s best for your environment, we highly recommended that you enable ASR rules in audit mode. With this approach, you’ll be able to determine the possible impact on your organization, e.g. your line-of-business applications.

 

Sadly, many line-of-business applications were written with limited security concerns, and they might perform tasks that resemble malware or malicious activity.

 

By monitoring audit data and adding exclusions for necessary applications, you can deploy ASR rules without impacting productivity.

 

To sum it up, Audit mode allows you to make a more informed decision, about which rules you will effectively enable. We’ll further explore this in the next future series of this blog.

 

#8 What are the rules Microsoft recommends enabling?

This is actually a tricky one… the answer is: it depends!

 

We created ASR rules leveraging data insights on the most common attacked areas and what areas we know can be commonly thwarted to compromise an organization.

 

With that said, you might have a follow-up question: why doesn’t Microsoft prevent that from happening from the very beginning?

 

Well, Office macros is a good example.

Do we love them? No! They are a security nightmare…

Do we need them? Yes!

 

We have millions of customers that still dearly depend on Office macros to run their businesses. It’s not a simple decision for an organization to enforce or determine that, starting tomorrow, all macros won’t be ever be able to, create a child process, for example. But what if you don’t allow macros at all in your environment (e.g. disable VBA and macros all together)? Then the ASR rules related to these scenarios probably will have very little meaning in your environment.

 

Hopefully you’ll now understand why the answer is, “it depends”.

 

Overall, we recommend enabling every possible rule. Nevertheless, there are some clear cut cases where you shouldn’t enable a rule. For example, we do not 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 reading each rule specific information and/or warnings, which are available in our public documentation.

 

Here’s the specific warning that is called out for the example given above:

 

ASR_Part1_Warning.png

 

 

OK! That’s a wrap for the first blog post in this series on attack surface reduction rules! Stay tuned for more in the coming weeks. If you want to come back and view all the blogs in this series, you can follow it here.

 

See you soon!

 

António Vasconcelos and Rob Mallicoat

Program Managers @ Microsoft Defender ATP Product Group

31 Comments
Microsoft

Congrats on getting the first part of this set of blogs posted @Antonio Vasconcelos !  

Thanks for such article. Always wondering after audit mode, why the Edge stealing credentials (detected by ASR)?

@Petr Vlk We will explain in further detail how to audit events in the upcoming blog post series. My guess is that it might be a plugin within MS Edge (former or Anaheim?) that is triggering the LSASS rule. We have something in the pipeline to provide more details for these kind of scenarios.

But I have to be honest that, personally, Edge never came up as an App showing in the logs, especially for the LSASS rule.

DM me with more details if you're willing to share a bit more info. Curious to understand what's happening.

Thanks for this series, I always promote ASR as one simple solution to standard attacks.

 

Details about detections send by DM. It is around the new one Edge. Chrome sometime behave the same. Personally suspect the Credential Manager imports or something like that.

 

Also, just small feedback. If you set only one ASR rule to block and all others to audit, the Security Center show statistics like "100% devices use ASR rules to block threats", but in reality it is not all of them.

Brass Contributor

thanks for the article.

Wil you provide the ASR rules to enable problem. Moreover I want to cross check on my laptop running. 

Also explain what is Hardware based isolation

Iron Contributor

Thanks for the article - very useful!!!

 

Looking forward to the rest of the series.

@Petr Vlk Thanks for the feedback! I'll have a look at the logs. And I'll see if we have a bug filled for that WDSC issue you reported.

 

@RAJUMATHEMATICSMSC We will cover how to enable, troubleshoot, create exceptions, etc. Stay tuned for the next blog series!

 

@PJR_CDF Thank you!!

Deleted
Not applicable

from the top of my head:

 

these GUIDs should be set to "audit":

26190899-1602-49E8-8B27-EB1D0A1CE869

"Block Office communication application from creating child processes" but clicking the URL in Outlook should launch the default browser


9E6C4E1F-7D60-472F-BA1A-A39EF669E4B2

"Block credential stealing from the Windows local security authority subsystem (lsass.exe)" but RDP client (mstsc.exe) stopped working after enabling this rule

 

d1e49aac-8f56-4280-b9ba-993a6d77406c

If enabled, blocks installation of new features using Roles & Features on Windows Servers - process WmiPrvSE.exe is blocked.

 

@Deleted Thanks for the feedback.

 

I could not repro any of those scenarios using Windows 1909 + Office 365 ProPlus and Windows Server 2019.

 

Please open a support case so our Support Engineers can have a look at it.

 

Thanks,

António.

Deleted
Not applicable

@Antonio Vasconcelos thanks, perhaps MS fixed these problems, I will gladly re-check it in our environment ;)

Due to current WFH rules, it might take some time, as we try to avoid any potentially breaking changes.

Copper Contributor

It's an interesting topic and one I have been working on just today although it's interesting to see that one of the rules does not appear in the intune gui to enable however it is possible to enable it through a mdm csp.

 

Is this just my tenant or is anyone else missing the following rule in the gui?

 

Block persistence through WMI event subscription

@Chris Snell It's not just your tenant. These differences will be documented in the next blog post (next week).

Iron Contributor

Hi @Antonio Vasconcelos  & @Rob Mallicoat ,

 

We are just at the process of Auditing/Validating the Endpoints to ensure the correct settings are being enabled "as advertised" and as part of that my Brother pointed out this great resource on Github that does a lot of the heavy lifting apart from the fact that it's for Build 1709:
https://github.com/cottinghamd/HardeningAuditor/blob/master/ASD1709HardeningComplianceCheck.ps1 


It clearly has some elements missing on ASR, so needs updating.

Running this in Powershell brings out *ALL* the ASR rules via Get-MpPreference :

  • $Preferences = Get-MpPreference; $Preferences.ExclusionPath
  • $Preferences = Get-MpPreference; $Preferences.ExclusionProcess
  • $Preferences = Get-MpPreference; $Preferences.AttackSurfaceReductionRules_Actions
  • $Preferences = Get-MpPreference; $Preferences.AttackSurfaceReductionRules_Ids

From this I was able to effectively report the following table to prove/validate the correct settings are in place, but it is very long winded process.

Question - how come we are stuck with GUID's, can't these be called something easy to recognize?

 

ASR_Rules.JPG

 

Please see this post from Monday for more context - https://techcommunity.microsoft.com/t5/windows-it-pro-blog/optimize-windows-monthly-update-deploymen...

Hi @David Caddick ! Thanks for the feedback!

 

Please note that we have a item in the pipeline for improving the GPO configuration and use a pre-built list of rules vs having to set the GUIDs.

As for scripts to help in the manual process of configuring and reporting on ASR rules, please check this out: https://github.com/anthonws/MDATP_PoSh_Scripts/blob/master/ASR/ASR_Analyzer_v2.1.ps1.

This script is going to be mentioned in part 3, which is going to be all about reporting and analyzing auditing ASR rules.

The script will be uploaded to the official MDATP GitHub repos soon.

 

Hth,

António.

Brass Contributor

Two weeks before I added possible ASR rules ID in group policy Editor. 

Adding is very.

Even though adding rules ID is also very easy in powershell, it does not any scripts only copy and paste is enough.

@RAJUMATHEMATICSMSC The above script is not about setting the rules, it's more about reporting via PowerShell. Which is a bit tricky to do, since we output GUIDs and 0, 1 and 2.

Iron Contributor

Hi @Antonio Vasconcelos & @Rob Mallicoat,

Running the Powershell script gives this output - and it appears to not be reporting ASR Exclusions for exe's and services:

Running script gives thisRunning script gives this

Note the lack of ASR Exclusions - and yet I get this result running these commands that is more accurate on what I am expecting:

PS C:\Users\w56179\Downloads> $Preferences = Get-MpPreference; $Preferences.ExclusionPath

%ProgramData%\Microsoft\Windows Defender

%ProgramFiles%\Manufacturer\Endpoint Agent\*.ead

%ProgramFiles%\Manufacturer\Endpoint Agent\temp

%ProgramFiles%\Windows Defender

%SystemRoot%\CCM\*.sdf

%SystemRoot%\CCM\Logs

%SystemRoot%\CCMCache

%SystemRoot%\CCMSetup

%SystemRoot%\Logs

 

PS C:\Users\w56179\Downloads> $Preferences = Get-MpPreference; $Preferences.ExclusionProcess

%ProgramFiles% (x86)\Zscaler\ZSAService\ZSAService.exe

%ProgramFiles% (x86)\Zscaler\ZSATray\ZSATray.exe

%ProgramFiles% (x86)\Zscaler\ZSATunnel\ZSATunnel.exe

%ProgramFiles%\Manufacturer\Endpoint Agent\brkrprcs64.exe

%ProgramFiles%\Manufacturer\Endpoint Agent\cui.exe

%ProgramFiles%\Manufacturer\Endpoint Agent\edpa.exe

%ProgramFiles%\Manufacturer\Endpoint Agent\prcs32.exe

%ProgramFiles%\Manufacturer\Endpoint Agent\wdp.exe

%SystemRoot%\CCM\CcmExec.exe

%SystemRoot%\CCM\CcmRepair.exe

%SystemRoot%\CCM\RemCtrl\CmRcService.exe

%SystemRoot%\CCMSetup\CcmSetup.exe

@David Caddick You're listing AV exclusions and not ASR rules Exclusions. They are different/independent!

"AttackSurfaceReductionOnlyExclusions" vs "ExclusionExtension/Path/Process".

Brass Contributor

I have already added ASR rules with enabled Acton after that I verified  via powershell. 

I Did via group policy Editor, its safe. 

Deleted
Not applicable

@Antonio Vasconcelos 

I was trying to open a JPEG attached to an email :(

2020-04-25 110110.png

 

rundll32.exe - I am still using Windows Photo Viewer (https://en.wikipedia.org/wiki/Windows_Photo_Viewer)

 

(Yes, I had to re-enable WPV first https://www.howtogeek.com/225844/how-to-make-windows-photo-viewer-your-default-image-viewer-on-windo... )

@Deleted FYI, I was not able to repro that scenario in Windows 1909 and Outlook version 2003.

 

Please submit this feedback via WDSI ASR - https://www.microsoft.com/en-us/wdsi/support/report-exploit-guard.

 

Hth,

António.

Deleted
Not applicable

@Antonio Vasconcelos 

 

I am running Microsoft Office 365 ProPlus with following ASR settings:

2020-04-28 084812.png

 

Microsoft

@Antonio Vasconcelos  I wanted to see how often those ASR rules get updated

 

Thank you

Iron Contributor

Hi @Deleted it looks like you have 15 Rules listed - I thought there was only 14?

Deleted
Not applicable

fresh error:

Adnotacja 2020-05-14 095540.png

Am I supposed to track events and make this exception? Or this is just a bug that will be fixed by MS?

 

In such situation I am thinking that perhaps I am the only guy on the planet really doing this ASR stuff ;)

Deleted
Not applicable

@David Caddick no, there are 15 rules:

 

"The following sections describe each of the 15 attack surface reduction rules" in https://docs.microsoft.com/en-us/windows/security/threat-protection/microsoft-defender-atp/attack-su...

 

and even on this page you can find:

"#6 What are the available rules? And, are they available in all Windows versions?

As of now, we provide you a total of 15 rules. Spanning across multiple pillars of protection, like Office, Credentials, Scripts, E-Mail, etc.

"

Deleted
Not applicable

@Antonio Vasconcelos 

do you have Credential Guard enabled?

 

lsass.exe is triggering "Block credential stealing from the Windows local security authority subsystem (lsass.exe)" rule??

Adnotacja 2020-05-14 101300.png

 

A wild guess: LsaIso.exe (Credential Guard) is reporting that lsass.exe is getting/"stealing" credentials? 

 

Disclaimer: we are using MS Security Baseline (https://techcommunity.microsoft.com/t5/microsoft-security-baselines/security-baseline-final-for-wind...) + ASR rules

Deleted
Not applicable

Outlook.exe trying to launch Teams.exe :(

 

Adnotacja 2020-05-14 105236.png

@Deleted 

 

Today ASR rules report in M365 SCC incorrectly shows LSASS.EXE has the culprit for triggering the alert.

If you use Advanced Hunting you'll be able to see what is the InitiatingProcess, that triggered the LSASS ASR rule.

 

As for Teams.exe, please test in block mode. If it's really blocked, please report in WDSI. What specific action where you doing? Opening a Teams meeting via a link in an e-mail?

 

Thanks!

Iron Contributor

Hi @Antonio Vasconcelos,

 

This is something that has been bugging me for a while:

Today ASR rules report in M365 SCC incorrectly shows LSASS.EXE has the culprit for triggering the alert.

If you use Advanced Hunting you'll be able to see what is the InitiatingProcess, that triggered the LSASS ASR rule.

I take it that this is going to be corrected at some point to point to the InitiatingProcess(s)?

Or is it a case of always using the Advanced Hunting facility to identify the process?

 

Regards,

Dave C

 

Brass Contributor

Can all 15 ASR rules be configured to the enabled state; on normal windows client computers by using group policy? If these ASR can be added then is it possible that these rules will be added to Windows Security for Home IT users  to better secure their computers.

Version history
Last update:
‎Apr 22 2020 02:38 AM
Updated by: