NtCancelWaitCompletionPacket

Prototyp

NTSTATUS NtCancelWaitCompletionPacket(
  HANDLE  WaitCompletionPacketHandle,
  BOOLEAN RemoveSignaledPacket
);

Argumente

Syscall-IDs pro Windows-Version

Syscall-Stub

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

Undokumentierte Hinweise

Bildet ein Paar mit `NtAssociateWaitCompletionPacket`. Das Threadpool-Wait-Subsystem erstellt intern ein `WAIT_COMPLETION_PACKET` (ein Kernel-Object, das ein Dispatcher-Object — Event, Semaphore, Mutant, Timer — und einen IOCP verbindet, in den ein Completion-Eintrag gepostet wird, sobald der Dispatcher signalisiert). `NtCancelWaitCompletionPacket` löst diese Bindung, damit das Paket einem anderen Dispatcher zugeordnet werden kann (typischer Grund, warum ntdll ihn aufruft: `TpSetWait` wiederverwendet ein bestehendes Paket auf dem Wait-Object des Threadpools). Das `RemoveSignaledPacket`-Flag behandelt die Race-Condition, in der das Paket zwischen dem letzten Completion-Poll des Aufrufers und der Cancellation gefeuert hat — TRUE entfernt den verwaisten Completion-Eintrag, damit er nicht unerwartet aus `GetQueuedCompletionStatus` herauspoppt.

Häufige Malware-Nutzung

Im offensiven Einsatz fast immer mit `NtAssociateWaitCompletionPacket` gepaart. In **PoolPartys „Worker Factory via Wait Completion"-Variante** nutzt der Cleanup-Schritt `NtCancelWaitCompletionPacket`, um das gefälschte Paket abzulösen, nachdem der Threadpool-Worker dazu gebracht wurde, in Shellcode zu dispatchen — und hinterlässt die Wait-Infrastruktur sauber zurückgesetzt, damit der Zielprozess beim nächsten legitimen `TpSetWait` nicht abstürzt. Standalone-Einsatz ist offensiv selten: Cancellation allein verleiht keine Fähigkeit. Sie taucht aber gelegentlich als Forensik-Artefakt in Memory-Captures injizierter Prozesse auf — ein `EPROCESS`, dessen Handle-Tabelle ein `WaitCompletionPacket`-Object enthält, das der Prozess nie selbst erzeugt hat, ist ein starker Hinweis auf Injection.

Erkennungs­möglichkeiten

Niedriges Standalone-Signal — die `TpWaitForWait`/`TpSetWait`-Pfade von ntdll emittieren diese Aufrufe in jedem nicht-trivialen Programm ständig. Der Detection-Wert liegt in *prozessübergreifenden* Mustern: Ein Handle vom Typ `WaitCompletionPacket`, das in der Handle-Tabelle eines anderen Prozesses auftaucht (Sysmon-Event 10 / Kernel-Handle-Table-Dumps via `!handle` in WinDbg), ist anomal, weil diese Objekte normalerweise prozesslokal sind. EDRs, die Threadpool-Datenstrukturen (`_TP_TIMER`, `_TP_WAIT`) auf fremde Callback-Adressen überwachen, bringen das breitere PoolParty-Muster ans Licht.

Direkte Syscall-Beispiele

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

MITRE ATT&CK-Mappings

• T1055Process Injectionmitre ↗
• T1106Native APImitre ↗