The Magnificent ASR Rules

This blog is the third part of the Endpoint Security Series. It will be about the Attack Surface Reduction In this third post of the series, let’s tackle Attack Surface Reduction (ASR) Rules. As a vital component of Microsoft Defender’s security suite, ASR adds a much-needed layer of protection to fend off advanced threats. But simply relying on Defender’s default setup won’t cut it—enabling and configuring ASR is essential.

1. Attack Surface Reduction (ASR) Explained

Microsoft Defender may be pre-installed and ready to go on Windows, but don’t let that lure you into complacency. As highlighted in my previous post on Office hardening, default configurations are far from enough. ASR provides that extra “oomph” to bolster your defenses—yet, surprisingly, it’s often overlooked by organizations.

By default, ASR rules aren’t active, so unless you enable them, your defenses won’t catch more sophisticated attacks. A prime example? The “block Office from creating child processes” rule. Need proof of its importance? Look no further than CVE-2021-40444—enough said. You can enable ASR rules by configuring them in the Endpoint Security settings or by creating a dedicated ASR policy.

Explore each rule’s specific capabilities; they can be a game-changer.

For in-depth details on ASR rules, visit this Microsoft page.

2. Background information about ASR

Here are some essential pointers to keep in mind with ASR:

• Configuration Modes: ASR rules can be set to ‘Enabled,’ ‘Not Configured,’ or ‘Audit mode.’ Always test with ‘Audit’ before full deployment.
• PowerShell for ASR: Use Set-MPPreference -AttackSurfaceReductionRules_Ids to configure ASR rules directly.
• Exclusions: While exclusions apply globally to ASR rules, not all support exclusions (e.g., “block process creations from PSExec and WMI commands”). Note: if you’re managing devices through MECM, this specific rule will interrupt WMI-based management.

• Cloud-Delivered Protection Requirement: The rule “Block executable files from running unless they meet a prevalence, age, or trusted list criterion” requires this setting.
• Supported Licenses: ASR requires Windows Pro, Enterprise, or Education.
• Intune Configurations: In Intune, ASR exclusions support wildcards and environmental variables but operate under the system context—user context exclusions aren’t supported.
• Event Logging: Always start with Windows Event Logs when auditing ASR rules.

• Registry Monitoring: Each ASR rule has a unique GUID in the registry; check here to verify rule deployment.(Software\microsoft\windows defender\windows defender exploit guard\ASR\rules

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 that 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

https://call4cloud.nl/2020/10/the-blind-event-log

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…

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)