Process Hollowing: How Malware Hijacks Legitimate Programs to Evade Detection

To understand Process Hollowing, it is necessary to grasp how the Windows operating system handles processes and memory management.

When a user or the system launches an application (like notepad.exe or svchost.exe), Windows creates a process object. This process acts as a container, holding the application's executable code, memory space, security context, and processing threads. Under normal circumstances, the executable file on the disk is mapped directly into this memory space, and the primary thread begins executing the code.

Process Hollowing, also known as RunPE (Run Portable Executable), subverts this normal execution flow. The core concept is to create a process using a known, trusted executable, pause its execution before it really begins, scoop out (or "hollow") its legitimate code from memory, and inject the attacker's malicious code in its place. Once the code is swapped, the process is resumed.

Because the process originated from a legitimate file on the disk (e.g., explorer.exe), Task Manager, standard system monitoring tools, and basic Antivirus (AV) scanners looking only at process names and file paths will see nothing out of the ordinary. The malicious payload adopts the identity, privileges, and visual camouflage of the hollowed host process.

The execution of Process Hollowing requires a precise sequence of interactions with the Windows operating system. Attackers typically use a "dropper" or "loader" executable to orchestrate these steps.

Step 1: Process Creation in Suspended State

The attack begins with the malware loader calling the CreateProcess Windows API to launch a legitimate target executable (often a system binary like svchost.exe, explorer.exe, or cmd.exe). Crucially, the loader passes the CREATE_SUSPENDED flag during this API call.

This flag instructs the operating system to create the process container and allocate the necessary memory but immediately suspends the primary execution thread. The legitimate application's code is loaded into memory, but it has not yet started running.

Step 2: Unmapping (Hollowing) the Legitimate Memory

With the legitimate process suspended, the attacker needs to clear out the memory space to make room for the malicious payload. This is the "hollowing" phase.

The loader typically uses the NtUnmapViewOfSection or ZwUnmapViewOfSection Native API (NTAPI) function. By targeting the base address where the legitimate executable's image was loaded in the suspended process's memory space, the loader effectively unmaps and discards the legitimate code. The process container is now essentially empty, retaining only the structural metadata and the suspended thread.

Step 3: Allocating Memory for the Payload

Next, the loader must carve out a new space within the hollowed process for the malicious payload. The loader uses the VirtualAllocEx API function to allocate a new block of memory within the target process's virtual address space.

The attacker ensures that this new memory block is large enough to hold the malicious payload and is allocated with the appropriate permissions, typically PAGE_EXECUTE_READWRITE, allowing data to be written to it and subsequently executed.

Step 4: Injecting the Malicious Payload

Once the memory is allocated, the loader writes the malicious Portable Executable (PE) file into the newly prepared memory space. This is achieved using the WriteProcessMemory API function.

The loader copies the headers and the various sections (like .text, .data, .rdata) of the malicious executable into the target process, effectively transplanting the malware's brain into the empty shell of the legitimate application.

Step 5: Fixing Memory Structures and Thread Context

Because a new executable has been injected, the loader must adjust the internal structures of the hollowed process to ensure it can execute the new code properly.

First, the loader uses GetThreadContext to retrieve the current state of the suspended primary thread. It then modifies the thread context—specifically updating the EAX (on x86) or RCX (on x64) register to point to the Entry Point of the newly injected malicious payload.

Additionally, the loader must update the Process Environment Block (PEB) of the hollowed process using WriteProcessMemory so that the ImageBaseAddress points to the new base address where the malicious payload was injected.

Step 6: Resuming Execution

Finally, with the legitimate code removed, the malicious code injected, and the thread context updated to point to the malware's starting point, the loader uses the ResumeThread API function.

The operating system "wakes up" the suspended thread. However, instead of executing the original, legitimate code, the thread immediately begins executing the malicious payload. To the casual observer or basic security tool, the legitimate application appears to be running normally.

Process Hollowing is not a theoretical concept; it is actively utilized by a vast array of threat actors, ranging from financially motivated cybercriminals to state-sponsored APT groups.

Banking Trojans and Infostealers

Historically, malware families like Zeus, TrickBot, and Emotet heavily relied on Process Hollowing. These trojans often injected themselves into core Windows processes like explorer.exe or browser processes. By hiding within these trusted processes, the malware could stealthily monitor web traffic, steal banking credentials, and capture keystrokes without raising suspicion from the user or basic antivirus software.

Ransomware Operations

Modern ransomware-as-a-service (RaaS) operations frequently use Process Hollowing to deploy their encryption payloads. For instance, a loader might execute, download the ransomware payload, and then hollow out a legitimate process (such as a Windows utility or a commonly installed application like a PDF reader) to perform the file encryption. This helps the ransomware evade behavioral detection mechanisms that might otherwise block an unknown executable attempting to rapidly modify thousands of files.

Red Teaming and Cobalt Strike

Process Hollowing is a staple technique in adversary simulation. Red Team frameworks like Cobalt Strike utilize a variant of Process Hollowing to execute their "beacons" (the payload that communicates with the command and control server). By default, Cobalt Strike often spawns rundll32.exe or werfault.exe in a suspended state, injects the beacon payload, and resumes execution, allowing Red Teams to simulate advanced persistent threats effectively.

While often used interchangeably, it is important to distinguish Process Hollowing from general Process Injection.

Process Injection is a broad category encompassing various techniques where malicious code is inserted into a running, live process. In standard injection (like DLL Injection or APC Injection), the original legitimate code continues to run alongside the injected malicious code.

Process Hollowing, however, is a specific form of injection where the original legitimate code is completely evicted (unmapped) and replaced entirely by the malicious code. The legitimate application never actually executes; it merely serves as a deceptive container from the moment of creation.

Detecting Process Hollowing is a priority for modern Endpoint Detection and Response (EDR) solutions. Because the technique relies on a specific sequence of API calls and creates discrepancies between memory and disk, defenders can implement robust strategies to detect and mitigate it.

1. Advanced Memory Scanning and Analysis

The most effective defense against Process Hollowing relies on sophisticated memory analysis.

• Memory-Disk Comparison: EDR solutions should periodically compare the memory pages of running processes against their corresponding executable files on disk. In a hollowed process, the executable code mapped in memory will fundamentally differ from the legitimate file residing on the disk. This discrepancy is a massive red flag.
• Scanning Unbacked Memory: Hollowed payloads are often injected into memory allocations that are not backed by a file on disk (unlike normal executables). Security tools must scan memory regions with EXECUTE_READWRITE permissions that lack a corresponding file mapping, utilizing YARA rules to detect known malware signatures in these suspicious memory segments.

2. Behavioral Monitoring and API Hooking

Monitoring the specific sequence of actions required for Process Hollowing can reveal the attack as it happens.

• Suspicious API Sequences: Security tools can hook into Windows APIs to monitor process creation. Detecting a process launching with the CREATE_SUSPENDED flag, immediately followed by calls to NtUnmapViewOfSection, VirtualAllocEx, and WriteProcessMemory targeting the suspended process, is highly indicative of Process Hollowing.
• Parent-Child Process Anomalies: Analyze process lineage. For example, if a seemingly harmless document application spawns cmd.exe or powershell.exe in a suspended state and subsequently injects memory into it, this is anomalous behavior that warrants immediate investigation.

3. Leveraging System Telemetry

Security Operations Centers (SOCs) can utilize built-in Windows telemetry to hunt for Hollowing artifacts.

• Event Tracing for Windows (ETW): ETW provides deep visibility into process execution. Providers like Microsoft-Windows-Kernel-Process can be used to track process creation states and memory allocations. Threat hunters can analyze ETW logs for patterns consistent with the Hollowing API sequence.
• Sysmon Logging: Configure Sysmon with advanced rules to log process creation (Event ID 1) and specifically monitor for processes created in a suspended state. Additionally, Sysmon Event ID 8 (CreateRemoteThread) and Event ID 10 (ProcessAccess) can provide context when a loader attempts to manipulate a target process.

4. Implementing Exploit Mitigation Technologies

While not a silver bullet against Hollowing specifically, implementing broad exploit mitigation technologies can increase the overall difficulty for attackers.

• Windows Defender Application Control (WDAC): Enforcing strict application control policies restricts the initial execution of the malicious dropper or loader required to perform the hollowing attack.
• Arbitrary Code Guard (ACG): ACG prevents the dynamic generation or modification of executable code in memory. While primarily designed to stop exploit payloads, enforcing ACG on critical processes makes it significantly harder for attackers to allocate executable memory and inject payloads using techniques like Process Hollowing.