NtCreateIoCompletion

Prototipo

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

Argumentos

IDs de syscalls por versión de Windows

Stub del syscall

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

Notas no documentadas

Los puertos de finalización de E/S son la primitiva de notificación asíncrona de alto rendimiento que sustenta casi todo servidor Windows: IIS, SQL Server, ThreadPool de .NET, threadpool de Win32, RPC, WinHTTP y la mayoría de pilas de red de terceros. `CreateIoCompletionPort` en kernel32 es un envoltorio delgado que llama a NtCreateIoCompletion la primera vez que ve un handle desconocido. El objeto del kernel almacena una cola doblemente enlazada de entradas KQUEUE, un límite de concurrencia y una lista de hilos actualmente asociados vía NtAssociateWaitCompletionPacket o apilados en NtRemoveIoCompletion. El parámetro `Count` es un tope blando, no un límite rígido — hilos adicionales pueden desencolar si los existentes bloquean.

Uso común por malware

Mayormente benigno por sí mismo — toda aplicación moderna crea estos. La relevancia para PoolParty es estructural: los puertos de finalización son la mitad-cola de la primitiva worker factory. Un atacante crea uno (en su propio proceso o duplicándolo en una víctima), lo cablea a una worker factory vía NtCreateWorkerFactory, y luego usa NtSetIoCompletion para entregar items de trabajo falsificados. El puerto es también la cola que drena NtWaitForWorkViaWorkerFactory. Algunos gadgets de ofuscación de sleep (Ekko, técnicas estilo foliage) abusan de las esperas en puerto de finalización para imitar el perfil de E/S de un servidor inactivo benigno.

Oportunidades de detección

La creación es demasiado común para alertar. La señal interesante es la *topología de handles*: un puerto de finalización creado en el proceso A, duplicado al proceso B vía NtDuplicateObject, e inmediatamente atado a una worker factory en B es un patrón PoolParty de manual. Rastrear duplicaciones de handle de objetos `IoCompletion` cruzando procesos vía ObRegisterCallbacks (o un callback de kernel que hookee PsSetCreateThreadNotifyRoutine para inspeccionar la cola asociada del nuevo hilo) da cobertura de alta fidelidad. El ETW Microsoft-Windows-Kernel-IoCompletion ofrece visibilidad limitada.

Ejemplos de syscalls directos

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

Mapeos MITRE ATT&CK

• T1055Process Injectionmitre ↗
• T1106Native APImitre ↗