NtSetIoCompletion

Prototype

NTSTATUS NtSetIoCompletion(
  HANDLE     IoCompletionHandle,
  PVOID      KeyContext,
  PVOID      ApcContext,
  NTSTATUS   IoStatus,
  ULONG_PTR  IoStatusInformation
);

Arguments

Syscall IDs by Windows version

Syscall stub

4C 8B D1            mov r10, rcx
B8 B3 01 00 00      mov eax, 0x1B3
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

Direct equivalent of `PostQueuedCompletionStatus`. The packet is appended to the port's KQUEUE and one waiter (in NtRemoveIoCompletion, NtRemoveIoCompletionEx, or NtWaitForWorkViaWorkerFactory) is woken. The kernel does not interpret `KeyContext` or `ApcContext` — they are echoed back verbatim. That opacity is what makes the syscall so versatile both for legitimate async I/O dispatch and for malicious forged-packet injection.

Common malware usage

The 'Worker via Completion Port' PoolParty variant: open the victim's threadpool completion port (often via a leaked handle or NtDuplicateObject), then issue NtSetIoCompletion with `ApcContext` pointing at a structure shaped like a `TP_DIRECT` — when ntdll!TppWorkerThread dequeues the packet, its dispatcher will follow the pointers and call the function the attacker chose. Crucially, no new memory needs to be allocated in the victim if a usable gadget already exists; the entire injection collapses to a single syscall once the handle is obtained. Forged completion packets have also been used historically by exploit chains targeting Win32k callback flaws and by various sandbox escapes in browsers (Chromium's IO thread, Edge's broker).

Detection opportunities

Like NtCreateIoCompletion, the syscall is far too common in legitimate code to alert on directly. The cross-process variant is the actionable signal: NtSetIoCompletion on a handle whose underlying object's owning process differs from the caller is essentially never legitimate. ETW Microsoft-Windows-Kernel-IoCompletion can expose post events at high cost; a lower-overhead approach is ObRegisterCallbacks on the IoCompletion object type, gating on cross-process handle duplications. Forged-packet content inspection is theoretically possible but expensive — TP_DIRECT-shaped contexts dereferenced into RWX VAD regions are a credible heuristic.

Direct syscall examples

// hRemoteIocp is a handle in OUR address space that maps to the VICTIM's
// threadpool completion port (obtained via NtDuplicateObject or handle leak).
// pVictimGadget is a writable+executable address in the victim already shaped
// like a TP_DIRECT entry whose callback field points at shellcode.
NTSTATUS s = NtSetIoCompletion(
    hRemoteIocp,
    NULL,                  // KeyContext — irrelevant for TP_DIRECT path
    pVictimGadget,         // ApcContext — what TppWorkerThread will dispatch through
    STATUS_SUCCESS,
    0);                    // Information

// Plain PostQueuedCompletionStatus equivalent — every server you've written
// uses this under the hood.
NtSetIoCompletion(hIocp,
                  (PVOID)42,           // your CompletionKey
                  (PVOID)pOverlapped,  // your OVERLAPPED*
                  STATUS_SUCCESS,
                  bytesTransferred);

NtSetIoCompletion PROC
    mov  r10, rcx
    mov  eax, 1B3h
    syscall
    ret
NtSetIoCompletion ENDP

MITRE ATT&CK mappings

• T1055Process Injectionmitre ↗
• T1106Native APImitre ↗