Configure all available Attack Surface Reduction Rules via custom configuration profile with Microsoft Intune
The purpose of this blog post is to inform you how to configure Attack Surface Reduction Rules via custom configuration profile with Intune. Attack Surface Reduction is often abbreviated to ASR. There are several options to configure ASR and some blog posts on how to configure ASR. I will explain in this blog post the custom configuration option. If you want to know how to use the built-in option and configure it with Endpoint Security profiles, Check out this blog post
Basic requirements:
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).
Configuration possibilities
There are several options available to configure the Attack Surface Reduction rules. Within Microsoft Intune, you have five options to configure ASR rules.
- Attack Surface Reduction Rules via 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.
- Attack Surface Reduction Rules via custom configuration profile
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.
- Attack Surface Reduction Rules via 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.
- Attack Surface Reduction Rules via 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.
- Attack Surface Reduction Rules via 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 EnabledWhich 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 did not cover all the ASR rules but Microsoft updated the portal and now are able to configure all the ASR rules via Endpoint Security ASR profile.
So you had to set the 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 I prefer to set the Attack Surface Reduction Rules via custom configuration profile and the Endpoint Security ASR Profile. Before the update, I decided to use Custom Configuration Profiles to set all the ASR rules via an OMA-URI. but It is harder to set up and understand however with this method I was able to set all the rules. Nowadays I will use the Endpoint Security ASR Profile option.
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 |
| OMA-URI: * | ./Vendor/MSFT/Policy/Config/Defender/AttackSurfaceReductionRules |
| Data Type: * | String |
| Value: * | 75668c1f-73b5-4cf0-bb93-3ecf5cb7cc84=1|3b576869-a4ec-4529-8536-b80a7769e899=1|d4f940ab-401b-4efc-aadc-ad5f3c50688a=1|92e97fa1-2edf-4476-bdd6-9dd0b4dddc7b=1|5beb7efe-fd9a-4556-801d-275e5ffc04cc=1|d3e037e1-3eb8-44c8-a917-57927947596d=1|9e6c4e1f-7d60-472f-ba1a-a39ef669e4b2=1|d1e49aac-8f56-4280-b9ba-993a6d77406c=1|b2b3f03d-6a65-4f7b-a9c7-1c7ef74a9ba4=1|01443614-cd74-433a-b99e-2ecdc07bfc25=1|be9ba2d9-53ea-4cdc-84e5-9b1eeee46550=1|c1db55ab-c21a-4637-bb3f-a12568109d35=1|7674ba52-37eb-4a4f-a9a1-f0f9a1619a2c=1|26190899-1602-49e8-8b27-eb1d0a1ce869=1|e6db77e5-3df2-4cf1-b95a-636979351e5b=1|56a863a9-875e-4185-98a7-b882c64b5ce5=1 |
OMA-URI ASR rules exclusions: (Use only when exclusions are required)
| Name: * | ASR rules exclusions |
| Description: | Exclusions |
| OMA-URI: * | ./Vendor/MSFT/Policy/Config/Defender/AttackSurfaceReductionOnlyExclusions |
| Data Type: * | String |
| Value: * | C:Examplefolder1|C:Examplefolder2 |
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
- Block JavaScript or VBScript from launching downloaded executable content
How to configure the ASR rules via a custom configuration profile
- Open Microsoft endpoint manager
- In the menu select Devices
- Under Devices, select Windows and select configuration profiles
Or use the following link Windows – Microsoft Endpoint Manager admin center - Click on + Create Profile
- 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.
Hi! My name is René Laas. I have passion and enthusiasm for the Microsoft 365 Cloud. I am based in the Netherlands.
Rami Al-zayat 
Albert Stoynov
Andrea De Santis
Hi.
I created this CUSTOM asr policy but this is not working, error in all devices.
./Vendor/MSFT/Policy/Config/Defender/AttackSurfaceReductionRules
c1db55ab-c21a-4637-bb3f-a12568109d35=1|b2b3f03d-6a65-4f7b-a9c7-1c7ef74a9ba4=1
Any idea why?
Use advanced protection against ransomware
Block untrusted and unsigned processes that run from USB
I managed to work this out.
Here is the string to use if you want to set it to Audit mode. In this case I am setting “Block abuse of exploited vulnerable signed drivers”
./Vendor/MSFT/Policy/Config/Defender/RequireAdditionalSecurityProviders Data type: String Value:
Hi John,
The setting: “Block abuse of exploited vulnerable signed drivers” has the GUID: 56a863a9-875e-4185-98a7-b882c64b5ce5.
This can also be set via the ./Vendor/MSFT/Policy/Config/Defender/AttackSurfaceReductionRules OMA-URI. But you need to set
75668c1f-73b5-4cf0-bb93-3ecf5cb7cc84=1|3b576869-a4ec-4529-8536-b80a7769e899=1|d4f940ab-401b-4efc-aadc-ad5f3c50688a=1|92e97fa1-2edf-4476-bdd6-9dd0b4dddc7b=1|5beb7efe-fd9a-4556-801d-275e5ffc04cc=1|d3e037e1-3eb8-44c8-a917-57927947596d=1|9e6c4e1f-7d60-472f-ba1a-a39ef669e4b2=1|d1e49aac-8f56-4280-b9ba-993a6d77406c=1|b2b3f03d-6a65-4f7b-a9c7-1c7ef74a9ba4=1|01443614-cd74-433a-b99e-2ecdc07bfc25=1|be9ba2d9-53ea-4cdc-84e5-9b1eeee46550=1|c1db55ab-c21a-4637-bb3f-a12568109d35=1|7674ba52-37eb-4a4f-a9a1-f0f9a1619a2c=1|26190899-1602-49e8-8b27-eb1d0a1ce869=1|e6db77e5-3df2-4cf1-b95a-636979351e5b=1|56a863a9-875e-4185-98a7-b882c64b5ce5=2
All ASR rules must be set in 1 Custom profile. No other ASR rules configuration locations like security baselines should be set otherwise the config will ping pong. This will result in not the best defense.
But now all ASR rules can also be configured via the GUI with the ASR Rules profile. I prefer to use that profile. Other people can understand what has been set without translating the ASR rules GUID.
Kind regards,
René Laas
Hi Rene,
Thank you for this information, it’s really informative. One thing I am not sure of and that is where I set the options below for these custom rules?
Option 0 -> Disable and not configure the ASR rule
Option 1 -> Enable ASR rule
Option 2 -> Set ASR rule in audit mode
I can see where to do this for the listed ASR Rules but not for custom rules.
Kind regards
John