Microsoft Defender Attack Surface Reduction recommendations
Tags: Microsoft Defender, Palantirtech, Infosec, Information Security

This blog post provides a set of recommendations based on the audit data Palantir’s Infosec team has collected from the Windows Defender Attack Surface Reduction (ASR) family of security controls over the past two years. We hope it will assist other security teams who are considering a deployment. We’ll aim to highlight the considerations for each setting based on production deployment experience.

For those that are new to the topic, Windows Defender Attack Surface Reduction (ASR) is the name Microsoft gave a collection of controls that restrict common malware and exploit techniques on Windows endpoints.

Unlike Windows Defender Exploit Guard, ASR controls are simple on/off switches that administrators can deploy in very short order with group policy or Intune, especially if they plan to use audit-only mode.

This paragraph from the Microsoft website provides a great overview:

ASR targets software behaviors that are often abused by attackers, such as:

Launching executable files and scripts that attempt to download or run files

Running obfuscated or otherwise suspicious scripts

Performing behaviors that apps don’t usually initiate during normal day-to-day work

Such behaviors are sometimes seen in legitimate applications; however, they are considered risky because they are commonly abused by malware. Attack surface reduction rules can constrain these kinds of risky behaviors and help keep your organization safe.

Recommendation summary

We aimed to be somewhat opinionated in this post to provide value to readers but we also acknowledge that all of the settings have their own environmental nuance. Please refer to the descriptions below this summary section for the reasons we’ve made the recommendations. It’s very likely that you’ll be dealing with a different set of constraints in the networks you protect.

For those looking to dive right in to the logs in their environment, the information will be recorded in two different events:

Audit Only: Windows Event 1122

Block Mode: Windows Event 1121

Configuring any ASR setting in block mode will cause Windows to deny the behavior and also log the event. The obvious challenge is that Windows is likely to restrict legitimate use cases in some environments and that’s what we are hoping to help avoid with this post. Audit mode on its own will provide an excellent source of data for defenders and can be configured fleet wide in most corporate environments in under an hour using group policy.

A note on ASR deployment and event log forwarding: At Palantir, we make heavy use of Windows Event Forwarding (WEF) to collect the 1121 and 1122 events for analysis. Our WEF guide can be found here and configuration samples here. Our ASR deployment was configured by setting the group policy settings described here. You can use a single policy for all ASR rules; you’ll just need to decide between block mode and audit mode for each setting you configure. An alternative is to create multiple policies where exceptions need to be granted to block mode rules, configuring the exceptions as higher priority group policies, restricted by “apply group policy“ access control entries on the group policy object.

Rule breakdown

Block untrusted and unsigned processes that run from USB

Configuring “Block untrusted and unsigned processes that run from USB” in block mode caused no issues whatsoever. We configured this rule in block mode on day one and didn’t register a single event related to this ASR rule over the past 18 months. We feel this rule would be safe to deploy in block mode in almost any corporate environment.

Recommendation: Block Mode.

Block Adobe Reader from creating child processes

We identified early in our ASR journey that “Block Adobe Reader Child Process” does cause a minor issue related to the way Adobe currently approaches updates for some products.

Here’s an example event:

Message=Windows Defender Exploit Guard has blocked an operation that

is not allowed by your IT administrator. For more information please contact your IT administrator.

ID: 7674BA52-32EB-4A4F-A9A1-F0F9A1619A2C

Detection time: 2020-10-16T19:35:03.723Z

User: DOMAIN\User

Path: C:\xxx\Acrobat_DC_Set-Up.exe

Process Name: C:\xxx\AcroRd32.exe

Security intelligence Version: 1.325.883.0

Engine Version: 1.1.17500.4

Product Version: 4.18.2009.7

The update mechanism of the Adobe application attempts to launch a child process to do the work. This is a problem for the ASR rule.

Rather than rolling back the rule, we opted to perform the Adobe updates via our central software patching and maintenance service so that there is no legitimate need for Adobe to be launching child processes. We’ve decided to accept the slight operational cost for the sake of additional security related to PDF malware.

Recommendation: Block Mode.

Tip: Be careful with the Adobe update process. Make sure you have an alternative update approach.

Block executable content from email client and webmail

We registered no events relating to this control in the data we collected. Many of our users do leverage email clients and webmail that the rule targets. Our theory is that other controls in the email delivery path do a reasonable job of protecting users against executable content in email. Obviously we still recommend leaving this control in place as a last backstop to protect endpoints.

Recommendation: Block Mode.

Block JavaScript or VBScript from launching downloaded executable content

We registered no events relating to this control in the 18+ months of data we collected.

Microsoft provide the following advice:

“Although not common, line-of-business applications sometimes use scripts to download and launch installers”.

However, the Windows environment this post is based on contains roughly 1000 endpoints and we did not record any indication of this behavior. For that reason, we feel it is most likely safe for the majority of corporate networks but administrators should be aware of the warning above.

Recommendation: Block Mode.

Block persistence through WMI event subscription

We registered no events relating to this control in the 18+ months of data we collected. 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 describe this one as: “this rule prevents malware from abusing WMI to attain persistence on a device”.

This persistence behavior has been implemented in many C2 frameworks to make it an easy win for adversaries and for that reason, we’d already developed additional alerts related to this behavior but did appreciated the simplicity of this control. We configured block and have not recorded any issues.

Recommendation: Block Mode.

Block credential stealing from the Windows local security authority subsystem (lsass.exe)

The lsass protection rule is one of the most common ASR audit mode events we’ve come across. It generates roughly 12 million events every six months in our environment.

Many safe processes will generate ASR alerts for the lsass.exe rule and from a defender perspective, it’s reasonably hard to differentiate between legitimate use cases and and adversary tradecraft.

While planning our block mode implementation, we originally decided not to enforce blocking on this rule because of the significant number of events 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:

In some apps, the code enumerates all running processes and attempts to open them with exhaustive permissions. This rule denies the app’s process open action and logs the details to the security event log. This rule can generate a lot of noise. If you have an app that simply enumerates LSASS, but has no real impact in functionality, there is NO need to add it to the exclusion list. By itself, this event log entry doesn’t necessarily indicate a malicious threat.

We also should mention that we had already deployed Credential Guard in the environment. This gave us extra comfort in thinking it was unlikely there was a legitimate, critical, use case for cross process lsass access.

For those reasons, we moved the lsass rule into block mode and it paid off. We’ve had the rule deployed for three months as of the data of this post and have recorded no user impact. We’ll be sure to update this post if new considerations come to light.

Microsoft also provide some advise for a statistical approach to differentiate between signal and noise in this post.

Recommendation: Block Mode.

Tip: You will see a lot of audit mode events for this setting. Don’t let that be the end of your attempt to move to block mode.

Block Office applications from creating executable content

We recorded roughly 100 audit events every six months for a small subset of users. On closer investigation, we learned that the file causing an issue with the ASR rule “Block Office applications from creating executable content” is:

“microsoft.office.smartlookup.ssr.js”

This file appears to be part of the Office smart lookup feature, which is described by Microsoft here.

The Office processes leveraging the .js file for smart lookup are broken up as follows:

MS Excel 75% of the time

MS OneNote 20% of the time.

MS Word 5% of the time.

A question we asked ourselves as defenders was whether an attacker could leverage this .js file? While unlikely, it seems as though this file might provide an opportunity for persistence at the very least. For that reason we’ve not excluded the file from ASR auditing at this point. We moved the rule to block mode with some exceptions for the users with a business case and have updated our internal wiki to make it easier for people to request exceptions based on business need.

Recommendation: Block Mode.

Tip: Be careful if the Microsoft Office Smart Lookup feature is important to your users.

Block Office applications from injecting code into other processes

It was surprising and disappointing to learn that we had legitimate use cases that would prevent us from moving forward with block mode for this rule right away. It seemed like an easy one.

The Microsoft explanation for this rule says:

This rule blocks code injection attempts from Office apps into other processes. Attackers might attempt to use Office apps to migrate malicious code into other processes through code injection, so the code can masquerade as a clean process. There are no known legitimate business purposes for using code injection.

Over a six month period, we collected around 10,000 events related to this behavior.

The majority of the events relate to a proprietary/commercial, non-Microsoft application we identified in the environment that is deployed for a very small number of users. To give a sense for how irregular the use of process injection seems to be:

The proprietary/commercial application was responsible for 97% of this behavior in the environment.

Adobe Acrobat represented 1% (roughly 100 events per 6 months)

Microsoft Word alerts represented an additional 1%

The remaining events combined for 1% and were distributed across the office suite.

At this point we are unable to move forward with this rule in block mode for the majority of the fleet and have had to create a separate group policy to accommodate a small subset of users.

Recommendation: Block Mode with a small exceptions group.

Tip: This is one of the controls you’ll need to carefully asses your audit data for. If you’re unlucky enough to have a business critical application with this behavior and only a small number of people require the add-in, we recommend using a separate exception group policy for the small group of users.

Block Win32 API calls from Office macros

If you’re read this far, thank you, but you must be thinking, “This one should have been an easy block decision.” We felt the same way, and were surprised with the data.

We’re currently recording about 15,000 events in this category every half year.

The events all relate to the use of an older style of Office macro, the events point to variations of:

C:\Program Files\Microsoft Office\root\Office16\STARTUP\ProprietaryThing.dotm → word/vbaProject.bin

The most succinct explanation of this behavior we found is here.

The page explains that:

“The vbaProject.bin file is a binary OLE COM container. This was the format used in older xls versions of Excel prior to Excel 2007. Unlike all of the other components of an xlsx/xlsm file the data isn’t stored in XML format. Instead the functions and macros as stored as a pre-parsed binary format”.

In our environment we can attribute this behavior to a legacy plugin that is required for a very small number of users. Interestingly, a single user (who relies heavily on the plugin) generates roughly 30% of the event volume.

As a side note: We block macros for most users in this network and recommend the same for other environments we work with. @Oddvarmoe recently released this excellent blog post describing the security options for macros in a corporate setting.

Recommendation: Block Mode with a small exceptions group.

Tip: This is a second control that you’ll need to carefully asses your data for. If you’re unlucky enough to have a business critical application with this behavior, we recommend that you try to use a separate exception group policy for those users while you push the vendor for an update.

Block all Office applications from creating child processes

This control generates about 150 events every six months across a small number of endpoint devices. The endpoint devices are used by team members that share a common set of workflows. Interestingly, half of the events relate to a commercial/proprietary application used by the team.

We reviewed the vendor documentation for the application and found that this child process approach is actually the lesser of two evils offered for the correct functioning of the application and is not possible to avoid and also meet the business need. The alternate option provided by the vendor leverages rundll32.exe to achieve a similar goal.

The remaining 50% (~75 per 6 months) of events in this ASR category are split between the well-known Office binaries (Word, Excel, etc.) and installers for some of the less common applications in the suite (officeconnectsetup, officeconnectupdate, etc.).

Recommendation: Block Mode with a small exceptions group.

Tip: Another control that you’ll need to carefully asses the data for. We recommend using a separate exception group policy for users with a business need.

Block execution of potentially obfuscated scripts

This was a low volume but widespread event. We observed about 70 events per six months. The events were spread across a number of different endpoint devices.

The majority of events (80%+) in each six month period belong to:

C:\Windows\System32\WindowsPowerShell\v1.0\Modules\SmbShare\Smb.types.ps1xml

The Smb.types.ps1xml file is interesting. The leaf attributes in the xml structured file are powershell commands but they do not actually appear to be obfuscated beyond being part this uncommon file type.

For example:

<GetScriptBlock>

[Microsoft.PowerShell.Cmdletization.GeneratedTypes.SmbShare.ShareState]

($this.PSBase.CimInstanceProperties['ShareState'].Value)

</GetScriptBlock>

There is is also an unsigned PowerShell module that gets flagged a lot compared to the remaining data. You’ll find it in the location:

C:\Windows\System32\WindowsPowerShell\v1.0\Modules\ServerManagerTasks\ServerManagerTasks.psd1

Like the SMBTypes file, this one is also created by Microsoft and doesn’t appear to be a concern.

# Author of this module

Author = 'Microsoft Corporation'

It does not appear to be obfuscated in any way, but is definitely tripping up the detection.

As Defenders, we are not particularly excited by excluding unsigned scripts from the ASR ruleset, even when it’s in a reasonably secure path. We don’t love the possibility for an adversary to easily modify them and potentially stay under our radar.

In addition to the two interesting Microsoft files, we also had alerts for “potential obfuscation” which related to internal development workflows.

Recommendation: Block Mode in a corporate setting, but be careful with developer machines.

Tip: We were not as concerned with the Microsoft files above being blocked as we were in making sure our large developer workforce was not negatively impacted. If you’re in an environment where it is easy to separate developer machines from corporate machines from a group policy perspective, that may be a sensible way to approach this control. You may be able to build detections based on the audit mode events.

Block executable files from running unless they meet a prevalence, age, or trusted list criterion

We realized right away that this ASR control was unlikely to provide value in block mode at Palantir simply because our developers generate new files frequently. We still felt it might assist others to share the data we collected regarding this control:

We generated about 180,000 1122 ASR events of this category every six months.

Roughly 110,000 (60%) of the events relate directly to internal development workflows.

The remaining events were attributed to very common, frequently updated, external packages.

In a practical sense, we’ve accepted that we won’t be able to move past audit mode on this one. This control still provides great value in audit mode, though. We’re able to see, in a very simple query, all of the binaries that Microsoft Defender raises an eyebrow at because of their age and other trust heuristics.

Recommendation: Audit Mode.

Tip: Only the most strictly controlled environments will be able to support this ASR setting in block mode. In addition to developer workflows, the applications we collect audit events for are very common, they’re just frequently updated.

Use advanced protection against ransomware

Here’s how Microsoft describe this control:

This rule provides an extra layer of protection against ransomware. It scans executable files entering the system to determine whether they’re trustworthy. If the files closely resemble ransomware, this rule blocks them from running, unless they’re in a trusted list or an exclusion list.

In the environment we audited, this control was similar to the “block executables unless they meet a prevalence…” control and did catch some developer workflows. We saw ~500 events per six months and all of the events related to internal product development for a team working on a Windows application.

For that reason, it wasn’t a good fit for the whole company to have this ASR rule in enforced mode, but we were able to leverage a separate policy for those that required an exception, and would encourage others to do the same. The key to reducing friction is to monitor for events after enabling the rule and have a process for exceptions.

Recommendation: Block Mode.

Tip: Be careful if you support developer workflows.

Block process creations originating from PSExec and WMI commands

One our “favorite” lateral movement techniques, sometimes leveraged by the SpecterOps adversary simulation team we work with, is to use the “network login” type and WMI/psexec style lateral movement. We say it’s our “favorite” because it’s very challenging to prevent.

We wrote a long post on the topic here, but for the purposes of considering this ASR control consider that:

Network login type will bypass things like “allow logon” rights management via group policy on the client side and can be as simple as “runas /user:contoso\bob-t1 ‘psexec.exe \\tier1server.contoso.com cmd.exe’”

Network login type and psexec will often bypass network inspection devices looking for tier violations.

Modification of the DisableRestrictedAdmin key can be used to disable MFA in many cases and this can be achieved via PSExec/WMI with a single authentication factor.

But most importantly (and sadly):

This ASR rule, which seems perfect, cannot be moved into block mode if you use SCCM in the environment.

The paragraph provided by Microsoft is:

This rule is incompatible with management through Microsoft Endpoint Configuration Manager because this rule blocks WMI commands the Configuration Manager client uses to function correctly.

As expected, this event generates about 1,000,000 events per six months, spread among ~1000 devices. It’s a big volume event when you use SCCM. With careful filtering, we are still able to derive value from the events, though: anything outside of the SCCM use cases stand out.

The recommendation here is to analyze the events that do not relate to SCCM to quickly identify abnormalities that this rule was designed to block.

Recommendation: Audit Mode, especially if you use SCCM or Intune.

Tip: If you use SCCM and event volume is a concern, you may wish to leave this ASR rule unconfigured. If you don’t use SCCM or Intune, start with Audit mode, review the data, and aim to move to Block mode.

Block Office communication applications from creating child processes

In an environment with Microsoft Outlook and Microsoft Teams, we’re tracking about 5000 events per 6 months.

50% of the events are Outlook,

40% is Teams.

The remaining events are linked to the communication apps as expected and originate from processes with integrations.

The events spread is very similar to what we experience with the “Block Win32 API calls from Office macros”; it is mostly attributed to 3rd party commercial integrations used by a small portion of our user base. Half of all the events belong to a single power user, and less than 50 users have logged events of this type.

Recommendation: Audit Mode for users with Office integrations.

Tip: This will be different in most environments. Investigate audit events first and move to block mode if none are registered.

File and path exceptions

Attack Surface Reduction policies can be configured with file and folder exclusions. The process is described here.

There are three important notes you should be aware of:

Exclusions apply to all of your ASR rules, there are not ASR file/folder exclusions per rule.

Exclusions apply to audit events as well.

Block persistence through WMI event subscription is not supported for exclusions.

We didn’t like the idea that the audit only events would also be excluded. We have limited the use of file exclusions relating to ASR.

ASR Audit Mode

It’s important to mention that a lot of value is derived from audit mode events, and while our goal was block mode for everything if possible, we don’t consider remaining in audit mode a strictly negative outcome. Our incident response team have taken the time to understand what “normal” looks like for each of the categories we are not blocking and have been able to derive high fidelity signal from the events.

Deploying ASR in audit mode can be done quickly and relatively safely. The key tip is to remain on the lookout for excessive logging that could contribute to performance problems or increased volume in your logging pipelines.

A note for reviewing audit logs: The way to track and asses an individual ASR rule when searching event logs is via the per rule unique GUID. The GUID for each rule can be found in the Microsoft documentation. For example, to review the “Adobe Reader” rule above we would search for 1121 events containing “7674ba52–37eb-4a4f-a9a1-f0f9a1619a2c”.

Additional Information

Author

Chad D.