Addressed validation warnings

windows/security/threat-protection/microsoft-defender-atp/exploit-protection-reference.md

@@ -7,7 +7,6 @@ ms.pagetype: security
 ms.prod: w10
 ms.mktglfcycl: manage
 ms.sitesec: library
-ms.pagetype: security
 ms.localizationpriority: medium
 audience: ITPro
 author: appcompatguy
@@ -189,7 +188,7 @@ Arbitrary Code Guard helps protect against a malicious attacker loading the 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).
 
-By preventing the *execute* flag from being set, the [Data Execution Prevention](#Data-Execution-Prevention-(DEP)) 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](#Data-Execution-Prevention-DEP) feature of Windows 10 can then protect against the instruction pointer being set to that memory and running that code.
 
 ### Compatibility considerations
 
@@ -316,7 +315,7 @@ 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/en-us/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. 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).
 - **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.
 
@@ -369,7 +368,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](https://docs.microsoft.com/windows/win32/debug/pe-format#export-directory-table) which points to the [export address table](https://docs.microsoft.com/en-us/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](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.
 
 ### Compatibility considerations
 
@@ -402,7 +401,7 @@ Address Space Layout Randomization (ASLR) mitigates the risk of an attacker usin
 
 Mandatory ASLR forces a rebase of all DLLs within the process. A developer can enable ASLR using the [/DYNAMICBASE](https://docs.microsoft.com/cpp/build/reference/dynamicbase-use-address-space-layout-randomization?view=vs-2019) linker option, and this mitigation has the same effect.
 
-When the memory manager is mapping in the image into the process, Mandatory ASLR will forcibly rebase DLLs and EXEs that have not opted in to ASLR. Note, however, that this rebasing has no entropy, and can therefore be placed at a predictable location in memory. For rebased and randomized location of binaries, this mitigation should be paired with [Randomize memory allocations (Bottom-up ASLR)](#randomize-memory-allocations-(bottom-up-aslr)).
+When the memory manager is mapping in the image into the process, Mandatory ASLR will forcibly rebase DLLs and EXEs that have not opted in to ASLR. Note, however, that this rebasing has no entropy, and can therefore be placed at a predictable location in memory. For rebased and randomized location of binaries, this mitigation should be paired with [Randomize memory allocations (Bottom-up ASLR)](#randomize-memory-allocations-bottom-up-aslr).
 
 ### Compatibility considerations
 
@@ -617,7 +616,7 @@ 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/en-us/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 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).
 
 This mitigation is automatically applied to Windows Store applications.
 
@@ -715,4 +714,4 @@ Compatibility issues are uncommon. Applications which are leveraging fake 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 [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 ATP](https://docs.microsoft.com/microsoft-365/security/mtp/advanced-hunting-overview).