If it is your job to manage and secure Windows endpoints and you aren’t aware of ASR rules, you need to start moving towards learning what they are, then getting them all configured in block mode*. ASR rules are an extra layer of preventative defense that you should be using alongside your Antivirus/EDR solution.
This post will not go into excruciating detail about what an ASR rule is, but how you might work to get them configured across the environments you manage.
*with the necessary considerations and exclusions. Blocking every rule might not suit your workflows.
“I don’t know what an Attack Surface Reduction rule is”
https://learn.microsoft.com/en-us/defender-endpoint/attack-surface-reduction
“I need to see an example”
Suppose you download a malicious PDF attachment via an email you received. It is perfectly plausible that the file you downloaded contains something that went undetected by your antivirus’s traditional detection methods (for example, the malware contains something that is not yet recorded in signature databases), and bypassed all the other bits, because it’s either: really sophisticated, or you haven’t configured your security settings properly (the latter is most often the cause).
You open the PDF, click on an element, which spawns a new process to install unwanted remote access software. Bad news all around right?
What the ASR rule “Block Adobe Reader from creating child processes” is designed to do, is stop the behaviour of that action entirely. I think this is pretty cool.
There’s loads of these rules configured to do all sorts of blocky protective stuff which you can see here – https://learn.microsoft.com/en-us/defender-endpoint/attack-surface-reduction-rules-reference#asr-rule-to-guid-matrix
Getting Started with Attack Surface Reduction Rules
Our first milestone is to deploy all applicable rules in audit mode – if your devices are onboarded to Defender, you can view the audit information from the Microsoft Security portal under Reports –> Attack Surface Reduction
ASR rules do NOT require Defender as the primary AV, although it is an easy assumption to make (as I once did). You can enable ASR rules on any Windows device via GPO/Intune/RMM/PowerShell or by having the apprentice go around to each and every machine to set with GP Edit.
Which rules to apply?
At the time of writing, here are the rules which are not in preview:
- Block abuse of exploited vulnerable signed drivers
- Block Adobe Reader from creating child processes
- Block all Office applications from creating child processes
- Block credential stealing from the Windows local security authority subsystem (lsass.exe)
- Block executable content from email client and webmail
- Block executable files from running unless they meet a prevalence, age, or trusted list criterion
- Block execution of potentially obfuscated scripts
- Block JavaScript or VBScript from launching downloaded executable content
- Block Office applications from creating executable content
- Block Office applications from injecting code into other processes
- Block Office communication application from creating child processes
- Block persistence through WMI event subscription
- Block process creations originating from PSExec and WMI commands
- Block untrusted and unsigned processes that run from USB
- Block Webshell creation for Servers
- Block Win32 API calls from Office macros
- Use advanced protection against ransomware
Deploying in Audit Mode
Generally speaking, the Microsoft Learn doc has info on this, but some of it is outdated – https://learn.microsoft.com/en-us/defender-endpoint/enable-attack-surface-reduction#configuration-methods
Intune
This is by far the easiest method AND supports per-rule exclusions:
Go to Endpoint Security –> Attack Surface Reduction –> Create Policy –> Platform: Windows 10, Windows 11 and Windows Server, Profile: Attack Surface Reduction Rules
Set all desired rules to Audit Mode in this single policy:
Deploy to all devices.
Group Policy
MS Docs still good for this.
PowerShell
If you have devices not centrally managed by Intune or joined to Active Directory, then you hopefully have access to something that can push a single cmdlet to all devices. For the rules I’ve listed above, that command is:
Set-MpPreference -AttackSurfaceReductionRules_Ids 56a863a9-875e-4185-98a7-b882c64b5ce5,7674ba52-37eb-4a4f-a9a1-f0f9a1619a2c,d4f940ab-401b-4efc-aadc-ad5f3c50688a,9e6c4e1f-7d60-472f-ba1a-a39ef669e4b2 ,be9ba2d9-53ea-4cdc-84e5-9b1eeee46550,01443614-cd74-433a-b99e-2ecdc07bfc25,5beb7efe-fd9a-4556-801d-275e5ffc04cc,d3e037e1-3eb8-44c8-a917-57927947596d,3b576869-a4ec-4529-8536-b80a7769e899,75668c1f-73b5-4cf0-bb93-3ecf5cb7cc84,26190899-1602-49e8-8b27-eb1d0a1ce869,e6db77e5-3df2-4cf1-b95a-636979351e5b,d1e49aac-8f56-4280-b9ba-993a6d77406c,b2b3f03d-6a65-4f7b-a9c7-1c7ef74a9ba4,a8f5898e-1dc8-49a9-9878-85004b8a61e6,92e97fa1-2edf-4476-bdd6-9dd0b4dddc7b,c1db55ab-c21a-4637-bb3f-a12568109d35 -AttackSurfaceReductionRules_Actions AuditMode,AuditMode,AuditMode,AuditMode,AuditMode,AuditMode,AuditMode,AuditMode,AuditMode,AuditMode,AuditMode,AuditMode,AuditMode,AuditMode,AuditMode,AuditMode,AuditMode
This follows the format listed on docs:
Add-MpPreference -AttackSurfaceReductionRules_Ids <rule ID> -AttackSurfaceReductionRules_Actions AuditModeReviewing the Reports
Okay so I have all this data, what do I do with it?
The aim here is to introduce as few exclusions as possible, in the spirit of minimising the attack surface of a device. What this allows, is your end-users to work without noticing you’ve hugeley increased the security of their device.
The most frequent exclusions I apply to ASR rules are to allow critical business Office add-ins to function on rule Block all Office applications from creating child processes.
Applying the Exclusions
Finding the path (to enlightenment)
You might know the full path of the app which is being blocked, but if you don’t, you can get them from the from the ASR report view :
- Add Exclusions
- Get Selected exclusion paths
- Grab from the dowloaded CSV
- Copy/modify path into your selected exclusion method
Intune
Intune supports per-rule exclusions, so in theory you can simply create a second ASR rule profile in Intune, and have all your rule properties configured in a single place (assuming the device scope is the same for everyone).
In my example, I need an add-on for Office to be excluded, and the install path is in AppData:
I am using the wildcard (*) to specify that the username could be unique on each machine, while giving the rest of the expected path – Learn more about how to set exclusion paths.
Once this is set, I can set the rule to Block mode.
Group Policy
You cannot create per-rule exclusions with Group Policy, however for management reasons, it is my recommendation that you create a GPO for each ASR rule*, where you configure the settings named:
- Configure Attack Surface Reduction Rules
- Exclude files and paths from Attack Surface Reduction rules
*this will save time later when you move these configurations to Intune.
Configuration
To replicate what I demonstrated in my Intune example, I made a new policy and have configured as shown:
Firstly, the new GPO:
Now I find the policy:
Set the ASR rule “Block Office applications from creating executable content” using the GUID from the ASR reference, and the action to take… (Value ‘1’ is block):
Then I configure the Exclusions:
‘Value name’ is the path, ‘Value’ is 0 as specified in the help box:
Repeat this for all rules as required.
Be aware that all rules will have the same exclusions.
PowerShell
Just like Group Policy, it is not possible to set per-rule exclusions using PowerShell, you are limited to a single cmdlet:
Add-MpPreference -AttackSurfaceReductionOnlyExclusions "<fully qualified path or resource>"Once your exclusions are set, you can update your ASR rules to block mode using:
Set-MpPreference -AttackSurfaceReductionRules_Ids 56a863a9-875e-4185-98a7-b882c64b5ce5,7674ba52-37eb-4a4f-a9a1-f0f9a1619a2c,d4f940ab-401b-4efc-aadc-ad5f3c50688a,9e6c4e1f-7d60-472f-ba1a-a39ef669e4b2 ,be9ba2d9-53ea-4cdc-84e5-9b1eeee46550,01443614-cd74-433a-b99e-2ecdc07bfc25,5beb7efe-fd9a-4556-801d-275e5ffc04cc,d3e037e1-3eb8-44c8-a917-57927947596d,3b576869-a4ec-4529-8536-b80a7769e899,75668c1f-73b5-4cf0-bb93-3ecf5cb7cc84,26190899-1602-49e8-8b27-eb1d0a1ce869,e6db77e5-3df2-4cf1-b95a-636979351e5b,d1e49aac-8f56-4280-b9ba-993a6d77406c,b2b3f03d-6a65-4f7b-a9c7-1c7ef74a9ba4,a8f5898e-1dc8-49a9-9878-85004b8a61e6,92e97fa1-2edf-4476-bdd6-9dd0b4dddc7b,c1db55ab-c21a-4637-bb3f-a12568109d35 -AttackSurfaceReductionRules_Actions Enabled,Enabled,Enabled,Enabled,Enabled,Enabled,Enabled,Enabled,Enabled,Enabled,Enabled,Enabled,Enabled,Enabled,Enabled,Enabled,EnabledSecurity Considerations
It is not ideal to set blanket-wide exclusions for all ASR rules when the intention is to allow a very specific activity on a single rule, however, it is worse to not have the ASR rules configured at all.
Make a start with ASR rules, they could be the thing that prevent a breach.
This post is intended to raise awareness and spark curiosity about potenentially underutilised security settings at your disposal. Be sensible, read the Microsoft documentation, and consider the risks of tinkering with such controls.