Implementing and monitoring Attack Surface Reduction rules (ASR)

Attack Surface Reduction rules have huge impact on endpoint security in a positive way. Last year I’ve implemented these rules in at least 10 environments with almost no impact for user experience. Based on these experiences I’ve made my personal recommendations, when it comes to Attack Surface Reduction. Disclaimer: personal recommendations 😉 .

Keep in mind that every environment is different and deploying security features like this can have impact! My recommendations are based on Modern Workspaces and not on-premises environments. Although they are almost the same this blog only shows how it’s done in a Modern Workspace environment.

Note: This blog only shows a few ASR rules. Currently there are much more ASR rules available. Most of them are save to deploy to your devices after a short audit period. Make sure to exclude things which need and can be excluded safely.

What are Attack Surface Reduction rules?

Attack Surface Reduction is a part of Windows Defender. Attack Surface Reduction prevents unwanted process executions or activities on your endpoints. ASR focusses on (malicious) behavior which is typical for malware. Microsoft describes it as follows:

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

Recommended ASR rules

Most of these ASR rules are covered in the “Defender for Endpoint Baseline” policy. I personally prefer splitting these kind of configurations into single policies. Makes filtering, assigning and excluding specific settings more flexible. Reminder, the ASR rules below are my personal recommendations! There are more ASR rules available. See the complete list of ASR rules here.

Note: There are more ASR rules available (which are not shown below), but are also recommended. It’s save to deploy all the available ASR rules if you configure them in audit mode.

• Block process creations from PSExec and WMI commands 

Microsoft: This rule blocks processes created through PsExec and WMI from running. Both PsExec and WMI can remotely execute code, so there is a risk of malware abusing this functionality for command and control purposes, or to spread an infection throughout an organization’s network.

[!WARNING] Only use this rule if you’re managing your devices with Intune or another MDM solution. This rule is incompatible with management through Microsoft Endpoint Configuration Manager because this rule blocks WMI commands the Configuration Manager client uses to function correctly.

• Block executable unless they meet a prevalence/age 

Microsoft: This rule blocks executable files, such as .exe, .dll, or .scr, from launching. Thus, launching untrusted or unknown executable files can be risky, as it might not be initially clear if the files are malicious.

[!IMPORTANT] You must enable cloud-delivered protection to use this rule.

The rule Block executable files from running unless they meet a prevalence, age, or trusted list criterion is owned by Microsoft and is not specified by admins. This rule uses cloud-delivered protection to update its trusted list regularly.

• Block Office applications from creating child processes

Microsoft: This rule blocks Office apps from creating child processes. Office apps include Word, Excel, PowerPoint, OneNote, and Access.

Creating malicious child processes is a common malware strategy. Malware that abuse Office as a vector often run VBA macros and exploit code to download and attempt to run more payloads. However, some legitimate line-of-business applications might also generate child processes for benign purposes; such as spawning a command prompt or using PowerShell to configure registry settings.

• Block Office apps from creating executable content

Microsoft: This rule prevents Office apps, including Word, Excel, and PowerPoint, from creating potentially malicious executable content, by blocking malicious code from being written to disk.

Malware that abuses Office as a vector might attempt to break out of Office and save malicious components to disk. These malicious components would survive a computer reboot and persist on the system. Therefore, this rule defends against a common persistence technique

• Block JS or VBS launching downloaded exec content

Microsoft: This rule prevents scripts from launching potentially malicious downloaded content. Malware written in JavaScript or VBScript often acts as a downloader to fetch and launch other malware from the Internet.

Although not common, line-of-business applications sometimes use scripts to download and launch installers.

• Use advanced protection against ransomware

Microsoft: This rule provides an extra layer of protection against ransomware. It uses both client and cloud heuristics to determine whether a file resembles ransomware. This rule does not block files that have one or more of the following characteristics:

The rule tends to err on the side of caution to prevent ransomware.

[!NOTE] You must enable cloud-delivered protection to use this rule.

Download and Import

The ASR rules i recommend can be downloaded from my Github repo here. These JSON files can be imported easily in your tenant with this great Powershell module by John Seerden.

• Download the ASR rules (JSON files) from my Github Repo. Store them in a temporary location (e.g. C:\ASR)

• Install the Powershell module and prerequisites

Install-Module -Name IntuneBackupAndRestore
Install-Module -Name Microsoft.Graph.Intune

• Connect to Microsoft Graph and Import the Powershell module

Connect-MSGraph
Import-Module IntuneBackupAndRestore

• Import the downloaded ASR (JSON) files

Invoke-IntuneRestoreDeviceManagementIntent -Path C:\ASR

After the import completed u will find the following ASR rules in Endpoint Manager under Endpoint Security -> Attack surface reduction. Keep in mind that the policies are configured in block mode. Probably you want to start in Audit mode unless you have a separate test device. Assign the policies to a device group and enjoy!

Ps. See how it affects your Secure Score and recommendations after being deployed to several devices 🙂

Endpoint logging investigation at the Endpoint

Endpoints logging can be found in either two ways. Tech guys probably prefer the endpoint itself. On the endpoint it self the event viewer is your tool to monitor. Navigate to Applications and Services Logs -> Microsoft -> Windows -> Windows Defender -> Operational. Filter for one of the following Event ID’s. This depends on how you configured the ASR rules. Or, select both like i did 🙂 .

Endpoint logging investigation at the Security Portal

The second option for logging is the Security Portal. Within the Security Portal you can find all reporting and diagnostics you’ll need. Access the logging via this link. Picture below shows recent ASR detections which gives an opportunity to monitor behavior remotely.

ASR rules Device overview.

Exclusions

There could be several reasons why u want to implement exclusions from these rules. Think of specific Office Add-ins? These could be blocked by ASR. Instead of disabling the ASR rule we should look into exclusions.

• Browse to Endpoint Manager
• Navigate to Endpoint Security -> Attack Surface Reduction
• Create a new policy
• Select Windows 10 and later as platform
• Select Attack Surface Reduction as profile type.

Give your configuration profile a name and description (optional)

Scroll down to the bottom of the page. Fill the available fields with your exclusions. In the picture below you can see some available variables en wildcards which can be used for exclusions. The complete list of variables and wildcards is available here.

Assign the policy to your device group and click Create.