Pool Party Injections: Detecting Abused Work Queues
“Pool Party” groups research variants that redirect Windows thread-pool machinery toward untrusted code. These techniques avoid depending on a conspicuous newly created remote thread, so defenders must inspect memory provenance, handle access, worker state, and callback execution together.
No thread-pool structure layouts, mutation instructions, or runnable examples are provided. The objective is detection and incident response.
Thread-pool architecture
Windows thread pools coordinate reusable worker threads and queued work, timers, waits, I/O completions, and related callbacks. Research variants target different objects or queues, but share a defensive invariant: a process that should not administer another process obtains consequential access, influences executable data or callback state, and causes an existing worker to reach an unexpected address.
Detection model
- Flag rare cross-process access involving worker-factory, completion, timer, wait, or thread-pool-related objects.
- Look for executable private memory or changed image pages in the target process.
- Sample worker-thread stacks and identify callbacks outside signed, expected modules.
- Correlate remote writes with subsequent activity on previously idle worker threads.
- Weight high-value targets such as browsers, identity processes, and management agents more heavily.
Internal pool structures vary by Windows release. Avoid brittle offsets in production logic unless a supported sensor owns version handling. Behavioral correlation is more maintainable.
Investigation and safe testing
Preserve the source and target processes, open-handle relationships, VAD metadata, threads, stacks, modules, and timing. Determine whether the source is signed, expected to instrument the target, and prevalent in the environment. Use Volatility 3, Moneta, PE-sieve, and SwiftOnSecurity's Sysmon configuration as a Windows telemetry reference. For safe validation, create a benign local application that uses documented thread-pool APIs inside its own process, then verify the analytic does not confuse normal callbacks with cross-process manipulation.
ATT&CK, CVEs, and controls
The behavior maps broadly to T1055 Process Injection. Pool Party is a research taxonomy, not a CVE, and normal thread-pool facilities are not vulnerabilities. Apply application control, least privilege, credential isolation, protected-process capabilities where supported, memory and handle telemetry, and target-specific allowlists for legitimate debuggers, accessibility software, and security agents.