Edit

Share via

Exploit protection reference

  • Article

Applies to:

Want to experience Microsoft Defender for Endpoint? Sign up for a free trial.

Exploit protection provides advanced protections for applications that enterprise admins and IT pros can apply after a developer has compiled and distributed software.

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 by using PowerShell, Group Policy, or MDM, when processing this XML configuration file, individual registry settings are configured for you.

When the policy distributing the XML file is no longer enforced, settings deployed by this XML configuration file won't 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, 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 isn't 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, compile JavaScript into native code in order to optimize performance. In order to support this mitigation, they'll 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 are 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've been downloaded from the internet from a sandboxed browser.

This mitigation blocks image loads if the image has an Access Control Entry (ACE) which grants access to Low IL processes and which doesn't have a trust label ACE. It's 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 triggers a STATUS_ACCESS_DENIED error. For details on how integrity levels work, see Mandatory Integrity Control.

Compatibility considerations

Block low integrity images prevent the application from loading files that were downloaded from the internet. If your application workflow requires loading images that are downloaded, you'll want to ensure that they're 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 blocks image loads if the image is determined to be on a remote device. It's implemented by the memory manager, which blocks the file from being mapped into memory. If an application attempts to map a remote file, it triggers a STATUS_ACCESS_DENIED error.

Compatibility considerations

Block remote images 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 isn't in the system fonts directory, the font won't 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 aren't 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 allows 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 isn't signed by Microsoft, the memory manger returns 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 isn't signed by Microsoft. As such, it is 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 are digitally signed by the Microsoft Store, and adding this configuration allows 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 use 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's called. If the target isn't 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's a compatibility issue that the application developer didn't 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 wasn't 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 throws 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 can't be disabled. Since an application has 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 stores machine code in memory that isn't 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) don't 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 loads 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 aren't loaded. Beginning with Windows 7, AppInit DLLs need to be digitally signed, as described here. Additionally, beginning with Windows 8, AppInit DLLs won't 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, only work on Windows Desktop apps, and not UWP apps. This mitigation also prevents this legacy IME from loading into the specified Windows Desktop app.
  • Windows Event Hooks - An application can call the SetWinEventHook API to register 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 registering 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 won't 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's 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 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.

Don't 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 generates a STATUS_GUARD_PAGE_VIOLATION. The mitigation handles this exception, and if the accessing instruction doesn't pass validation, the process is 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.dll
  • flash*.ocx
  • jscript*.ocx
  • vbscript.dll
  • vgx.dll
  • mozjs.dll
  • xul.dll
  • acrord32.dll
  • acrofx32.dll
  • acroform.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 haven't 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 doesn't load at its preferred base address. Some older applications strip out this information in production builds, and therefore these binaries can't 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.

Hardware-enforced stack protection

Description

Hardware-enforced stack protection offers robust protection against ROP exploits since it maintains a record of the intended execution flow of a program. To ensure smooth ecosystem adoption and application compatibility, Windows will offer this protection as an opt-in model, so developers can receive this protection, at your own pace.

Compatibility considerations

Hardware-enforced stack protection will only work on chipsets with support for hardware shadow stacks, Intel's Control-flow Enforcement Technology (CET) or AMD shadow stacks.

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 Defender for Endpoint.

Enforce for all modules instead of Compatible modules - You can enable this mitigation to Enforce for all modules instead of Compatible modules.

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 have the PAGE_GUARD protection applied to them. When someone tries to access this memory, it generates a STATUS_GUARD_PAGE_VIOLATION. The mitigation handles this exception, and if the accessing instruction doesn't pass validation, the process is terminated.

This mitigation protects the following Windows APIs:

  • GetProcAddress
  • GetProcAddressForCaller
  • LoadLibraryA
  • LoadLibraryExA
  • LoadLibraryW
  • LoadLibraryExW
  • LdrGetProcedureAddress
  • LdrGetProcedureAddressEx
  • LdrGetProcedureAddressForCaller
  • LdrLoadDll
  • VirtualProtect
  • VirtualProtectEx
  • VirtualAlloc
  • VirtualAllocEx
  • NtAllocateVirtualMemory
  • NtProtectVirtualMemory
  • CreateProcessA
  • CreateProcessW
  • WinExec
  • CreateProcessAsUserA
  • CreateProcessAsUserW
  • GetModuleHandleA
  • GetModuleHandleW
  • RtlDecodePointer
  • DecodePointer

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're 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:

  • LoadLibraryA
  • LoadLibraryW
  • LoadLibraryExA
  • LoadLibraryExW
  • LdrLoadDll
  • VirtualAlloc
  • VirtualAllocEx
  • NtAllocateVirtualMemory
  • VirtualProtect
  • VirtualProtectEx
  • NtProtectVirtualMemory
  • HeapCreate
  • RtlCreateHeap
  • CreateProcessA
  • CreateProcessW
  • CreateProcessInternalA
  • CreateProcessInternalW
  • NtCreateUserProcess
  • NtCreateProcess
  • NtCreateProcessEx
  • CreateRemoteThread
  • CreateRemoteThreadEx
  • NtCreateThreadEx
  • WriteProcessMemory
  • NtWriteVirtualMemory
  • WinExec
  • CreateFileMappingA
  • CreateFileMappingW
  • CreateFileMappingNumaW
  • NtCreateSection
  • MapViewOfFile
  • MapViewOfFileEx
  • MapViewOfFileFromApp
  • LdrGetProcedureAddressForCaller

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:

  • LoadLibraryA
  • LoadLibraryW
  • LoadLibraryExA
  • LoadLibraryExW
  • LdrLoadDll
  • VirtualAlloc
  • VirtualAllocEx
  • NtAllocateVirtualMemory
  • VirtualProtect
  • VirtualProtectEx
  • NtProtectVirtualMemory
  • HeapCreate
  • RtlCreateHeap
  • CreateProcessA
  • CreateProcessW
  • CreateProcessInternalA
  • CreateProcessInternalW
  • NtCreateUserProcess
  • NtCreateProcess
  • NtCreateProcessEx
  • CreateRemoteThread
  • CreateRemoteThreadEx
  • NtCreateThreadEx
  • WriteProcessMemory
  • NtWriteVirtualMemory
  • WinExec
  • CreateFileMappingA
  • CreateFileMappingW
  • CreateFileMappingNumaW
  • NtCreateSection
  • MapViewOfFile
  • MapViewOfFileEx
  • MapViewOfFileFromApp
  • LdrGetProcedureAddressForCaller

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's 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, and 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 won't 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 raises an exception (STATUS_INVALID_HANDLE).

This mitigation is automatically applied to Windows Store applications.

Compatibility considerations

Applications that weren't accurately tracking handle references, and which weren't 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 aren't 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 are verified to ensure that they're also digitally signed as a Windows binary. If they fail the signature check, the dll won't be loaded, and throws 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 are impacted, and there's 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 doesn't fall between the bottom and the top of the stack, then an event is recorded and, if not in audit mode, the process is terminated.

The APIs intercepted by this mitigation are:

  • LoadLibraryA
  • LoadLibraryW
  • LoadLibraryExA
  • LoadLibraryExW
  • LdrLoadDll
  • VirtualAlloc
  • VirtualAllocEx
  • NtAllocateVirtualMemory
  • VirtualProtect
  • VirtualProtectEx
  • NtProtectVirtualMemory
  • HeapCreate
  • RtlCreateHeap
  • CreateProcessA
  • CreateProcessW
  • CreateProcessInternalA
  • CreateProcessInternalW
  • NtCreateUserProcess
  • NtCreateProcess
  • NtCreateProcessEx
  • CreateRemoteThread
  • CreateRemoteThreadEx
  • NtCreateThreadEx
  • WriteProcessMemory
  • NtWriteVirtualMemory
  • WinExec
  • CreateFileMappingA
  • CreateFileMappingW
  • CreateFileMappingNumaW
  • NtCreateSection
  • MapViewOfFile
  • MapViewOfFileEx
  • MapViewOfFileFromApp
  • LdrGetProcedureAddressForCaller

Compatibility considerations

Applications that are using fake stacks are impacted, and there's 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.

Tip

Do you want to learn more? Engage with the Microsoft Security community in our Tech Community: Microsoft Defender for Endpoint Tech Community.