Memory-protection techniques prevent malware execution and unauthorized attempts to gain control of a system through buffer overflow. Application Control offers multiple techniques to prevent zero-day attacks.
At a high-level, the available techniques stop two kinds of exploits.
Buffer overflow followed by direct code execution.
Buffer overflow followed by indirect code execution using Return-Oriented Programming.
For a detailed and updated list of exploits prevented by memory-protection techniques, subscribe to Trellix Threat Intelligence Services security advisories.
Technique | Description | |
|---|---|---|
CASP — Critical Address Space Protection (mp-casp) | CASP is a memory-protection technique that renders useless any shellcode running from the non-code area. This shellcode is an abnormal event that usually happens because of a buffer overflow. CASP allows code to execute from non-code area but disallows the code from invoking any meaningful API calls, such as CreateProcess() and DeleteFile(). When exploit code invokes these APIs, CASP blocks it and it fails to do any damage.
| |
Supported operating systems | 32-bit and 64-bit — Windows Server 2008, Windows 7, Windows Embedded 7, Windows 8, Windows Embedded 8, Windows 8.1, Windows Embedded 8.1, Windows 10, Windows 10 IoT Enterprise, Windows 11, Windows Server 2016, Windows Server 2019, and Windows Server 2022. | |
Default state | Enabled | |
Event generated | PROCESS_HIJACK_ATTEMPTED | |
NX — No eXecute (mp-nx) | The NX feature uses the Windows Data Execution Prevention (DEP) feature to protect processes against exploits that try to execute code from writable memory area (stack/heap). NX also provides granular bypass capability and raises violation events that can be viewed on the ePO - SaaS console. Windows DEP prevents code from being run from a non-executable memory region. This abnormal event mostly occurs due to a buffer overflow. The malicious exploit attempts to execute code from these non-executable memory regions. | |
Supported operating systems | 64-bit — Windows Server 2008, Windows Server 2008 R2, Windows 7, Windows Embedded 7, Windows 8, Windows Embedded 8, Windows 8.1, Windows Embedded 8.1, Windows 10, Windows 10 IoT Enterprise, Windows 11, Windows Server 2012, Windows Server 2012 R2, Windows Server 2016, Windows Server 2019, and Windows Server 2022. This feature isn't available on the IA64 architecture. | |
Default state | Enabled | |
Event generated | NX_VIOLATION_DETECTED | |
Forced DLL Relocation (mp-vasr-forced-relocation) | This feature forces relocation of those dynamic-link libraries (DLLs) that have opted out of the Windows native ASLR feature. Some malware relies on these DLLs always being loaded at the same and known addresses. By relocating such DLLs, these attacks are prevented. | |
Supported operating systems | 32-bit and 64-bit — Windows Server 2008, Windows Server 2008 R2, Windows 7, Windows Embedded 7, Windows 8, Windows Embedded 8, Windows 8.1, Windows Embedded 8.1, Windows 10, Windows 10 IoT Enterprise, Windows 11, Windows Server 2012, Windows Server 2012 R2, Windows Server 2016, Windows Server 2019, and Windows Server 2022. | |
Default state | Enabled | |
Event generated | VASR_VIOLATION_DETECTED | |
Occasionally, some applications (as part of their day-to-day processing) might run code in an atypical way and be prevented from running by the memory-protection techniques. To allow such applications to run, you can define specific rules to bypass the memory-protection techniques.