Bypassing EDR Heuristics with Windows Fibers

TLDR: Windows Fibers offer a stealthy, underutilized execution mechanism that allows attackers to bypass thread-based detection heuristics. By masking malicious callstacks and performing remote fiber injection, researchers can execute payloads without triggering common EDR alerts. This post breaks down the mechanics of the Phantom Thread and Poison Fiber techniques and introduces the Weetabix tool for detecting these artifacts in memory.

Security researchers often focus on threads as the primary vehicle for code execution, but the Windows API provides a secondary, often ignored mechanism: Fibers. While Microsoft documentation suggests avoiding them, they remain a functional part of the operating system. Because most EDR solutions are tuned to monitor thread creation, context switching, and stack anomalies associated with standard threads, fibers provide a significant blind spot. If you are running a red team engagement, relying solely on thread-based injection techniques is a fast way to get your beacon flagged.

The Mechanics of Fiber-Based Execution

Fibers are essentially stackful coroutines. Unlike threads, which are scheduled by the kernel, fibers are manually scheduled by the application. This user-mode scheduling means the kernel is largely unaware of fiber transitions, which is exactly what makes them dangerous. When you convert a thread to a fiber using ConvertThreadToFiber, you gain the ability to create and switch between multiple execution contexts within a single thread.

From an offensive perspective, this is a delivery mechanism that avoids the noise of creating new threads. Most EDRs hook thread-related APIs to monitor for suspicious activity. By staying within the context of an existing thread, you avoid the kernel-level callbacks that typically trigger alerts. The simplicity of the API is its greatest strength. You allocate a fiber, supply a pointer to your shellcode, and call SwitchToFiber to execute it.

Masking Callstacks with Phantom Thread

The primary challenge with fiber-based execution is detection via callstack analysis. If an EDR performs a stack walk while your shellcode is executing, it will see an unbacked or suspicious return address. The Phantom Thread technique solves this by maintaining a "clean" fiber alongside your malicious one.

When your payload is sleeping or waiting for C2 instructions, you switch execution to an innocent-looking fiber. This innocent fiber has a legitimate callstack that passes standard stack-walking heuristics. The transition is seamless because the application handles the scheduling. By ensuring your malicious fiber is dormant while the innocent one is active, you effectively hide your tracks from periodic memory scanners.

Remote Injection via Poison Fiber

Local execution is useful, but remote injection is where the real impact lies. The Poison Fiber technique allows you to target a remote process that is already using fibers. By enumerating the target process's heap, you can locate existing fiber objects. Once identified, you have two primary options for injection:

1. Direct Overwrite: If you have sufficient space, you can overwrite the existing fiber's context with your shellcode.
2. Callback Injection: You can manipulate the Fiber Local Storage (FLS) callback table. By appending a malicious callback or overwriting an existing one, you force the target application to execute your code when the fiber is eventually deleted or switched.

The following snippet demonstrates how one might identify a fiber object by its heap block size, a consistent artifact across Windows versions:

// Identifying potential fiber objects by heap block size
// Fibers consistently request 0x530 bytes on the heap
if (lpHeapBlockSize == 0x530) {
    // Potential fiber object identified
    // Proceed to validate via Xor'd Stack Cookie
}

This approach is particularly effective because it relies on the target application to trigger the execution for you. You are not calling CreateRemoteThread; you are simply poisoning an existing structure and waiting for the application to perform a routine task.

Real-World Applicability

During a penetration test, you will likely encounter applications that use fibers for performance-critical tasks, such as browsers or audio processing software. If you can gain code execution in these processes, you should immediately check for fiber-based structures. Using Weetabix, you can automate the enumeration of these objects. If you find a dormant fiber, you have a prime candidate for persistent, stealthy execution.

The impact of this technique is high because it forces defenders to change how they monitor memory. Standard EDRs that rely on thread-based telemetry will miss these transitions entirely. If you are a defender, you need to start looking for fiber-specific indicators, such as the SameTebFlags field in the Thread Environment Block (TEB) or the presence of unexpected FLS callbacks.

Defensive Considerations

Defenders must move beyond thread-centric monitoring. While fiber-based attacks are currently niche, they represent a clear path for bypassing modern EDRs. Implementing memory scanning that specifically validates the integrity of the FLS callback table and monitors for suspicious SwitchToFiber calls is a necessary step. Furthermore, auditing the SameTebFlags for threads that should not be running as fibers can provide early warning of an attacker attempting to mask their presence.

As researchers continue to push the boundaries of what is possible in user-mode, the gap between thread-based detection and reality will only widen. Keep an eye on how your EDR handles fiber transitions, and if you are building detection logic, ensure it accounts for the full range of execution primitives available in the Windows API. The next time you see a process that seems to be doing nothing, check the heap for dormant fibers. You might find more than you expected.