The keystone to good security hygiene is limiting your attack surface. Attack surface reduction is a technique to remove or constrain exploitable behaviors in your systems. In this blog, we discuss the two attack surface reduction rules introduced in the most recent release of Windows and cover suggested deployment methods and best practices.
Software applications may use known, insecure methods, or methods later identified as useful for malware exploits. For example, macros are an old and powerful tool for task automation. However, macros can spawn child processes, invoke the Windows API, and perform other tasks which render them exploitable by malware.
Windows Defender Advanced Threat Protection (Windows Defender ATP) enables you to take advantage of attack surface reduction rules that allow you to control exploitable threat vectors in a simple and customizable manner. In previous releases of Windows we launched rules that let customers disallow remote process creation through WMI or PSExec and block Office applications from creating executable content. Other rules include the ability to disable scripts from creating executable content or blocking file executions unless age and prevalence criteria are met.
The latest attack surface reduction rules in Windows Defender ATP in latest re based on system and application vulnerabilities uncovered by Microsoft and other security companies. Below we describe that these rules do. More importantly, we outline recommendations for deploying these rules in enterprise environments.
Block Office communication apps from creating child processes
The Block Office Communication Applications from Creating Child Processes rule protects against attacks that attempt to abuse the Outlook email client. For example, in late 2017 Sensepost demonstrated the DDEAUTO attack, which was later discovered to be applicable to Outlook as well. In this case, this attack surface reduction rule disables the creation of another process from Outlook – this means that DDE still works and data can be exchanged by two running applications, but new processes cannot be created. It is important to note that DDE, and DDEAUTO, are legacy, inter-process communication features available since 1987. Many line-of-business applications rely on this capability. If, for example, DDE is not used in your organization, or if you want to restrict the capability of DDE to already running processes, this can be configured by using the AllowDDE registry key for Office.
While rare, if your organization’s applications utilize creating child processes from within Office communication applications, this attack surface reduction rule provides protection by allowing legitimate processes with exclusions. By limiting child processes that can be launched by Outlook to only processes with well-defined functionality, this attack surface reduction rule confines a potential exploit or a social engineering threat from further infecting or compromising the system.
Block Adobe Reader from creating child processes
The second rule we’ve introduced, Block Adobe Reader from Creating Child Processes limits the ability of a threat in a malicious PDF file from launching additional payloads, either embedded in a PDF file or downloaded by a threat, irrespective of how the malicious code in the PDF gained code execution – either by social engineering or by exploiting an unknown vulnerability.
While there may be legitimate business reasons for a business PDF file to create a child process through scripting, this is a behavior that should be discouraged as it is prone to misuse. Our data indicates few legitimate applications utilize this technique. The Block Adobe Reader from Creating Child Processes rule disables child process creation in PDF content except for those files excluded by the IT administrator.
Recommendations on exclusions and deployment
Attack surface reduction rules close frequently used and exploitable behaviors in the operating system and in apps. However, legitimate line-of-business and commercial applications have been written utilizing these same behaviors. To enable non-malicious applications critical to your business, exclusions can be used if they are flagged as violating an attack surface reduction rule. Core Microsoft components, such as operating system files or Office applications, reside in a global exclusion list maintained as part of Defender. These do not need exclusions.
Exclusions, when applied, are honored by other Windows Defender ATP exploit mitigation features including Controlled folder access and Network protection, in addition to attack surface reduction rules. This simplifies exclusion management and standardizes application behavior.
Attack surface reduction rules have three settings: off, audit, and block. Our recommended practice to deploy attack surface reduction rules is to first implement the rule in audit mode.
Audit mode will identify exploitable behavior use but will not block the behavior. With audit, if you have a line of business application utilizing a behavior that is exploitable, the invoking application can be identified, and an exclusion added.
Rules can be enabled in audit with Group Policy, SCCM, or PowerShell. You can review the audited events with Advanced hunting and Alert investigation in Windows Defender Security Center; by creating a custom view in Windows Event Viewer; or using automated log aggregation tools like SIEM.
When audit telemetry reveals that line-of-business applications are no longer being impacted by the attack surface reduction rule, the attack surface reduction rule setting can be switched to block. This will protect against malware exploitation of the behavior.
For larger enterprises, Microsoft recommends deploying attack surface reduction rules in “rings”. Rings are groups of machines radiating outward like non-overlapping tree rings. When the inner ring is successfully deployed with required exclusions, the next ring can be deployed. One of the ways you can create a ring process is by creating specific groups of users or devices in Intune or with a Group Policy management tool.
Monitor attack surface reduction event telemetry
Once a rule is deployed in block mode, it is important to monitor corresponding event telemetry. This data contains important information. For example, an application update may now require an exclusion or multiple alerts from a user clicking on email executable attachments can indicate additional training is required. Attack surface reduction rule events may be from a single, random malware breach, or your organization may be the object of a new, persistent attack attempting to utilize a vector covered by attack surface reduction rules suddenly producing a large increase in related attack surface reduction-rule block events.
Where to get more information and support
If you haven’t deployed any attack surface reduction rules, take a look at our documentation and discover how you can better protect your enterprise.
Minimizing your attack surface can yield large paybacks in decreased threat vulnerability and in allowing the security operations team to focus on other threat vectors.
As with all security features, enable attack surface reduction rules in a methodical, controlled manner that allows legitimate business applications to be excluded from analysis.
Peter Thayer and Iaan D’Souza-Wiltshire (@IaanMSFT)
Windows Defender ATP
Talk to us
Questions, concerns, or insights on this story? Join discussions at the Microsoft community and Windows Defender Security Intelligence.
Follow us on Twitter @WDSecurity and Facebook Windows Defender Security Intelligence.
