Require Attack Surface Reduction Rules in your (Custom) Compliance Policy

Intune has great features, why don’t we combine them!? In this post I’ll show you how you can require specific ASR (Attack Surface Reduction Rules) for your devices by using a Custom Compliance policy.

The text below the first header is copied over from learn.microsoft.com. The fun part starts after the first two (2) headers. For those who know about Attack Surface Reduction and Custom Compliance policies can skip the first headers.

What are Attack Surface Reduction Rules?

Your organization’s attack surface includes all the places where an attacker could compromise your organization’s devices or networks. Reducing your attack surface means protecting your organization’s devices and network, which leaves attackers with fewer ways to perform attacks. Configuring attack surface reduction rules in Microsoft Defender for Endpoint can help!

Attack surface reduction rules target certain software behaviors, such as:

• Launching executable files and scripts that attempt to download or run files
• Running obfuscated or otherwise suspicious scripts
• Performing behaviors that apps don’t usually initiate during normal day-to-day work

Such software behaviors are sometimes seen in legitimate applications. However, these behaviors are often considered risky because they are commonly abused by attackers through malware. Attack surface reduction rules can constrain software-based risky behaviors and help keep your organization safe.

Source: Use attack surface reduction rules to prevent malware infection | Microsoft Learn

What is Custom Compliance?

Custom Compliance policies make it possible to require almost everything as a compliance requirement for your devices. In the past, I’ve blogged about requiring Dynamic Lock as a part of your compliance policy.

Custom compliance policies need a PowerShell script for a detection/query and a JSON file for reporting and/or to verify the setting. The JSON file is basically the required state and the PowerShell script output should match the JSON data.

When your detection (PowerShell) script and the required configured state in your verify (JSON) script match, your device will be marked as compliant. Otherwise the device is marked as not compliant. This can lead to not having access to data/apps based on Conditional Access policies.

Available ASR rules

Note: The number in front of the ASR rule is not an official number. I gave these ASR rules a number to match them in my actual PowerShell script and JSON file.

• #ASR1: Block abuse of exploited vulnerable signed drivers – 56a863a9-875e-4185-98a7-b882c64b5ce5
• #ASR2: Block Adobe Reader from creating child processes – 7674ba52-37eb-4a4f-a9a1-f0f9a1619a2c
• #ASR3: Block all Office applications from creating child processes – d4f940ab-401b-4efc-aadc-ad5f3c50688a
• #ASR4: Block credential stealing from the Windows local security authority subsystem (lsass.exe) – 9e6c4e1f-7d60-472f-ba1a-a39ef669e4b2
• #ASR5: Block executable content from email client and webmail – be9ba2d9-53ea-4cdc-84e5-9b1eeee46550
• #ASR6: Block executable files from running unless they meet a prevalence, age, or trusted list criterion – 01443614-cd74-433a-b99e-2ecdc07bfc25
• #ASR7: Block execution of potentially obfuscated scripts – 5beb7efe-fd9a-4556-801d-275e5ffc04cc
• #ASR8: Block JavaScript or VBScript from launching downloaded executable content – d3e037e1-3eb8-44c8-a917-57927947596d
• #ASR9: Block Office applications from creating executable content – 3b576869-a4ec-4529-8536-b80a7769e899
• #ASR10: Block Office applications from injecting code into other processes – 75668c1f-73b5-4cf0-bb93-3ecf5cb7cc84
• #ASR11: Block Office communication application from creating child processes – 26190899-1602-49e8-8b27-eb1d0a1ce869
• #ASR12: Block persistence through WMI event subscription – e6db77e5-3df2-4cf1-b95a-636979351e5b
• #ASR13: Block process creations originating from PSExec and WMI commands – d1e49aac-8f56-4280-b9ba-993a6d77406c
• #ASR14: Block untrusted and unsigned processes that run from USB – b2b3f03d-6a65-4f7b-a9c7-1c7ef74a9ba4
• #ASR15: Block Win32 API calls from Office macros – 92e97fa1-2edf-4476-bdd6-9dd0b4dddc7b
• #ASR16: Use advanced protection against ransomware – c1db55ab-c21a-4637-bb3f-a12568109d35

How do we implement this?

Don’t worry. The complete scripts (PowerShell and JSON) can be found here in my GitHub repo. The instructions below are useful to understand how these work. While implementing the scripts from my GitHub repo without modifying them will probably result in not compliant devices!

Determine the current ASR rules

First things first. We need to know what Attack Surface Reduction rules are deployed to our devices. We can’t built a custom compliance policy without knowing what we actually require.

Pick a fully enrolled device where your Attack Surface Reduction rules are deployed.

Determine the deployed rules by using the following PowerShell cmdlet as Admin: Get-MPPreference | Select-Object -ExpandProperty AttackSurfaceReductionRules_Ids

Write down the GUID’s shown in the output. Please match these with the numbers I gave them above and write them down.

Grab my PowerShell script

Grab the script in my GitHub repo here. There’s NO need to remove the code blocks that belong to a specific Attack Surface Reduction rule. Again, DO NOT remove or modify anything in this script.

Example code block:

#ASR1
$GetASR1 = Get-MPPreference | Select-Object -ExpandProperty AttackSurfaceReductionRules_Ids
$Value1 = "56a863a9-875e-4185-98a7-b882c64b5ce5"

If ($GetASR1 -contains $Value1){
$Value1 = "1"
} 
else
{
$Value1 = "0"
}

If a specific Attack Surface Reduction rule is configure it will report 1, if not it will report 0. This output is stored in the $Value1 parameter for #ASR1, $Value2 for #ASR2 and so on..

In the end. There’s an output which will be used for our JSON file. For example:

{"ASR7":"1","ASR12":"0","ASR13":"1","ASR16":"1","ASR5":"1","ASR8":"1","ASR11":"0","ASR1":"0","ASR4":"1","ASR10":"1","ASR15":"1","ASR2":"1","ASR9":"1","ASR3":"0","ASR6":"1","ASR14":"1"}

Grab my JSON script and modify it!

Grab the example script in my GitHub repo here. This JSON file must match the output shown above. There are two (2) ways of handling with the JSON file:

1. Remove all the ASR #x blocks which reported “0” in the output.
2. Add all code blocks (1 / 16). Make sure the Operand parameter matches the output per ASR rule.

Note: When you picked 2 as your desired method you should modify the Settingname, Operand, MoreInfoURL and Title parameters.

Example JSON block:

       { 
              "SettingName":"ASR2",
              "Operator":"IsEquals",
              "DataType":"Int64",
              "Operand":"1",
              "MoreInfoUrl":"https://joeyverlinden.com",
              "RemediationStrings":[{ 
                    "Language":"en_US",
                    "Title":"ASR Rule 2 missing",
                    "Description": "Our corporate compliance policy requires specific ASR rules on your device."
                   }]
            }

Add Custom Compliance script in Intune

• Open the Microsoft Intune portal and navigate to Endpoint security > Device compliance > Scripts
• On the Compliance policies | Scripts page,  click Add > Windows 10 and later
• On the Basics page, specify a Name and optionally a Description, Publisher and click Next

• On the Settings page, specify the following information and click Next. Note: Grab the script in my GitHub repo here.
• Run this script using the logged on credentials: No
• Enfore script signature check: No
• Run script in 64 bit PowerShell Host: Yes

Add JSON script in Intune

Create the JSON file which is being used for reporting (and to verify).

1. Open the Microsoft Intune portal navigate to Endpoint security > Device compliance
2. On the Compliance policies | Policies page, click Create Policy
3. select Windows 10 and later with Platform and click Create
4. On the Basics page, fill in a name for the device compliance policy and click Next
5. On the Compliance settings page, navigate to the Custom Compliance section, provide the following information and click Next

• Custom compliance: Select Require
• Select your discovery script: Select the just uploaded PowerShell script (policy)
• Upload and validate the JSON file with your custom compliance settings: Select the required JSON file

Admin experience

As an Administrator you want to verify that these settings are deployed properly. Devices report compliant if all the Attack Surface Reduction rules mark compliant.

On the device compliance blade, we see all individual Attack Surface Reduction rules reporting compliant. If there are several not compliant rules, there must be something wrong in your JSON file.