This article helps you understand how exploit protection works, both at the policy level and at the individual mitigation level, to help you successfully build and apply Exploit Protection policies.
How mitigations are applied
Exploit Protection mitigations are applied per application.
Mitigations are configured via a registry entry for each program that you configure protections for. These settings are stored in the MitigationOptions registry entry for each program (HKEY_LOCAL_MACHINE \ SOFTWARE \ Microsoft \ Windows NT \ CurrentVersion \ Image File Execution Options \ ImageFileName \ MitigationOptions). They take effect when you restart the program and remain effective until you change them and restart the program again.
Important
Image File Execution Options only allows you to specify a file name or path, and not a version number, architecture, or any other differentiator. Be careful to target mitigations to apps which have unique names or paths, applying them only on devices where you have tested that version and that architecture of the application.
If you configure exploit protection mitigations using an XML configuration file, either via PowerShell, Group Policy, or MDM, when processing this XML configuration file, individual registry settings will be configured for you.
When the policy distributing the XML file is no longer enforced, settings deployed by this XML configuration file will not be automatically removed. To remove Exploit Protection settings, export the XML configuration from a clean Windows 10 or Windows 11 device, and deploy this new XML file. Alternately, Microsoft provides an XML file as part of the Windows Security Baselines for resetting Exploit Protection settings.
To reset exploit protection settings using PowerShell, you could use the following command:
Set-ProcessMitigation -PolicyFilePath EP-reset.xml
Following is the EP-reset.xml distributed with the Windows Security Baselines:
<?xml version="1.0" encoding="UTF-8"?>
<MitigationPolicy>
<AppConfig Executable="ONEDRIVE.EXE">
<DEP OverrideDEP="false" />
<ASLR OverrideRelocateImages="false" />
<Payload OverrideEnableExportAddressFilter="false" OverrideEnableExportAddressFilterPlus="false" OverrideEnableImportAddressFilter="false" OverrideEnableRopStackPivot="false" OverrideEnableRopCallerCheck="false" OverrideEnableRopSimExec="false" />
<ImageLoad OverrideBlockRemoteImages="false" />
</AppConfig>
<AppConfig Executable="firefox.exe">
<DEP OverrideDEP="false" />
<ASLR ForceRelocateImages="true" />
</AppConfig>
<AppConfig Executable="fltldr.exe">
<DEP OverrideDEP="false" />
<Payload OverrideEnableExportAddressFilter="false" OverrideEnableExportAddressFilterPlus="false" OverrideEnableImportAddressFilter="false" OverrideEnableRopStackPivot="false" OverrideEnableRopCallerCheck="false" OverrideEnableRopSimExec="false" />
<ImageLoad OverrideBlockRemoteImages="false" />
<ChildProcess OverrideChildProcess="false" />
</AppConfig>
<AppConfig Executable="GROOVE.EXE">
<DEP OverrideDEP="false" />
<ASLR ForceRelocateImages="true" />
<Payload OverrideEnableExportAddressFilter="false" OverrideEnableExportAddressFilterPlus="false" OverrideEnableImportAddressFilter="false" OverrideEnableRopStackPivot="false" OverrideEnableRopCallerCheck="false" OverrideEnableRopSimExec="false" />
<ImageLoad OverrideBlockRemoteImages="false" />
<ChildProcess OverrideChildProcess="false" />
</AppConfig>
<AppConfig Executable="Acrobat.exe">
<DEP OverrideDEP="false" />
<ASLR ForceRelocateImages="true" />
<Payload OverrideEnableExportAddressFilter="false" OverrideEnableExportAddressFilterPlus="false" OverrideEnableImportAddressFilter="false" OverrideEnableRopStackPivot="false" OverrideEnableRopCallerCheck="false" OverrideEnableRopSimExec="false" />
</AppConfig>
<AppConfig Executable="AcroRd32.exe">
<DEP OverrideDEP="false" />
<ASLR ForceRelocateImages="true" />
<Payload OverrideEnableExportAddressFilter="false" OverrideEnableExportAddressFilterPlus="false" OverrideEnableImportAddressFilter="false" OverrideEnableRopStackPivot="false" OverrideEnableRopCallerCheck="false" OverrideEnableRopSimExec="false" />
</AppConfig>
<AppConfig Executable="chrome.exe">
<DEP OverrideDEP="false" />
</AppConfig>
<AppConfig Executable="EXCEL.EXE">
<DEP OverrideDEP="false" />
<ASLR ForceRelocateImages="true" />
<Payload OverrideEnableExportAddressFilter="false" OverrideEnableExportAddressFilterPlus="false" OverrideEnableImportAddressFilter="false" OverrideEnableRopStackPivot="false" OverrideEnableRopCallerCheck="false" OverrideEnableRopSimExec="false" />
</AppConfig>
<AppConfig Executable="iexplore.exe">
<DEP OverrideDEP="false" />
<ASLR ForceRelocateImages="true" />
<Payload OverrideEnableExportAddressFilter="false" OverrideEnableExportAddressFilterPlus="false" OverrideEnableImportAddressFilter="false" OverrideEnableRopStackPivot="false" OverrideEnableRopCallerCheck="false" OverrideEnableRopSimExec="false" />
</AppConfig>
<AppConfig Executable="INFOPATH.EXE">
<DEP OverrideDEP="false" />
<ASLR ForceRelocateImages="true" />
<Payload OverrideEnableExportAddressFilter="false" OverrideEnableExportAddressFilterPlus="false" OverrideEnableImportAddressFilter="false" OverrideEnableRopStackPivot="false" OverrideEnableRopCallerCheck="false" OverrideEnableRopSimExec="false" />
</AppConfig>
<AppConfig Executable="java.exe">
<DEP OverrideDEP="false" />
<Payload OverrideEnableExportAddressFilter="false" OverrideEnableExportAddressFilterPlus="false" OverrideEnableImportAddressFilter="false" OverrideEnableRopStackPivot="false" OverrideEnableRopCallerCheck="false" OverrideEnableRopSimExec="false" />
</AppConfig>
<AppConfig Executable="javaw.exe">
<DEP OverrideDEP="false" />
<Payload OverrideEnableExportAddressFilter="false" OverrideEnableExportAddressFilterPlus="false" OverrideEnableImportAddressFilter="false" OverrideEnableRopStackPivot="false" OverrideEnableRopCallerCheck="false" OverrideEnableRopSimExec="false" />
</AppConfig>
<AppConfig Executable="javaws.exe">
<DEP OverrideDEP="false" />
<Payload OverrideEnableExportAddressFilter="false" OverrideEnableExportAddressFilterPlus="false" OverrideEnableImportAddressFilter="false" OverrideEnableRopStackPivot="false" OverrideEnableRopCallerCheck="false" OverrideEnableRopSimExec="false" />
</AppConfig>
<AppConfig Executable="LYNC.EXE">
<DEP OverrideDEP="false" />
<ASLR ForceRelocateImages="true" />
<Payload OverrideEnableExportAddressFilter="false" OverrideEnableExportAddressFilterPlus="false" OverrideEnableImportAddressFilter="false" OverrideEnableRopStackPivot="false" OverrideEnableRopCallerCheck="false" OverrideEnableRopSimExec="false" />
</AppConfig>
<AppConfig Executable="MSACCESS.EXE">
<DEP OverrideDEP="false" />
<ASLR ForceRelocateImages="true" />
<Payload OverrideEnableExportAddressFilter="false" OverrideEnableExportAddressFilterPlus="false" OverrideEnableImportAddressFilter="false" OverrideEnableRopStackPivot="false" OverrideEnableRopCallerCheck="false" OverrideEnableRopSimExec="false" />
</AppConfig>
<AppConfig Executable="MSPUB.EXE">
<DEP OverrideDEP="false" />
<ASLR ForceRelocateImages="true" />
<Payload OverrideEnableExportAddressFilter="false" OverrideEnableExportAddressFilterPlus="false" OverrideEnableImportAddressFilter="false" OverrideEnableRopStackPivot="false" OverrideEnableRopCallerCheck="false" OverrideEnableRopSimExec="false" />
</AppConfig>
<AppConfig Executable="OIS.EXE">
<DEP OverrideDEP="false" />
<Payload OverrideEnableExportAddressFilter="false" OverrideEnableExportAddressFilterPlus="false" OverrideEnableImportAddressFilter="false" OverrideEnableRopStackPivot="false" OverrideEnableRopCallerCheck="false" OverrideEnableRopSimExec="false" />
</AppConfig>
<AppConfig Executable="OUTLOOK.EXE">
<DEP OverrideDEP="false" />
<ASLR ForceRelocateImages="true" />
<Payload OverrideEnableExportAddressFilter="false" OverrideEnableExportAddressFilterPlus="false" OverrideEnableImportAddressFilter="false" OverrideEnableRopStackPivot="false" OverrideEnableRopCallerCheck="false" OverrideEnableRopSimExec="false" />
</AppConfig>
<AppConfig Executable="plugin-container.exe">
<DEP OverrideDEP="false" />
<Payload OverrideEnableExportAddressFilter="false" OverrideEnableExportAddressFilterPlus="false" OverrideEnableImportAddressFilter="false" OverrideEnableRopStackPivot="false" OverrideEnableRopCallerCheck="false" OverrideEnableRopSimExec="false" />
</AppConfig>
<AppConfig Executable="POWERPNT.EXE">
<DEP OverrideDEP="false" />
<ASLR ForceRelocateImages="true" />
<Payload OverrideEnableExportAddressFilter="false" OverrideEnableExportAddressFilterPlus="false" OverrideEnableImportAddressFilter="false" OverrideEnableRopStackPivot="false" OverrideEnableRopCallerCheck="false" OverrideEnableRopSimExec="false" />
</AppConfig>
<AppConfig Executable="PPTVIEW.EXE">
<DEP OverrideDEP="false" />
<ASLR ForceRelocateImages="true" />
<Payload OverrideEnableExportAddressFilter="false" OverrideEnableExportAddressFilterPlus="false" OverrideEnableImportAddressFilter="false" OverrideEnableRopStackPivot="false" OverrideEnableRopCallerCheck="false" OverrideEnableRopSimExec="false" />
</AppConfig>
<AppConfig Executable="VISIO.EXE">
<DEP OverrideDEP="false" />
<ASLR ForceRelocateImages="true" />
<Payload OverrideEnableExportAddressFilter="false" OverrideEnableExportAddressFilterPlus="false" OverrideEnableImportAddressFilter="false" OverrideEnableRopStackPivot="false" OverrideEnableRopCallerCheck="false" OverrideEnableRopSimExec="false" />
</AppConfig>
<AppConfig Executable="VPREVIEW.EXE">
<DEP OverrideDEP="false" />
<ASLR ForceRelocateImages="true" />
<Payload OverrideEnableExportAddressFilter="false" OverrideEnableExportAddressFilterPlus="false" OverrideEnableImportAddressFilter="false" OverrideEnableRopStackPivot="false" OverrideEnableRopCallerCheck="false" OverrideEnableRopSimExec="false" />
</AppConfig>
<AppConfig Executable="WINWORD.EXE">
<DEP OverrideDEP="false" />
<ASLR ForceRelocateImages="true" />
<Payload OverrideEnableExportAddressFilter="false" OverrideEnableExportAddressFilterPlus="false" OverrideEnableImportAddressFilter="false" OverrideEnableRopStackPivot="false" OverrideEnableRopCallerCheck="false" OverrideEnableRopSimExec="false" />
</AppConfig>
<AppConfig Executable="wmplayer.exe">
<DEP OverrideDEP="false" />
<Payload OverrideEnableExportAddressFilter="false" OverrideEnableExportAddressFilterPlus="false" OverrideEnableImportAddressFilter="false" OverrideEnableRopStackPivot="false" OverrideEnableRopCallerCheck="false" OverrideEnableRopSimExec="false" />
</AppConfig>
<AppConfig Executable="wordpad.exe">
<DEP OverrideDEP="false" />
<Payload OverrideEnableExportAddressFilter="false" OverrideEnableExportAddressFilterPlus="false" OverrideEnableImportAddressFilter="false" OverrideEnableRopStackPivot="false" OverrideEnableRopCallerCheck="false" OverrideEnableRopSimExec="false" />
</AppConfig>
</MitigationPolicy>
Mitigation Reference
The following sections detail the protections provided by each exploit protection mitigation, the compatibility considerations for the mitigation, and the configuration options available.
Arbitrary code guard
Description
Arbitrary code guard helps protect against a malicious attacker loading the code of their choice into memory through a memory safety vulnerability and being able to execute that code.
Arbitrary code guard protects an application from executing dynamically generated code (code that is not loaded, for example, from the exe itself or a dll). Arbitrary code guard works by preventing memory from being marked as executable. When an application attempts to allocate memory, we check the protection flags. (Memory can be allocated with read, write, and/or execute protection flags.) If the allocation attempts to include the execute protection flag, then the memory allocation fails and returns an error code (STATUS_DYNAMIC_CODE_BLOCKED). Similarly, if an application attempts to change the protection flags of memory that has already been allocated and includes the execute protection flag, then the permission change fails and returns an error code (STATUS_DYNAMIC_CODE_BLOCKED).
By preventing the execute flag from being set, the data execution prevention feature of Windows 10 and Windows 11 can then protect against the instruction pointer being set to that memory and running that code.
Compatibility considerations
Arbitrary code guard prevents allocating any memory as executable, which presents a compatibility issue with approaches such as Just-in-Time (JIT) compilers. Most modern browsers, for example, will compile JavaScript into native code in order to optimize performance. In order to support this mitigation, they will need to be rearchitected to move the JIT compilation outside of the protected process. Other applications whose design dynamically generates code from scripts or other intermediate languages will be similarly incompatible with this mitigation.
Configuration options
Allow thread opt-out – You can configure the mitigation to allow an individual thread to opt-out of this protection. The developer must have written the application with awareness of this mitigation, and have called the SetThreadInformation API with the ThreadInformation parameter set to ThreadDynamicCodePolicy in order to be allowed to execute dynamic code on this thread.
Audit only – You can enable this mitigation in audit mode in order to measure the potential compatibility impact on an application. Audit events can then be viewed either in the event viewer or using Advanced Hunting in Defender for Endpoint.
Block low integrity images
Description
Block low integrity images prevents the application from loading files that are untrusted, typically because they have been downloaded from the internet from a sandboxed browser.
This mitigation will block image loads if the image has an Access Control Entry (ACE) which grants access to Low IL processes and which does not have a trust label ACE. It is implemented by the memory manager, which blocks the file from being mapped into memory. If an application attempts to map a low integrity image, it will trigger a STATUS_ACCESS_DENIED error. For details on how integrity levels work, see Mandatory Integrity Control.
Compatibility considerations
Block low integrity images will prevent the application from loading files that were downloaded from the internet. If your application workflow requires loading images that are downloaded, you will want to ensure that they are downloaded from a higher-trust process, or are explicitly relabeled in order to apply this mitigation.
Configuration options
Audit Only – You can enable this mitigation in audit mode in order to measure the potential compatibility impact on an application. Audit events can then be viewed either in the event viewer or using Advanced Hunting in Microsoft Defender for Endpoint.
Block remote images
Description
Blocking remote images helps to prevent the application from loading files that are hosted on a remote device, such as a UNC share. Blocking remote images helps protect against loading binaries into memory that are on an external device controlled by the attacker.
This mitigation will block image loads if the image is determined to be on a remote device. It is implemented by the memory manager, which blocks the file from being mapped into memory. If an application attempts to map a remote file, it will trigger a STATUS_ACCESS_DENIED error.
Compatibility considerations
Block remote images will prevent the application from loading images from remote devices. If your application loads files or plug-ins from remote devices, then it will not be compatible with this mitigation.
Configuration options
Audit Only – You can enable this mitigation in audit mode in order to measure the potential compatibility impact on an application. Audit events can then be viewed either in the event viewer or using Advanced Hunting in Microsoft Defender for Endpoint.
Block untrusted fonts
Description
Block untrusted fonts mitigates the risk of a flaw in font parsing leading to the attacker being able to run code on the device. Only fonts that are installed into the windows\fonts directory will be loaded for processing by GDI.
This mitigation is implemented within GDI, which validates the location of the file. If the file is not in the system fonts directory, the font will not be loaded for parsing and that call will fail.
This mitigation is in addition to the built-in mitigation provided in Windows 10 1607 and later, and Windows 11, which moves font parsing out of the kernel and into a user-mode app container. Any exploit based on font parsing, as a result, happens in a sandboxed and isolated context, which reduces the risk significantly. For details on this mitigation, see the blog Hardening Windows 10 with zero-day exploit mitigations.
Compatibility considerations
The most common use of fonts outside of the system fonts directory is with web fonts. Modern browsers, such as Microsoft Edge, use DirectWrite instead of GDI, and are not impacted. However, legacy browsers, such as Internet Explorer 11 (and IE mode in the new Microsoft Edge) can be impacted, particularly with applications such as Office 365, which use font glyphs to display UI.
Configuration options
Audit Only – You can enable this mitigation in audit mode in order to measure the potential compatibility impact on an application. Audit events can then be viewed either in the event viewer or using Advanced Hunting in Microsoft Defender for Endpoint.
Code integrity guard
Description
Code integrity guard ensures that all binaries loaded into a process are digitally signed by Microsoft. Code integrity guard includes WHQL (Windows Hardware Quality Labs) signatures, which will allow WHQL-approved drivers to run within the process.
This mitigation is implemented within the memory manager, which blocks the binary from being mapped into memory. If you attempt to load a binary that is not signed by Microsoft, the memory manger will return the error STATUS_INVALID_IMAGE_HASH. By blocking at the memory manager level, this prevents both binaries loaded by the process and binaries injected into the process.
Compatibility considerations
This mitigation specifically blocks any binary that is not signed by Microsoft. As such, it will be incompatible with most third-party software, unless that software is distributed by (and digitally signed by) the Microsoft Store, and the option to allow loading of images signed by the Microsoft Store is selected.
Configuration options
Also allow loading of images signed by Microsoft Store – Applications that are distributed by the Microsoft Store will be digitally signed by the Microsoft Store, and adding this configuration will allow binaries that have gone through the store certification process to be loaded by the application.
Audit Only – You can enable this mitigation in audit mode in order to measure the potential compatibility impact on an application. Audit events can then be viewed either in the event viewer or using Advanced Hunting in Microsoft Defender for Endpoint.
Control flow guard (CFG)
Description
Control flow guard (CFG) mitigates the risk of attackers using memory corruption vulnerabilities by protecting indirect function calls. For example, an attacker may user a buffer overflow vulnerability to overwrite memory containing a function pointer, and replace that function pointer with a pointer to executable code of their choice (which may also have been injected into the program).
This mitigation is provided by injecting another check at compile time. Before each indirect function call, another instructions are added which verify that the target is a valid call target before it is called. If the target is not a valid call target, then the application is terminated. As such, only applications that are compiled with CFG support can benefit from this mitigation.
The check for a valid target is provided by the Windows kernel. When executable files are loaded, the metadata for indirect call targets is extracted at load time and marked as valid call targets. Additionally, when memory is allocated and marked as executable (such as for generated code), these memory locations are also marked as valid call targets, to support mechanisms such as JIT compilation.
Compatibility considerations
Since applications must be compiled to support CFG, they implicitly declare their compatibility with it. Most applications, therefore, should work with this mitigation enabled. Because these checks are compiled into the binary, the configuration you can apply is merely to disable checks within the Windows kernel. In other words, the mitigation is on by default, but you can configure the Windows kernel to always return “yes” if you later determine that there is a compatibility issue that the application developer did not discover in their testing, which should be rare.
Configuration options
Use strict CFG – In strict mode, all binaries loaded into the process must be compiled for Control Flow Guard (or have no executable code in them – such as resource dlls) in order to be loaded.
Note
Control flow guard has no audit mode. Binaries are compiled with this mitigation enabled.
Data Execution Prevention (DEP)
Description
Data execution prevention (DEP) prevents memory that was not explicitly allocated as executable from being executed. DEP helps protect against an attacker injecting malicious code into the process, such as through a buffer overflow, and then executing that code.
If you attempt to set the instruction pointer to a memory address not marked as executable, the processor will throw an exception (general-protection violation), causing the application to crash.
Compatibility considerations
All x64, ARM, and ARM-64 executables have DEP enabled by default, and it cannot be disabled. Since an application will have never been executed without DEP, compatibility is assumed.
All x86 (32-bit) binaries have DEP enabled by default, but DEP can be disabled per process. Some old legacy applications, typically applications developed prior to Windows XP SP2, might not be compatible with DEP. Such applications typically generate code dynamically (for example, JIT compiling) or link to older libraries (such as older versions of ATL) which dynamically generate code.
Configuration options
Enable ATL Thunk emulation – This configuration option disables ATL Thunk emulation. ATL, the ActiveX Template Library, is designed to be as small and fast as possible. In order to reduce binary size, it would use a technique called thunking. Thunking is typically thought of for interacting between 32-bit and 16-bit applications, but there are no 16-bit components to ATL here. Rather, in order to optimize for binary size, ATL will store machine code in memory that is not word-aligned (creating a smaller binary), and then invoke that code directly. ATL components compiled with Visual Studio 7.1 or earlier (Visual Studio 2003) do not allocate this memory as executable – thunk emulation resolves that compatibility issue. Applications that have a binary extension model (such as Internet Explorer 11) will often need to have ATL Thunk emulation enabled.
Disable extension points
Description
This mitigation disables various extension points for an application, which might be used to establish persistence or elevate privileges of malicious content.
This includes:
- AppInit DLLs – Whenever a process starts, the system will load the specified DLL into to context of the newly started process before calling its entry point function. Details on AppInit DLLs can be found here. With this mitigation applied, AppInit DLLs are not loaded. Beginning with Windows 7, AppInit DLLs need to be digitally signed, as described here. Additionally, beginning with Windows 8, AppInit DLLs will not be loaded if SecureBoot is enabled, as described here.
- Legacy IMEs – An Input Method Editor (IME) allows a user to type text in a language that has more characters than can be represented on a keyboard. Third parties are able to create IMEs. A malicious IME might obtain credentials or other sensitive information from this input capture. Some IMEs, referred to as Legacy IMEs, will only work on Windows Desktop apps, and not UWP apps. This mitigation will also prevent this legacy IME from loading into the specified Windows Desktop app.
- Windows Event Hooks – An application can call the SetWinEventHook API to wp-signup.php interest in an event taking place. A DLL is specified and can be injected into the process. This mitigation forces the hook to be posted to the wp-signup.phping process rather than running in-process through an injected DLL.
Compatibility considerations
Most of these extension points are relatively infrequently used, so compatibility impact is typically small, particularly at an individual application level. The one consideration is if users are using third-party Legacy IMEs that will not work with the protected application.
Configuration options
There are no configuration options for this mitigation.
Note
Disable extension points has no audit mode.
Disable Win32k system calls
Description
Win32k.sys provides a broad attack surface for an attacker. As a kernel-mode component, it is frequently targeted as an escape vector for applications that are sandboxed. This mitigation prevents calls into win32k.sys by blocking a thread from converting itself into a GUI thread, which is then given access to invoke Win32k functions. A thread is non-GUI when created, but converted on first call to win32k.sys, or through an API call to IsGuiThread.
Compatibility considerations
This mitigation is designed for processes that are dedicated non-UI processes. For example, many modern browsers will use process isolation and incorporate non-UI processes. Any application that displays a GUI using a single process will be impacted by this mitigation.
Configuration options
Audit Only – You can enable this mitigation in audit mode in order to measure the potential compatibility impact on an application. Audit events can then be viewed either in the event viewer or using Advanced Hunting in Microsoft Defender for Endpoint.
Do not allow child processes
Description
This mitigation prevents an application from creating new child applications. A common technique used by adversaries is to initiate a trusted process on the device with malicious input (a “living off the land” attack), which often requires launching another application on the device. If there are no legitimate reasons why an application would launch a child process, this mitigation mitigates that potential attack vector. The mitigation is applied by setting a property on the process token, which blocks creating a token for the child process with the error message STATUS_CHILD_PROCESS_BLOCKED.
Compatibility considerations
If your application launches child applications for any reason, such as supporting hyperlinks that launch a browser or an external browser, or which launch other utilities on the computer, this functionality will be broken with this mitigation applied.
Configuration options
Audit Only – You can enable this mitigation in audit mode in order to measure the potential compatibility impact on an application. Audit events can then be viewed either in the event viewer or using Advanced Hunting in Microsoft Defender for Endpoint.
Export address filtering
Description
Export address filtering (EAF) mitigates the risk of malicious code looking at the export address table of all loaded modules to find modules that contain useful APIs for their attack. This is a common tactic used by shellcode. In order to mitigate the risk of such an attack, this mitigation protects three commonly attacked modules:
- ntdll.dll
- kernelbase.dll
- kernel32.dll
The mitigation protects the memory page in the [export directory that points to the export address table. This memory page will have the PAGE_GUARD protection applied to it. When someone tries to access this memory, it will generate a STATUS_GUARD_PAGE_VIOLATION. The mitigation handles this exception, and if the accessing instruction doesn’t pass validation, the process will be terminated.
Compatibility considerations
This mitigation is primarily an issue for applications such as debuggers, sandboxed applications, applications using DRM, or applications that implement anti-debugging technology.
Configuration options
Validate access for modules that are commonly abused by exploits – This option, also known as EAF+, adds protections for other commonly attacked modules:
mshtml.dllflash*.ocxjscript*.ocxvbscript.dllvgx.dllmozjs.dllxul.dllacrord32.dllacrofx32.dllacroform.api
Additionally, by enabling EAF+, this mitigation adds the PAGE_GUARD protection to the page containing the “MZ” header, the first two bytes of the DOS header in a PE file, which is another aspect of known memory content which shellcode can look for to identify modules potentially of interest in memory.
Audit Only – You can enable this mitigation in audit mode in order to measure the potential compatibility impact on an application. Audit events can then be viewed either in the event viewer or using Advanced Hunting in Microsoft Defender for Endpoint.
Force randomization for images (Mandatory ASLR)
Description
Address Space Layout Randomization (ASLR) mitigates the risk of an attacker using their knowledge of the memory layout of the system in order to execute code that is already present in process memory and already marked as executable. This can mitigate the risk of an attacker using techniques such as return-to-libc attacks, where the adversary sets the context and then modifies the return address to execute existing code with context that suits the adversary’s purpose.
Mandatory ASLR forces a rebase of all DLLs within the process. A developer can enable ASLR using the /DYNAMICBASE linker option, and this mitigation has the same effect.
When the memory manager is mapping in the image into the process, Mandatory ASLR will forcibly rebase DLLs and EXEs that have not opted in to ASLR. Note, however, that this rebasing has no entropy, and can therefore be placed at a predictable location in memory. For rebased and randomized location of binaries, this mitigation should be paired with Randomize memory allocations (Bottom-up ASLR).
Compatibility considerations
This compatibility impact of ASLR is typically constrained to older applications that were built using compilers that made assumptions about the base address of a binary file or have stripped out base relocation information. This can lead to unpredictable errors as the execution flow attempts to jump to the expected, rather than the actual, location in memory.
Configuration options
Do not allow stripped images – This option blocks the loading of images that have had relocation information stripped. The Windows PE file format contains absolute addresses, and the compiler also generates a [base relocation table that the loader can use to find all relative memory references and their offset, so they can be updated if the binary does not load at its preferred base address. Some older applications strip out this information in production builds, and therefore these binaries cannot be rebased. This mitigation blocks such binaries from being loaded (instead of allowing them to load at their preferred base address).
Note
Force randomization for images (Mandatory ASLR) has no audit mode.
Import address filtering (IAF)
Description
The import address filtering (IAF) mitigation helps mitigate the risk of an adversary changing the control flow of an application by modifying the import address table (IAT) to redirect to arbitrary code of the attacker’s choice when that function is called. An attacker could use this approach to hijack control, or to intercept, inspect, and potentially block calls to sensitive APIs.
The memory pages for all protected APIs will have the PAGE_GUARD protection applied to them. When someone tries to access this memory, it will generate a STATUS_GUARD_PAGE_VIOLATION. The mitigation handles this exception, and if the accessing instruction doesn’t pass validation, the process will be terminated.
This mitigation protects the following Windows APIs:
GetProcAddressGetProcAddressForCallerLoadLibraryALoadLibraryExALoadLibraryWLoadLibraryExWLdrGetProcedureAddressLdrGetProcedureAddressExLdrGetProcedureAddressForCallerLdrLoadDllVirtualProtectVirtualProtectExVirtualAllocVirtualAllocExNtAllocateVirtualMemoryNtProtectVirtualMemoryCreateProcessACreateProcessWWinExecCreateProcessAsUserACreateProcessAsUserWGetModuleHandleAGetModuleHandleWRtlDecodePointerDecodePointer
Compatibility considerations
Legitimate applications that perform API interception may be detected by this mitigation and cause some applications to crash. Examples include security software and application compatibility shims.
Configuration options
Audit Only – You can enable this mitigation in audit mode in order to measure the potential compatibility impact on an application. Audit events can then be viewed either in the event viewer or using Advanced Hunting in Microsoft Defender for Endpoint.
Randomize memory allocations (Bottom-up ASLR)
Description
Randomize memory allocations (Bottom-up ASLR) adds entropy to relocations, so their location is randomized and therefore less predictable. This mitigation requires Mandatory ASLR to take effect.
The size of the 32-bit address space places practical constraints on the entropy that can be added, and therefore 64-bit applications make it more difficult for an attacker to guess a location in memory.
Compatibility considerations
Most applications that are compatible with Mandatory ASLR (rebasing) are also compatible with the other entropy of Bottom-up ASLR. Some applications may have pointer-truncation issues if they are saving local pointers in 32-bit variables (expecting a base address below 4 GB), and thus will be incompatible with the high entropy option (which can be disabled).
Configuration options
Don’t use high entropy – this option disables the use of high-entropy ASLR, which adds 24 bits of entropy (1 TB of variance) into the bottom-up allocation for 64-bit applications.
Note
Randomize memory allocations (Bottom-up ASLR) has no audit mode.
Simulate execution (SimExec)
Description
Simulate execution (SimExec) is a mitigation for 32-bit applications only. This helps validate that calls to sensitive APIs will return to legitimate caller functions. It does this by intercepting calls into sensitive APIs, and then simulating the execution of those APIs by walking through the encoded assembly language instructions looking for the RET instruction, which should return to the caller. It then inspects that function and walks backwards in memory to find the preceding CALL instruction to determine whether the function and CALL instruction match, and that the RET hasn’t been intercepted.
The APIs intercepted by this mitigation are:
LoadLibraryALoadLibraryWLoadLibraryExALoadLibraryExWLdrLoadDllVirtualAllocVirtualAllocExNtAllocateVirtualMemoryVirtualProtectVirtualProtectExNtProtectVirtualMemoryHeapCreateRtlCreateHeapCreateProcessACreateProcessWCreateProcessInternalACreateProcessInternalWNtCreateUserProcessNtCreateProcessNtCreateProcessExCreateRemoteThreadCreateRemoteThreadExNtCreateThreadExWriteProcessMemoryNtWriteVirtualMemoryWinExecCreateFileMappingACreateFileMappingWCreateFileMappingNumaWNtCreateSectionMapViewOfFileMapViewOfFileExMapViewOfFileFromAppLdrGetProcedureAddressForCaller
If a ROP gadget is detected, the process is terminated.
Compatibility considerations
Applications that perform API interception, particularly security software, can cause compatibility problems with this mitigation.
This mitigation is incompatible with the Arbitrary Code Guard mitigation.
Configuration options
Audit Only – You can enable this mitigation in audit mode in order to measure the potential compatibility impact on an application. Audit events can then be viewed either in the event viewer or using Advanced Hunting in Microsoft Defender for Endpoint.
Validate API invocation (CallerCheck)
Description
Validate API invocation (CallerCheck) is a mitigation for return-oriented programming (ROP) techniques that validates that sensitive APIs were called from a valid caller. This mitigation inspects the passed return address, and then heuristically disassembles backwards to find a call above the return address to determine if the call target matches the parameter passed into the function.
The APIs intercepted by this mitigation are:
LoadLibraryALoadLibraryWLoadLibraryExALoadLibraryExWLdrLoadDllVirtualAllocVirtualAllocExNtAllocateVirtualMemoryVirtualProtectVirtualProtectExNtProtectVirtualMemoryHeapCreateRtlCreateHeapCreateProcessACreateProcessWCreateProcessInternalACreateProcessInternalWNtCreateUserProcessNtCreateProcessNtCreateProcessExCreateRemoteThreadCreateRemoteThreadExNtCreateThreadExWriteProcessMemoryNtWriteVirtualMemoryWinExecCreateFileMappingACreateFileMappingWCreateFileMappingNumaWNtCreateSectionMapViewOfFileMapViewOfFileExMapViewOfFileFromAppLdrGetProcedureAddressForCaller
If a ROP gadget is detected, the process is terminated.
Compatibility considerations
Applications that perform API interception, particularly security software, can cause compatibility problems with this mitigation.
This mitigation is incompatible with the Arbitrary Code Guard mitigation.
Configuration options
Audit Only – You can enable this mitigation in audit mode in order to measure the potential compatibility impact on an application. Audit events can then be viewed either in the event viewer or using Advanced Hunting in Microsoft Defender for Endpoint.
Validate exception chains (SEHOP)
Description
Validate exception chains (SEHOP) is a mitigation against the Structured Exception Handler (SEH) overwrite exploitation technique. Structured exception handling is the process by which an application can ask to handle a particular exception. Exception handlers are chained together, so that if one exception handler chooses not to handle a particular exception, it can be passed on to the next exception handler in the chain until one decides to handle it. Because the list of handler is dynamic, it is stored on the stack. An attacker can use a stack overflow vulnerability to then overwrite the exception handler with a pointer to the code of the attacker’s choice.
This mitigation relies on the design of SEH, where each SEH entry contains both a pointer to the exception handler, as well as a pointer to the next handler in the exception chain. This mitigation is called by the exception dispatcher, which validates the SEH chain when an exception is invoked. It verifies that:
- All exception chain records are within the stack boundaries
- All exception records are aligned
- No exception handler pointers are pointing to the stack
- There are no backward pointers
- The exception chain ends at a known final exception handler
If these validations fail, then exception handling is aborted, and the exception will not be handled.
Compatibility considerations
Compatibility issues with SEHOP are relatively rare. It’s uncommon for an application to take a dependency on corrupting the exception chain. However, some applications are impacted by the subtle changes in timing, which may manifest as a race condition that reveals a latent multi-threading bug in the application.
Configuration options
Note
Validate exception chains (SEHOP) has no audit mode.
Validate handle usage
Description
Validate handle usage is a mitigation that helps protect against an attacker using an existing handle to access a protected object. A handle is a reference to a protected object. If application code is referencing an invalid handle, that could indicate that an adversary is attempting to use a handle it has previously recorded (but which application reference counting wouldn’t be aware of). If the application attempts to use an invalid object, instead of simply returning null, the application will raise an exception (STATUS_INVALID_HANDLE).
This mitigation is automatically applied to Windows Store applications.
Compatibility considerations
Applications that were not accurately tracking handle references, and which were not wrapping these operations in exception handlers, will potentially be impacted by this mitigation.
Configuration options
Note
Validate handle usage has no audit mode.
Validate heap integrity
Description
The validate heap integrity mitigation increases the protection level of heap mitigations in Windows, by causing the application to terminate if a heap corruption is detected. The mitigations include:
- Preventing a HEAP handle from being freed
- Performing another validation on extended block headers for heap allocations
- Verifying that heap allocations are not already flagged as in-use
- Adding guard pages to large allocations, heap segments, and subsegments above a minimum size
Compatibility considerations
This mitigation is already applied by default for 64-bit applications and for 32-bit applications targeting Windows Vista or later. Legacy applications from Windows XP or earlier are most at-risk, though compatibility issues are rare.
Configuration options
Note
Validate heap integrity has no audit mode.
Validate image dependency integrity
Description
The validate image dependency mitigation helps protect against attacks that attempt to substitute code for dlls that are statically linked by Windows binaries. The technique of DLL planting abuses the loader’s search mechanism to inject malicious code, which can be used to get malicious code running in an elevated context. When the loader is loading a Windows signed binary, and then loads up any dlls that the binary depends on, these binaries will be verified to ensure that they are also digitally signed as a Windows binary. If they fail the signature check, the dll will not be loaded, and will throw an exception, returning a status of STATUS_INVALID_IMAGE_HASH.
Compatibility considerations
Compatibility issues are uncommon. Applications that depend on replacing Windows binaries with local private versions will be impacted, and there is also a small risk of revealing subtle timing bugs in multi-threaded applications.
Configuration options
Audit Only – You can enable this mitigation in audit mode in order to measure the potential compatibility impact on an application. Audit events can then be viewed either in the event viewer or using Advanced Hunting in Microsoft Defender for Endpoint.
Validate stack integrity (StackPivot)
Description
The validate stack integrity (StackPivot) mitigation helps protect against the Stack Pivot attack, a ROP attack where an attacker creates a fake stack in heap memory, and then tricks the application into returning into the fake stack that controls the flow of execution.
This mitigation intercepts many Windows APIs, and inspects the value of the stack pointer. If the address of the stack pointer does not fall between the bottom and the top of the stack, then an event is recorded and, if not in audit mode, the process will be terminated.
The APIs intercepted by this mitigation are:
LoadLibraryALoadLibraryWLoadLibraryExALoadLibraryExWLdrLoadDllVirtualAllocVirtualAllocExNtAllocateVirtualMemoryVirtualProtectVirtualProtectExNtProtectVirtualMemoryHeapCreateRtlCreateHeapCreateProcessACreateProcessWCreateProcessInternalACreateProcessInternalWNtCreateUserProcessNtCreateProcessNtCreateProcessExCreateRemoteThreadCreateRemoteThreadExNtCreateThreadExWriteProcessMemoryNtWriteVirtualMemoryWinExecCreateFileMappingACreateFileMappingWCreateFileMappingNumaWNtCreateSectionMapViewOfFileMapViewOfFileExMapViewOfFileFromAppLdrGetProcedureAddressForCaller
Compatibility considerations
Applications that are using fake stacks will be impacted, and there is also a small risk of revealing subtle timing bugs in multi-threaded applications. Applications that perform API interception, particularly security software, can cause compatibility problems with this mitigation.
This mitigation is incompatible with the Arbitrary Code Guard mitigation.
Configuration options
Audit Only – You can enable this mitigation in audit mode in order to measure the potential compatibility impact on an application. Audit events can then be viewed either in the event viewer or using Advanced Hunting in Microsoft Defender for Endpoint.