Configure All available ASR rules with Microsoft Intune
The purpose of this blog post is to inform you how to configure Attack Surface Reduction (ASR) via Intune. There are several options to configure ASR and some blog posts on how to configure ASR. I will explain the custom configuration and why I have chosen not to use the built-in option.
Extensive requirements: (Entire feature set of ASR rules)
Note. With a Windows E5 license, you get advanced management capabilities including monitoring, analytics, and workflows available in Defender for Endpoint, as well as reporting and configuration capabilities in the Microsoft 365 Defender portal.
What are Attack Surface Reduction rules?
Attack surfaces are all the places where your organization is vulnerable to cyber threats and attacks. An attacker could compromise your organization’s devices or networks. To minimize the risk that an attacker could compromise your device, you must implement security measures e.g., Attack Surface Reduction rules, Network protection, application control, etc. See Microsoft documentation for all the security measures.
So, Attack Surface Reduction rules are settings that make your device better protected against attacks and odd behavior. Attack Surface Reduction protects you e.g., against potentially obfuscated scripts or credentials stealing from Windows local security authority subsystem (LSASS).
There are several options available to configure the Attack Surface Reduction rules. Within Microsoft Intune, you have five options to configure ASR rules.
- Configuration Profiles – Endpoint protection
Endpoint protection configuration profile can be used to control the security of Windows devices. The category Microsoft Defender Exploit Guard contains an Attack Surface Reduction group and contains nearly all currently available ASR rules.
- Configuration Profiles – Custom configuration
A custom configuration profile can be used to configure settings that are available in Configuration Service Provider (CSP). CSP also includes all ASR rules. ASR rules and exclusions need to be set via custom OMA-URI’s.
- Endpoint Security – MDM Security Baseline
Security baselines are Microsoft-recommended configuration settings. These settings are based on feedback from Microsoft security engineering teams, product groups, partners, and customers. A security baseline includes a group of Microsoft Defender settings. The Security Baseline contains nearly all currently available ASR rules.
- Endpoint Security – Attack Surface Reduction rules
The Attack Surface Reduction rules profile can be used to configure the Attack Surface Reduction rules and contains nearly all currently available ASR rules.
- PowerShell script
PowerShell is a cross-platform task automation solution made up of a command-line shell, a scripting language, and a configuration management framework. We can use a PowerShell script to set all the available ASR rules.
PowerShell command for e.g., Block abuse of exploited vulnerable signed drivers:
Add-MpPreference -AttackSurfaceReductionRules_Ids 56a863a9-875e-4185-98a7-b882c64b5ce5 -AttackSurfaceReductionRules_Actions Enabled
Which option should I use?
Depending on the organization’s preferences, As you can see in the above paragraph there are several methods to deploy. I always advise keeping all the configurations together in one profile, so all ASR rules are in one configuration.
The easiest way is to configure ASR rules is the endpoint security Attack Surface Reduction rules profile and change all the ASR rules settings e.g., Security baseline to not configure. If you don’t change the settings to not configure you can get profile conflicts.
But the Attack Surface Reduction rules profile doesn’t cover all the ASR rules. You must set those rules on another method. What is very annoying for us is that you can’t put the missing rules only through an OMA-URI because then they will overrule each other. You must set the rule via a PowerShell Command, but the disadvantage of PowerShell command is that when it is set it will never go back to the default when you unassign the PowerShell script.
So based on that I decided to use Custom Configuration Profiles to set all the ASR rules via an OMA-URI. It is more difficult to set up and understand however with this method I can configure all the rules.
Attack Surface Reduction rules deployment phases
As with any new, wide-scale implementation which could potentially impact your line-of-business operations, it is important to be methodical in your planning and implementation. Because of the powerful capabilities of ASR rules in preventing malware, careful planning and deployment of these rules are necessary to ensure they work best for your unique customer workflows. To work in your environment, you need to plan, test, implement, and operationalize ASR rules carefully.
Custom Profile Attack Surface Reduction rules settings
Lucky for us are all the ASR rules already in the Configuration Service Provider (CSP), so we don’t have to ingest an ADMX file. Every ASR rule has a different GUID. All the GUIDs can be found here.
- Option 0 -> Disable and not configure the ASR rule
- Option 1 -> Enable ASR rule
- Option 2 -> Set ASR rule in audit mode
OMA-URI ASR rules:
|Name: *||ASR rules|
|Description:||All ASR rules enabled|
|Data Type: *||String|
OMA-URI ASR rules exclusions: (Use only when exclusions are required)
|Name: *||ASR rules exclusions|
|Data Type: *||String|
Note. Exclusions will affect every ASR rule. But not all ASR rules support exclusions. The following rules don’t support exclusions:
- Block persistence through WMI event subscription
How to configure the ASR rules
- Select Windows 10 and later as the platform
- Select Templates as the profile type and select Custom
- Click on Create
- Provide a policy name, e.g., ASR rules
- Set a description, so that everyone with access to the portal knows the purpose
- Click on Next and configure the custom Configuration profile
- Click on the Add button to add an OMA-URI
- Fill in OMA-URI data as described in the previous paragraph.
- Click on Next
- Enter a scope tag if needed and click on Next
- Assign the profile to a group and click on Next
- Set an applicability rule if needed and click on Next
- Check the configuration at the Review + Create page and click on Create
Test your Attack Surface Reduction rules
If you assigned the ASR rules to a user or device and are successfully applied on the Windows device. You can use the Event viewer to check what is applied.
The DeviceManagement-Enteprise-Diagnostics-Provide -> Admin log file can be used to check the applied configurations. The log includes the ASR rules configuration. A successful configuration will show as Event ID 814.
You can also get a detailed report with ASR rules events, blocks, and warnings if you have an E5 subscription and use Microsoft Defender for Endpoint.
For testing and validating the ASR rules, you can use Attack Surface Reduction – Microsoft Defender Testground. Besides the notification to the user, a log entry with ID 1121 will be created in the Windows Defender -> Operational log.