NtWaitForWorkViaWorkerFactory

Prototype

NTSTATUS NtWaitForWorkViaWorkerFactory(
  HANDLE                         WorkerFactoryHandle,
  PFILE_IO_COMPLETION_INFORMATION MiniPacket
);

Arguments

IDs de syscalls par version de Windows

Stub du syscall

4C 8B D1            mov r10, rcx
B8 E6 01 00 00      mov eax, 0x1E6
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

En interne, c'est un dequeue fusionné de l'IoCompletion sous-jacent plus une mise à jour de `WaitingWorkerCount` de la factory. Le paquet renvoyé suit la mise en page à quatre champs de `FILE_IO_COMPLETION_INFORMATION` qu'utilise NtRemoveIoCompletion, mais l'attente est *liée* à la factory — seuls les threads dont la worker factory correspond peuvent consommer sa file, et le noyau utilise ce lien pour faire respecter les limites de threads et les timeouts d'inactivité. Un retour `STATUS_TIMEOUT` pousse le threadpool à envisager la récupération du worker ; un retour réussi le fait sauter dans sa boucle de dispatch.

Usage courant par les malwares

Toute la proposition de valeur de PoolParty est que le noyau ne se soucie *pas* du code qui se trouve s'exécuter sur un thread appelant ce syscall — une fois un worker bloqué ici, tout ce qui est écrit dans le port de complétion amont (ou tout ce que pointent `KeyContext`/`ApcContext` si le dispatcher utilisateur leur fait confiance) devient un flux d'exécution contrôlé par l'utilisateur. La plupart des variantes PoolParty n'émettent pas elles-mêmes NtWaitForWorkViaWorkerFactory : elles laissent le légitime ntdll!TppWorkerThread continuer à l'appeler, puis empoisonnent soit la StartRoutine de la factory, soit les items qu'elle défile. La variante « worker via completion port » forge explicitement des paquets qui, une fois consommés par ce syscall et dispatchés par TppWorkerThread, finissent par appeler du code contrôlé par l'attaquant via l'indirection de callback du threadpool.

Opportunités de détection

Comme NtWorkerFactoryWorkerReady, impossible à signaler isolément — chaque processus Windows moderne a en permanence des dizaines de threads en sommeil ici. La détection doit se concentrer sur le *contenu* des paquets renvoyés. Les providers ETW IoCompletion peuvent échantillonner le trafic du port de complétion ; les écarts entre les contextes de callback attendus (que le threadpool suit en interne dans des structures `TP_DIRECT` / `TP_CALLBACK_INSTANCE`) et ce qui a réellement été délivré sont le signal le plus fiable. Le scan mémoire des piles de threads worker pour des adresses de retour hors des plages ntdll/kernel32 connues est un contrôle comportemental raisonnable après l'observation d'une paire Create/Release inter-processus suspecte.

Exemples de syscalls directs

// Stripped-down clone of ntdll!TppWorkerThread for educational use.
VOID WINAPI MyWorker(PVOID context) {
    HANDLE hWf = (HANDLE)context;
    FILE_IO_COMPLETION_INFORMATION packet;
    for (;;) {
        NTSTATUS s = NtWaitForWorkViaWorkerFactory(hWf, &packet);
        if (s == STATUS_TIMEOUT) break;          // pool decided to reap us
        if (!NT_SUCCESS(s)) break;

        // packet.KeyContext is *not* trusted in legitimate ntdll —
        // it dispatches through internal TP_CALLBACK_INSTANCE tables.
        Dispatch(&packet);

        NtWorkerFactoryWorkerReady(hWf);
    }
}

NtWaitForWorkViaWorkerFactory PROC
    mov  r10, rcx
    mov  eax, 1E6h
    syscall
    ret
NtWaitForWorkViaWorkerFactory ENDP

// Diagnostic helper used in PoolParty research — drains one packet from a
// worker factory and prints the would-be dispatch context.
use ntapi::ntioapi::FILE_IO_COMPLETION_INFORMATION;
use ntapi::ntexapi::NtWaitForWorkViaWorkerFactory;

unsafe fn observe_one(h_wf: windows_sys::Win32::Foundation::HANDLE) {
    let mut p: FILE_IO_COMPLETION_INFORMATION = core::mem::zeroed();
    let s = NtWaitForWorkViaWorkerFactory(h_wf, &mut p);
    if s == 0 {
        eprintln!(
            "KeyContext={:p} ApcContext={:p} Status={:#x} Info={:#x}",
            p.KeyContext, p.ApcContext,
            p.IoStatusBlock.u.Status, p.IoStatusBlock.Information
        );
    }
}

Mappings MITRE ATT&CK

• T1055Process Injectionmitre ↗
• T1027.011Obfuscated Files or Information: Fileless Storagemitre ↗
• T1106Native APImitre ↗