Attack surface reduction rules for Microsoft productivity apps
Attack surface reduction rules in Microsoft Defender for Endpoint help prevent apps from launching executable files and scripts, running suspicious scripts and more.
The increase in remote work, along with increased use of multiple employee devices, is creating an ever-expanding enterprise attack surface. Using attack surface reduction, or ASR, can help organizations prevent malicious actors from exploiting vulnerabilities and weaknesses these two variables create.
A variety of products and platforms are available to help reduce the attack surface. Organizations looking to specifically protect and manage endpoints can consider Microsoft Defender for Endpoint. To help security professionals understand this Microsoft platform and its features, authors Paul Huijbregts, Joe Anich and Justen Graves wrote Microsoft Defender for Endpoint in Depth.
The book specifically dives into how to tackle ASR in common productivity applications, including Microsoft Office and Outlook. In the following excerpt from Chapter 3, the authors explain how to use Microsoft Defender for Endpoint ASR rules to block such productivity apps from taking specific actions, such as creating executable content or child processes.
Download a PDF of Chapter 3 for more. Also, be sure to read our interview with Huijbregts, Anich and Graves, where they discuss using Microsoft Defender for Endpoint for security posture management.
Productivity app rules
These rules are used to block behaviors or attacks that attempt to exploit productivity applications:
- Block Office applications from creating executable content
- Block Office applications from creating child processes
- Block Office applications from injecting code into other processes
- Block Win32 API calls from Office macros
- Block Adobe Reader from creating child processes
Click to learn more about
Microsoft Defender for
Endpoint in Depth.
Block Office applications from creating executable content
In attacks that involve exploiting vulnerabilities in Office processes or abusing the features and functionalities of Office applications, one of the common successive stages is to drop and execute a malicious file on the affected device. This is where the attacker succeeds in successfully intruding into the device and can perform any number of malicious activities from this point onward.
This rule prevents Office applications, Word, Excel, PowerPoint, and OneNote from dropping the executable content on the disk. In doing so, the rule aims to block the attacks at a crucial stage where attackers are looking to gain access and obtain a foothold on the machines.
In the case of Windows executables files -- that is, Portable Executable (PE) files, the rule only blocks untrusted and unsigned files from being written to the disk. This prevents some of the intended use cases from being blocked. However, the script files are outright blocked without validating trust or friendliness status.
A few popular applications have already been excluded from the rule using backend exclusions or global exclusions. However, to protect you from attacks that may abuse these exclusions, Microsoft has intentionally refrained from publishing a list of the excluded applications/processes. Despite deploying global exclusions, you may still need to deploy local exclusions for first-party internal or third-party LOB applications blocked by the rule.
Block all Office applications from creating child processes
As mentioned earlier, attackers that use Office applications -- that is, Word, Excel, PowerPoint, OneNote, and Access -- as the point-of-entry vector often attempt to download and execute malicious files on the affected device, or Office processes are used to execute system processes or admin tools or benign third-party processes to deepen or broaden the infection—for example, launching Command Prompt or PowerShell to disable an important security control or make some registry changes.
As such, this rule provides another important control -- it blocks all Office applications from launching any child processes. No trusted files, friendly files, system files, admin tools, or benign third-party applications are allowed to execute.
Block Office applications from injecting code into other processes
Injecting code into legitimate clean processes (mostly, signed processes) is a well-known detection evasion technique. Office processes have not been immune to this technique. However, the researchers at Microsoft understand that there is no good reason for Office processes to inject code into other running processes. This rule blocks processes related to Word, Excel, and PowerPoint Office applications from performing code injection activity.
As with the rest of the productivity app rules, this rule also supports ASR exclusions.
Block Win32 API calls from Office macros
The Office VBA macro is an extremely popular feature among Office users. However, even though Office supports calling Win32 APIs from inside the VBA macro code, most organizations do not make use of the functionality as often. On the other hand, attackers can use it to perform a host of malicious activities, including conducting a fileless execution of the malicious shell code, making it exceedingly difficult to detect. This rule blocks the execution of macro code that contains Win32 API calls.
The rule supports exclusions. As such, the organizations that need macros to make Win32 API calls can exclude specific Office files and continue to block the rest.
Block Adobe Reader from creating child processes
As with Office applications, attackers can also use various techniques to perform attacks using Adobe Reader processes. In such attacks, the Adobe Reader process often launches additional payloads or admin tools. This rule blocks such attacks by blocking Adobe Reader from launching child processes.
As with Office rules, a few popular applications have already been excluded from the rule using global exclusions. As always, you can also deploy on-client exclusions.
Script rules
These two rules are focused on mail clients creating and launching executable content, something very popular with malicious documents sent in phishing or spearphishing campaigns:
- Block execution of potentially obfuscated scripts
- Block JavaScript/VBScript from launching downloaded executable content
Block execution of potentially obfuscated scripts
Obfuscating scripts (for example, containing JavaScript/VBScript/PowerShell (PS)/macro code) is a customary practice among script authors. It provides a way to obscure the contents for protecting proprietary information, as sometimes it may include intellectual property. However, malware authors abuse this capability to make their malicious scripts difficult to read, analyze, and detect.
This rule looks for properties that are indicative of obfuscation and uses machine learning (ML) models on top of the identified properties to classify and successively block the scripts.
Since the rule makes use of ML models, there is always a certain degree of FPs associated with this rule. To mitigate the adverse impact of such FPs, such as productivity app rules, this rule also supports exclusions.
Block JavaScript/VBScript from launching downloaded executable content
Downloading malicious scripts or binaries and using them to perform malicious activities during the stages of an attack is quite a widespread practice. As the name suggests, the aim of this rule is to block JavaScript and VBScript scripts from launching downloaded malicious content. Once enabled the rule blocks such scripts from executing on the protected device.
However, several genuine scenarios need scripts to be able to download and execute hosted content. As such, the rule also supports ASR exclusions.
Communication app rules
These rules are intended to reduce the chance that communication applications are abused as an initial attack vector:
- Block executable content from email client and webmail
- Block Office communication applications from creating child processes
Block executable content from email client and webmail
In attacks that involve email as the vector, it is often seen that some sort of malicious executable file is delivered to the affected device in the form of an email attachment. Therefore, this rule has been created to block all executable files (such as .exe, .dll, and .scr) as well as popular script files (such as .ps1, .vbs, and .js) delivered via email. When such emails are opened and the executable or script file is accessed, the rule inspects and blocks the files in question.
The rule works for the Outlook client application as well as Outlook.com and other popular webmail providers.
In general, most organizations do not approve of sharing executable or script files over email. However, there is always a pocket of users or devices where the activity is observed and successively either allowed or simply ignored. It is never recommended to allow such sharing over email; however, in case you have a need to allow this, at least for a small set of devices, this rule also supports ASR exclusions.
Block Office communication applications from creating child processes
As mentioned earlier, email has been used as a point-of-entry vector for a long time. Blocking the executable files delivered using email is just one scenario. Other popular scenarios include exploiting vulnerabilities or abusing loopholes in the Outlook app. In such cases, the attack kill chain usually contains the Outlook app launching some processes on the affected devices. In most cases, these are admin tools that can get abused to lower the security posture of the device and download additional malicious binaries or tools needed for the attack.
This rule protects against such attacks by blocking all child processes created by the Outlook app.
Note that as with the Office-related rules from the Productivity app rules section, a few popular applications have already been excluded from the rule using global exclusions. The rule also supports ASR exclusions. Users can always exclude internal or LOB apps blocked by this rule.
