Bypassing EDR Telemetry with Windows Fibers

TLDR: Windows Fibers offer a stealthy mechanism for code execution that remains largely invisible to standard EDR telemetry. By manipulating the Thread Environment Block and Thread Information Block, attackers can execute shellcode without triggering common thread-based alerts. Researchers can now use the Weetabix tool to enumerate these fibers from memory and identify malicious activity that traditional tools miss.

Modern endpoint detection and response systems have become exceptionally good at flagging suspicious thread creation. If you spawn a thread in a remote process or perform classic process injection, you are almost guaranteed to trigger an alert. This reality has forced offensive researchers to look for more obscure operating system primitives that do not rely on standard thread scheduling. Windows Fibers are exactly that: a legacy, user-mode scheduling mechanism that has been hiding in plain sight since Windows 95.

The Mechanics of Fiber Abuse

Fibers are essentially lightweight, user-mode threads. Unlike standard threads, which are managed by the kernel, fibers are managed entirely by the application. Because the kernel is unaware of them, they do not appear in standard thread enumeration tools. This creates a massive blind spot for security products that rely on kernel-level hooks or standard API calls to monitor execution.

To use a fiber, an application must first convert a standard thread into a fiber using ConvertThreadToFiber. Once converted, the application can create additional fibers, allocate Fiber Local Storage (FLS), and manually switch execution between them using SwitchToFiber. From an attacker's perspective, this is a goldmine. You can execute shellcode within a fiber, and because the context switch happens entirely in user mode, there is no expensive kernel transition to log.

The most dangerous aspect of this technique is the ability to use malicious callbacks. When you allocate FLS, you can define a callback function that executes when the fiber is deleted or the index is freed. An attacker can set up a malicious callback, trigger the cleanup, and execute their payload. Since this cleanup process is a standard part of the application lifecycle, it rarely raises suspicion.

Extracting Telemetry from Memory

Detecting this activity requires a shift in how we approach memory forensics. Because fibers are stored in the heap and not tracked by the kernel, you cannot simply query the OS for a list of active fibers. You have to go into the process memory and parse the internal structures yourself.

The Weetabix tool automates this process. It scans the process heap for fiber objects, which are allocated in fixed 530-byte blocks on 64-bit systems. By parsing the Thread Environment Block (TEB) and the Thread Information Block (TIB), the tool can associate these fiber objects with their parent threads and extract the FLS indices.

Here is how you can manually inspect the TIB to see if a thread is running fibers:

// Check the third bit of the TIB flag field
if (NtCurrentTeb()->NtTib.Self->Flags & 0x4) {
    // Thread is using fibers
}

When you run this against a process, you are looking for anomalies. A legitimate application using fibers will have a predictable structure. A C2 framework like Cobalt Strike using fibers for thread stack spoofing will look different. By comparing the fiber's execution address against known loaded modules, you can quickly identify shellcode running from unbacked memory.

Real-World Implications for Pentesters

During a red team engagement, you will likely encounter EDRs that have moved away from user-land hooks because they are too easy to bypass. These systems now rely heavily on Event Tracing for Windows (ETW) and kernel callbacks for thread creation. By using fibers, you effectively sidestep these monitors.

If you are testing an application that uses fibers, your primary goal is to identify where the fiber objects are stored and whether you can manipulate the FLS callbacks. If you can control the FLS index, you can redirect execution flow to your own shellcode. This is particularly effective against security agents that do not perform deep heap inspection.

Defenders are not entirely helpless, but they need to change their strategy. Relying on thread creation events is no longer sufficient. Security teams must implement memory scanning that specifically looks for the 530-byte heap allocations associated with fiber objects. Furthermore, monitoring for the SwitchToFiber API call in user-mode hooks can provide the necessary visibility into these context switches.

Moving Beyond Standard Detections

The shift toward using obscure OS primitives like fibers highlights a broader trend in offensive security. As EDRs become more sophisticated at detecting common techniques, researchers are moving deeper into the undocumented corners of the Windows API. This is not just about evasion; it is about understanding the operating system better than the people who built the security products.

If you are building detection logic, stop looking for the "what" and start looking for the "how." The fact that a thread is running is less important than how that thread is being scheduled. By focusing on the underlying structures like the TIB and the heap, you can build detections that are resilient to the latest generation of C2 frameworks.

The next time you are on an engagement, take a look at the processes that are heavily using user-mode scheduling. You might find that the most interesting activity is not happening in a new thread, but in a fiber that the OS doesn't even know exists. Keep digging into these structures, because the more we understand about how Windows manages its own resources, the better we can secure them.