NtRemoveIoCompletion

Prototyp

NTSTATUS NtRemoveIoCompletion(
  HANDLE          IoCompletionHandle,
  PVOID          *KeyContext,
  PVOID          *ApcContext,
  PIO_STATUS_BLOCK IoStatusBlock,
  PLARGE_INTEGER  Timeout
);

Argumente

Syscall-IDs pro Windows-Version

Syscall-Stub

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

Ein weiterer außerordentlich stabiler Syscall — `0x9` seit Windows 7. NtRemoveIoCompletion ist die Kernel-Seite von `GetQueuedCompletionStatus`. Er pop't ein Paket aus der KQUEUE des Ports; ist die Queue leer, blockiert er den aufrufenden Thread auf der Wait-List des Ports, bis NtSetIoCompletion gerufen wird, ein echtes I/O abschließt oder das Timeout abläuft. Der Win32-Wrapper übersetzt nur zwischen dem dreifeldrigen Kernel-Return (KeyContext, ApcContext, IoStatusBlock) und der Win32-Vier-Argument-Form (numBytes, completionKey, lpOverlapped).

Häufige Malware-Nutzung

Wie NtCreateIoCompletion ist dieser Syscall in legitimem Code so allgegenwärtig, dass er keine eigenständige Angriffssignatur besitzt. PoolParty-Exploitation ruft ihn nicht direkt auf — die Worker-Factory-Varianten verwenden stattdessen NtWaitForWorkViaWorkerFactory, das an die Factory gebunden ist. NtRemoveIoCompletion taucht in Sleep-Evasion-Gadgets auf, die das Leerlaufmuster eines harmlosen Servers imitieren (Schleife auf NtRemoveIoCompletion mit langem Timeout, Beacon beim Wecken entschlüsseln, vor erneutem Warten wieder verschlüsseln) und in einigen Custom-C2-Transports, die sich an Overlapped-Sockets klammern, um ihren Verkehr im Rauschen legitimer I/O zu vergraben.

Erkennungs­möglichkeiten

Isoliert praktisch nicht erkennbar. Verhaltensanalytik, die Completion-Port-Wartmuster mit dem *Fehlen* korrespondierender realer I/O korreliert, kann Sleep-Gadgets markieren — ein Prozess, der viele Threads in NtRemoveIoCompletion auf einem Port hält, in den niemand außerhalb des Prozesses schreibt, ist anomal. ETW Microsoft-Windows-Kernel-IoCompletion kann Dequeue-Events teuer abtasten. Der realistischste Detektionsvektor bleibt vorgelagert: das verdächtige NtCreateIoCompletion/NtCreateWorkerFactory-Paar fangen, danach wird NtRemoveIoCompletion-Aktivität zur sekundären Evidenz.

Direkte Syscall-Beispiele

for (;;) {
    PVOID key = NULL, apc = NULL;
    IO_STATUS_BLOCK iosb;
    LARGE_INTEGER timeout; timeout.QuadPart = -10000000LL * 30; // 30s rel
    NTSTATUS s = NtRemoveIoCompletion(hIocp, &key, &apc, &iosb, &timeout);
    if (s == STATUS_TIMEOUT) continue;
    if (!NT_SUCCESS(s)) break;
    HandlePacket(key, (LPOVERLAPPED)apc, iosb.Status,
                 (DWORD)iosb.Information);
}

; Stable across every Win10/Win11 build.
NtRemoveIoCompletion PROC
    mov  r10, rcx
    mov  eax, 9
    syscall
    ret
NtRemoveIoCompletion ENDP

// Mimic a benign server's idle pattern. Real implants would also re-encrypt
// their RX region around the wait and timing-correlate with HTTP keep-alives.
use ntapi::ntioapi::{NtRemoveIoCompletion, IO_STATUS_BLOCK};
use winapi::shared::ntdef::LARGE_INTEGER;

unsafe fn napkin_sleep(h_iocp: windows_sys::Win32::Foundation::HANDLE, secs: i64) {
    let mut key: *mut core::ffi::c_void = core::ptr::null_mut();
    let mut apc: *mut core::ffi::c_void = core::ptr::null_mut();
    let mut iosb: IO_STATUS_BLOCK = core::mem::zeroed();
    let mut to: LARGE_INTEGER = core::mem::zeroed();
    *to.QuadPart_mut() = -10_000_000 * secs;
    let _ = NtRemoveIoCompletion(h_iocp, &mut key, &mut apc, &mut iosb, &mut to);
}

MITRE ATT&CK-Mappings

• T1106Native APImitre ↗
• T1027.011Obfuscated Files or Information: Fileless Storagemitre ↗