NtCreateIoCompletion

Prototype

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

Arguments

IDs de syscalls par version de Windows

Stub du 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

Notes non documentées

Les ports de complétion d'E/S sont la primitive de notification asynchrone à haute performance qui sous-tend presque tout serveur Windows : IIS, SQL Server, ThreadPool .NET, threadpool Win32, RPC, WinHTTP et la plupart des piles réseau tierces. `CreateIoCompletionPort` dans kernel32 est un mince wrapper qui appelle NtCreateIoCompletion la première fois qu'il voit un handle inconnu. L'objet noyau stocke une file doublement chaînée d'entrées KQUEUE, une limite de concurrence et une liste de threads actuellement associés via NtAssociateWaitCompletionPacket ou empilés dans NtRemoveIoCompletion. Le paramètre `Count` est un plafond souple, pas une limite stricte — des threads supplémentaires peuvent défiler si les existants bloquent.

Usage courant par les malwares

Le plus souvent bénin en soi — toute application moderne en crée. La pertinence PoolParty est structurelle : les ports de complétion sont la moitié file de la primitive worker factory. Un attaquant en crée un (dans son processus ou par duplication chez la victime), le câble à une worker factory via NtCreateWorkerFactory, puis utilise NtSetIoCompletion pour délivrer des items de travail forgés. Le port est aussi la file que NtWaitForWorkViaWorkerFactory vide. Certains gadgets d'obfuscation de sleep (Ekko, techniques style foliage) abusent les attentes sur port de complétion pour imiter le profil d'E/S d'un serveur inactif bénin.

Opportunités de détection

La création est trop courante pour alerter. Le signal intéressant est la *topologie de handle* : un port de complétion créé dans le processus A, dupliqué dans le processus B via NtDuplicateObject, puis immédiatement lié à une worker factory dans B est un schéma PoolParty d'école. Suivre les duplications de handle d'objets `IoCompletion` entre processus via ObRegisterCallbacks (ou un callback noyau hookant PsSetCreateThreadNotifyRoutine pour inspecter la file liée du nouveau thread) donne une couverture haute fidélité. L'ETW Microsoft-Windows-Kernel-IoCompletion offre une visibilité limitée.

Exemples de syscalls directs

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

Mappings MITRE ATT&CK

• T1055Process Injectionmitre ↗
• T1106Native APImitre ↗