The Magnificent ASR Rules

The Magnificent ASR Rules

This blog is the third part of the Endpoint Security Series. It will be about the Attack Surface Reduction (ASR) Rules.

I will divide this blog into multiple parts

  1. ASR Explained
  2. Background Information about ASR
  3. Testing/Monitoring it
  4. How to deploy ASR rules on the go?
  5. Did I missed Something?
  6. Troubleshooting

1.ASR Explained

Microsoft Defender is one of the key pillars within Microsoft’s security products. Microsoft Defender is enabled out of the box when deploying Windows 10. But only relying on the basic/default configuration is not best practice.

As mentioned in my last blog, it’s very important to harden your Office apps.

A perfect addition is “Attack Surface Reduction” (ASR). ASR rules are somehow overlooked by many organizations. ASR can be configured by enabling the ASR rules in the device endpoint manager. By default, they’re not configured, so you’re not protected against more sophisticated attacks!!

One of the rules you definitely want to enable is the “block Office from creating child processes” rule… Do you want to know why? Take a look at CVE-2021-40444 . I guess you now know why it’s important.

These ASR rules can be configured by creating an endpoint protection device configuration or by creating a new attack surface reduction policy within the endpoint security settings.

Please take a look at all the rules you can configure. Each rule has its on “power”

If you want to know more about each rule, please visit this Microsoft page. They explain it very well

Use attack surface reduction rules to prevent malware infection | Microsoft Docs

2.Background information about ASR

I guess I need to point out some tips about ASR

-The ASR rules can be: on/not configured or audit mode (it’s best practice to make sure you audit first before you enable them)

-You can configure them with PowerShell: Set-MPPreference -AttackSurfaceReductionRules_Ids

Exclusions will affect every ASR rule. But not all ASR rules support exclusions. Two of them do not support exclusions:

-Only enable the ASR rule: “block process creations originating from PSExec and WMI commands” when you are using Intune or another MDM solution! Management through Microsoft Endpoint Configuration Manager (MECM) will stop functioning because this rule blocks WMI commands.

-Cloud delivered protection has to be enabled as a requirement for the rule: “Block executable files from running unless they meet a prevalence, age, or trusted list criterion”. Admins can’t specify anything with this rule, because it’s owned by Microsoft.

-A Windows 10 Pro/Enterprise/Education license is required

-ASR rules configured in Intune do support wildcard and environmental variables exclusions. Beware, ASR rules don’t support user context exclusions, as they’re running in system context. Also, it’s very nice that some exclusions are already built-in.

– Windows event log is the key when you want to wisely audit the ASR rules first.

-Check the registry when you deployed the ASR rules. Every GUID corresponds to an ASR rule.

3. Testing/Monitoring ASR

If you want to test your ASR deployment, you will need to visit this page to download some nice DOCX you can play with

https://demo.wd.microsoft.com/?ocid=cx-wddocs-testground

-Do you fancy reports as well? Go check out the ASR reports after you tested on the Microsoft playground. You will find it in the security.microsoft.com portal.

Regels voor het verminderen van kwetsbaarheid voor aanvallen – Microsoft 365-beveiliging

-And if you want to do some advanced hunting

Advanced hunting – Microsoft Defender for Endpoint (windows.com)

And Enter this query: DeviceEvents| where ActionType startswith ‘Asr’

4. How to deploy ASR rules on the go?

As mentioned at the beginning of this blog, you can do so by creating a new Endpoint Security configuration Profile

But why not doing it with PowerShell?

Take a look at my Github page… it will show you how to deploy your whole Intune Tenant with PowerShell

https://github.com/Call4cloud/Enrollment

It still needs a lot of work…. but I needed to start somewhere…

One of the settings which are deployed with this script is of course configuring the ASR rules.

The JSON file contains all ASR settings, you can modify these according to your business needs. Afterwards, just launch the PowerShell script to deploy the settings.

Open Intune device configurations to notice a new device configuration policy has just been created.

5. Did I missed something?

When taking a good look at the ASR rules, you will notice one rule is missing in the Endpoint Security settings. That one rule would be to “block abuse of exploited vulnerable signed drivers”. Let’s take a look at what Microsoft has to tell us what it does and how to configure it:

“This rule prevents an application from writing a vulnerable signed driver to disk. In-the-wild, vulnerable signed drivers can be exploited by local applications – that have sufficient privileges – to gain access to the kernel. Vulnerable signed drivers enable attackers to disable or circumvent security solutions, eventually leading to system compromise.”

But when you are not able to configure it in the Endpoint Security, how are we going to configure this nice ASR rule?

So we can configure a new custom made CSP with this settings:

OMA-URI: ./Vendor/MSFT/Policy/Config/Defender/AttackSurfaceReductionRules

Settings:56a863a9-875e-4185-98a7-b882c64b5ce5=1

  • 0 : Disable (Disable the ASR rule)
  • 1 : Block (Enable the ASR rule)
  • 2 : Audit (Evaluate how the ASR rule would impact your organization if enabled)

And the PowerShell Method

Add-MpPreference -AttackSurfaceReductionRules_Ids 56a863a9-875e-4185-98a7-b882c64b5ce5 -AttackSurfaceReductionRules_Actions Enabled

I find it very, very weird this ASR rule can’t be configured (or maybe not yet?) by configuring an Endpoint Security policy.

6. Troubleshooting

Deploying it and making it work is great but what are you going to do when all systems fail?

You will need to have a good understanding of how ASR works and where the events are logged.

I created a really good blog on how to determine if ASR is blocking even when the event log tells you nothing

Conclusion

Not setting the ASR rules when you have the proper licensing for it, could be a mistake… ASR rules are a very successful way to block more sophisticated attacks. But of course, ASR rules are just another barrier that can be bypassed. I’ll tell you more in my next blog…

Again I need to mention the “block abuse…” rule… It’s so weird we need an additional CSP to configure this?

Cardsharksabc GIFs - Get the best GIF on GIPHY

If you want to read more parts of the Endpoint Security Series:

*The second part about CFA (click here)

*The Fourth Part about WDAC (click here)

3 thoughts on “The Magnificent ASR Rules

  1. Pingback: The forgotten fruits of securing your Windows 10 Endpoint - Call4Cloud
  2. What about deploying ASR using Intune ATP security baseline? according to Microsoft baselines are the recommended configuration in terms of security posture, or am I missing something?
    The only thing that’s isn’t include within is WDATP tamper protection (which is wired).

    1. Hi

      Of course, that is a good option. But I prefer to work with standalone configurations. When enabling the atp baseline, options like hello/firewall/device installation/bitlocker are enabled by default. I have got 1 device configuration profile for BitLocker, 1 profile for hello etc. I find it easier to troubleshoot instead of 1 profile with all settings defined.

Leave a Reply

Your email address will not be published. Required fields are marked *

  +  22  =  25