NtCreateIoCompletion

Prototype

NTSTATUS NtCreateIoCompletion(
  PHANDLE             IoCompletionHandle,
  ACCESS_MASK         DesiredAccess,
  POBJECT_ATTRIBUTES  ObjectAttributes,
  ULONG               Count
);

Arguments

Syscall IDs by Windows version

Syscall stub

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

I/O completion ports are the high-performance asynchronous notification primitive that underpins almost every Windows server: IIS, SQL Server, .NET ThreadPool, Win32 threadpool, RPC, WinHTTP, and most third-party network stacks. `CreateIoCompletionPort` in kernel32 is a thin wrapper that calls NtCreateIoCompletion the first time it sees an unrecognised handle. The kernel object stores a doubly-linked queue of KQUEUE entries, a concurrency limit, and a list of threads currently associated via NtAssociateWaitCompletionPacket or stacked in NtRemoveIoCompletion. The `Count` parameter is a soft cap, not a hard limit — extra threads can dequeue if existing ones block.

Common malware usage

Mostly benign on its own — every modern application creates these. The PoolParty relevance is structural: completion ports are the queue half of the worker factory primitive. An attacker creates one (in their own process or by duplicating into a victim), wires it into a worker factory via NtCreateWorkerFactory, and then uses NtSetIoCompletion to deliver forged work items. The completion port is also the queue NtWaitForWorkViaWorkerFactory drains. Some sleep-obfuscation gadgets (e.g. Ekko, foliage-style techniques) abuse completion-port waits to mimic the I/O profile of a benign idle server.

Detection opportunities

Creation is too common to alert on. The interesting signal is *handle topology*: a completion port created in process A, duplicated into process B via NtDuplicateObject, and then immediately bound to a worker factory in process B is a textbook PoolParty pattern. Tracking handle duplications of `IoCompletion` objects across process boundaries via ObRegisterCallbacks (or a kernel callback hooking PsSetCreateThreadNotifyRoutine to inspect the new thread's bound queue) gives high-fidelity coverage. ETW Microsoft-Windows-Kernel-IoCompletion provides limited visibility.

Direct syscall examples

HANDLE hIoCompletion = NULL;
OBJECT_ATTRIBUTES oa;
InitializeObjectAttributes(&oa, NULL, 0, NULL, NULL);
NTSTATUS s = NtCreateIoCompletion(
    &hIoCompletion,
    IO_COMPLETION_ALL_ACCESS,
    &oa,
    0);                                  // 0 = NumberOfProcessors concurrency
if (!NT_SUCCESS(s)) return s;

// Create locally, then duplicate INTO the victim — the victim's worker factory
// will be bound to it in the next step.
HANDLE hLocal = NULL, hRemote = NULL;
OBJECT_ATTRIBUTES oa; InitializeObjectAttributes(&oa, NULL, 0, NULL, NULL);
NtCreateIoCompletion(&hLocal, IO_COMPLETION_ALL_ACCESS, &oa, 1);
NtDuplicateObject(NtCurrentProcess(), hLocal,
                  hVictim, &hRemote,
                  0, 0, DUPLICATE_SAME_ACCESS);

NtCreateIoCompletion PROC
    mov  r10, rcx
    mov  eax, 0B2h
    syscall
    ret
NtCreateIoCompletion ENDP

MITRE ATT&CK mappings

• T1055Process Injectionmitre ↗
• T1106Native APImitre ↗