> Windows Syscalls
ntoskrnl.exeT1055T1106

NtReleaseWorkerFactoryWorker

Fordert den Kernel auf, mindestens einen Worker in der Factory verfügbar zu machen — vom User-Mode-Threadpool benutzt, um den Pool beim Einreichen von Arbeit zu wecken.

Prototyp

NTSTATUS NtReleaseWorkerFactoryWorker(
  HANDLE  WorkerFactoryHandle
);

Argumente

NameTypeDirDescription
WorkerFactoryHandleHANDLEinHandle auf die Worker Factory, deren Pending-Worker-Zähler erhöht werden soll.

Syscall-IDs pro Windows-Version

Windows-VersionSyscall-IDBuild
Win10 15070x155win10-1507
Win10 16070x15Cwin10-1607
Win10 17030x162win10-1703
Win10 17090x165win10-1709
Win10 18030x167win10-1803
Win10 18090x168win10-1809
Win10 19030x169win10-1903
Win10 19090x169win10-1909
Win10 20040x16Fwin10-2004
Win10 20H20x16Fwin10-20h2
Win10 21H10x16Fwin10-21h1
Win10 21H20x171win10-21h2
Win10 22H20x171win10-22h2
Win11 21H20x179win11-21h2
Win11 22H20x17Cwin11-22h2
Win11 23H20x17Cwin11-23h2
Win11 24H20x17Ewin11-24h2
Server 20160x15Cwinserver-2016
Server 20190x168winserver-2019
Server 20220x177winserver-2022
Server 20250x17Ewinserver-2025

Kernel-Modul

ntoskrnl.exe → NtReleaseWorkerFactoryWorker

Verwandte APIs

SubmitThreadpoolWorkNtSetIoCompletionNtCreateWorkerFactoryNtWaitForWorkViaWorkerFactoryNtWorkerFactoryWorkerReady

Syscall-Stub

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

Das interne Gegenstück zum 'Worker wecken'-Schritt von `SubmitThreadpoolWork`. Der User-Mode-Wrapper `TpPostWork` posted ein Paket an den Completion-Port und ruft dann NtReleaseWorkerFactoryWorker auf, falls kein wartender Worker zu sehen ist — der Syscall erhöht den Release-Zähler der Factory und bittet den Kernel bei Bedarf, einen zusätzlichen Thread bis zu `ThreadMaximum` zu erzeugen. Zusammen mit NtWorkerFactoryWorkerReady und NtWaitForWorkViaWorkerFactory bildet er den dreiteiligen Worker-Lebenszyklus.

Häufige Malware-Nutzung

In einer PoolParty-'Worker via Completion Port'-Variante posted der Angreifer ein gefälschtes Work-Item über NtSetIoCompletion und ruft dann NtReleaseWorkerFactoryWorker auf, um sicherzustellen, dass ein Worker-Thread es zügig aufgreift — nützlich, wenn der Pool des Opfers untätig ist und das schädliche Paket sonst unbegrenzt in der Queue läge. Prozessübergreifender Aufruf (auf einem duplizierten Remote-Worker-Factory-Handle) ist in legitimem Code selten; er ist ein nützliches stützendes Signal zusammen mit einem cross-process NtCreateWorkerFactory.

PoolParty PoC (completion-port variant)

Erkennungs­möglichkeiten

Intra-process-Invokationen sind laut und nicht handlungsleitend. Die handlungsleitende Signatur ist prozessübergreifend: ein Release auf eine Worker Factory, deren Eigentümerprozess *nicht* der Aufrufer ist. Kernel-Callbacks erkennen dies, indem sie die `ProcessId` des WorkerFactory-Objekts gegen PsGetCurrentProcessId an der Syscall-Stelle vergleichen. Es gibt keine dokumentierte User-Mode-Telemetrie für diesen Syscall.

Direkte Syscall-Beispiele

cWake a worker after posting a forged item

// PoolParty completion-port variant — after NtSetIoCompletion delivered the
// payload, nudge the factory to guarantee a worker thread services it.
NtSetIoCompletion(hIoCompletion, NULL, NULL, STATUS_SUCCESS, 1);
NtReleaseWorkerFactoryWorker(hWorkerFactory);

asmx64 direct stub (Win11 24H2 SSN 0x17E)

NtReleaseWorkerFactoryWorker PROC
    mov  r10, rcx
    mov  eax, 17Eh
    syscall
    ret
NtReleaseWorkerFactoryWorker ENDP

MITRE ATT&CK-Mappings

Last verified: 2026-05-20