NtCancelWaitCompletionPacket

Prototype

NTSTATUS NtCancelWaitCompletionPacket(
  HANDLE  WaitCompletionPacketHandle,
  BOOLEAN RemoveSignaledPacket
);

Arguments

IDs de syscalls par version de Windows

Stub du syscall

4C 8B D1            mov r10, rcx
B8 97 00 00 00      mov eax, 0x97      ; Win11 24H2 SSN
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

S'apparie avec `NtAssociateWaitCompletionPacket`. Le sous-système d'attente du threadpool crée en interne un `WAIT_COMPLETION_PACKET` (un objet noyau qui lie ensemble un dispatcher object — event, sémaphore, mutant, timer — et un IOCP dans lequel une entrée de completion sera postée lorsque le dispatcher signalera). `NtCancelWaitCompletionPacket` délie le paquet pour qu'il puisse être réassocié à un autre dispatcher (la raison typique pour laquelle ntdll l'appelle : un `TpSetWait` réutilise un paquet existant sur l'objet wait du threadpool). Le flag `RemoveSignaledPacket` gère la course où le paquet a tiré entre le dernier sondage de completion de l'appelant et l'annulation — TRUE consomme l'entrée de completion orpheline pour qu'elle ne sorte pas de `GetQueuedCompletionStatus` de manière inattendue.

Usage courant par les malwares

Presque toujours apparié à `NtAssociateWaitCompletionPacket` dans l'usage offensif. Dans la **variante « Worker Factory via Wait Completion » de PoolParty**, l'étape de nettoyage utilise `NtCancelWaitCompletionPacket` pour détacher le paquet falsifié après que le worker threadpool a été incité à dispatcher dans du shellcode — laissant l'infrastructure d'attente proprement réinitialisée pour que le processus cible ne plante pas au prochain `TpSetWait` légitime. L'usage isolé est rare offensivement : l'annulation seule ne confère aucune capacité. Elle apparaît cependant parfois comme artefact forensique dans les captures mémoire de processus injectés — un `EPROCESS` dont la table de handles contient un objet `WaitCompletionPacket` que le processus n'a jamais créé lui-même est un fort indicateur d'injection.

Opportunités de détection

Faible signal isolé — les chemins `TpWaitForWait`/`TpSetWait` de ntdll émettent ces appels en continu dans tout programme non trivial. La valeur de détection réside dans les motifs *cross-process* : un handle de type `WaitCompletionPacket` apparaissant dans la table de handles d'un autre processus (Sysmon Event 10 / dumps de table de handles noyau via `!handle` dans WinDbg) est anormal car ces objets sont normalement process-local. Les EDR qui surveillent les structures de données du threadpool (`_TP_TIMER`, `_TP_WAIT`) à la recherche d'adresses de callback étrangères feront remonter le pattern PoolParty plus large.

Exemples de syscalls directs

// Reuse an existing wait packet on a different event.
NtCancelWaitCompletionPacket(hPacket, TRUE /* eat orphan completion */);
NtAssociateWaitCompletionPacket(
    hPacket,
    hIoCompletion,
    hNewEvent,                      // new dispatcher
    (PVOID)keyContext, (PVOID)apc,
    STATUS_SUCCESS, 0, NULL);

; NtCancelWaitCompletionPacket direct syscall (Win11 24H2 SSN 0x97)
NtCancelWaitCompletionPacket PROC
    mov  r10, rcx
    mov  eax, 97h
    syscall
    ret
NtCancelWaitCompletionPacket ENDP

Mappings MITRE ATT&CK

• T1055Process Injectionmitre ↗
• T1106Native APImitre ↗