NtCreateIoCompletion

Prototyp

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

Argumente

Syscall-IDs pro 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

Undokumentierte Hinweise

I/O-Completion-Ports sind die hochperformante asynchrone Benachrichtigungs-Primitive, die fast jeden Windows-Server trägt: IIS, SQL Server, .NET-ThreadPool, Win32-Threadpool, RPC, WinHTTP und die meisten Netzwerk-Stacks Dritter. `CreateIoCompletionPort` in kernel32 ist ein dünner Wrapper, der NtCreateIoCompletion beim ersten Sichten eines unbekannten Handles aufruft. Das Kernel-Objekt speichert eine doppelt verkettete Queue von KQUEUE-Einträgen, ein Concurrency-Limit und eine Liste aktuell zugeordneter Threads (via NtAssociateWaitCompletionPacket oder in NtRemoveIoCompletion gestapelt). Der `Count`-Parameter ist eine weiche Obergrenze, kein hartes Limit — zusätzliche Threads dürfen dequeuen, wenn bestehende blockieren.

Häufige Malware-Nutzung

Für sich genommen meist harmlos — jede moderne Anwendung erzeugt diese. Die PoolParty-Relevanz ist strukturell: Completion-Ports sind die Queue-Hälfte der Worker-Factory-Primitive. Ein Angreifer erzeugt einen (im eigenen Prozess oder per Duplikation in ein Opfer), verdrahtet ihn via NtCreateWorkerFactory mit einer Worker Factory und liefert dann via NtSetIoCompletion gefälschte Work-Items. Der Port ist auch die Queue, die NtWaitForWorkViaWorkerFactory leert. Manche Sleep-Obfuskations-Gadgets (Ekko, foliage-artige Techniken) missbrauchen Completion-Port-Waits, um das I/O-Profil eines harmlosen Idle-Servers zu imitieren.

Erkennungs­möglichkeiten

Erzeugung ist zu häufig, um zu alarmieren. Das interessante Signal ist die *Handle-Topologie*: ein in Prozess A erzeugter Completion-Port, via NtDuplicateObject in Prozess B dupliziert und dort sofort an eine Worker Factory gebunden, ist ein Lehrbuch-PoolParty-Muster. Das Verfolgen von Handle-Duplikationen von `IoCompletion`-Objekten über Prozessgrenzen via ObRegisterCallbacks (oder ein Kernel-Callback, der PsSetCreateThreadNotifyRoutine hookt, um die gebundene Queue des neuen Threads zu inspizieren) liefert hochwertige Abdeckung. ETW Microsoft-Windows-Kernel-IoCompletion bietet begrenzte Sichtbarkeit.

Direkte Syscall-Beispiele

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 ↗