There’s an arms race happening at the endpoint. EDR products represent a genuine leap forward in enterprise security: behavioral monitoring, continuous telemetry, automated response. When an EDR agent is working correctly, it provides extraordinary visibility. Adversaries know this. The EDR agent is the single most consequential obstacle between initial access and mission completion. So it’s become the primary target.
The Architecture Adversaries Understand Better Than Most Defenders
EDR is not a single product. It is a stack of monitoring layers, each operating at a different level of the operating system, with distinct trust boundaries and distinct failure points. Attackers do not think about EDR as a monolithic tool to evade. They think about which specific layer to attack based on what access they have and what they need to accomplish. Defenders need to think the same way.
- Userland hooks: When a process runs on a Windows endpoint, EDR injects a monitoring library into it and modifies the Windows API functions that process uses to interact with the operating system. Every sensitive call gets intercepted and inspected before it reaches the kernel. Think of it as a wiretap on the calls a process makes. The structural weakness: the wiretap lives in the memory of the process being monitored, which means the process itself can find it and remove it.
- Kernel callbacks: EDR also registers notification routines directly with the Windows kernel that fire when key system events occur: a new process starts, a thread is created, a driver is loaded. These run at a higher privilege level than userland hooks and are harder to tamper with from within a normal user process. The tradeoff is that they report that something happened without the detailed context that userland hooks capture.
- ETW Threat Intelligence: Windows includes a kernel-level telemetry system called Event Tracing for Windows (ETW) with a security-focused provider that records sensitive operations such as cross-process memory access and remote thread creation. Because these events originate inside the kernel, no amount of tampering with user-space code can suppress them. They can, however, be turned off entirely if an attacker achieves kernel-level execution.
- Minifilter drivers: EDR deploys file system drivers that intercept read and write operations at the kernel level, allowing it to inspect file content in real time, detect the bulk encryption behavior characteristic of ransomware, and flag suspicious access patterns before damage is done.
- AMSI (Antimalware Scan Interface): Attackers frequently try to hide malicious scripts by encoding or obfuscating the content before it runs. AMSI strips that away. Script hosts like PowerShell pass content through AMSI after all the encoding has been unwound, so the EDR sees the actual payload rather than the disguise. The weakness mirrors userland hooks: AMSI runs inside the process it is protecting, which means code running in that same process can interfere with it.
Layer 1: Bypassing Userland Hooks
Userland hooks are the most commonly attacked EDR monitoring layer, and the reason is architectural: they exist in the memory of the process being watched. An attacker who has code running in that process can reach out and remove them. This is not a subtle trick. It is a direct consequence of where the hooks live.
- DLL remapping: EDR hooks work by modifying the in-memory copy of ntdll.dll, the Windows library that bridges user processes and the kernel. An attacker can load the original, unmodified ntdll.dll from disk, compare it to the hooked version in memory, identify every function that has been altered, and overwrite those alterations with the originals. Every EDR userland hook, gone in a single operation.
- Direct syscalls: Rather than removing hooks, attackers can route around them entirely. Every Windows API function ultimately translates into a numbered system call instruction that crosses into the kernel. If an attacker knows the right number, they can issue that instruction directly, bypassing the hooked API function and the EDR hook it contains. Tools like SysWhispers, Hell’s Gate, and Tartarus’ Gate resolve the correct syscall numbers at runtime, making this portable across Windows versions without needing the numbers hardcoded.
- Indirect syscalls: Direct syscalls solved the hook problem but created a new detection signal: the call stack looked wrong. A syscall originating from attacker-controlled memory rather than a legitimate Windows library is a red flag for EDR products that analyze call origins. Indirect syscalls eliminate this signal by routing the final syscall instruction through the legitimate ntdll.dll library itself, so the call stack looks exactly like a normal Windows API call.
What defenders should do: Monitor for processes that load a second copy of ntdll.dll from disk, a behavior with no legitimate use case. EDR products with call stack analysis are more resilient to direct and indirect syscall techniques than those without it. Prioritize vendors who have invested in this capability.
Layer 2: Killing the Script Inspector
Attackers who rely on PowerShell scripts, .NET assemblies, or other scripted payloads have a specific problem: AMSI. Because AMSI inspects content after all obfuscation has been stripped away, it sees through the encoding tricks that defeat signature-based scanners. For this class of attacker, disabling AMSI is usually the first step after gaining access.
- Memory patching: The most direct approach is to overwrite the first few bytes of the AMSI scanning function with a return instruction, causing it to exit immediately and report a clean result without actually scanning. Defenders responded by monitoring for processes that change the memory permissions on AMSI’s code region, since making code writable before patching it is a detectable step. Attackers responded with techniques that avoid that step.
- Reflection-based manipulation: In PowerShell and .NET environments, attackers can use the runtime’s own introspection features to reach inside AMSI’s internal state and flip a flag that tells PowerShell AMSI failed to initialize, causing it to skip all scanning for the remainder of the session. No code is patched, no memory protections are changed. As of early 2026, this technique remains effective against many EDR products when the bypass code itself uses basic obfuscation to avoid signature detection.
- Hardware breakpoint abuse: Instead of modifying AMSI’s code, attackers use CPU debug registers to set a hardware-level breakpoint on the scanning function. When execution reaches that point, an exception handler intercepts control and substitutes a clean return value. Nothing is written to AMSI’s memory at all, which means memory-write-based detection never fires. CrowdStrike documented this technique and noted that few EDR products monitor the state of debug registers closely enough to catch it reliably.
What defenders should do: Constrain PowerShell to Constrained Language Mode in environments where full scripting capability is not required. Enable Script Block Logging and Module Logging so that even if AMSI is bypassed, PowerShell activity is captured through a separate channel. Treat any process that modifies AMSI-related memory regions or loads unusual .NET assemblies as a high-priority investigation.
Layer 3: Cutting the Telemetry Feed
EDR is only as effective as the data it receives. Event Tracing for Windows (ETW) is one of its most important sources, particularly the kernel-level Threat Intelligence provider that records sensitive operations like reading another process’s memory (a key step in credential theft) or injecting code into a running process. An attacker who can cut that feed does not need to evade detection. There is nothing left to detect with.
- Userland ETW patching: ETW events generated by a user process pass through a function in ntdll.dll before reaching the kernel. Patching that function with a return instruction causes the process to stop generating ETW events entirely. The EDR continues receiving telemetry from every other process on the system. The attacker’s process simply goes quiet.
- Trace session manipulation: ETW routes events through named sessions that connect data providers to consumers. An attacker with sufficient privileges can enumerate which sessions the EDR is consuming, then shut those sessions down or remove specific providers from them. This surgically severs the EDR’s telemetry pipeline without patching any code.
- Kernel-level ETW TI disabling: The on/off state of the ETW Threat Intelligence provider is stored as a flag in kernel memory. An attacker who gains kernel execution through a vulnerable driver can locate and clear that flag, shutting off kernel-generated security telemetry at its source. This eliminates events that user-space patching cannot touch. EDRSandblast demonstrated this against multiple production EDR products.
What defenders should do: Deploy independent network detection and response (NDR) alongside EDR. Telemetry that travels over the wire cannot be suppressed by patching endpoint memory. Monitor for unexpected termination or modification of ETW trace sessions. Treat a process that goes silent on telemetry as more suspicious, not less.
Layer 4: Taking the Kernel
The most damaging class of EDR evasion operates at the kernel level. When an attacker achieves kernel execution, they are operating at the same privilege level as the EDR’s own drivers and kernel components. At that point, disabling the EDR is not an evasion technique. It is a straightforward administrative action.
The primary vehicle is Bring Your Own Vulnerable Driver (BYOVD). The attacker loads a legitimate, digitally signed driver that contains a known exploitable vulnerability. Because the driver carries a valid signature, Windows loads it. The vulnerability is then exploited to achieve arbitrary kernel execution, after which the attacker can terminate protected processes, remove callback registrations, unload drivers, and modify kernel data structures directly.
- Kernel callback removal: The Windows kernel maintains arrays of function pointers representing the EDR’s registered monitoring callbacks. With kernel access, an attacker locates these arrays, identifies the entries that belong to the EDR driver, and removes or replaces them with no-ops. The EDR agent continues running. Its management console may show it as healthy. It is no longer receiving any of the event notifications it needs to detect threats. EDRSandblast demonstrated complete callback removal against three distinct production EDR products without triggering a single detection.
- Minifilter detachment: The EDR’s file system driver is unloaded from the kernel’s driver stack. Without it, the EDR loses all visibility into file operations, including the mass encryption that ransomware performs across a victim’s files.
- Bring Your Own Installer: Some security products are built so that running their own installer first removes the existing installation before placing the new one. Attackers who can initiate that installer and abort it at the right moment leave the endpoint in a state where the EDR has been cleanly uninstalled and nothing has replaced it. Research in 2025 confirmed this technique works against multiple products.
BYOVD is not theoretical. EDRKillShifter has been adopted by at least ten ransomware groups. A February 2026 incident documented by Huntress showed attackers using driver abuse to neutralize dozens of endpoint protection tools across a target environment in a single operation.
What defenders should do: Enable HVCI and the Microsoft Vulnerable Driver Blocklist on all endpoints. Consider Windows Defender Application Control (WDAC) driver allowlisting for stronger coverage. Enforce strict least-privilege so standard users cannot install drivers or services. Invest in telemetry sources that remain intact even after endpoint compromise: network detection, identity monitoring, and cloud-based visibility.
Layer 5: Hiding in Plain Memory
A post-exploitation implant spends most of its time doing nothing. It checks in with its command-and-control server on a schedule, receives instructions, executes them, and then goes dormant again until the next check-in. That dormant window is when EDR memory scanners look for it, scanning for recognizable code patterns or suspicious memory configurations. In-memory evasion is the set of techniques designed to make the implant unrecognizable during those windows.
- Sleep obfuscation: Before entering its dormant state, the implant encrypts its own code and data in memory. When it wakes, it decrypts and resumes. During the sleep window, a memory scanner looking at that region finds only encrypted bytes. No code signatures match. No behavioral patterns are present. The implant looks like random noise.
- Shellcode fluctuation: The implant continuously cycles its memory region between active and inactive states. When active, the code is present and executable. When idle, the memory permissions are changed to non-executable and the content is overwritten with encrypted or random data. Scanners that flag executable memory regions with suspicious content, or regions with read-write-execute permissions, find nothing because those properties only exist during brief execution windows.
- Call stack spoofing: EDR products increasingly track not just what a process does, but where the instruction to do it came from. A process opening a handle to another process’s memory is a major red flag if the instruction originated from an unrecognized memory region, and routine if it came from a known system library. Call stack spoofing fabricates a convincing chain of return addresses so that sensitive operations appear to originate from trusted system code. The Moonwalk++ proof of concept published in late 2025 defeated multiple detection tools specifically designed to find injected code when running inside a legitimate Windows process.
What defenders should do: Prioritize EDR vendors with memory scanning capabilities that go beyond static signature matching, specifically those that can detect encrypted or fluctuating memory regions behaviorally. Complement endpoint memory scanning with process behavior analysis at the network layer, where implant check-ins leave traces that in-memory evasion cannot suppress.
Layer 6: Disappearing Into the Environment
Every technique described so far involves attacker code that must avoid detection. The most effective evasion strategy is to not write attacker code at all. Living-off-the-land attacks use the tools and processes already present on the target system, generating activity that is functionally indistinguishable from normal administrative work.
- Living off the land: PowerShell, Windows Management Instrumentation (WMI), certutil, bitsadmin, rundll32. These are legitimate Microsoft-signed utilities present on every Windows system. When an attacker uses them for reconnaissance, lateral movement, or payload delivery, the resulting process creation and network telemetry looks identical to a system administrator doing routine maintenance. CrowdStrike reports that 79% of detections are now malware-free, a direct reflection of how widely this approach has been adopted.
- Process injection: Rather than launching a new, suspicious-looking process, attackers inject their code into a process that is already trusted and expected to be running: explorer.exe, svchost.exe, a browser, a security tool. The malicious activity then appears to come from that trusted process, inheriting its reputation and often its EDR exclusions. Advanced injection techniques including APC queue injection, process hollowing, and threadless injection use fewer detectable API calls than classical methods and are significantly harder for behavioral detection rules to flag.
- DLL sideloading: Windows resolves library names by searching a predictable sequence of directories. An attacker who places a malicious DLL with the right filename in the same directory as a legitimate signed application causes that application to load the attacker’s library when it starts. The malicious code runs inside a trusted process. The ToddyCat threat group used this technique against an ESET scanning tool, sideloading a malicious DLL that then proceeded to disable kernel-level security monitoring from within a process the EDR was configured to trust.
What defenders should do: Establish behavioral baselines for how legitimate administrative tools are used in your environment. Detections built on deviation from that baseline are far more effective than generic rules about tool usage. Audit and restrict which directories allow DLL loading. Application allowlisting, while operationally demanding, eliminates the DLL sideloading attack surface entirely.
The Takeaway
Every layer of EDR has a failure mode. Adversaries have mapped them, built tooling against them, and operationalized that tooling at scale across ransomware groups and nation-state operators alike. The answer is not to abandon EDR. EDR continues to stop a significant volume of attacks, particularly less sophisticated ones that do not invest in evasion. The answer is to stop treating it as sufficient against a determined adversary.
The endpoint sensor was designed to watch everything. The most capable attackers have learned to blind it before it sees them. Addressing that gap requires a defensive posture that does not depend on the sensor remaining intact: independent telemetry, preemptive concealment of attack surfaces before adversaries can find them, and architectural resilience built on the assumption that the EDR may already be compromised.
Brad Potteiger is the Chief Technology Officer at Arms Cyber, where he leads the development of next-generation preemptive security & anti-ransomware technology. Arms Cyber’s patented Stealth Posture Management platform protects organizations across Windows, Linux, and MacOS by making critical data invisible and resilient to attackers.
The same stealth-driven agent that makes ransomware and other attacks irrelevant now closes the visibility gap left by DLP,...
A behavioral baseline is not a product you buy. It is a commitment you make – to understand what your environment actually...
If you only followed the payment data, you might conclude that the ransomware problem is getting better. Average ransom payments...
In 1989, ransomware arrived by floppy disk. The ransom demand was $189. Today, the average payment exceeds $800,000, attack...
To connect now, contact: [email protected].