Microsoft ASR - Full Overview & Licensing

Learn how to implement Microsoft ASR and what licensing models provide it 

In today's business landscape, cyber-attacks aren't just common—they're a daily battle. This has prompted a surge in the demand for advanced security measures, among which Endpoint Detection and Response (EDR) stands out. Microsoft Defender for Endpoint (MDE), part of the Microsoft Defender XDR suite, embodies this demand by offering a comprehensive EDR solution. 

MDE contains a variety of security features ranging from monitoring all your endpoints to alerting or automated incident response. One of its security features is Attack Surface Reduction (ASR). Microsoft ASR is a set of rules, separate from each other, that one can activate to disable many common attacker vectors, such as Office documents with malicious macros. 

While ASR rules can significantly improve your environment's security posture, their deployment demands careful consideration to avoid disrupting business operations. For this reason, in this article, we will review each ASR rule, its license requirements, the logs it generates, and the precautions to consider before activating ASR rules in block mode.

Summary of key Microsoft ASR concepts 

The table below lists different aspects of ASR rules that we will cover in this article. 

Microsoft ASR requirements and security features

In the following sections, we will examine ASR rules, their definitions, and the licenses required for them. We will review each one in detail. Finally, we will cover some things to keep in mind before activating ASR rules in block mode.

What are the Microsoft ASR rules?

Microsoft ASR currently consists of 17 rules designed to hinder threat actors at various stages of an attack, including lateral movement, credential theft, phishing attempts, execution of malicious scripts, and deployment of polymorphic threats like ransomware. It's important to note that the number of rules may be subject to change in the future. There are currently six methods to configure or activate ASR rules:

1. Intune
2. Custom Intune profile
3. MDM
4. Microsoft Configuration Manager
5. Group Policy
6. PowerShell

Administrators can use this detailed Microsoft article to learn how to use each of these alternatives to roll out and configure ASR rules in your environment. One of the things you will have to decide during the activation is the running mode for each of the rules:

1. Not Configured or Disabled mode- The ASR rule is not activated or has been disabled.
2. Audit mode- Given that each company has a unique IT environment, it is advisable to run all rules in audit mode and see what benign applications are blocked. If their execution has been blocked, this might hinder business processes.
3. Warn mode- A relatively new mode that will block content execution but will notify the user of this block via a dialog box. However, the dialog box also gives the user the option to cancel the block. This is valid for only 24 hours, after which the user will be warned again if the same malicious content is executed.
4. Block mode- This strict mode will block the execution of any content if it triggers one of the ASR rules and cannot be undone by the users. If the block is a false positive, only the IT administrators can add it as an exclusion. 

Microsoft’s recommended process for ASR configuration. (Source)

Licensing and other requirements

Note that ASRs can only be applied to these Windows OS editions:

• Windows 10 Pro, version 1709 or later 
• Windows 10 Enterprise, version 1709 or later 
• Windows Server, version 1803 (Semi-Annual Channel) or later 
• Windows Server 2022 
• Windows Server 2019 
• With special onboarding instructions
  • Windows Server 2016
  • Windows Server 2012 R2

It's crucial for Microsoft Defender Antivirus (AV) to be the primary antivirus software on your device, actively running without other antivirus products. Simply having Defender AV off or in a secondary role isn't sufficient for the effective functioning of Attack Surface Reduction (ASR) rules; Microsoft underscores the necessity of Defender AV's active presence for ASR rules to operate as intended.

Having fulfilled the technical requirements, your company must consider and choose a suitable licensing model that includes ASR. The following are viable license models:

• Windows Enterprise E5- Includes advanced management and security capabilities. 
• Windows Enterprise E3- Doesn’t provide advanced management/configuration capabilities, easier event monitoring, detailed analytics in MDE, or reporting in Defender XDR.
• Microsoft Defender for Endpoint Plan 2- An advanced Defender plan that includes features like EDR and Microsoft Threat Experts.
• Microsoft Defender for Endpoint Plan 1- Provides less flexible configuration possibilities and doesn’t provide log review in Advanced Hunting Queries (AHQ) in MDE, increasing the manual effort for security analysts to retrieve the logs from each device for analysis or Threat-hunting activities.

List of all available ASR rules

Microsoft divides the 17 ASR rules into two groups: standard and other. Standard rules are a subset of ASR rules that Microsoft highly recommends that you activate, as they, according to Microsoft, have little to no impact on the end user. The three current standard rules are:

1. Block abuse of exploited vulnerable signed drivers-  Prevents an application from writing a vulnerable signed driver to disk.
2. Block credential stealing from the Windows local security authority subsystem (lsass.exe)- Given that lsass.exe caches all kinds of user credentials or Kerberos tickets in an AD environment, this rule hinders credential stealing and any potential lateral movement with stolen credentials.
3. Block persistence through WMI event subscription- WMI subscription is an advanced persistence mechanism that was first used by the Stuxnet malware. Activating these rules will trigger an alert if suspicious WMI subscriptions are noticed in your environment.
   On the other hand, other rules are a subset of ASR rules that might break applications and scripts or hinder business processes. For this set of rules, Microsoft recommends that they go through the auditing and testing phase before activating them:
4. Block Adobe Reader from creating child processes- Malicious PDF attachments are a common technique in phishing emails. By activating this rule, you ensure that Adobe Reader will not spawn dangerous child processes such as powershell.exe or cmd.exe after opening a suspicious PDF.
5. Block all Office applications from creating child processes- Similar to the above, it blocks Office applications, such as Word or Excel with malicious macros, from creating dangerous child processes on behalf of the attacker.
6. Block Office applications from creating executable content- It blocks Office applications (with malicious macros) from creating or dropping binaries on the system, a common technique often used by hackers.
7. Block Office applications from injecting code into other processes- Since dropping binaries to disk might be detected by the AV, attackers have shifted to injecting malicious code or binaries directly into memory. By activating this rule, memory injection via Office applications is prohibited.
8. Block Office communication application from creating child processes- similar to the above, but focused on M365 applications, such as Sharepoint.
9. Block executable content from email client and webmail- Given that phishing emails are the most common entry vector for malware, this rule attempts to block exploitation attempts that are delivered via email.
10. Block executable files from running unless they meet a prevalence, age, or trusted list criterion- Although Microsoft doesn’t reveal all the considered criteria, certain suspicious files that do not fulfill several criteria will be prevented from being executed.
11. Block execution of potentially obfuscated scripts- given that most attackers obfuscate their scripts to bypass signature-based detections, this rule can be used to catch obfuscated scripts that are attempting execution.
12. Block JavaScript or VBScript from launching downloaded executable content- some malware types called “downloaders” will attempt to download additional malicious items from the Internet. With this rule, malicious scripts will be prevented from doing so.
13. Block process creations originating from PSExec and WMI commands- while PSExec and WMI are often used by IT, these are also living-of-the-land binaries that attackers abuse for lateral movement. This rule attempts to block the child processes that these two Windows executables attempt to create.
14. Block untrusted and unsigned processes that run from USB- Rogue USB devices might be infected and make their way into your environment. By activating this rule, you block any started processes that originate from USB sticks.  
15. Block webshell creation for servers- A common persistence mechanism in web servers is the installation of webshells via various methods. This enables the attacker to remotely command the server to perform malicious operations, with the webshell running as a child process of the benign web server process.
16. Block Win32 API calls from Office macros- Win32 APIs are advanced functions in Windows that enable malware to interact with the OS kernel directly, a feature often abused by advanced malware. Activating this rule monitors if such behavior is triggered by malicious macros and block execution.
17. Use advanced protection against ransomware- Ransomware is one of today's biggest cybersecurity threats. Microsoft created this ASR rule to discover malware in its early phases based on common ransomware behavior, such as deleting shadow copies or killing AV processes/services.

A more detailed description of these “other rules” can be found in Microsoft’s Attack Surface reduction rules article.

Microsoft ASR events and log analysis

When ASR rules are triggered, either in audit or block mode, they will generate certain events that can be analyzed in:

1. MDE via AHQ- Part of DeviceEvents table, an analyst could query for ASR events for all or specific devices onboarded in MDE for the last 30 days. For example, the below query will show all ASR events for all onboarded endpoints in your environment:
   

   DeviceEvents
   | where ActionType startswith 'Asr'
   

   Other examples to get you started with ASR-related AHQ queries can be found here.

2. Windows Defender log channel- ASR events are covered by three specific event IDs. Note that some configurations are required for these events to be parsed correctly.

Additionally, the triggering of some ASR rules will also generate a security alert or incident in MDE. A detailed list of which ASR rules would trigger an alert in MDE can be found here. 

Things to consider when using Microsoft ASR

Like most security enhancements, while they improve your security posture, there are always some things to be considered:

• False positives- No security detection or solution is perfect, and false positives are bound to happen. Even though administrators can create exclusions, note that, for example, some ASR rules do not honor any Defender AV exclusions. For false positives from these ASR rules, the IT administrators would need to add exclusions to the ASR rule itself and not via Defender AV. 
• Centralized logging- While centrally querying for ASR events with AHQ in MDE is only possible in the most expensive licensing, Enterprise E5, your company can still tap into the ASR events centrally by using a centralized SIEM solution. This way, each endpoint can be configured to forward the local event logs to SIEM, which can then be queried in SIEM for all endpoints, similar to what AHQ in MDE provides.
• ASR is not a bulletproof solution- Microsoft ASR rules certainly make it harder for attackers to compromise your assets, but they are not perfect. As with everything in the cybersecurity world, there will always be a bypass to a security mechanism, followed by a new security measure to prevent the bypass, and so on, in a never-ending cat-and-mouse game. This makes defense-in-depth crucial for the security of your organization.

Consider using ASR rules and other advanced email security solutions that provide seamless integration with M365 to enable employees to report suspicious emails that ASR might not have noticed or blocked. More importantly, even when every security mechanism fails or is bypassed, security-aware employees might still be able to save the day. That is why investing in security awareness training and phishing simulations is essential to make security part of your company’s culture.

IRONSCALES Themis CoPilot Phishing Button. (Source)