EDR Bypass via Telemetry Gaps: What Most Rules Miss

There is a popular framing that 'EDR vendors play whack-a-mole with attackers' - as if every undetection is a missed signature. The framing is mostly wrong. The successful evasion techniques in modern post-exploitation are almost never about hiding from a signature engine; they are about staying outside the telemetry funnel that the signature engine consumes from. If the event never gets logged, the rule never fires. If the rule never fires, the alert never goes to the SOC. The whole defensive stack collapses upstream of any detection logic.

We have observed three classes of telemetry blind spot that account for the overwhelming majority of post-exploitation activity that survives modern, well-tuned EDR. None of these are novel; all of them are well-documented in the offensive community. They keep working because the defensive community has been slower to internalise the implication: a detection that lives downstream of an avoidable telemetry source is fundamentally optional.

Direct syscalls

Most EDRs hook user-mode functions in NTDLL - NtAllocateVirtualMemory, NtProtectVirtualMemory, NtCreateThreadEx - to capture allocations, protection changes, and thread creations during process injection. The hook is a small instruction patch at the start of the function that redirects execution into the EDR's own DLL, where the call is logged and (sometimes) blocked.

If a binary issues syscalls directly - by emitting the syscall instruction itself rather than calling through NTDLL - the hook is never reached. The kernel has no idea anything unusual happened, because nothing unusual happened from its perspective: a process executed a syscall, which is what processes do. The EDR's user-mode visibility into that operation is zero.

; NtAllocateVirtualMemory direct syscall stub on Win11 26100
mov   r10, rcx
mov   eax, 0x18         ; syscall number for the target build
syscall
ret

The mitigation is at the kernel: ETW Threat-Intelligence and Microsoft-Windows-Threat-Intelligence ETW providers report syscall events the EDR can subscribe to. Many EDRs do, but not all syscalls are reported, not all builds are covered, and provider availability varies between Windows versions. The blind spot is shrinking but is far from closed.

Heaven's Gate

On 64-bit Windows, 32-bit processes run in WoW64. Their NTDLL hooks are the 32-bit hooks, but the kernel is 64-bit, and there is a transition point - the famous 'Heaven's Gate' - where execution flips from 32-bit to 64-bit mode to make the actual syscall. If an attacker can flip into 64-bit mode without touching the 32-bit NTDLL hooks, they bypass user-mode telemetry entirely.

Heaven's Gate is old (Roy G. Biv documented it in 2009) and has been written about endlessly, but it remains effective because legacy 32-bit applications still exist in real environments and the transitional code path remains a structural feature of WoW64. The defensive answer is to move off 32-bit applications wherever possible - every time you do, you are removing an entire class of evasion surface from your environment.

Living off the land

The most reliably effective evasion has nothing to do with code at all. It uses signed Microsoft binaries (LOLBINs), legitimate cloud APIs, or operational tools the environment already runs, in ways that are subtly out of policy but indistinguishable from baseline activity at the telemetry layer.

PowerShell, of course, but also: msbuild.exe compiling and running C# in-memory; regsvr32 with scriptlets fetched from /s; cmstp.exe loading SCT-style INFs; Background Intelligent Transfer Service for staged downloads; certutil for base64 decode and binary fetch; rundll32 hosting arbitrary script content via inline PowerShell. None of these binaries are unusual on a domain-joined machine. All of them produce telemetry that looks identical to legitimate use without much more context than 'this binary launched'. The only durable signal is correlation with the rest of the host's behaviour.

What actually works

The pattern across all three blind spots is the same: detection that depends on a single telemetry source is fragile to anyone who knows how to step outside that source. Robust detection is built across multiple, independent signals - kernel events plus identity logs plus network metadata plus process-tree analytics - such that there is no single attacker action that simultaneously evades all of them.

1. Enable kernel-side ETW Threat-Intelligence and require your EDR to consume it. If your EDR doesn't, that is a procurement question, not a detection-engineering question.
2. Treat 32-bit application surface as legacy debt with a security cost. Plan migrations.
3. Build cumulative detections that score across many low-fidelity signals over time, rather than hoping for a single high-fidelity event that the attacker will helpfully not avoid.
4. Audit your own logging coverage. Run the actual evasion techniques against your own platform on a test endpoint and verify what shows up. The gap between what your vendor claims to capture and what you can actually see in the SIEM is, in our experience, larger than most teams expect.

EDR is not a single product capability you buy. It is a posture you operate. The vendors who say otherwise are doing their job. Yours is to stress-test the posture from the inside.