Working with Exploit Protection to protect devices from being exploited

This week is all about Exploit Protection. An often overlooked security feature that is available in the Windows Security app, screaming for more awareness. Exploit Protection was originally introduced as one of the four main components of Windows Defender Exploit Guard (Exploit Guard). Exploit Guard itself was introduced as a major update to Microsoft Defender Antivirus, in Windows 10 version 1709, and was the successor of Enhance Mitigation Experience Toolkit (EMET). Actually, the Exploit Protection component contains the actual replacement functionality of EMET, and more. Nowadays Exploit Protection is part of the App & browser control section in the Windows Security app, but many configuration paths still refer to Exploit Guard. In this post I’ll start with an introduction about Exploit protection, followed with the steps to configure Exploit Protection by using Microsoft Intune. I’ll end this post by verifying the configuration.

Note: Exploit Protection is no longer part of the MDM security baseline, starting with the version of December 2020. An additional reason for some awareness.

Introduction to Exploit Protection

Exploit Protection adds an additional layer of malware protection, by automatically applying a number of exploit mitigation techniques to either the Operating System (OS) or to an individual app. Those exploit mitigation techniques help with protecting devices from malware that uses exploits to spread and infect other devices. That behavior might sound familiar, as Exploit Protection includes many of the features that were previously part of EMET, and more. When a mitigation is encountered on a device, a notification will be displayed in Action Center and, when using Exploit Protection together with Defender for Endpoint, there will also be detailed reporting into the different mitigation events and blocks.

Note: Keep in mind that EMET reached end of support already on July 31, 2018 and should no longer be used. The reference to EMET is simply made as it was an often used tool for exploit mitigation and the techniques might sound familiar. However, it’s still possible to convert and import existing EMET configuration profiles into Exploit Protection.

There are currently over 20 exploit mitigations, from blocking remote images to blocking untrusted fonts. Those different mitigations can be set to on, off, or their default value. Some of those mitigations have additional configuration options that can only be configured via PowerShell. The table below provides a quick overview of the currently available exploit mitigations, with a short description, the default value and the level that it can be applied to.

Control flow guard (CFG)This mitigation ensures control flow integrity for indirect calls. OnSystem & app
Data Execution Prevention (DEP)This mitigation prevents code from being run from data-only memory pages.OnSystem & app
Force randomization for images (Mandatory ASLR)This mitigation forcibly relocates images not compiled with /DYNAMICBASE.OffSystem & app
Randomize memory allocations (Bottom-Up ASLR)This mitigation randomizes locations for virtual memory allocations. OnSystem & app
Validate exception chains (SEHOP)This mitigation ensures the integrity of an exception chain during exception dispatch. OnSystem & app
Validate heap integrityThis mitigation terminates a process when heap corruption is detected.OnSystem & app
Arbitrary code guard (ACG)This mitigation prevents the introduction of non-image-backed executable code and prevents code pages from being modified. N/aApp
Block low integrity imagesThis mitigation prevents the loading of images marked with Low Integrity.N/a App
Block remote imagesThis mitigation prevents loading of images from remote devices.N/aApp
Block untrusted fontsThis mitigation prevents loading any GDI-based fonts not installed in the system fonts directory, notably fonts from the web.N/aApp
Code integrity guardThis mitigation restricts loading of images signed by Microsoft, WHQL, or higher.N/aApp
Disable extension pointsThis mitigation disables various extensibility mechanisms that allow DLL injection into all processes.N/aApp
Disable Win32k system callsThis mitigation prevents an app from using the Win32k system call table.N/aApp
Don’t allow child processesThis mitigation prevents an app from creating child processes.N/aApp
Export address filtering (EAF)This mitigation detects dangerous operations being resolved by malicious code. N/aApp
Import address filtering (IAF)This mitigation detects dangerous operations being resolved by malicious code.N/aApp
Simulate execution (SimExec)This mitigation ensures that calls to sensitive APIs return to legitimate callers. N/aApp
Validate API invocation (CallerCheck)This mitigation ensures that sensitive APIs are invoked by legitimate callers. N/aApp
Validate handle usageThis mitigation causes an exception to be raised on any invalid handle references.N/aApp
Validate image dependency integrityThis mitigation enforces code signing for Windows image dependency loading.N/aApp
Validate stack integrity (StackPivot)This mitigation ensures that the stack hasn’t been redirected for sensitive APIs. N/aApp

Note: The default value represents the Use default configuration in Exploit Protection and indicates the recommended setting for home users. IT administrators should always consider the required protection for their organizational needs.

Configuration of Exploit Protection

The configuration of Exploit Protection, via Microsoft Intune, can be achieved by performing three actions. The first action is to manually configure the required configuration, on a specific device that represents the default setup and configuration. The second action is exporting that manually created configuration and the third action is distributing that exported configuration by using Microsoft Intune.

Let’s start with the first two actions. Open the Windows Security app and navigate to App & browser control > Exploit protection settings. In the Exploit protection settings section, configure the different exploit mitigations (as described in the table above) in the System settings section (to configure the required system-wide settings) and the App settings section (to configure the app specific required settings and overrides) and click Export settings to export the required configured settings. That export provides an XML-file that can be used in Microsoft Intune.

The third and last action is to actually distribute the created XML-file by using Microsoft Intune. There are multiple profile types available that can be used for this purpose, but the most obvious profile to use is in the Endpoint security node. That’s the location for all the security features nowadays and that contains the Endpoint protection profile. The following nine steps walk through the process of distributing the XML-file.

  1. Open the Microsoft Endpoint Manager admin center portal navigate to Endpoint security  > Attack surface reduction to open the Endpoint security | Attack surface reduction blade
  2. On the Endpoint security | Attack surface reduction blade, click Create Profile to open the Create profile wizard
  3. On the Create a profile page, provide the following information and click Create to open the Create profile wizard
  • Platform: Select Windows 10 and later as value
  • Profile: Select Endpoint protection as value
  1. On the Basics page, provide the following information for the profile and click Next
  • Name: Provide a valid name for the profile to distinguish it from other similar profiles
  • Description: (Optional) Provide a valid description for the profile to further differentiate profiles
  • Platform: (Pre-selected) Windows 10 and later
  1. On the Configuration settings page, configure the following information and click Next
  • Upload XML: Select the exported XML-file (as shown in figure 1) as the value
  • Block users from editing the Exploit Guard protection interface: Select Yes when users should not be able to edit the Exploit Protection settings by using the Windows Security app
  1. On the Scope tags page, configure the applicable scopes for the profile and click Next
  2. On the Assignments page, configure the assignment for the profile and click Next
  3. On the Review + create page, verify the configuration and click Create

Verify the Exploit Protection configuration

After applying the Export Protection configuration, it’s always good to know how to verify the applied configuration. The easiest method to verify a successful configuration, is by using the Block users from editing the Exploit Guard protection interface setting (as mentioned in step 6 above). That configuration will make the applied configuration grayed out and show the message that This setting is managed by your administrator. That, however, is not always the best configuration, as sometimes more flexibility is required. So, besides that configuration it’s always good to know how to further verify that the configuration is applied on the system. That can be achieved by using the PowerShell cmdlet Get-ProcessMitigation, as also described in the Exploit Protection – Microsoft Defender Testground. That PowerShell cmdlet will provide an overview of the applied configuration for the different running processes on the device. That configuration can be related to what’s seen in the Windows Security app (as shown below in Figure 2). It’s possible for an app to have a different configuration when there are overrides configured for that app in the Program settings.

Besides the Windows experience and the Microsoft Endpoint Manager admin center UI, it’s always good to know what the actual setting is that’s being configured. When configuring Exploit Protection, via Microsoft Intune, the OMA-URI ./Device/Vendor/MSFT/Policy/Config/ExploitGuard/ExploitProtectionSettings is used for the configuration and that’s an ADMX-backed setting. That ADMX-backed setting uses the setting ExploitProtection_Name that is coming from ExploitGuard.admx. That setting configures the ExploitProtectionSettings value in the HKLM\Software\Policies\Microsoft\Windows Defender ExploitGuard\Exploit Protection registry key. Together that provides some more locations to look for a successful configuration and a bit more feeling with the actual configuration.

More information

For more information about (configuring) exploit protection, refer to the following docs.

4 thoughts on “Working with Exploit Protection to protect devices from being exploited”

  1. As always great write up , I see everyone is saying the Exploit Guard is no longer needed as Microsoft does not recommend using it , so confused on way forward.

  2. Any idea why ï gGet-ProcessMitigation results in error “requested registry access not allowed” when applying the policies from Configmgr


Leave a Comment

This site uses Akismet to reduce spam. Learn how your comment data is processed.