From 3cf68d613a4b5fb7ddc8dff12408fd9ad8cf0763 Mon Sep 17 00:00:00 2001 From: Denise Vangel-MSFT Date: Fri, 6 Nov 2020 12:08:05 -0800 Subject: [PATCH] Update exploit-protection-reference.md --- .../exploit-protection-reference.md | 124 +++++++++--------- 1 file changed, 62 insertions(+), 62 deletions(-) diff --git a/windows/security/threat-protection/microsoft-defender-atp/exploit-protection-reference.md b/windows/security/threat-protection/microsoft-defender-atp/exploit-protection-reference.md index 8776de4b02..8e0b432b66 100644 --- a/windows/security/threat-protection/microsoft-defender-atp/exploit-protection-reference.md +++ b/windows/security/threat-protection/microsoft-defender-atp/exploit-protection-reference.md @@ -1,7 +1,7 @@ --- -title: Exploit Protection Reference +title: Exploit protection reference keywords: mitigations, vulnerabilities, vulnerability, mitigation, exploit, exploits, emet -description: Details on how the Exploit Protection feature works in Windows 10 +description: Details on how the exploit protection feature works in Windows 10 search.product: eADQiWindows 10XVcnh ms.pagetype: security ms.prod: w10 @@ -26,9 +26,9 @@ ms.custom: asr - [Microsoft Defender for Endpoint](https://go.microsoft.com/fwlink/p/?linkid=2146631) -Exploit Protection provides advanced protections for applications which the IT Pro can apply after the developer has compiled and distributed the software. +Exploit protection provides advanced protections for applications that the IT Pro can apply after the developer has compiled and distributed the 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. +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 @@ -39,11 +39,11 @@ Mitigations are configured via a registry entry for each program that you config > [!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. +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 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: +To reset exploit protection settings using PowerShell, you could use the following command: ```powershell Set-ProcessMitigation -PolicyFilePath EP-reset.xml @@ -181,21 +181,21 @@ Following is the EP-reset.xml distributed with the Windows Security Baselines: ## Mitigation Reference -The below sections detail the protections provided by each Exploit Protection mitigation, the compatibility considerations for the mitigation, and the configuration options available. +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 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](https://docs.microsoft.com/windows/win32/api/memoryapi/nf-memoryapi-virtualalloc), 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*](https://docs.microsoft.com/windows/win32/memory/memory-protection-constants) 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](https://docs.microsoft.com/windows/win32/api/memoryapi/nf-memoryapi-virtualprotect) that has already been allocated and includes the [*execute*](https://docs.microsoft.com/windows/win32/memory/memory-protection-constants) protection flag, then the permission change fails and returns an error code (STATUS_DYNAMIC_CODE_BLOCKED). +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](https://docs.microsoft.com/windows/win32/api/memoryapi/nf-memoryapi-virtualalloc), 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*](https://docs.microsoft.com/windows/win32/memory/memory-protection-constants) 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](https://docs.microsoft.com/windows/win32/api/memoryapi/nf-memoryapi-virtualprotect) that has already been allocated and includes the [*execute*](https://docs.microsoft.com/windows/win32/memory/memory-protection-constants) 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 can then protect against the instruction pointer being set to that memory and running that code. +By preventing the *execute* flag from being set, the data execution prevention feature of Windows 10 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. +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 @@ -207,23 +207,23 @@ Arbitrary Code Guard prevents allocating any memory as executable, which present ### Description -Block low integrity images prevents the application from loading files which are untrusted, typically because they have been downloaded from the internet from a sandboxed browser. +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](https://docs.microsoft.com/windows/win32/secauthz/mandatory-integrity-control). ### Compatibility considerations -Block low integrity images will prevent the application from loading files which were downloaded from the internet. If your application workflow requires loading images which 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. +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 [Defender for Endpoint](https://docs.microsoft.com/microsoft-365/security/mtp/advanced-hunting-overview). +**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](https://docs.microsoft.com/microsoft-365/security/mtp/advanced-hunting-overview). ## Block remote images ### Description -Block remote images will prevent the application from loading files which are hosted on a remote device, such as a UNC share. This helps protect against loading binaries into memory which are on an external device controlled by the attacker. +Block remote images will prevent the application from loading files that are hosted on a remote device, such as a UNC share. This 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. @@ -233,25 +233,25 @@ Block remote images will prevent the application from loading images from remote ### 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](https://docs.microsoft.com/microsoft-365/security/mtp/advanced-hunting-overview). +**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](https://docs.microsoft.com/microsoft-365/security/mtp/advanced-hunting-overview). ## 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 which are installed into the windows\fonts directory will be loaded for processing by GDI. +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. -Note that this mitigation is in addition to the built-in mitigation provided in Windows 10 1607 and later, 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](https://www.microsoft.com/security/blog/2017/01/13/hardening-windows-10-with-zero-day-exploit-mitigations/). +This mitigation is in addition to the built-in mitigation provided in Windows 10 1607 and later, 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](https://www.microsoft.com/security/blog/2017/01/13/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](https://docs.microsoft.com/typography/fonts/font-faq#web). 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. +The most common use of fonts outside of the system fonts directory is with [web fonts](https://docs.microsoft.com/typography/fonts/font-faq#web). 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 [Defender for Endpoint](https://docs.microsoft.com/microsoft-365/security/mtp/advanced-hunting-overview). +**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](https://docs.microsoft.com/microsoft-365/security/mtp/advanced-hunting-overview). ## Code integrity guard @@ -259,17 +259,17 @@ The most common use of fonts outside of the system fonts directory is with [web Code integrity guard ensures that all binaries loaded into a process are digitally signed by Microsoft. This includes [WHQL](https://docs.microsoft.com/windows-hardware/drivers/install/whql-release-signature) (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 which 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. +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 which 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. +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 which are distributed by the Microsoft Store will be digitally signed by the Microsoft Store, and adding this configuration will allow binaries which have gone through the store certification process to be loaded by the application. +**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 [Defender for Endpoint](https://docs.microsoft.com/microsoft-365/security/mtp/advanced-hunting-overview). +**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](https://docs.microsoft.com/microsoft-365/security/mtp/advanced-hunting-overview). ## Control flow guard (CFG) @@ -277,7 +277,7 @@ This mitigation specifically blocks any binary which is not signed by Microsoft. Control flow guard (CFG) mitigates the risk of attackers leveraging 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 an additional check at compile time. Before each indirect function call, additional 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 which are compiled with CFG support can benefit from this mitigation. +This mitigation is provided by injecting an additional check at compile time. Before each indirect function call, additional 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. @@ -296,19 +296,19 @@ Since applications must be compiled to support CFG, they implicitly declare thei ### Description -Data Execution Prevention (DEP) prevents memory which was not explicitly allocated as executable from being executed. This helps protect against an attacker injecting malicious code into the process, such as through a buffer overflow, and then executing that code. +Data execution prevention (DEP) prevents memory that was not explicitly allocated as executable from being executed. This 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 generally assumed. +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 will have DEP enabled by default, but it can be disabled per process. Some very old legacy applications, typically applications developed prior to Windows XP SP2, may not be compatible with DEP. These are typically applications that dynamically generate code (e.g. JIT compiling) or link to older libraries (such as older versions of ATL) which dynamically generate code. +All x86 (32-bit) binaries will have DEP enabled by default, but it can be disabled per process. Some old legacy applications, typically applications developed prior to Windows XP SP2, may not be compatible with DEP. These are typically applications that dynamically generate code (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 which 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 which have a binary extension model (such as Internet Explorer 11) will often need to have ATL Thunk emulation enabled. +**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 @@ -318,13 +318,13 @@ This mitigation disables various extension points for an application, which migh 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](https://docs.microsoft.com/windows/win32/winmsg/about-window-classes#application-global-classes). With this mitigation applied, AppInit DLLs are not loaded. Note that, beginning with Windows 7, AppInit DLLs need to be digitally signed, [as described here](https://docs.microsoft.com/windows/win32/win7appqual/appinit-dlls-in-windows-7-and-windows-server-2008-r2). Additionally, beginning with Windows 8, AppInit DLLs will not be loaded if SecureBoot is enabled, [as described here](https://docs.microsoft.com/windows/win32/dlls/secure-boot-and-appinit-dlls). +- **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](https://docs.microsoft.com/windows/win32/winmsg/about-window-classes#application-global-classes). With this mitigation applied, AppInit DLLs are not loaded. Beginning with Windows 7, AppInit DLLs need to be digitally signed, [as described here](https://docs.microsoft.com/windows/win32/win7appqual/appinit-dlls-in-windows-7-and-windows-server-2008-r2). Additionally, beginning with Windows 8, AppInit DLLs will not be loaded if SecureBoot is enabled, [as described here](https://docs.microsoft.com/windows/win32/dlls/secure-boot-and-appinit-dlls). - **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](https://docs.microsoft.com/windows/win32/api/winuser/nf-winuser-setwineventhook) 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 3rd party Legacy IMEs which will not work with the protected application. +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 @@ -341,11 +341,11 @@ Win32k.sys provides a broad attack surface for an attacker. As a kernel-mode com ### Compatibility considerations -This mitigation is designed for processes which are dedicated non-UI processes. For example, many modern browsers will leverage process isolation and incorporate non-UI processes. Any application which displays a GUI using a single process will be impacted by this mitigation. +This mitigation is designed for processes that are dedicated non-UI processes. For example, many modern browsers will leverage 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 [Defender for Endpoint](https://docs.microsoft.com/microsoft-365/security/mtp/advanced-hunting-overview). +**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](https://docs.microsoft.com/microsoft-365/security/mtp/advanced-hunting-overview). ## Do not allow child processes @@ -355,23 +355,23 @@ This mitigation prevents an application from creating new child applications. A ### Compatibility considerations -If your application launches child applications for any reason, such as supporting hyperlinks which launch a browser or an external browser, or which launch other utilities on the computer, this functionality will be broken with this mitigation applied. +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 [Defender for Endpoint](https://docs.microsoft.com/microsoft-365/security/mtp/advanced-hunting-overview). +**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](https://docs.microsoft.com/microsoft-365/security/mtp/advanced-hunting-overview). ## 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 3 commonly attacked modules: +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](https://docs.microsoft.com/windows/win32/debug/pe-format#export-directory-table) which points to the [export address table](https://docs.microsoft.com/windows/win32/debug/pe-format#export-address-table). This memory page will have the [PAGE_GUARD](https://docs.microsoft.com/windows/win32/memory/creating-guard-pages) 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. +The mitigation protects the memory page in the [export directory that points to the [export address table](https://docs.microsoft.com/windows/win32/debug/pe-format#export-address-table). This memory page will have the [PAGE_GUARD](https://docs.microsoft.com/windows/win32/memory/creating-guard-pages) 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 @@ -394,7 +394,7 @@ This mitigation is primarily an issue for applications such as debuggers, sandbo 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](https://docs.microsoft.com/windows/win32/debug/pe-format#ms-dos-stub-image-only), 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 [Defender for Endpoint](https://docs.microsoft.com/microsoft-365/security/mtp/advanced-hunting-overview). +**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](https://docs.microsoft.com/microsoft-365/security/mtp/advanced-hunting-overview). ## Force randomization for images (Mandatory ASLR) @@ -408,11 +408,11 @@ When the memory manager is mapping in the image into the process, Mandatory ASLR ### Compatibility considerations -This compatibility impact of ASLR is typically constrained to older applications which were built using compilers which 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. +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](https://docs.microsoft.com/windows/win32/debug/pe-format#the-reloc-section-image-only) which 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). +**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. @@ -421,7 +421,7 @@ This compatibility impact of ASLR is typically constrained to older applications ### 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 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](https://docs.microsoft.com/windows/win32/memory/creating-guard-pages) 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. @@ -455,11 +455,11 @@ This mitigation protects the following Windows APIs: ### Compatibility considerations -Legitimate applications which perform API interception may be detected by this mitigation and cause some applications to crash. Examples include security software and application compatibility shims. +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 [Defender for Endpoint](https://docs.microsoft.com/microsoft-365/security/mtp/advanced-hunting-overview). +**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](https://docs.microsoft.com/microsoft-365/security/mtp/advanced-hunting-overview). ## Randomize memory allocations (Bottom-up ASLR) @@ -467,15 +467,15 @@ Legitimate applications which perform API interception may be detected by this m 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. -Note that 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 significantly more difficult for an attacker to guess a location in memory. +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 which are compatible with Mandatory ASLR (rebasing) will also be compatible with the additional 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 4GB), and thus will be incompatible with the high entropy option (which can be disabled). +Most applications that are compatible with Mandatory ASLR (rebasing) will also be compatible with the additional 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 (1TB of variance) into the bottom-up allocation for 64-bit applications. +**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. @@ -484,7 +484,7 @@ Most applications which are compatible with Mandatory ASLR (rebasing) will also ### Description -Simulate execution (SimExec) is a mitigation for 32-bit applications only which 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 compare if the two match and that the RET hasn't been intercepted. +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: @@ -527,19 +527,19 @@ If a ROP gadget is detected, the process is terminated. ### Compatibility considerations -Applications which perform API interception, particularly security software, can cause compatibility problems with this mitigation. +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 [Defender for Endpoint](https://docs.microsoft.com/microsoft-365/security/mtp/advanced-hunting-overview). +**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](https://docs.microsoft.com/microsoft-365/security/mtp/advanced-hunting-overview). ## Validate API invocation (CallerCheck) ### Description -Validate API invocation (CallerCheck) is a mitigation for return oriented programming (ROP) techniques which 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. +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: @@ -582,19 +582,19 @@ If a ROP gadget is detected, the process is terminated. ### Compatibility considerations -Applications which perform API interception, particularly security software, can cause compatibility problems with this mitigation. +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 ATP](https://docs.microsoft.com/microsoft-365/security/mtp/advanced-hunting-overview). +**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](https://docs.microsoft.com/microsoft-365/security/mtp/advanced-hunting-overview). ## Validate exception chains (SEHOP) ### Description -Validate exception chains (SEHOP) is a mitigation against the *Structured Exception Handler (SEH) overwrite* exploitation technique. [Structured Exception Handling](https://docs.microsoft.com/windows/win32/debug/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 leverage a stack overflow vulnerability to then overwrite the exception handler with a pointer to the code of the attacker's choice. +Validate exception chains (SEHOP) is a mitigation against the *Structured Exception Handler (SEH) overwrite* exploitation technique. [Structured exception handling](https://docs.microsoft.com/windows/win32/debug/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 leverage 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: @@ -619,13 +619,13 @@ Compatibility issues with SEHOP are relatively rare. It's uncommon for an applic ### Description -*Validate handle usage* is a mitigation which helps protect against an attacker leveraging an existing handle to access a protected object. A [handle](https://docs.microsoft.com/windows/win32/sysinfo/handles-and-objects) 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). +*Validate handle usage* is a mitigation that helps protect against an attacker leveraging an existing handle to access a protected object. A [handle](https://docs.microsoft.com/windows/win32/sysinfo/handles-and-objects) 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 which were not accurately tracking handle references, and which were not wrapping these operations in exception handlers, will potentially be impacted by this mitigation. +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 @@ -656,21 +656,21 @@ This mitigation is already applied by default for 64-bit applications and for 32 ### Description -The *validate image dependency* mitigation helps protect against attacks which attempt to substitute code for dlls which 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. +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 which 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. +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 [Defender for Endpoint](https://docs.microsoft.com/microsoft-365/security/mtp/advanced-hunting-overview). +**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](https://docs.microsoft.com/microsoft-365/security/mtp/advanced-hunting-overview). ## 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 which controls the flow of execution. +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 a number of 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. @@ -713,11 +713,11 @@ The APIs intercepted by this mitigation are: ### Compatibility considerations -Applications which are leveraging fake stacks will be impacted, and there is also a small risk of revealing subtle timing bugs in multi-threaded applications. -Applications which perform API interception, particularly security software, can cause compatibility problems with this mitigation. +Applications that are leveraging 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 [Defender for Endpoint](https://docs.microsoft.com/microsoft-365/security/mtp/advanced-hunting-overview). +**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](https://docs.microsoft.com/microsoft-365/security/mtp/advanced-hunting-overview).