Assessing the effectiveness of a new security data source: Windows Defender Exploit Guard

Oct 15, 2019 · 12 min read

Windows Defender Exploit Guard (WDEG) is a suite of preventative and detective controls to identify and mitigate active exploitation attempts against Windows hosts. Based on the previous success of the Enhanced Mitigation Experience Toolkit (EMET), WDEG not only supplies mitigations for a wide array of attacks but acts as an investigative resource by providing context-rich event logs for anomalous events.

Image for post
Image for post

While Palantir’s Computer Incident Response Team (CIRT) relies heavily on security vendor products for endpoint telemetry and detection capabilities, investigation and exploitation of new security-related data sources are foundational to our success. This blog post analyzes Exploit Guard as a new data source for inclusion in Alerting and Detection Strategies (ADS). We will also detail an enterprise configuration and roll-out strategy and provide a sampling of detection hypotheses.

We’ve provided a new GitHub repository with previously unavailable event documentation as supporting documentation for this post. You can find it here:

Introduction to Windows Defender Exploit Guard

Windows Defender Exploit Guard is a series of host-based intrusion prevention and detection capabilities natively present in Windows 10. The capabilities lock down the device against a wide variety of attack vectors and attempt to block behaviors commonly used in malware attacks, without relying on traditional signature based detection.

There are four primary features available in WDEG:

  • Exploit Protection: Mitigations against common exploit techniques. Replaces, supplements, and enhances functionality of EMET.

This blog post will primarily focus on understanding and exploring Exploit Protection and Attack Surface Reduction capabilities of WDEG. Also, while this post is intended to remain solution-agnostic, it is worth noting that all WDEG events are automatically ingested into Microsoft Defender Advanced Threat Protection and have their own unique MiscEvent ActionType which are easily queried using Advanced Hunting queries.

Exploit Protection

Exploit Protection (EP) is the natural successor to EMET and was introduced in Windows 10 v1709. EP provides the following native mitigation capabilities for exploitation attempts:

  • Arbitrary code guard (ACG)

EP policies are configured in an XML file and are distributed via Group Policy Object (GPO) or other means (e.g. InTune) to endpoints. In most cases, the policy file is built on a reference machine using PowerShell and then the configuration is exported and used elsewhere. More information on configuring and deploying EP policies will be covered later in this blog.

Many of the policies are granular and can be applied system-wide, or on a per-process basis. Additionally, many policy options provide an audit mode to log violations without enacting potentially destructive mitigation behavior. This audit functionality can be used to validate deployment of EP policies prior to enforcement, or simply be used as a telemetry source for detection engineers.

Attack Surface Reduction

Attack Surface Reduction (ASR) was introduced in Windows 10 v1709 and leverages WDAV to disrupt commonly-abused attack primitives.

Examples of ASR rules include:

  • Block executable content from email client and webmail

Unlike EP, ASR policies are not XML files and are instead managed via GPO, InTune, or PowerShell and have corresponding GUIDs for each rule. Like EP, many of the ASR rules can be applied in both an enforcement and audit mode. Upon triggering, ASR events are populated in the “Microsoft-Windows-Windows Defender\Operational” log with event IDs 1121 and 1122 in the case of audit and enforcement actions, respectively.

Exploit Protection event documentation

One of the most valuable features of WDEG are the Windows event logs generated when a security feature is triggered. While documentation on configuration and deployment of WDEG is readily accessible, documentation on what events WDEG supports, and the context around them, does not exist. The Palantir CIRT is of the opinion that the value of an event source is realized only upon documenting each field, applying context around the event, and leveraging these as discrete detection capabilities.

WDEG supplies events from multiple event sources (ETW providers) and destinations (event logs). In the documentation that follows, events are organized by their respective event destination. Additionally, many events use the same event template and are grouped accordingly. Microsoft does not currently document these events and context was acquired by utilizing documented ETW methodology, reverse engineering, and with support from security researchers (James Forshaw and Alex Ionescu) generously answering questions on Windows internals.

As part of this blog post, we have open-sourced our Exploit Guard event documentation on our GitHub. You can find the repository here:

Deployment, configuration, and tuning

Now that we have a deep understanding of the available capabilities and event logs provided by WDEG, we can start deployment to our environment. This deployment will start with an initial auditing configuration used to gauge event volume and evaluate the practicality of enabling enforcement mode. After centrally collecting and analyzing event logs, we may then remediate any identified issues and enable enforcement mode. Further violations may be then be treated as potential security incidents and fuel the detection pipeline.

General deployment guidance

Please keep in mind that the deployment of WDEG is very environment-specific and the processes, recommendations, or configurations here need to be tuned to your specific needs, environment, or use cases.

At a high level, our approach focused on the development of a single WDEG baseline configuration. We applied this baseline via Active Directory Group Policy. Our final, stable deployment of the ASR and EP controls occurred via multiple iterations, steadily increasing the level of protection deployed to workstations.

  • Begin with a freshly deployed Windows machine using the standard desktop build for your environment.

Recommended initial configuration settings

Apply exploit-specific settings to the following processes:

  • iexplore.exe

Specifically, consider applying the following mitigations initially in audit mode:

  • Child process creation

Palantir deployment

Initially, the guidance from the Recommended Initial Configuration Settings section of this document was applied to a fresh Palantir Windows image using PowerShell. Our security team monitored applications for a period of four weeks in “audit only” mode using Windows Event Forwarding and a SIEM. Shortly after the monitoring phase, we moved a handful of “canary” systems to enforcement mode with the following system wide protections:

  • DEP

We noticed a handful of application failures on the small number of canary machines and decided to step back the CFG enforcement as a system wide protection. Leaving us with the following system wide protections:

  • DEP

(We will evaluate reintroducing CFG for most applications at a later date.)

We also applied more specific per-application guidance to our most common line of business applications. Our current Configuration Script is available here for reference.

Alerting and detection strategy development

With our new understanding of the available event logs, their context, and limitations, our CIRT engineers can now use this this information when building their alerting and detection strategies. The following is a sampling of hypotheses developed to serve as the basis of potential alerting/threat hunting queries broken down by Exploit Guard mitigation.

Non-Microsoft binary loading

This WDEG mitigation logs any attempt by a Microsoft-signed process to load a non-Microsoft-signed module. In lieu of application whitelisting auditing/enforcement, this could serve as a potentially valuable data source.


System-level. Contrary to some documentation, this mitigation can be applied to all processes. Audit logging that can be applied system-wide are ideal in order to identify and whitelist false positives. Of course, system-wide audit logs come at the cost of event volume, which, in the case of non-MSFT module loads will be large.

Potentially anomalous observations

  • A module that doesn’t load from System32 or a sub-directory within the process executable.

Known false positives

  • Any binary that loads from the Global Assembly Cache (GAC) (e.g. starts with “\Windows\assembly”). These are NGEN’d (i.e. native compiled .NET assemblies built for performance purposes) binaries that while unsigned, originated from signed .NET assemblies (assuming the GAC wasn’t tampered — requires admin). Any .NET process will load these binaries.

False positive reduction strategies

  • Separate out events where the DLL is unsigned (SignatureLevel: 1) and those that are signed (SignatureLevel: 4). While malware can certainly be signed, it is more likely to be unsigned.

Missing event context

  • The hash of the DLL that was logged.

Remote image loading

The remote image loading mitigation logs whenever an image is loaded from a remote share (SMB/WebDAV). It is recommended that this mitigation be logged system-wide.


System-level and process-level. When placing in audit mode, ideally, the system-wide setting be enabled as event volume should be relatively low.

False positive reduction strategies

  • Identify event volume of images loaded from non-Palantir remote resources.

Missing event context

  • Image hash

Font auditing/blocking

Fonts have been used frequently as a means of gaining direct, arbitrary kernel code execution. They have been a widely abused target for exploits due to their complexity, the complexity of the renderer (the Win32K subsystem), and that they have historically been loaded in the kernel. As an exploitation primitive, fonts are most frequently loaded in memory, for which font load events can capture that particular context. Any non-standard font loads should be scrutinized and are expected to be low-volume events.



Potentially anomalous observations

  • Initially all font load events should be inspected in audit mode to validate event volume.

Missing event context

  • Font hash


The most important advice we give teams is that it’s likely that some applications will fail, and they will require rule tuning. This is especially true in environments where software inventory is not well understood, or where end users have the ability to install their own packages. A reasonable period of testing LOB applications is the best way to asses the impact (using the recommended initial configuration from this guide). Very tolerant canary users are invaluable in this phase.

That said, when an application fails due to exploit protection, the first symptom is usually a failure of the application to launch at all. During testing, we observed this behavior in a few applications. Some of the more notable ones were Firefox, the PowerShell ISE and the Box sync client. (The failures were in the period we had CFG enabled as a system wide protection).

Later, when we pushed the policy out to production, we observed a small number if failures at random times after application launch. Having the same policy on our own devices as was applied to end users provided the opportunity to quickly reproduce and observe failures in a few ways:

  • The most obvious indication of Exploit Guard failure is an exploit guard specific log entry, as outlined in this documentation.

Our general ongoing approach is to review the exploit guard events we forward to a SIEM for indicators that new application failures are occurring in the environment and try to correct them before support tickets are ever logged.

All in all, the rate of failures has been surprisingly low so far. Perhaps we are not being aggressive enough in the sense that Exploit Guard has more assertive controls to offer, but we are cautious to balance business needs with security outcomes. We’ll be looking to further tighten our policies over the next six months and plan to reach out to vendors of applications that struggle to support exploit protection.

For now, the protections shown in Github are a reasonably up to date reference of how we have deployed this technology. We hope it will make it easy for you to get your reference system built. The really short and to-the-point version is that we deployed DEP, BottomUp, and SEHOP system-wide, then we went further with logging for our core application set.


Upon documenting, configuring, deploying, and tuning the rich security data source offered by Windows Defender Exploit Guard, we can now form alerting and threat hunting hypotheses that will serve as the basis for the development of robust Alerting and Detection Strategies. Our hope in presenting this post is that you may walk away with an appreciation of the people and process behind improving an enterprise security posture.

It is also important to acknowledge that it isn’t always feasible to blindly trust that a security vendor will expose such optics and/or offer high-quality alerts based on such telemetry. We are firm believers that while endpoint security products play a strong role in a holistic security program, they can never be 100% tailored to suit the unique needs of an enterprise environment. This is why rather than waiting for others to establish methodology around a new technology, we dive in head first to assess the potential value it might offer and we hope that you will do the same!

Further reading


Chad D., Dane S., Matt G.

Palantir Blog

Palantir Blog

Medium is an open platform where 170 million readers come to find insightful and dynamic thinking. Here, expert and undiscovered voices alike dive into the heart of any topic and bring new ideas to the surface. Learn more

Follow the writers, publications, and topics that matter to you, and you’ll see them on your homepage and in your inbox. Explore

If you have a story to tell, knowledge to share, or a perspective to offer — welcome home. It’s easy and free to post your thinking on any topic. Write on Medium

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store