Microsoft Defender Attack Surface Reduction recommendations
This blog post contains a list of recommendations that Palantir’s Infosec team gathered from the Windows Defender Attack Surface Reduction family of security controls during the past two years. It is hoped that it will be helpful to other security teams considering a deployment. Based on our production deployment experience, we’ll highlight the important points for each setting.
Windows Defender Attack Surface Reduction (ASR), as Microsoft calls it, is a set of controls that limit common malware and exploit techniques on Windows devices.
ASR controls, unlike Windows Defender Exploit Guard are easy on/off switches administrators can deploy quickly with Intune or group policy, especially if they intend to use audit-only mode.
This paragraph from the Microsoft website provides a great overview:
ASR targets software behavior that is often misused by attackers.
- Launch executable files and scripts to attempt to download or execute files
- Running suspicious or obfuscated scripts
- Perform behaviors that apps won’t normally initiate during their day-to-day tasks
These behaviors can sometimes be seen in legitimate applications. However, they are often abused by malware and are considered dangerous. These types of risky behavior can be restricted by rules that reduce the attack surface and help to keep your company safe.
Summary of the recommendation
Although we tried to be opinionated in this post to give value to readers, we also recognize that each setting has its own environmental nuance. For more information on the reasons behind the recommendations, please refer to the sections below. You will likely face different set constraints when protecting your networks.
Two events will record the information for those who wish to dive directly into the logs.
- Audit only: Windows Event 1122
- Block ModeWindows Event 1121
Windows will deny the behavior if you set any ASR setting to block mode. will also log the event. Windows can restrict legitimate use cases in certain environments, which is the obvious problem. This is what this post aims to avoid. Audit mode can be used by itself to provide valuable data for defenders. It can also be configured fleet-wide in most corporate environments using group policy in less than an hour.
Rule breakdown
Untrusted or unsigned processes running from USB can be blocked
Block mode configuration of “Block untrusted, unsigned processes that run on USB” caused no problems. This rule was set up in block mode from the beginning. We have not seen any events related to this rule for 18 months. This rule is safe to be deployed in block mode in most corporate environments.
RecommendationBlock Mode
Adobe Reader can’t be used to create child processes
We discovered early in our ASR journey, that “Block Adobe Reader Child Process” does not cause a minor problem related to Adobe’s current approach to updates for certain products.
The Adobe application update mechanism attempts to launch a child process that does the work. This is an issue for the ASR rule.
We chose to roll back the rule and perform Adobe updates via our central software maintenance service. This ensures that Adobe does not have to launch child processes. We are willing to pay a small operational cost to protect PDF malware.
Recommendation: Block Mode.TipAdobe Update Process: Take care. You should always have another option for updating.
Block executable content in email client and webmail
No events related to this control were found in the data that we collected. Many of our users use webmail and email clients that meet the rules. We believe that the other controls in an email delivery path do a fair job protecting users from executable content in emails. We recommend that this control be left in place as last-resort protection to endpoints.
Recommendation: Block Mode.
Stop JavaScript and VBScript from launching executable content downloaded
In the 18+ months that we have collected data, there were no events related to this control.
Microsoft offers the following advice:
- ” Line-of-business applications often use scripts to launch installers, although this is not a common practice.
The Windows environment that this post is based upon contains approximately 1000 endpoints. We did not observe any evidence of such behavior. It is therefore safe for most corporate networks, but administrators should be aware.
Recommendation: Block Mode.
Block persistence via WMI event subscription
In the 18+ months that we collected data, there were no events related to this control. We actually started in Audit mode because we missed the note about it being a block mode only control (audit mode defaults to block).
Microsoft describes this as ” this rule prohibits malware abusing WMI to achieve persistence on a device.”
This persistence behavior was implemented in many C2 Frameworks to make it easy for adversaries. We’d already created additional alerts for this behavior, but we appreciated the simplicity of this control. We have not had any problems with block configuration.
Recommendation: Block Mode.
Block credential theft from the Windows subsystem of the local security authority (lsass.exe).
We’ve seen the last protector rule as one of the most frequent ASR audit mode events. It generates approximately 12 million events per six months in our environment.
ASR alerts will be generated for the lsass.exe rule by many safe processes. Defenders won’t be able to distinguish between legitimate use cases or adversary tradecraft.
We originally decided and not to implement block mode because of the large number of events that were recorded in audit mode.
After thinking about it for a while, and digging deeper into some of the use cases and alerts, we felt that we were capturing mostly the events described by Microsoft in this note:
We also should mention that we had already deployed Credential Guard in the environment. We felt more secure in knowing that cross-process lsass access was unlikely to be a valid, critical use case.
We moved the last rules into block mode because it was profitable. The rule has been in place for three months, as per the data at this post. We have not seen any user impact. If new considerations arise, we’ll update this post.
Recommendation: Block Mode.
TipAudit mode events will be displayed for this setting. Do not let this be the end of any attempt to get to block mode.
Block Office applications prevent executable content creation
A small number of users were subject to approximately 100 audit events every six months. We discovered that the file that was causing the issue with the ASR rule “Block Office Applications from creating executable Content” was:
- “microsoft.office.smartlookup.ssr.js”
This file appears to be part of the Office smart lookup feature, which is described by Microsoft here.
These are the Office processes that leverage the.js file to smart lookup.
- MS Excel 75% of all the time
- MS OneNote 20% of all the time.
- MS Word takes 5% of the time
As defenders, we wanted to know if an attacker could use this.js file. Although it is unlikely, this file could offer persistence. We have not yet excluded the file from ASR auditing. We have moved the rule to block mode, with exceptions for users with business cases, and updated our internal Wiki to make it easier to request exceptions based upon business needs.
RecommendationBlock Mode.TipIf the Microsoft Office Smart Lookup feature has an important role for your users, be careful.
Block Office applications are prohibited from injecting code into any other processes
Surprisingly, and even disappointing, we discovered that there were legitimate use cases that would stop us from using block mode to implement this rule immediately. It seemed easy.
Microsoft explains this rule as:
We collected approximately 10,000 events related to this behavior over a period of six months.
The majority of the events related to a proprietary/commercial, non-Microsoft application we identified in the environment that is deployed for a very small number of users. This is a visual representation of how irregular process injection appears to be.
- The proprietary/commercial application was responsible for 97% of this behavior in the environment.
- Adobe Acrobat was represented at 1% (roughly 100 events every 6 months).
- Microsoft Word alerts were an additional 1%
- The rest of the events accounted for 1% each and were distributed throughout the office suite.
We are currently unable to continue with the rule in block mode across the fleet. Therefore, we have created a separate policy for a subset of users.
RecommendationBlock Mode with small exceptions.
Tip: This control is the one you will need to examine your audit data carefully for. If this is a critical business application, and only a few people need the add-in for their work, we recommend creating a separate exception policy.
Office macros can block Win32 API calls
Thank you for reading this far. But you might be thinking, “This one should’ve been an easy block decision.” We felt the same and were surprised by the data.
This category currently records approximately 15,000 events every half-year.
These events are all related to an older style Office macro. The events point to:
- C:\Program Files\Microsoft Office\root\Office16\STARTUP\ProprietaryThing.dotm – word/vbaProject.bin
The most succinct explanation of this behavior we found is here.
This page explains:
This behavior can be attributed to a legacy plugin, which is only required by a small number of users. It is interesting to note that only one user, who relies heavily upon the plugin, generates approximately 30% of the event volume.
Side note: We recommend that macros are blocked for all users on this network. @Oddvarmoe recently released this excellent blog post describing the security options for macros in a corporate setting.