NtSetIoCompletion

Prototipo

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

Argumentos

IDs de syscalls por versión de Windows

Stub del syscall

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

Notas no documentadas

Equivalente directo de `PostQueuedCompletionStatus`. El paquete se añade a la KQUEUE del puerto y se despierta un esperante (en NtRemoveIoCompletion, NtRemoveIoCompletionEx o NtWaitForWorkViaWorkerFactory). El kernel no interpreta `KeyContext` ni `ApcContext` — se devuelven literales. Esa opacidad hace al syscall muy versátil tanto para el despacho legítimo de E/S asíncrona como para la inyección maliciosa de paquetes forjados.

Uso común por malware

La variante PoolParty 'Worker via Completion Port': abrir el puerto de finalización del threadpool de la víctima (a menudo vía un handle filtrado o NtDuplicateObject), luego emitir NtSetIoCompletion con `ApcContext` apuntando a una estructura con forma `TP_DIRECT` — cuando ntdll!TppWorkerThread desencola el paquete, su dispatcher seguirá los punteros y llamará la función elegida por el atacante. Crucialmente, no necesita asignarse nueva memoria en la víctima si ya existe un gadget utilizable; la inyección se reduce a un solo syscall una vez obtenido el handle. Paquetes de finalización falsificados también han sido usados históricamente por cadenas de exploit contra fallos de callback de Win32k y por varias evasiones de sandbox en navegadores (hilo IO de Chromium, broker de Edge).

Oportunidades de detección

Como NtCreateIoCompletion, el syscall es demasiado común en código legítimo para alertar directamente. La variante inter-proceso es la señal accionable: NtSetIoCompletion sobre un handle cuyo objeto subyacente pertenece a un proceso distinto del llamador es esencialmente nunca legítimo. El ETW Microsoft-Windows-Kernel-IoCompletion puede exponer eventos post a alto coste; un enfoque más liviano es ObRegisterCallbacks sobre el tipo de objeto IoCompletion, condicionado a duplicaciones de handle inter-proceso. La inspección del contenido de paquetes forjados es teóricamente posible pero costosa — contextos con forma de TP_DIRECT desreferenciados en regiones VAD RWX son una heurística creíble.

Ejemplos de syscalls directos

// 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

Mapeos MITRE ATT&CK

• T1055Process Injectionmitre ↗
• T1106Native APImitre ↗