Adversaries may inject malicious code into process via Extra Window Memory (EWM) in order to evade process-based defenses as well as possibly elevate privileges. EWM injection is a method of executing arbitrary code in the address space of a separate live process.
Before creating a window, graphical Windows-based processes must prescribe to or register a windows class, which stipulate appearance and behavior (via windows procedures, which are functions that handle input/output of data).(Citation: Microsoft Window Classes) Registration of new windows classes can include a request for up to 40 bytes of EWM to be appended to the allocated memory of each instance of that class. This EWM is intended to store data specific to that window and has specific application programming interface (API) functions to set and get its value. (Citation: Microsoft GetWindowLong function) (Citation: Microsoft SetWindowLong function)
Although small, the EWM is large enough to store a 32-bit pointer and is often used to point to a windows procedure. Malware may possibly utilize this memory location in part of an attack chain that includes writing code to shared sections of the process’s memory, placing a pointer to the code in EWM, then invoking execution by returning execution control to the address in the process’s EWM.
Execution granted through EWM injection may allow access to both the target process's memory and possibly elevated privileges. Writing payloads to shared sections also avoids the use of highly monitored API calls such as <code>WriteProcessMemory</code> and <code>CreateRemoteThread</code>.(Citation: Elastic Process Injection July 2017) More sophisticated malware samples may also potentially bypass protection mechanisms such as data execution prevention (DEP) by triggering a combination of windows procedures and other system functions that will rewrite the malicious payload inside an executable portion of the target process. (Citation: MalwareTech Power Loader Aug 2013) (Citation: WeLiveSecurity Gapz and Redyms Mar 2013)
Running code in the context of another process may allow access to the process's memory, system/network resources, and possibly elevated privileges. Execution via EWM injection may also evade detection from security products since the execution is masked under a legitimate process.
View in MITRE ATT&CK®| Capability ID | Capability Description | Mapping Type | ATT&CK ID | ATT&CK Name | Notes |
|---|---|---|---|---|---|
| intel-vt | Intel Virtualization Technology | Win 11, VBS, Memory Integrity | T1055.011 | Extra Window Memory Injection |
Comments
Memory integrity is a Virtualization-based security feature that protects and hardens Windows by running kernel mode code integrity within the isolated virtual environment of VBS (VBS uses Intel VT-x). Memory integrity also restricts kernel memory allocations that could be used to compromise the system. Memory integrity is sometimes referred to as hypervisor-protected code integrity (HVCI). VBS provides an isolated environment that acts as a root-of-trust for the OS and its core components. It is enabled by Intel VT-x, VT-x2 with Extended Page Tables, SMMUs (Intel VT-d) and Secure Boot (Intel Boot Guard).
Memory Integrity protects against behaviors that involve exploitation of kernel components including core drivers in memory, changing security configurations and running untrusted code (based on signatures).
"HVCI protects modification of the Control Flow Guard (CFG) bitmap for kernel mode drivers. Protects the kernel mode code integrity process that ensures that other trusted kernel processes have a valid certificate."
"Hypervisor-protected code integrity introduces a new rule that no kernel memory pages are both writeable and executable, which eliminates an entire category of attacks that dynamically generate code. Additionally, HVCI comes enabled with a code integrity security policy that blocks drivers known to be used in kernel tampering, including Mimikatz, the old vulnerable VBox driver, and the Capcom driver commonly used in rootkits. Ultimately, HVCI provides optimal protection for the kernel against tampering and escalation of privilege attacks. ... With HVCI enabled, attempts to modify the process structures will fail, preventing the protected process flag from being removed, which prevents process memory inspection or module injection into LSA."
HW Enforced stack protection (HWESP) relies on Virtualization Based Security (VBS) which use Intel PTT, Intel VT-x, Intel VT-d and Intel BootGuard to ensure the OS components loaded are not tampered with and isolate security sensitive processes. Additionally, it uses Intel Control Flow Enforcement Technology (Intel CET) to allow hardware to ensure that sensitive areas in the regions of memory (such as the stack) for processes are not tampered with by either injecting code or changing the control flow of the code or both.
HWESP includes four components Code Integrity Guard, Arbitrary Code Guard, Control Flow Guard and Shadow Stack protections.
Code Integrity Guard attempts to prevent "... arbitrary code generation by enforcing signature requirements for loading binaries".
Arbitrary Code Guard attempts to ensure "... signed pages are immutable and dynamic code cannot be generated ...".
Control Flow Guard ensures control flow integrity by enforcing "... integrity on indirect calls (forward-edge CFI)."
Shadow Stack ensures control flow integrity by enforcing "... integrity on return addresses on the stack (backward-edge CFI)."
Together these features aim to ensure integrity of binary images run on Windows 11 and prevent dynamic code from running or changing the control flow of the code. Since these features offer real-time protection for sensitive regions of memory, these are marked as offering significant protection.
References
|
| intel-vt | Intel Virtualization Technology | Win 11, HWESP | T1055.011 | Extra Window Memory Injection |
Comments
Memory integrity is a Virtualization-based security feature that protects and hardens Windows by running kernel mode code integrity within the isolated virtual environment of VBS (VBS uses Intel VT-x). Memory integrity also restricts kernel memory allocations that could be used to compromise the system. Memory integrity is sometimes referred to as hypervisor-protected code integrity (HVCI). VBS provides an isolated environment that acts as a root-of-trust for the OS and its core components. It is enabled by Intel VT-x, VT-x2 with Extended Page Tables, SMMUs (Intel VT-d) and Secure Boot (Intel Boot Guard).
Memory Integrity protects against behaviors that involve exploitation of kernel components including core drivers in memory, changing security configurations and running untrusted code (based on signatures).
"HVCI protects modification of the Control Flow Guard (CFG) bitmap for kernel mode drivers. Protects the kernel mode code integrity process that ensures that other trusted kernel processes have a valid certificate."
"Hypervisor-protected code integrity introduces a new rule that no kernel memory pages are both writeable and executable, which eliminates an entire category of attacks that dynamically generate code. Additionally, HVCI comes enabled with a code integrity security policy that blocks drivers known to be used in kernel tampering, including Mimikatz, the old vulnerable VBox driver, and the Capcom driver commonly used in rootkits. Ultimately, HVCI provides optimal protection for the kernel against tampering and escalation of privilege attacks. ... With HVCI enabled, attempts to modify the process structures will fail, preventing the protected process flag from being removed, which prevents process memory inspection or module injection into LSA."
HW Enforced stack protection (HWESP) relies on Virtualization Based Security (VBS) which use Intel PTT, Intel VT-x, Intel VT-d and Intel BootGuard to ensure the OS components loaded are not tampered with and isolate security sensitive processes. Additionally, it uses Intel Control Flow Enforcement Technology (Intel CET) to allow hardware to ensure that sensitive areas in the regions of memory (such as the stack) for processes are not tampered with by either injecting code or changing the control flow of the code or both.
HWESP includes four components Code Integrity Guard, Arbitrary Code Guard, Control Flow Guard and Shadow Stack protections.
Code Integrity Guard attempts to prevent "... arbitrary code generation by enforcing signature requirements for loading binaries".
Arbitrary Code Guard attempts to ensure "... signed pages are immutable and dynamic code cannot be generated ...".
Control Flow Guard ensures control flow integrity by enforcing "... integrity on indirect calls (forward-edge CFI)."
Shadow Stack ensures control flow integrity by enforcing "... integrity on return addresses on the stack (backward-edge CFI)."
Together these features aim to ensure integrity of binary images run on Windows 11 and prevent dynamic code from running or changing the control flow of the code. Since these features offer real-time protection for sensitive regions of memory, these are marked as offering significant protection.
References
|