Inspecting Microsoft Defender Attack Surface Reduction Rules

What I will be covering in this article 👇🏽

1. Not a How, but more of a Why
2. Proactive Prevention Vs. Reactive Detection
3. The Ever-Expanding Attack Surface
4. Why Does Attack Surface Management Matter? – Painting the Picture With An Example
5. A Good Rollout Roadmap
6. Policy Exceptions – Experience From the Field
7. Planning the Deployment
8. Let’s Categorize the Rules
9. Understanding the ASR Rule Modes
10. If You are Moving From a Different EDR/ XDR Solution
11. Understanding the ASR Rules Dependencies
12. Audit Mode and Coming Out of Audit Mode
13. What rules to Enable First?
14. Once the Rules Are In Operation
15. Using Advanced Threat Hunting
16. Wrapping Up

Not a How, but more of a Why

I want to make sure this is not an article where you come to check the steps to configure settings but to answer some questions related to the overall Security Posture of your endpoints. Why do you need to understand the risks in the growing attack surface, and what could you do to minimize them with the technology that you may already have in place?

Proactive Prevention Vs. Reactive Detection

Attack Surface Reduction rules fall into the Proactive Prevention category because simply the rules block the attack vectors right off the bat. The rules are the sections of an endpoint that attackers are most likely to exploit and that can’t wait as it can be too late and these components prevent malware execution, phishing, and exploit attempts before they succeed.

The Ever-Expanding Attack Surface

Attack Surface Reduction is a huge topic in the cybersecurity industry, and it’s always recommended to have some sort of protection as the Attack Surface keeps on growing. The tactic you used today will not be the same tomorrow or maybe not enough as more and more appliances are being introduced and new tools, applications, and systems are accessing your network and running on platforms. If you are using an EDR or XDR solution today, you will see some if not many Attack Surface Reduction Rules, and the chances are you may have already configured them. In this article, I want to break down the Defender Attack Surface Rules (ASR rules) and show you what components each rule takes care of and overall, how they can minimize the attack surface.

And you will notice from time to time there are new rules being introduced into the rule set as a proactive step to fight against advisories.

Why Does Attack Surface Management Matter? – Painting the Picture With An Example

Take a typical scenario where you may have to dial down a security control because of an application limitation or until the vendor supports the recommended security control in their app. I have seen sometimes legacy apps that do not support exporting new versions of M365 App file formats (.docx, .xlsx, etc.) and still rely on older versions which can pose potential threats from malicious macros, VB scripts, etc. All the potential ways an advisory can come in. If the methods of stopping older versions of Office apps can’t be implemented, it need to be properly documented and should get confirmed by the vendors to make sure security controls are relaxed only to the relevant user group.

But that’s not enough. Relaxing the control will potentially expand your attack surface even for one user, and this needs to be managed ASAP. Incoming the ASR rules. The correct rule must be turned on to combat any macro-related attacks. They should be audited and ideally, you should be able to perform Threat Hunting activities to understand the gravity of an exploitation situation.

A Good Rollout Roadmap

I believe the below roadmap provided by Microsoft is a good reference material to map out your ASR rules rollout journey. It can be a version of this but always refer to this as a best practice.

Every section has its own set of activities that need to be carried out. Communication with the right stakeholders is the key.

Policy Exceptions – Experience From the Field

Exceptions are not really the exclusions. Creating forked (alternate policies from the main policy) policies from the main policy with exceptions is acceptable make sure you avoid enabling the policies to a subset of devices until you figure out how to sort out the impact you noticed during the Auditing period which you know can kill the user productivity.

However, measurements should be taken to add them to the main Block mode policy ASAP. This can include the uplift of a system that does not comply with the latest Security controls to making sure the macros used in Excel is secure enough that they do not make Win32 API calls.

Planning the Deployment

Planning to test and enable the rules plays a big part as these are not recommended to enable willy-nilly. Only because the rules can have effects on the applications and processes. Microsoft has recommended the below pathway during the planning.

If I go along with the Microsoft documentation, it has mentioned how to select the business unit to roll out the ASR rules.

• Size of business unit
• Availability of attack surface reduction rules champions
• Distribution and usage of:
  • Software
  • Shared folders
  • Use of scripts
  • Office macros
  • Other entities affected by attack surface reduction rules

🔗More info can be found here

Let’s Categorize the Rules

This will give you more context into the rules as the rules fall into some sort of a section in endpoint management. The below categorization will give you some idea of what problems it will try to solve.

Polymorphic threats	Lateral movement and credential theft	Productivity apps rules	Email rules	Script rules	Misc rules
Block executable files from running unless they meet a prevalence, age, or trusted list criterion	Block process creations originating from PSExec and WMI commands	Block Office applications from creating executable content	Block executable content from email client and webmail	Block JavaScript or VBScript from launching downloaded executable content	Block abuse of exploited vulnerable signed drivers
Block untrusted and unsigned processes that run from USB	Block credential stealing from the Windows local security authority subsystem (lsass.exe)	Block Adobe Reader from creating child processes	Block Office communication application from creating child processes	Block execution of potentially obfuscated scripts	Block use of copied or impersonated system tools (preview)
Use advanced protection against ransomware	Block persistence through WMI event subscription	Block all Office applications from creating child processes			Block rebooting machine in Safe Mode (preview)
		Block Office applications from injecting code into other processes			Block Webshell creation for Servers
		Block Win32 API calls from Office macros

Understanding the ASR Rule Modes

Mode	What will happen?	Status Code
Not configured	Rule is not enabled or disabled	0
Block	Rule is enabled	1
Audit	Rule is in evaluation mode. No effect to the end user	2
Warn	Rule is enabled. This gives a notification to the user. User has the option to bypass if needed.	6

If You are Moving From a Different EDR/ XDR Solution

ASR rules are an essential feature in most of the top-tier EDR/ XDR solutions and if you are already using those today and moving to Defender ASR rules,

• Map out the policies as there can be some policies missing or interpreted in a different way.
• Rule-based exclusions must be properly mapped out.
• It is always ideal to start with a Pilot batch for the migration so you know the path is clear for the other deployment rings.
• Understanding the Defender ASR rules prerequisites and dependencies is a must.
• If Defender ASR rules are not replacing the previous product’s rule/s, make sure they will be covered in a different security policy or a restriction.

Understanding the ASR Rules Dependencies

Noting that there are prerequisites for the ASR rules to be implemented such as licensing and OS types etc,. If you have the idea of implementing the rules, good, that’s part one of the planning. However, there are some dependencies outlined by Microsoft in order to get that up and running. The below section is from Microsoft Learn pages and it has described the dependencies in an understandable way.

1. Microsoft Defender Antivirus must be enabled and configured as the primary anti-virus solution, and must be in the following mode:

• Primary antivirus/antimalware solution
• State: Active mode

2. Cloud Protection (MAPS) must be enabled to enable attack surface reduction rule

3. Microsoft Defender Antivirus must not be in any of the following modes:

• Passive
• Passive Mode with Endpoint detection and response (EDR) in Block Mode
• Limited periodic scanning (LPS)
• Off

4. Microsoft Defender Antivirus components must be current versions for attack surface reduction rules

The following Microsoft Defender Antivirus component versions must be no more than two versions older than the most-currently-available version:

• Microsoft Defender Antivirus Platform update version – Microsoft Defender Antivirus platform is updated monthly.
• Microsoft Defender Antivirus engine version – Microsoft Defender Antivirus engine is updated monthly.
• Microsoft Defender Antivirus security intelligence – Microsoft continually updates Microsoft Defender security intelligence (also known as, definition and signature) to address the latest threats, and to refine detection logic.

Audit Mode and Coming Out of Audit Mode

Once the planning is completed, testing the rules in the Audit mode is a recommended activity as this will provide you some good insights into the overall rules’ behavior. Microsoft recommends keeping the rules in the audit mode for a minimum of 30 days to get insights about the impact of the rules on user productivity and better understand the restrictions, if you think about it, 30 days is a good period to collect some rich insights from Defender ASR rules reporting page. After the Audit period, they should be changed to the Block mode with exclusions in the rules if needed. This is something most of the organization aren’t doing or forgetting. The rules are as good as they are enabled in the block mode. You can actively see how effective they are when they are only in the block mode.

What rules to Enable First?

ASR rules can be broken down into 2 main sections. Standard protection rules can be enabled first as their impact is minimal or no impact.

Once that’s enabled, look for the other rules and enable them accordingly.

• Standard protection rules: Rules you must consider enabling first always as these have minimal to no impact on your end users.
• Other rules: These need to go through the Plan > Test > Enable phases as they need some thought before rolling out.

Standard protection rules

• Block credential stealing from the Windows local security authority subsystem (lsass.exe)
• Block abuse of exploited vulnerable signed drivers
• Block persistence through Windows Management Instrumentation (WMI) event subscription

Once the Rules Are In Operation

Congratulations! You have finally made them into the Block mode. The work is not done yet. This is where you start monitoring the rules and their behavior and making sure it will not hinder the user’s productivity and not block any false positives.

By now you should have created your alerts. These alerts will notify you of any malicious activities that have been blocked by the rule set.

Proper documentation is needed. If you have any exclusions, or different polices for different end-user groups, they need to be documented as that can be helpful in troubleshooting.

Checking the Defender reports and understanding the false positives make sure you are managing the attack surface in the right way.

Being on top of the ASR rules reports is essential as that will provide you with insights into the attack and any trends of attacks.

Using Advanced Threat Hunting

Advanced Hunting is one of the powerful features in Defender XDR, This activity is so essential as this will help you to understand the gravity of the issue quite easily. The importance of using Advanced hunting is you can set your own workbooks, alerting and queries to understand the incidents soon and action poactively. In this article, I’m not going to explain how to write the queries, but in case you don’t know or not clear, you can use KQL queries to get ASR Rules related incidents as you do for other incidents as well.

You can start with simple KQL queries as below and expand.

DeviceEvents
|where Timestamp > ago(30d)
| where ActionType startswith "Asr"
| summarize EventCount=count() by ActionType

DeviceEvents
| where (Actiontype startswith "AsrOfficechild")
| extend RuleId=extractjson("$Ruleid", AdditionalFields, typeof(string))
| project DeviceName, FileName, FolderPath, ProcessCommandLine, InitiatingProcessFileName, InitiatingProcessCommandLine

Wrapping Up

There shoule be a lot of thought go in to ASR rules as you need to be aware of the impact of it if you cibfigure them in the wrong way or set to block mode for the sake of enablinb them or think this will help you to solve all the device hardning requirements.

As I mentioned above, the attack surface is an ever-expanding landscape and proactively managing it is essential. Better yet, what if you haven’t taken the necessary steps to harden the endpoints and depending on your AV, device firewall solution, and maybe MFA take care of all the security problems? Not good enough. ASR rules will always complement on top of the security measures that you already have in place. So, making sure the other security configurations are up and running and securing your environment is a must.