Extra Window Memory Injection (EWMI) is a process injection technique that involves injecting code into the Extra Window Memory (EWM) of the Explorer tray window, which is a system window that displays icons for various system functions and notifications. This technique can be used to execute malicious code within the context of the Explorer tray window, potentially allowing the attacker to evade detection and carry out malicious actions.
In this blog post, we explain the T1055.011 Extra Window Memory Injection technique of the MITRE ATT&CK® framework and explore how adversaries employ Extra Window Memory Injection with real-world attack examples in detail.
![]()
|
|
What is Extra Window Memory?
In the Windows operating system, a window class is a data structure that specifies the appearance and behavior of a window. When a process creates a window, it must first register a window class that defines the characteristics of the window. As part of this registration process, the process can request that up to 40 bytes of extra memory (EWM) be allocated for each instance of the class. This extra memory is intended to store data specific to the window and can be accessed using specific API functions, such as GetWindowLong and SetWindowLong. These functions take the window handle as the first argument and the index of the field to be retrieved or set as the second argument. The field values are stored in the form of "window longs."
Adversary Use of Extra Window Memory Injection
The EWM is large enough to store a 32-bit pointer, which can point to a Windows procedure (aka Window proc). A window procedure is a function that handles input and output for a window, including messages sent to the window and actions performed by the window. Malware may attempt to use the EWM as part of an attack chain in which it writes code to shared sections of memory within a process, places a pointer to that code in the EWM, and then executes the code by returning control to the address stored in the EWM.
This technique, known as Extra Window Memory Injection (EWMI), allows the malware to execute code within the context of a target process, giving it access to both the process's memory and potentially elevated privileges. Malware developers may use this technique to avoid detection by writing payloads to shared sections of memory rather than using API calls like WriteProcessMemory and CreateRemoteThread, which are more closely monitored. More sophisticated malware may also bypass security measures like data execution prevention (DEP) by triggering a series of Windows procedures and other system functions that rewrite the malicious payload within an executable portion of the target process. This allows the malware to execute its code while bypassing DEP and other protection mechanisms.
Attackers can inject malicious code into this space and execute it, which can be particularly stealthy, given that EWM is a legitimate and less commonly monitored part of a window object. The essence of this technique is to place malicious code into the EWM and then have it executed, often through a callback function like a window procedure (the function that receives and processes all messages sent to a window).
Here's a high-level overview of how Extra Window Memory Injection typically works:
-
Identify Victim Application: The attacker selects a target Windows application that has a window with extra memory allocated.
-
Allocate or Find EWM: If the attacker has control over the application's source code or can alter it through other injection methods, they may directly allocate extra memory for a window using the RegisterClassEx or CreateWindowEx Windows API functions. Alternatively, the attacker finds a window class with previously allocated EWM.
-
Inject Malicious Code into EWM: The attacker uses an appropriate API, such as SetWindowLongPtr with GWL_USERDATA or a similar flag, to copy the malicious code into the EWM of the target window.
-
Trigger Execution: To execute the injected shellcode, the attacker will typically set up a scenario where a message sent to the target window causes the window procedure to jump to the EWM and execute the shellcode. This could be via a crafted message that manipulates the execution flow or by modifying the window procedure pointer directly to point to the injected code.