VirtualAlloc (kernel32.dll)

TLDR: VirtualAlloc reserves and commits a block of memory where the shellcode will be copied and sets the correct permissions (i.e. RW/RX/RWX).

https://learn.microsoft.com/en-us/windows/win32/api/memoryapi/nf-memoryapi-virtualalloc

https://learn.microsoft.com/en-us/windows/win32/Memory/memory-protection-constants

• When using VirtualAlloc with PAGE_EXECUTE_READWRITE (RWX) this often is seen as highly suspicious, normally memory should be allocated as RW first, then changed to RX with VirtualProtect.
• Private Commit : this typically means the shellcode was injected (reflectively loaded) into memory at runtime, and not backed by a file on disk or system-wide resource. An image commit occurs when memory is allocated and committed to load a file (i.e. an executable .exe or dynamic link library .dll) from disk into the process's address space. This is the standard method for loading program code or libraries, where the operating system maps the file into memory using mechanisms like the Portable Executable (PE) loader.
• Unbacked DLL in memory (not loaded with LoadLibrary)
• Just having these 3 imports in the Import Address Table (IAT) is already suspicious

We'll do some forensics on a sample using VirtualAlloc with RWX memory permissions later in the labs.

Executive Summary

VirtualAlloc doesn’t just reserve memory—it sets the stage. As a memory allocation API, it allows a process to carve out space within its own address space, providing a foundation for process injection techniques. While defenders often focus on execution APIs like CreateRemoteThread or SetThreadContext, the real groundwork begins with memory allocation. With memory marked as PAGE_EXECUTE_READWRITE, VirtualAlloc creates a space ready for shellcode. It’s not glamorous, but it’s ubiquitous: from red team toolkits to nation-state malware, VirtualAlloc is the silent enabler of code execution.

What is VirtualAlloc?

VirtualAlloc is a core API from kernel32.dll that allocates memory within the calling process’s address space. It’s a legitimate tool used in a wide range of applications—debuggers, profilers, and automation frameworks—whenever they need to reserve a region of memory for code or data. Unlike VirtualAllocEx, which targets a remote process, VirtualAlloc operates locally, making it simpler but still powerful for preparing memory for payloads. Its versatility makes it a staple in both legitimate and malicious contexts.

Why It Matters

Memory allocation within a process gives attackers a trusted foothold for their code. By reserving memory with VirtualAlloc, malicious code can run within the context of the current process, which may already have elevated privileges or a benign appearance. This avoids the need to spawn a suspicious new process. Think of processes like system utilities or trusted applications. By allocating memory locally, adversaries can stage shellcode, unpack a loader, or prepare for further injection, all while blending into the process’s normal behavior. It’s about stealth and flexibility—executing malicious logic under the guise of a legitimate binary.

How Attackers Abuse It

Attackers often use VirtualAlloc to reserve a memory region within the current process, setting up a staging area for their payload. They write their code into this region using APIs like WriteProcessMemory or direct memory manipulation, effectively embedding malicious logic. From there, they may trigger execution using CreateThread for straightforward execution, queue an APC for stealth, or manipulate existing threads to avoid new thread creation. This technique appears in countless malware families, targeting processes like explorer.exe or system services. By operating within a trusted process, attackers gain stealth, persistence, and access to privileged capabilities, making VirtualAlloc a cornerstone of modern post-exploitation.

Sample Behavior

Detecting malicious use of VirtualAlloc requires looking beyond the API itself to the context of its use. Legitimate tools, like debuggers or performance profilers, use VirtualAlloc in predictable scenarios, often from signed binaries or development environments. Malicious use, however, often appears in suspicious contexts: unsigned executables in temporary directories, unusual process behavior, or memory allocations paired with unexpected thread creation. If VirtualAlloc is followed by thread creation or code execution in a high-value process, it’s a red flag. Suspicious memory allocations in processes with no legitimate need for dynamic memory manipulation—especially combined with unusual execution flows—warrant scrutiny. Context is key.