Last Updated on May 17, 2022 by rudyooms

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 of Microsoft’s security products. Microsoft Defender is enabled out of the box when deploying Windows. Please Beware: Only relying on the basic/default configuration is not the 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 own “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 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. Afterward, 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 miss something?

When taking a good look at your existing Endpoint Security ASR Profile, you could notice that one rule is still missing in the Endpoint Security Profile. That missing ASR 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.”

Luckily Microsoft pushed down an update! With this update, you could configure this missing ASR rule in a new Endpoint Security ASR rule Profile

Another possibility would be to still use a CSP to push down that missing ASR Rule

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

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?

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)