NtReleaseWorkerFactoryWorker
Demande au noyau de rendre au moins un worker disponible dans la factory — utilisé par le threadpool utilisateur pour réveiller le pool à la soumission de travail.
Prototype
NTSTATUS NtReleaseWorkerFactoryWorker( HANDLE WorkerFactoryHandle );
Arguments
| Name | Type | Dir | Description |
|---|---|---|---|
| WorkerFactoryHandle | HANDLE | in | Handle vers la worker factory dont le compteur de workers en attente doit être incrémenté. |
IDs de syscalls par version de Windows
| Version de Windows | ID de syscall | Build |
|---|---|---|
| Win10 1507 | 0x155 | win10-1507 |
| Win10 1607 | 0x15C | win10-1607 |
| Win10 1703 | 0x162 | win10-1703 |
| Win10 1709 | 0x165 | win10-1709 |
| Win10 1803 | 0x167 | win10-1803 |
| Win10 1809 | 0x168 | win10-1809 |
| Win10 1903 | 0x169 | win10-1903 |
| Win10 1909 | 0x169 | win10-1909 |
| Win10 2004 | 0x16F | win10-2004 |
| Win10 20H2 | 0x16F | win10-20h2 |
| Win10 21H1 | 0x16F | win10-21h1 |
| Win10 21H2 | 0x171 | win10-21h2 |
| Win10 22H2 | 0x171 | win10-22h2 |
| Win11 21H2 | 0x179 | win11-21h2 |
| Win11 22H2 | 0x17C | win11-22h2 |
| Win11 23H2 | 0x17C | win11-23h2 |
| Win11 24H2 | 0x17E | win11-24h2 |
| Server 2016 | 0x15C | winserver-2016 |
| Server 2019 | 0x168 | winserver-2019 |
| Server 2022 | 0x177 | winserver-2022 |
| Server 2025 | 0x17E | winserver-2025 |
Module noyau
APIs liées
Stub du syscall
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
Notes non documentées
Le pendant interne de l'étape « réveiller un worker » de `SubmitThreadpoolWork`. Le wrapper utilisateur `TpPostWork` poste un paquet sur le port de complétion puis appelle NtReleaseWorkerFactoryWorker s'il ne voit aucun worker en attente — le syscall incrémente le compteur de release de la factory et, si nécessaire, demande au noyau de créer un thread supplémentaire jusqu'à `ThreadMaximum`. Avec NtWorkerFactoryWorkerReady et NtWaitForWorkViaWorkerFactory, il forme le cycle de vie à trois appels du worker.
Usage courant par les malwares
Dans une variante PoolParty « worker via completion port », l'attaquant poste un item de travail forgé via NtSetIoCompletion puis appelle NtReleaseWorkerFactoryWorker pour garantir qu'un thread worker le récupère rapidement — utile quand le pool de la victime est inactif et laisserait sinon le paquet malicieux en file indéfiniment. L'appel inter-processus (sur un handle de worker factory distant dupliqué) est rare en code légitime ; c'est un signal corroborant utile en conjonction avec un NtCreateWorkerFactory inter-processus.
Opportunités de détection
Les invocations intra-processus sont bruyantes et non actionnables. La signature actionnable est inter-processus : un Release sur une worker factory dont le processus propriétaire n'est *pas* l'appelant. Les callbacks noyau peuvent l'identifier en lisant le `ProcessId` de l'objet WorkerFactory et en le comparant à PsGetCurrentProcessId sur le site du syscall. Aucune télémétrie utilisateur documentée pour ce syscall.
Exemples de syscalls directs
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 ENDPMappings MITRE ATT&CK
Last verified: 2026-05-20