ETW in 2026: Why Your EDR's Blind Spot Is a Single ret Instruction

If you've followed EDR/red-team research this year, one number keeps showing up: in CrowdStrike's 2026 Global Threat Report, the vast majority of detections involved no malware at all — attackers logging in with valid credentials and living off signed, trusted binaries instead of dropping a payload a signature can catch. Detection has quietly shifted from "is this file bad" to "is this sequence of behavior normal for this host." And that shift lives or dies on one thing: telemetry.

Which is exactly why ETW (Event Tracing for Windows) has become one of the most fought-over pieces of the Windows security stack.

ETW is the backbone your EDR depends on

ETW is a kernel-level event bus that's been part of Windows for over two decades. Process creation, thread creation, image loads, TCP/UDP connections, file I/O, script execution, AMSI scans — nearly everything that matters for behavioral detection gets fired as a structured event that any subscriber can consume, no hooking or patching required. EDR vendors lean on it heavily to enrich and corroborate whatever their kernel callbacks and minifilter drivers already see.

That centrality is also the problem. If you can blind ETW for a process, you don't need to beat the EDR's logic — you just remove its eyes.

The one-instruction bypass

The technique that keeps showing up in 2026 write-ups is almost comically small. Every ETW provider call in a process ultimately funnels through a single function in ntdll.dll: EtwEventWrite. Patch the first instruction of that function in memory to an immediate ret, and every subsequent call returns instantly without ever emitting an event. No crash, no error, nothing for a naive monitor to catch — the process just goes dark on the ETW side while continuing to run normally. AMSI patching follows the same pattern against a different function.

The realistic countermeasure defenders lean on is watching for unexpected memory writes to ntdll.dll at the exact call sites ETW providers use — essentially, treating "why is a non-debugger process modifying loaded system DLL code" as a signal in itself. It's a good example of why behavioral/sequence detection has become the default in 2026: static signatures can't catch a one-byte patch, but "this process just self-modified a system DLL" is exactly the kind of anomaly sequence-based analytics are built to flag. BYOVD-based EDR killers push this even further by disabling telemetry from kernel level entirely — as of earlier this year, dozens of distinct signed-but-vulnerable drivers were being actively abused this way across ransomware crews.

Why this matters if you're not writing EDR software

Even if you're not building detection products, understanding ETW from the inside changes how you think about Windows security — what "visibility" actually means, why a process can look completely clean to naive monitoring while doing something abnormal, and where the real blind spots sit. The best way to build that intuition isn't reading about ETW, it's consuming it yourself.

That's the itch that got me building easyTw — a single-header C++ wrapper around the raw ETW consumer API. Setting up a working ETW session normally means ~150 lines of boilerplate: building an EVENT_TRACE_PROPERTIES struct with a trailing name buffer, chaining StartTrace/EnableTraceEx2/OpenTrace, running ProcessTrace on its own thread, and decoding raw event blobs via the TDH API. easyTw collapses that down to a handful of lines:

#include "easyTw.hpp"

int main() {
    easyTw::Session s("MySession");
    s.enable(easyTw::providers::KernelProcess);
    s.on_event([](const easyTw::Event& e) {
        if (e.opcode == 1)
            printf("New process: %s (PID %u)\n",
                e.get<std::string>("ImageFileName").c_str(), e.pid);
    });
    s.start();
    Sleep(10000);
    s.stop();
}

Swap in KernelNetwork or KernelFile and you're watching outbound connections or file I/O with the same five lines. It's not a replacement for a real EDR sensor stack — but for prototyping a detection idea, learning what a given provider actually emits, or just satisfying curiosity about what Windows is telling you that most tools never surface, it removes enough friction that you'll actually go do it instead of putting it off.

Takeaway

ETW evasion is a good case study for where endpoint security is right now: the primitives attackers abuse are small and well-documented, the telemetry pipeline they target is the same one defenders depend on, and the fight increasingly happens at the level of "does this specific memory write look normal" rather than "is this file signed." If you want to get past reading about that fight and start seeing the raw event stream yourself, ETW is one API call away — even if the vanilla Win32 way of getting there is 150 lines you'd rather not write by hand.

Repo: github.com/KernelPhantom-010/easyTw — MIT licensed, single header, drop it in and go.