ASR rules keep attackers out

What ASR rules are defined?

Microsoft has defined a set of ASR rules. These rules target applications that are commonly misused to get access to a system. Below is an overview of the current set of ASR rules, describing the effect and why the ASR rule should be enabled. 

• Block abuse of exploited vulnerable signed drivers
  An attacker with access to an application can create vulnerable signed drivers. This allows an attacker to communicate with the Windows kernel directly and bypass security measures. This rule prevents an application from creating signed drivers.
• Block all Office applications from creating child processes
  By enabling this rule, Office applications such as Word, Excel, Teams, etc. cannot create child processes. These are processes that run under the main process. Malicious macros use child processes to execute malicious code. By blocking child processes, a macro can no longer start child processes and malicious code cannot be executed.
• Block all Office applications from injecting code into other processes
  This rule prevents Office applications such as Word, Excel, Teams, etc. from injecting code into other processes. An attacker can inject code into another process through a malicious macro. This makes it possible to mask malicious activity behind a valid process. It also gives an attacker longer access to the infected system. By implementing the rule, macros can no longer write code to other processes.
• Block Office applications from creating executable content
  Besides injecting code into other processes or creating new ones, malicious macros can also download or create executable files. This still makes it possible to execute code on the system. Enabling this rules prevents Office products from creating executable files. 
  
• Block Win32 API calls from Office macros
  By default, Microsoft Office applications are allowed to use Win32 APIs. An attacker can invoke these APIs to write sophisticated macros. These macros are harder to detect and have more functionality. Enabling the rule blocks the use of Win32 APIs. 
  
• Block Adobe Reader from creating child processes
  As with Office applications, it is possible to start new child processes under the Adobe Reader process. This can be abused by attackers to execute code. By enabling this rule, the Adobe Reader process can no longer start child processes.
• Block credential stealing from the Windows Local Security Authority Subsystem (LSASS)
  The Windows operating system stores the hashed password of logged-in users within the Windows Local Security Authority Subsystem (LSASS) process. Attackers with administrative access to a system can extract hashed passwords from this process. This can give an attacker access to other users. By enabling this rule, it is no longer possible to access the LSASS from another process. 
  
• Block executable content from email client and webmail
  Besides sending Word or PDF files, an attacker can also mail executable files. A user can then download and execute this file. This allows malicious code to be executed on the user’s system. By enabling this rule executable files are blocked by Microsoft Outlook. files with the extensions .exe, .dll, .scr, .ps1, .js and .vbs are considered executable and thus blocked.
• Block execution of potentially obfuscated scripts
  Attackers with access to a system try to be as unobtrusive as possible. Thus, they try to hide their commands. One technique to do this is called obfuscation. For example, an attacker might introduce extra characters in to their command to hide the original command. By doing so, the attackers try to bypass security measures. Enabling this rule turns on extra security that blocks these kinds of obfuscated scripts. As a side note, PowerShell scripts are not temporarily blocked by Microsoft. 
  
• Block JavaScript or VBScript from launching downloaded executable content
  Some file formats support executing JavaScript or VBScript. These scripting languages can be used to download and execute executable files. This allows an attacker to gain access to the system. Enabling this rule blocks malicious files downloaded using JavaScript or VBScript. This means the downloaded files can no longer be executed.
• Block persistence through WMI event subscription
  After an attacker has gained access to a system, the attacker wants to keep access to the system. This is called persistence. An attacker can achieve this by creating an event in Windows Management Instrumentation (WMI). Enabling this rule blocks such events. This means that an attacker cannot use WMI events to maintain access on the system. However, there are many other techniques that an attacker can use to achieve goal. 
  
• Block process creations originating from PSExec and WMI commands
  The PSExec and WMI processes can be used to execute commands on a system from a remote location. An attacker can abuse this if he or she has valid login credentials for the system. This makes it possible to gain access to the underlying system. This rule blocks the execution of processes created via PSExec and WMI. 
  
• Block untrusted and unsigned processes that run from USB
  An attacker with physical access can plug a USB stick into a system and then run programs from the USB. Enabling the rule blocks files with the following extensions: .exe, .dll, and .scr.
• Use advanced protection against ransomware
  This rule provides additional protection against ransomware. When this rule is applied, potentially malicious files are executed in a sandbox environment. This is a protected environment in which Windows Defender can analyse the behaviour of the application. If the file looks like ransomware, it will be blocked.

ASR rules in practice

To make ASR rules more tangible, we prepared a simple example. In this example, we enabled the ASR rule ​“Block credential stealing from the Windows local security authority system” on a Windows machine. As mentioned above, this rule blocks access to the LSASS process.

In the example below, an attacker has gained administrative access to a system and is attempting to read passwords from the LSASS process using the Mimikatz utility. We initially ran this without enabling the ASR rule. The screenshot below shows that the content of the LSASS process has been succesfully extracted and hashed passwords are shown:

Then we enabled the ASR rule. If we now try to extract passwords again with Mimikatz, this will fail. This is because Mimikatz is no longer allowed to communicate with the LSASS process. This results in an error message shown in the screenshot below:

Wat te doen met ASR-regels?

ASR rules improve the security of a system and make it more resilient to common attacks. For this reason, we recommend implementing as many ASR rules as possible on all systems in the company network. In a next blog post we will discuss the implementation of ASR rules and what is involved.