Cybersecurity threats continue to evolve, with attackers finding new ways to hide malicious activity. A recently discovered technique, Waiting Thread Hijacking (WTH), takes stealth to the next level. Unlike traditional methods, WTH avoids obvious red flags that most security tools look for. This makes it harder to detect and more dangerous for systems that rely solely on standard protection.

Waiting Thread Hijacking (WTH) is a sophisticated process injection technique that builds upon and enhances traditional Thread Execution Hijacking. Unlike earlier methods, WTH avoids the use of high-risk APIs such as SuspendThread and SetThreadContext, commonly flagged by security tools. Instead, it targets waiting threads within Windows Thread Pools, leveraging standard memory allocation and write operations to execute malicious code discreetly. WTH operates within 64-bit, medium-integrity processes and requires only minimal permissions: PROCESS_VM_OPERATION, PROCESS_VM_READ and PROCESS_VM_WRITE for the process, along with THREAD_GET_CONTEXT for the thread.

Thread Pool Manipulation:

Waiting Thread Hijacking (WTH) exploits the Windows Thread Pool mechanism, originally introduced in Windows Vista to improve efficiency by reusing idle threads for queued tasks. Threads in a passive state typically identified as WrQueue are ideal for hijacking due to their inactivity. WTH uses the NtQuerySystemInformation API with the SystemProcessInformation class to enumerate threads in these states, focusing on those awaiting system calls like NtRemoveIoCompletion or NtWaitForWorkViaWorkerFactory. Instead of suspending threads manually, WTH covertly redirects execution by modifying return addresses on waiting threads.

Covert Execution Flow:

Rather than manipulating thread context directly a common red flag for Endpoint Detection and Response (EDR) systems WTH alters the thread’s return address within its stack. It retrieves the stack pointer using GetThreadContext, locates the return address (usually pointing to functions in ntdll.dll or kernelbase.dll), and replaces it with a reference to malicious shellcode using WriteProcessMemory. Once the thread is reactivated, execution seamlessly transfers to the injected payload, avoiding the use of detection-prone APIs like SetThreadContext or SuspendThread.

Shellcode Design and Process Continuity:

To maintain process integrity and avoid application crashes, WTH embeds a lightweight stub within its shellcode. This stub preserves the thread’s original return address, CPU flags and register states before executing the payload. Once execution completes, the stub restores the saved context and returns execution to its original flow. This ensures stability and avoids synchronization problems commonly associated with traditional Thread Execution Hijacking techniques.

Evasion Through Multi-Process Obfuscation:

To complicate detection by behavior-based monitoring, WTH can fragment its operation across multiple child processes. One process may handle memory allocation, another writes the shellcode, and a third adjusts thread stack values and applies executable permissions. This distributed approach confuses EDRs that rely on detecting linear patterns of malicious behavior within a single process. Furthermore, WTH’s dependence on standard APIs like VirtualAllocEx and WriteProcessMemory makes static signature-based detection (e.g., using YARA rules) considerably harder.

Technical Proof-of-Concept:

The WTH technique has been demonstrated in a proof-of-concept (PoC) implementation publicly available on GitHub. The PoC targets Windows 11 24H2 and uses VirtualAllocEx for memory reservation, WriteProcessMemory for payload injection and NtQuerySystemInformation for thread enumeration. Execution occurs naturally as the modified thread resumes, with the stub ensuring clean return to regular operation. An optional flag, SPLIT_STEPS, enables operation splitting across multiple processes to enhance stealth and evade detection.

Limitations and Detection Strategies:

WTH’s success is partially dependent on how aggressively EDR solutions monitor and block remote memory modifications. While some security products prevent all remote writes, others are more permissive, allowing WTH to bypass protections that thwart other techniques like Thread Naming or APC Injection. Despite its reliance on common APIs, behavioral monitoring—especially focused on remote memory interactions and their timing—remains one of the few viable detection strategies. WTH effectively shifts the detection burden from suspicious execution APIs to stealthy write operations, underscoring the importance of adaptive and context-aware EDR techniques.

Conclusion:

Waiting Thread Hijacking (WTH) introduces a stealthy and effective evolution of process injection by exploiting idle threads within Windows Thread Pools. Its use of benign APIs and multi-process obfuscation enables it to bypass traditional EDR detection mechanisms. By avoiding suspicious actions like thread suspension or context manipulation, WTH significantly reduces its footprint. However, its reliance on remote memory operations highlights the need for advanced behavioral monitoring. As attackers continue to refine such techniques, security solutions must evolve to detect and respond to increasingly subtle threats.