deepblue/windows-itpro-docs
1
0
Fork 0
mirror of https://github.com/MicrosoftDocs/windows-itpro-docs.git synced 2025-06-18 20:03:40 +00:00
Code Issues Actions 3 Packages Projects Releases Wiki Activity

Added remaining mitigation docs

Browse Source 
Completed initial draft of docs for all mitigations
This commit is contained in:
Chris Jackson
2020-08-17 17:59:32 -05:00
parent 0336c89b30
commit 0101885b9b
1 changed files with 263 additions and 3 deletions
Download Patch File Download Diff File Expand all files Collapse all files

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

@ -369,11 +369,11 @@ 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 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/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.
### Compatibility considerations
This mitigation is primarily an issue for applications such as debuggers, sandboxed applications, applications using DRM, or applications that implement anti-debugging technolgy.
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
@ -398,24 +398,284 @@ Additionally, by enabling EAF+, this mitigation adds the PAGE_GUARD protection t
### 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 leveraging 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](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)).
### 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.
### Configuration options
## Import address filtering
**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).
> [!Note]
> **Force randomization for images (Mandatory ASLR)** has no audit mode.
## Import address filtering (IAF)
### Description
The Import address filtering (IAF) mitigation helps mitigate the risk of an adversary changing the control flow of an application by modifying the import address table (IAT) to redirect to arbitrary code of the attacker's choice when that function is called. An attacker could use this approach to hijack control, or to intercept, inspect, and potentially block calls to sensitive APIs.
The memory pages for all protected APIs will have the [PAGE_GUARD](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.
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 which 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 ATP](https://docs.microsoft.com/microsoft-365/security/mtp/advanced-hunting-overview).
## 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.
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.
### Compatibility considerations
Most applications which are compatibile with Mandatory ASLR (rebasing) will also be compatibile 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).
### Configuration options
**Don't user 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.
> [!Note]
> **Randomize memory alocations (Bottom-up ASLR)** has no audit mode.
## Simulate execution (SimExec)
### 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.
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 which 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).
## 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.
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 which 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).
## 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.
This mitigation relies on the design of SEH, where each SEH entry contains both a pointer to the exception handler, as well as a pointer to the next handler in the exception chain. This mitigation is called by the exception dispatcher, which validates the SEH chain when an exception is invoked. It verifies that:
- All exception chain records are within the stack boundaries
- All exception records are aligned
- No exception handler pointers are pointing to the stack
- There are no backward pointers
- The exception chain ends at a known final exception handler
If these validations fail, then exception handling is aborted, and the exception will not be handled.
### Compatibility considerations
Compatibility issues with SEHOP are relatively rare. It's uncommon for an application to take a dependency on corrupting the exception chain. However, some applications are impacted by the subtle changes in timing, which may manifest as a race condition that reveals a latent multi-threading bug in the application.
### Configuration options
> [!Note]
> **Validate exception chains (SEHOP)** has no audit mode.
## Validate handle usage
### Description
*Validate handle usage* is a mitigation 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).
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.
### 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 additional validation on extended block headers for heap allocations
- Verifying that heap allocations are not already flagged as in-use
- Adding guard pages to large allocations, heap segments, and subsegments above a minimum size
### Compatibility considerations
This mitigation is already applied by default for 64-bit applications and for 32-bit applications targeting Windows Vista or later. Legacy applications from Windows XP or earlier are most at-risk, though compatibility issues are rare.
### Configuration options
> [!Note]
> **Validate heap integrity** has no audit mode.
## Validate image dependency integrity
### Description
The *validate image dependency* mitigation helps protect against attacks 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.
### 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.
### 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).
## 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.
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.
### Compatibility considerations
Compatibility issues are uncommon. 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.
### 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).