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.||On||System & app|
|Data Execution Prevention (DEP)||This mitigation prevents code from being run from data-only memory pages.||On||System & app|
|Force randomization for images (Mandatory ASLR)||This mitigation forcibly relocates images not compiled with /DYNAMICBASE.||Off||System & app|
|Randomize memory allocations (Bottom-Up ASLR)||This mitigation randomizes locations for virtual memory allocations.||On||System & app|
|Validate exception chains (SEHOP)||This mitigation ensures the integrity of an exception chain during exception dispatch.||On||System & app|
|Validate heap integrity||This mitigation terminates a process when heap corruption is detected.||On||System & app|
|Arbitrary code guard (ACG)||This mitigation prevents the introduction of non-image-backed executable code and prevents code pages from being modified.||N/a||App|
|Block low integrity images||This mitigation prevents the loading of images marked with Low Integrity.||N/a||App|
|Block remote images||This mitigation prevents loading of images from remote devices.||N/a||App|
|Block untrusted fonts||This mitigation prevents loading any GDI-based fonts not installed in the system fonts directory, notably fonts from the web.||N/a||App|
|Code integrity guard||This mitigation restricts loading of images signed by Microsoft, WHQL, or higher.||N/a||App|
|Disable extension points||This mitigation disables various extensibility mechanisms that allow DLL injection into all processes.||N/a||App|
|Disable Win32k system calls||This mitigation prevents an app from using the Win32k system call table.||N/a||App|
|Don’t allow child processes||This mitigation prevents an app from creating child processes.||N/a||App|
|Export address filtering (EAF)||This mitigation detects dangerous operations being resolved by malicious code.||N/a||App|
|Import address filtering (IAF)||This mitigation detects dangerous operations being resolved by malicious code.||N/a||App|
|Simulate execution (SimExec)||This mitigation ensures that calls to sensitive APIs return to legitimate callers.||N/a||App|
|Validate API invocation (CallerCheck)||This mitigation ensures that sensitive APIs are invoked by legitimate callers.||N/a||App|
|Validate handle usage||This mitigation causes an exception to be raised on any invalid handle references.||N/a||App|
|Validate image dependency integrity||This mitigation enforces code signing for Windows image dependency loading.||N/a||App|
|Validate stack integrity (StackPivot)||This mitigation ensures that the stack hasn’t been redirected for sensitive APIs.||N/a||App|
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.
- Open the Microsoft Endpoint Manager admin center portal navigate to Endpoint security > Attack surface reduction to open the Endpoint security | Attack surface reduction blade
- On the Endpoint security | Attack surface reduction blade, click Create Profile to open the Create profile wizard
- 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
- 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
- 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
- On the Scope tags page, configure the applicable scopes for the profile and click Next
- On the Assignments page, configure the assignment for the profile and click Next
- 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.
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”
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.
Not sure what statement you’re referring to. The features that were part of Exploit Guard are still an important part of the exploit protection configurations.
Any idea why ï gGet-ProcessMitigation results in error “requested registry access not allowed” when applying the policies from Configmgr
What are your permissions on that device?