Merge pull request #1908 from YongRhee-MSFT/docs-editor/exploit-protection-reference-1731685481

Update exploit-protection-reference.md

Author: Ruchika-mittal01

defender-endpoint/exploit-protection-reference.md

@@ -15,7 +15,7 @@ ms.collection:
 - m365-security
 - tier3
 - mde-asr
-ms.date: 11/07/2023
+ms.date: 11/15/2024
 search.appverid: met150
 ---
 
@@ -32,7 +32,7 @@ search.appverid: met150
 
 > Want to experience Microsoft Defender for Endpoint? [Sign up for a free trial.](https://signup.microsoft.com/create-account/signup?products=7f379fee-c4f9-4278-b0a1-e4c8c2fcdf7e&ru=https://aka.ms/MDEp2OpenTrial?ocid=docs-wdatp-enablesiem-abovefoldlink)
 
-Exploit protection provides advanced protections for applications that enterprise admins and IT pros can apply after a developer has compiled and distributed software.
+Exploit protection provides advanced protections for applications that enterprise admins and IT pros can apply after a developer compiles and distributes 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.
 
@@ -47,7 +47,12 @@ Mitigations are configured via a registry entry for each program that you config
 
 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.
+## Resetting exploit protection
+
+> [!IMPORTANT]
+> 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:
 
@@ -201,11 +206,11 @@ By preventing the *execute* flag from being set, the data execution prevention f
 
 ### 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.
+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 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**](/windows/win32/api/processthreadsapi/nf-processthreadsapi-setthreadinformation) API with the *ThreadInformation* parameter set to **ThreadDynamicCodePolicy** in order to be allowed to execute dynamic code on this thread.
+**Allow thread opt-out** - You can configure the mitigation to allow an individual thread to opt-out of this protection. The developer must write the application with awareness of this mitigation, and call the [**SetThreadInformation**](/windows/win32/api/processthreadsapi/nf-processthreadsapi-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](/defender-xdr/advanced-hunting-overview).
 
@@ -219,7 +224,7 @@ This mitigation blocks image loads if the image has an Access Control Entry (ACE
 
 ### 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.
+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 want to ensure that they're downloaded from a higher-trust process, or are explicitly relabeled in order to apply this mitigation.
 
 ### Configuration options
 
@@ -269,19 +274,19 @@ This mitigation is implemented within the memory manager, which blocks the binar
 
 ### 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.
+This mitigation specifically blocks any binary that isn't signed by Microsoft. As such, it's incompatible with most non-Microsoft 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.
+**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 go 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](/defender-xdr/advanced-hunting-overview).
 
 ## 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).
+Control flow guard (CFG) mitigates the risk of attackers using memory corruption vulnerabilities by protecting indirect function calls. For example, an attacker might 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 could also be 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.
 
@@ -308,7 +313,7 @@ If you attempt to set the instruction pointer to a memory address not marked as
 
 ### 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 x64, ARM, and ARM-64 executables have DEP enabled by default, and it can't be disabled. Since an application isn't 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.
 
@@ -361,7 +366,7 @@ 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 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.
+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 is broken with this mitigation applied.
 
 ### Configuration options
 
@@ -377,7 +382,7 @@ Export address filtering (EAF) mitigates the risk of malicious code looking at t
 - kernelbase.dll
 - kernel32.dll
 
-The mitigation protects the memory page in the [export directory that points to the [export address table](/windows/win32/debug/pe-format#export-address-table). This memory page will have the [PAGE_GUARD](/windows/win32/memory/creating-guard-pages) 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.
+The mitigation protects the memory page in the [export directory that points to the [export address table](/windows/win32/debug/pe-format#export-address-table). This memory page has the [PAGE_GUARD](/windows/win32/memory/creating-guard-pages) 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
 
@@ -428,11 +433,11 @@ This compatibility impact of ASLR is typically constrained to older applications
 
 ### 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.
+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 offers 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.
+Hardware-enforced stack protection only works on chipsets with support for hardware shadow stacks, Intel's Control-flow Enforcement Technology (CET) or AMD shadow stacks.
 
 ### Configuration options
 
@@ -478,7 +483,7 @@ This mitigation protects the following Windows APIs:
 
 ### 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.
+Legitimate applications that perform API interception might be detected by this mitigation and cause some applications to crash. Examples include security software and application compatibility shims.
 
 ### Configuration options
 
@@ -494,7 +499,7 @@ The size of the 32-bit address space places practical constraints on the entropy
 
 ### 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).
+Most applications that are compatible with Mandatory ASLR (rebasing) are also compatible with the other entropy of Bottom-up ASLR. Some applications might 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
 
@@ -507,7 +512,7 @@ Most applications that are compatible with Mandatory ASLR (rebasing) are also co
 
 ### 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.
+Simulate execution (SimExec) is a mitigation for 32-bit applications only. This helps validate that calls to sensitive APIs 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:
 
@@ -631,7 +636,7 @@ If these validations fail, then exception handling is aborted, and the exception
 
 ### 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.
+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 might manifest as a race condition that reveals a latent multi-threading bug in the application.
 
 ### Configuration options
 
@@ -642,7 +647,7 @@ Compatibility issues with SEHOP are relatively rare. It's uncommon for an applic
 
 ### Description
 
-*Validate handle usage* is a mitigation that helps protect against an attacker using an existing handle to access a protected object. A [handle](/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 raises an exception (STATUS_INVALID_HANDLE).
+*Validate handle usage* is a mitigation that helps protect against an attacker using an existing handle to access a protected object. A [handle](/windows/win32/sysinfo/handles-and-objects) is a reference to a protected object. If application code is referencing an invalid handle, it 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.