NtRemoveIoCompletion

Prototype

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

Arguments

IDs de syscalls par version de Windows

Stub du syscall

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

Notes non documentées

Autre syscall extraordinairement stable — `0x9` depuis Windows 7. NtRemoveIoCompletion est le côté noyau de `GetQueuedCompletionStatus`. Il dépile un paquet de la KQUEUE du port ; si la file est vide il bloque le thread appelant sur la liste d'attente du port jusqu'à un NtSetIoCompletion, la complétion d'une E/S réelle, ou l'expiration du timeout. Le wrapper Win32 ne fait que traduire entre le retour à trois champs du noyau (KeyContext, ApcContext, IoStatusBlock) et la forme à quatre arguments Win32 (numBytes, completionKey, lpOverlapped).

Usage courant par les malwares

Comme NtCreateIoCompletion, ce syscall est si ubiquitaire en code légitime qu'il n'a aucune signature d'attaque isolée. L'exploitation PoolParty ne l'invoque pas directement — les variantes worker factory utilisent NtWaitForWorkViaWorkerFactory à la place, lié à la factory. NtRemoveIoCompletion apparaît dans les gadgets d'évasion de sleep qui imitent le pattern d'inactivité d'un serveur bénin (boucle sur NtRemoveIoCompletion avec long timeout, déchiffre le beacon au réveil, rechiffre avant de retourner attendre) et dans certains transports C2 personnalisés qui se greffent sur des sockets overlapped pour enterrer leur trafic dans le bruit d'E/S légitimes.

Opportunités de détection

Indétectable de façon isolée en pratique. Les analytiques comportementales qui corrèlent les patterns d'attente sur port de complétion avec l'*absence* d'E/S réelles correspondantes peuvent signaler les gadgets de sleep — un processus qui maintient de nombreux threads dans NtRemoveIoCompletion sur un port que personne hors du processus n'écrit est anormal. ETW Microsoft-Windows-Kernel-IoCompletion peut échantillonner les événements de dequeue à coût élevé. Le vecteur de détection le plus réaliste reste en amont : attraper la paire suspecte NtCreateIoCompletion/NtCreateWorkerFactory, puis l'activité NtRemoveIoCompletion devient un indice secondaire.

Exemples de syscalls directs

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);
}

Mappings MITRE ATT&CK

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