Attack surface reduction

Often abbreviated to ASR, attack surface reduction rules are great ways to increase your security posture on Windows endpoints and servers. A typical rollout of ASR rules looks like this:

flowchart LR
    a[Implement an audit policy]
    ral[Review audit logs]
    mtb[Move items to block with no or few detections]
    ae[Add exclusions]

    a-->|Gather data|ral
    ral--->mtb
    ral--->ae
    ae--->|Repeat process|ral

We start with an audit policy auditing all items.
Let that data gather, typically 2 weeks at a minimum, a month is better, and the max the ASR report will store.
Review the audit logs, typically you will find 6 or so that can be moved to block immediately.
For rules with too many detections, add exclusions where necessary.
Repeat steps 2-4 until all rules are in block or not possible to block.

Note

This is a basic deployment guideline. There are some considerations that may impact how you choose to roll these out:

If you are finding ASR because you were compromised waiting to add blocks may not be ideal, instead you may want to consider implementing a rule in block and regularly reviewing detections for possible exclusions.
Warn is another option instead of block, it allows the user to let the process run but gives them a warning beforehand.
You may find the need for multiple policies targeting different device groups (Entra ID groups not MDE groups). For example, you may choose to use Warn for the Block executable files from running unless they meet a prevelance, age, or trusted list criteria rule on machines used by programmers or a Comp. Sci. Class to allow the development of applications.

The rules

Below you will find a list of all ASR rules and relevant information pertaining to them including:

Typical
- Microsoft has 3 ASR rules they consider "Standard", my "typical" designation is all the ASR rules that have been around for a while if you are deploying via Intune. The items not marked "typical" are in preview or are for servers.
GUID
- Typically only helpful when working with GPOs
Priority
- This is strictly my opinion. ASR rules can be deployed all at the same time. So consider this priority a mixture of ease of block implementation and how important the rule is. So...
  - High items are ones you will typically never have exclusions for and are clear threats
  - Medium items generally provide significant protection but often have exclusions that need to be considered
  - Low items tend to have exclusions you need to work through and don't provide as significant protection as some of the medium ones.
- Again this is personal opinion and these can all be audited and deployed together!
Notes
- This will link you to any special considerations or oddities for the rule noted later in the documentation.

Rule Name	GUID	Typical	Priority	Notes
Block abuse of exploited vulnerable signed drivers	56a863a9-875e-4185-98a7-b882c64b5ce5	True	High	Info
Block Adobe Reader from creating child processes	7674ba52-37eb-4a4f-a9a1-f0f9a1619a2c	True	Medium	Apps
Block all Office applications from creating child processes	d4f940ab-401b-4efc-aadc-ad5f3c50688a	True	Medium
Block credential stealing from the Windows local security authority subsystem (lsass.exe)	9e6c4e1f-7d60-472f-ba1a-a39ef669e4b2	True	Medium	Alternate mitigation and info
Block executable content from email client and webmail	be9ba2d9-53ea-4cdc-84e5-9b1eeee46550	True	High
Block executable files from running unless they meet a prevalence, age, or trusted list criterion	01443614-cd74-433a-b99e-2ecdc07bfc25	True	Medium	Requirement
Block execution of potentially obfuscated scripts	5beb7efe-fd9a-4556-801d-275e5ffc04cc	True	High	Requirement
Block JavaScript or VBScript from launching downloaded executable content	d3e037e1-3eb8-44c8-a917-57927947596d	True	Medium	Requirement
Block Office applications from creating executable content	3b576869-a4ec-4529-8536-b80a7769e899	True	Low
Block Office applications from injecting code into other processes	75668c1f-73b5-4cf0-bb93-3ecf5cb7cc84	True	Low	Issue
Block Office communication application from creating child processes	26190899-1602-49e8-8b27-eb1d0a1ce869	True	Low	Apps
Block persistence through WMI event subscription	e6db77e5-3df2-4cf1-b95a-636979351e5b	True	Medium	SCCM Issue
Block process creations originating from PSExec and WMI commands	d1e49aac-8f56-4280-b9ba-993a6d77406c	True	Medium	SCCM Issue
Block untrusted and unsigned processes that run from USB	b2b3f03d-6a65-4f7b-a9c7-1c7ef74a9ba4	True	High
Block Win32 API calls from Office macros	92e97fa1-2edf-4476-bdd6-9dd0b4dddc7b	True	Medium	Requirement
Use advanced protection against ransomware	c1db55ab-c21a-4637-bb3f-a12568109d35	True	High	Requirement
Block rebooting machine in Safe Mode (preview)	33ddedf1-c6e0-47cb-833e-de6133960387
Block use of copied or impersonated system tools (preview)	c0033c00-d16d-4114-a5a0-dc9b3a7d2ceb
Block Webshell creation for Servers	a8f5898e-1dc8-49a9-9878-85004b8a61e6			Issue
Block execution of files related to Remote Monitoring & Management tools

Deployment options

You can deploy ASR rules a few ways, I will cover the three main options and the pros and cons of them.

Intune

This is the ideal deployment scenario. You get access to most of the rules and greater flexibility.

Pros
- Can deploy rules for all items
- Can add exclusions per rule instead of for all rules
Cons
- If you aren't using Intune today you will need to onboard machines to Intune or deploy enforcement scoping
  - This could delay your deployment of auditing, consider deploying via SCCM or Group policy to get data gathered while you work on an Intune policy

SCCM

System Center Configuration Manager, sometimes called just Configuration Manager or SCCM is the second-best option.

Pros
- Larger organizations tend to have SCCM so it's a quick deployment to a collection to get started
- It's a GUI interface far superior to Group Policy
Cons
- It lacks many rules that have been added in recent years
- Exclusions are for all rules, not per-rule

Note

The ASR rule for Block process creations originating from PSExec and WMI commands is not applicable for devices running SCCM as SCCM relies heavily on PSExec and WMI. Setting this rule to block via another method will not apply to devices managed in SCCM and the report flags this rule as Not applicable on those devices.

Group policy

Group policy is an option, but it tends to be more of a way to start gathering data while you work on setting up Intune to manage your ASR rules.

Pros
- AD tends to be common in larger and older organizations, so it's readily available.
- Intune is superior to Group policy but Group Policy handles conflicts better than Intune as only one ASR policy from GPO's ever applies, where in Intune you theoretically can have many ASR policies applying different settings and creating conflicts.
Cons
- Very clunky interface for configuring audit rules, if you're an expert with Group Policy you will understand the reasoning for it, but it is tedious.
- Exclusions are difficult to add.

Conflicts

Above are the three common ways you might deploy ASR, some older environments might be deploying ASR via all of those methods, or maybe even via registry keys directly! So what happens when we have conflicting policies? There are actually many factors at play here and removing conflicts should be a top priority.

First, you can have conflicts between deployment options, of our three discussed deployment options the precedence looks like this:

Group Policy
Intune = SCCM

Group Policy should win out and Intune and SCCM should be on equal footing in theory.

Second, you can have conflicts within our deployment option. I am unfamiliar with how SCCM handles conflict but for Group Policy, the highest precedence GPO wins, there is no combining of ASR policy rules, only one policy ever applies.

For Intune this is more complex, lets look at an example below.

Rule	Policy 1	Policy 2	End result
Obfuscated scripts	Audit	Audit	Audited
Advanced ransomware protection	Block	Audit	Neither blocked or audited
Vulnerable driver	Block	Not configured	Blocked

Intune will attempt to make a "superset" policy which is a combination of all policies. Looking at the table above imagine you have two policies.

When both policies match, the shared setting is added to the "superset" policy
When the policies have different settings neither policy applies or gets added to our "superset" policy
If one policy has a setting configured and the other policy doesn't, the configured policy gets added to the "superset" policy

This is a very basic example and things can get more complicated.

Exclusions

Exclusions are key to getting your ASR rules into block mode without impacting your users. It is not uncommon to have some exclusions in some of your rules, always consider and evaluate any items before adding them as an exclusion.

There are two main ways to add exclusions, the obvious one is within the ASR policy itself, however you can also add exclusions using MDE indicators as well. These indicators can be based on the file hash or certificate and are much more secure than specifying a file name or file path. These indicators would also be an exclusion for all rules, not just select rules.

If using the ASR policy to add exclusions, it is best to specify a full path, Microsoft has given wildcards and environment variables to help with that.

Wildcard	Usage	Example
*	Match all file types or directories	`C:\Program Files\Office\.docx` `C:\Users\\Desktop\OrgApp_v2.1.exe`
?	Match any character, like a version number	`C:\Users\*\Desktop\OrgApp_v?.?.exe`
Environment Variable	Match a system environment variable	`%COMMONPROGRAMFILES%\App.exe`

Noted

YMMV, but you can find some system environment variable here.
For wildcards you can use a maximum of 6
You cannot wildcard a drive letter which can be problematic if looking at the Block untrusted and unsigned processes that run from USB, but consider using a file hash indicator instead.

Oddities

Microsoft has a full and thorough reference of descriptions and other useful items for all ASR rules. Notes I felt should be handy or not obvious are included below.

Block abuse of exploited vulnerable signed drivers

This only prevents new drivers from being added. Drivers that became vulnerable after having been installed are not impacted. This rule is still good for preventing a "bring your own driver" attack because it prevents a new known vulnerable driver from being installed and exploited.

Block Adobe Reader from creating child processes

Applies to Adobe Reader and Adobe Acrobat.

Block credential stealing from the Windows local security authority subsystem

Not required if you have LSA protection enabled on your endpoints, this will show as Not applicable in the ASR report.

Microsoft notes that you will find numerous detections for this rule simply from a process enumerating the LSASS service. They recommend moving it straight into block mode. Personally, I recommend trying to block this first and alone (no other ASR rules) with communication or waiting to move to block when you aren't making other changes so any side effects are easily spotted.

Block executable files from running unless they meet a prevalence, age, or trusted list criterion

Requires your Anti-virus policy has cloud protection enabled.

Block execution of potentially obfuscated scripts

Requires both cloud protection and script scanning be enabled in the Anti-virus policy.

Block JavaScript or VBScript from launching downloaded executable content

Requires your Anti-virus policy has script scanning enabled.

Block Office applications from injecting code into other processes

Microsoft maintains a list of known issues with software you can see on their reference page here.

Block Office communication application from creating child processes

Office communication applications include Outlook and Outlook.com. This rule breaks DLP policy tips.

Block persistence through WMI event subscription

You cannot use this rule if you have SCCM deployed as it relies heavily on WMI. If you do deploy the rule in a policy to a device managed by SCCM it should detect SCCM and mark the rule as Not applicable.

Block process creations originating from PSExec and WMI commands

You cannot use this rule if you have SCCM deployed as it relies heavily on these tools. If you do deploy the rule in a policy to a device managed by SCCM it should detect SCCM and mark the rule as Not applicable.

Block Win32 API calls from Office macros

Requires your Anti-virus policy has script scanning enabled.

Use advanced protection against ransomware

Requires your Anti-virus policy has cloud protection enabled.

Block Webshell creation for Servers

This is a server ASR policy, when deployed via Intune the entire policy will not apply to any non-server OS endpoints.