NtSetIoCompletion

Prototyp

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

Argumente

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

Undokumentierte Hinweise

Direktes Pendant zu `PostQueuedCompletionStatus`. Das Paket wird an die KQUEUE des Ports angehängt und ein Wartender (in NtRemoveIoCompletion, NtRemoveIoCompletionEx oder NtWaitForWorkViaWorkerFactory) wird geweckt. Der Kernel interpretiert weder `KeyContext` noch `ApcContext` — sie werden wortgetreu zurückgereicht. Diese Undurchsichtigkeit macht den Syscall so vielseitig: für legitimes asynchrones I/O-Dispatch wie für bösartige Forged-Packet-Injection.

Häufige Malware-Nutzung

Die PoolParty-'Worker via Completion Port'-Variante: den Threadpool-Completion-Port des Opfers öffnen (oft über einen geleakten Handle oder NtDuplicateObject), dann NtSetIoCompletion mit `ApcContext` aussenden, der auf eine `TP_DIRECT`-förmige Struktur zeigt — wenn ntdll!TppWorkerThread das Paket dequeue't, folgt sein Dispatcher den Pointern und ruft die vom Angreifer gewählte Funktion auf. Entscheidend: es muss kein neuer Speicher im Opfer alloziert werden, wenn ein brauchbares Gadget existiert; die Injection schrumpft auf einen einzigen Syscall, sobald der Handle vorliegt. Gefälschte Completion-Pakete wurden auch historisch in Exploit-Ketten gegen Win32k-Callback-Schwachstellen und in diversen Sandbox-Escapes in Browsern (Chromium-IO-Thread, Edge-Broker) verwendet.

Erkennungs­möglichkeiten

Wie NtCreateIoCompletion ist der Syscall in legitimem Code viel zu häufig, um direkt zu alarmieren. Die cross-process-Variante ist das handlungsleitende Signal: NtSetIoCompletion auf einem Handle, dessen zugrundeliegendes Objekt einem anderen Prozess gehört als dem Aufrufer, ist im Wesentlichen nie legitim. ETW Microsoft-Windows-Kernel-IoCompletion kann Post-Events teuer offenlegen; ein günstigerer Ansatz ist ObRegisterCallbacks am IoCompletion-Objekttyp, gegated über cross-process Handle-Duplikationen. Inhaltsinspektion gefälschter Pakete ist theoretisch möglich, aber teuer — TP_DIRECT-förmige Kontexte, die in RWX-VAD-Regionen dereferenziert werden, sind eine plausible Heuristik.

Direkte Syscall-Beispiele

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