NtAllocateVirtualMemoryEx

Prototype

NTSTATUS NtAllocateVirtualMemoryEx(
  HANDLE                 ProcessHandle,
  PVOID                 *BaseAddress,
  PSIZE_T                RegionSize,
  ULONG                  AllocationType,
  ULONG                  PageProtection,
  PMEM_EXTENDED_PARAMETER ExtendedParameters,
  ULONG                  ExtendedParameterCount
);

Arguments

Syscall IDs by Windows version

Syscall stub

4C 8B D1            mov r10, rcx
B8 78 00 00 00      mov eax, 0x78
F6 04 25 08 03 FE 7F 01   test byte ptr [0x7FFE0308], 1
75 03               jne short +3
0F 05               syscall
C3                  ret
CD 2E               int 2Eh
C3                  ret

Undocumented notes

NtAllocateVirtualMemoryEx was introduced in Windows 10 1803 to back the new VirtualAlloc2 / VirtualAlloc2FromApp APIs. Its SSN has shifted three times within the supported window — 0x74 on RS4–19H2, 0x76 from 20H1 through 23H2, and 0x78 on 24H2 / Server 2025 — so dynamic resolution (Hell's Gate / Halo's Gate / Tartarus' Gate) is mandatory when targeting more than one channel. Compared with NtAllocateVirtualMemory it adds the MEM_EXTENDED_PARAMETER array and supports placeholder allocations (used by Windows for sparse mappings and memfd-style file mappings).

Common malware usage

Increasingly preferred over the classic NtAllocateVirtualMemory for three reasons. (1) **Less-hooked surface**: many EDRs only patch NtAllocateVirtualMemory, leaving the Ex variant uninstrumented; recent BumbleBee, IcedID, and Latrodectus loaders explicitly call the Ex path for this reason. (2) **PAGE_TARGETS_INVALID** marks the new region as not-a-valid-indirect-call-target under CFG, then the loader switches it to PAGE_EXECUTE_READ; this is the documented way to bypass CFG when the host enables it. (3) **MEM_EXTENDED_PARAMETER with MemExtendedParameterAddressRequirements** lets the implant request an allocation at a precise high-entropy address, useful for spoofing module-like base addresses in remote processes.

Detection opportunities

Cross-process allocations via the Ex path with non-zero ExtendedParameterCount are uncommon outside graphics drivers and AppContainer brokers — alertable. ETW Threat Intelligence's `EtwTiLogAllocExecVm` callback fires on the Ex path as well as the classic call. Sysmon does not natively distinguish the two; correlation with NtWriteVirtualMemory / NtCreateThreadEx remains the cheapest behavioural signal. EDR vendors that hook only NtAllocateVirtualMemory will miss this entirely — verify hook coverage on both names during purple-team work.

Direct syscall examples

; Direct syscall stub for NtAllocateVirtualMemoryEx (SSN 0x78 on 24H2/2025)
NtAllocateVirtualMemoryEx PROC
    mov  r10, rcx          ; syscall convention
    mov  eax, 78h          ; SSN — RESOLVE DYNAMICALLY for multi-build targeting
    syscall
    ret
NtAllocateVirtualMemoryEx ENDP

// Allocate RWX page that CFG will not accept as a valid indirect call target.
// Then flip to RX before calling — defeats CFG-only mitigations.
#include <windows.h>

typedef NTSTATUS (NTAPI *pNtAllocateVirtualMemoryEx)(
    HANDLE, PVOID*, PSIZE_T, ULONG, ULONG, PMEM_EXTENDED_PARAMETER, ULONG);

PVOID  base = NULL;
SIZE_T size = 0x1000;
pNtAllocateVirtualMemoryEx Fn = (pNtAllocateVirtualMemoryEx)
    GetProcAddress(GetModuleHandleA("ntdll.dll"), "NtAllocateVirtualMemoryEx");
Fn((HANDLE)-1, &base, &size,
   MEM_COMMIT | MEM_RESERVE,
   PAGE_EXECUTE_READWRITE | PAGE_TARGETS_INVALID,
   NULL, 0);

// Cargo: windows-sys = "0.59" (Win32_System_Memory)
use windows_sys::Win32::System::Memory::{
    VirtualAlloc2, MEM_COMMIT, MEM_RESERVE, PAGE_EXECUTE_READWRITE,
};

pub unsafe fn alloc_rwx(size: usize) -> *mut core::ffi::c_void {
    VirtualAlloc2(0, core::ptr::null_mut(), size,
                  MEM_COMMIT | MEM_RESERVE,
                  PAGE_EXECUTE_READWRITE,
                  core::ptr::null_mut(), 0)
}

MITRE ATT&CK mappings

• T1055Process Injectionmitre ↗
• T1620Reflective Code Loadingmitre ↗
• T1106Native APImitre ↗