Endpoint Detection and Response (EDR) has become one of the most important layers in enterprise security. Modern EDR platforms monitor process creation, memory activity, system calls, file changes, network connections, and behavioral patterns. They are designed to capture endpoint telemetry that may not be detected by traditional antivirus software. EDR evasion tests how that visibility holds up when an attacker deliberately changes, reduces, or interferes with the signals defenders rely on.
That visibility creates an obvious question for an attacker — and for a red team:
What happens when important activity is never collected, or when it is collected but no longer looks like what a detection rule expects?
EDR evasion is often described as a contest between increasingly sophisticated malware and increasingly sophisticated detection. That is part of the story. The more important point is that a red-team engagement can use evasion testing to check the assumptions behind endpoint visibility, and the organization’s ability to detect and respond.
A security product may depend on user-mode hooks (small interception points placed inside common Windows functions) to inspect sensitive API calls. Another detection may rely on the call stack behind a process action. Memory scanners depend on suspicious code being observable when they inspect a process. Behavioral systems depend on telemetry being collected, processed, correlated, and presented correctly. At the deepest level, EDR itself depends on kernel mechanisms and security processes remaining available and trustworthy.
Each dependency creates a different visibility layer. And each layer can be tested.
Executive TL;DR
- EDR evasion is now less about making malicious code invisible and more about controlling where, when, and how endpoint activity can be seen. Techniques such as direct system calls, unhooking, call-stack manipulation, and hiding code in memory while it is inactive each target a different monitoring assumption.
- Avoiding one telemetry source does not automatically mean avoiding detection. Modern EDRs correlate multiple endpoint signals, and evasive behavior can itself become detectable.
- Recent academic research shows the challenge extends beyond the endpoint sensor itself. Telemetry-processing pipelines and machine-learning detectors can be manipulated under certain conditions.
- At the kernel level, the objective can shift entirely — from avoiding an EDR to degrading it. Vulnerable signed drivers and other defense-impairment techniques make this possible.
- Red-team testing validates whether the detection architecture survives realistic attempts to reduce or distort visibility. A configuration checklist cannot answer that question.
- For leadership, the question is not only whether the organization has EDR, but how much of an attack can still be reconstructed when one expected source of visibility stops behaving as expected.
EDR Visibility Is Conditional
An EDR agent sees a remarkable amount of endpoint activity. But it does not see everything in exactly the same way.
Windows provides several layers from which security products can observe execution. EDR vendors can inspect application programming interfaces, system calls, process and thread creation, memory regions, and kernel events. They can also analyze call stacks, event telemetry, network behavior, and combinations of these signals.
The result is not one complete record of truth but a collection of separate observations, and that difference matters.
When a security control assumes a sensitive Windows API will pass through an instrumented function, an attacker looks for another route. The underlying operation may still be reachable by a different path. If detection relies on the origin of a call, offensive tooling may attempt to change what that execution path looks like. If a memory scanner expects suspicious executable code to remain visible during inactivity, that assumption can be broken. An implant (the attacker’s code running on a compromised system) can change its memory state while it is inactive.
The objective is rarely to disappear from the operating system. It is to make the attack look different at the specific point where the defender expects to observe it.
This is why EDR evasion is better understood as a visibility problem than a malware problem.
Bypassing the Expected API and System-Call Path
One of the longest-running EDR evasion contests happens around the boundary between user mode, where applications run, and the Windows kernel, the core of the operating system.
EDR products can instrument sensitive Windows functions. That allows operations such as process access, memory manipulation, and thread creation to be inspected before execution reaches the kernel. This approach provides valuable visibility, but it also means offensive researchers understand exactly where one important layer of observation takes place.
Techniques such as direct system calls, indirect system calls, and unhooking attempt to change that path. Rather than relying on the user-mode functions a security product may instrument, offensive tooling can use alternative execution paths to reach underlying system functionality.
HookChain approaches this problem by combining import address table manipulation (altering the table a program uses to locate Windows functions), dynamic system-call resolution, and indirect system calls. Together, these techniques redirect execution around certain forms of ntdll.dll-based monitoring. HookChain: A New Perspective for Bypassing EDR Solutions
This area changes quickly. Direct system calls are only one option. Indirect system calls and related techniques try to keep the same underlying operation while changing what user-mode monitoring can see. Defenders then adapt to the new traces, and the cycle continues.
Evasion as a Detection Signal
The lesson here is not that system calls make EDR ineffective. The opposite is closer to the truth. Once defenders understand a bypass technique, the bypass can itself become a behavioral signal.
Elastic maintains a detection rule for suspicious process access tied to direct system-call behavior and unusual call traces. Elastic: Suspicious Process Access via Direct System Call
This shows the cycle clearly. A technique removes one observable artifact, defenders identify another, and offensive tradecraft adapts again. The visibility shifts rather than disappears.
When the Call Stack Becomes Part of the Detection
Avoiding an instrumented function is only one part of the problem.
Security products can also ask a different question: where did this operation come from?
The call stack gives defenders context around execution. An API call might appear legitimate on its own. But its ancestry can reveal that execution started in an unusual memory region, or in memory not linked to any legitimate file on disk (known as unbacked memory). This has pushed offensive research toward techniques intended to make execution context appear more consistent with legitimate application behavior.
Kyle Avery’s research into avoiding memory scanners illustrates the problem well. The work examines not only memory permissions and encryption but also stack tracing and return-address analysis. It demonstrates how defenders can use call-stack characteristics to identify suspicious execution even when other indicators have been modified.
When Behavioral Models Become the Target
Academic research shows this problem becomes broader when defenders model behavior rather than individual events.
At USENIX Security 2023, researchers introduced PROVNINJA. The framework generated adversarial system actions designed to resemble benign execution patterns, then evaluated them against provenance-based machine-learning detectors, which model the chain of relationships between processes, files, and network activity. In the evaluated scenarios, the generated variants reduced detection rates by as much as 59 percent.
Endpoint defense is increasingly behavioral, which raises the stakes. The attacker is no longer only asking whether one API call will generate an alert. The real question may be whether a sequence of activity can be shaped to resemble something the detection model already considers normal.
For defenders, this makes context more important. A single legitimate-looking event cannot establish legitimacy on its own. If the process ancestry, memory behavior, network destination, or later activity points to something else, that wider context should carry more weight.
Memory Is Not a Static Source of Evidence
Memory scanning creates another visibility layer — and another set of assumptions worth examining.
Traditional malware detection often focused on files written to disk. Fileless attacks and tools that run only in memory shifted the focus, making process memory itself a critical source of evidence. But memory has an important characteristic: its state changes over time.
An implant does not necessarily remain executable, decrypted, and active for its entire lifetime. Kyle Avery’s research describes several mechanisms offensive tooling uses to reduce exposure during inactive periods. These include changing memory protections and obscuring data while execution is dormant. These approaches are often grouped under the name sleep obfuscation. The same research makes an important qualification. Bypassing an open-source memory scanner does not automatically mean bypassing a commercial EDR.
Public tools are useful for studying visibility assumptions. They are not a universal proxy for how every commercial EDR operates.
Memory State Is Temporal — and That Has Consequences
Josh Lospinoso’s 2026 retrospective on Gargoyle provides a useful conceptual framing for what this means in practice. The original research demonstrated code transitioning between executable and non-executable states around short execution windows. Revisiting the technique nearly a decade later, Lospinoso emphasizes the broader lesson: memory state is temporal.
The implications go well beyond one proof of concept. A scanner observes a process at a particular moment. What it sees depends partly on what state that process happens to be in at that moment.
For security teams, this argues against treating any one memory snapshot as definitive evidence that an endpoint is clean. The stronger detection strategy correlates memory observations with what happens before and after them. Thread behavior, process ancestry, memory-protection changes, system calls, network activity, and module loading all contribute. Together, those signals reconstruct a sequence rather than relying on one observation.
Attackers Can Target the Telemetry Pipeline Itself
Most EDR discussions focus on avoiding the sensor. Recent research suggests defenders also need to think about what happens after the sensor collects data.
At USENIX WOOT 2026, researchers examined what they call Telemetry Complexity Attacks. Their work focused on the collection, serialization, storage, and visualization components used by malware-analysis and endpoint-security platforms.
The researchers evaluated 18 commercial and open-source platforms. Seven experienced failures at different stages of the telemetry pipeline. These included truncated behavioral reports, rejected data, serialization errors, and unresponsive interfaces.
Collection Is Not the Same as Visibility
This changes how visibility should be discussed. An endpoint sensor can technically collect activity. But if another component cannot process, store, or display that information correctly, the defender still ends up with an incomplete picture.
Telemetry collection is not the same thing as usable visibility.
In practice, security operations center (SOC) teams depend on an entire chain: collection agent, local processing, transport, ingestion, storage, correlation, alert generation, visualization, and analyst interpretation. A failure anywhere along that path can influence what defenders believe happened.
For red teams, this expands the testing question. It moves from “Can the endpoint agent detect this behavior?” to a harder one: “Does the full defensive pipeline still give the SOC reliable evidence to act on?”
From Evading the EDR to Impairing It
Some techniques do not try to hide from endpoint defenses at all. They target the security control itself.
MITRE ATT&CK categorizes activity that disables, degrades, or tampers with security tooling under Disable or Modify Tools (T1685). This includes stopping security services, killing processes, modifying configurations, and interfering with EDR agents, antivirus, logging agents, sensors, and other defensive capabilities.
One particularly important category involves vulnerable signed drivers.
BYOVD — Legitimacy as a Weapon
Kernel drivers operate at a highly privileged layer of Windows. Bring Your Own Vulnerable Driver, or BYOVD, involves introducing and abusing a vulnerable kernel driver, often one that is legitimately signed. Its effect depends on the vulnerability, access to the driver, and whether the system permits it to load. The resulting capability may enable privilege escalation or interference with security controls.
Sophos documented a real-world example with AuKill. In incidents investigated by Sophos X-Ops, attackers abused an outdated Microsoft Process Explorer driver. The goal was to terminate EDR processes before deploying ransomware or other payloads. Sophos observed AuKill in incidents involving Medusa Locker and LockBit.
This moves the discussion from evasion to control degradation.
Microsoft specifically recognizes vulnerable signed drivers as an attack path. Its mitigations include the vulnerable driver blocklist, Hypervisor-Protected Code Integrity, and App Control for Business. There is also a specific Attack Surface Reduction rule that prevents applications from writing covered vulnerable signed drivers to disk. Microsoft also notes a limitation: this ASR rule does not stop a driver that is already on the system from loading. Blocking that requires the vulnerable driver blocklist or an App Control policy.
Kernel-level visibility also deserves special attention because security telemetry can depend on operating-system mechanisms that sit below ordinary user-mode monitoring. Windows, for example, provides kernel routines through which drivers can register callbacks that are invoked when processes are created or exit. The architectural point is simple: endpoint visibility depends on lower-level operating-system components staying available and trustworthy.
Once the sensor itself becomes part of the attack surface, endpoint resilience means more than detecting malware. It means detecting damage to the detection capability.
Evasion Is Becoming Easier to Automate
There is another development security teams should watch closely.
Much of sophisticated EDR evasion historically required deep knowledge of Windows internals, defensive instrumentation, payload development, and individual endpoint products. That expertise barrier is beginning to change.
A 2026 arXiv preprint, Mutate to Bypass, describes AutoBypass — a multi-agent framework designed around iterative adaptation. It organizes public EDR-evasion knowledge, generates test payloads, analyzes telemetry from failed attempts, and adapts from there. The researchers reported successful evasion against all seven commercial endpoint-security platforms included in their experiments. Because the paper is a preprint, those results should be interpreted as research findings rather than independently validated industry benchmarks.
The direction is nevertheless important. Automation can reduce the cost of experimentation. Instead of an operator manually iterating through every failed technique, systems can increasingly use defensive feedback to choose another approach.
That is not a reason to assume EDR is becoming obsolete. It is a reason to test defensive assumptions more often. A detection that worked against last year’s implementation may still be conceptually sound while missing this year’s variation.
The Detection–Evasion Cycle Is Not the End State
There is a familiar pattern running through everything above.
Defenders instrument a behavior. Offensive researchers find another way to produce the same underlying effect. Defenders identify the new observable artifacts. Offensive tooling changes again.
Calling this an endless cycle is accurate, but incomplete.
The goal of enterprise security cannot be to predict and independently block every possible variation of every evasion technique. That does not scale.
A stronger model assumes that individual visibility mechanisms can fail. If user-mode instrumentation is avoided, other endpoint signals should still matter. Manipulating the call stack should not remove the context provided by surrounding process and memory behavior. A benign-looking memory state during one inspection window should not erase activity observed before or after it. And when endpoint telemetry becomes incomplete, network, identity, authentication, and application telemetry should help reconstruct the attack.
This is the same reason network evasion cannot be treated as an isolated control problem. Our analysis of Domain Fronting and the New Evasion Playbook covers this directly: attackers operate inside infrastructure defenders already trust.
Endpoint and network evasion pose the same strategic challenge. Can the organization distinguish legitimate technology from malicious use of that same technology? No single sensor can answer that question.
What Red Teams Should Actually Test
One impressive EDR bypass should not define the success of a mature red-team engagement. On its own, it proves very little.
The more valuable exercise asks how the defensive system as a whole responds when a red team deliberately stresses its visibility.
Resilience Across Visibility Layers
The first question is whether one visibility layer can fail without collapsing detection. If user-mode telemetry becomes unreliable, does another signal expose the operation? If memory inspection misses an implant during one state, does process, thread, or network telemetry expose what happens around it?
Equally important: does the SOC know when its visibility has degraded? MITRE ATT&CK recommends checking that expected EDR and monitoring agents continue reporting to their central management systems. It sounds basic, but it addresses a critical distinction: a quiet endpoint and a blind endpoint are not the same thing. MITRE ATT&CK: Disable or Modify Tools (T1685)
Behavioral Durability and Cross-Control Correlation
The second question is whether detections hold up against technique variations. A rule that identifies one public tool is useful. A detection that identifies the behavior the tool needs to accomplish is more durable. Organizations should know which detections rely on signatures, which rely on traces left by a specific tool, and which identify the attacker’s underlying goal. The last group is the most durable.
Endpoint telemetry should not exist in isolation. Identity, authentication, DNS, proxy, network, cloud, application, and endpoint signals become much more valuable when defenders can connect them. The attacker only needs one viable path. The defender needs enough context to recognize that path.
When EDR Becomes Part of the Incident
The final question is whether response still works when EDR is itself part of the problem. If an attacker degrades or terminates an endpoint agent, or the agent cannot report complete telemetry, responders need another way to establish scope. This requires planning before an incident — not after.
EDR Is a Control. Red Teaming Tests the Assumption Behind It.
The wrong conclusion from EDR-evasion research is that endpoint detection does not work.
Modern EDR platforms provide substantial visibility and routinely force attackers to spend more time, expertise, and operational effort avoiding detection. The more useful conclusion is that EDR effectiveness is conditional.
It depends on what telemetry is available and which observation mechanisms remain trustworthy. It also depends on how detections correlate those signals, whether the pipeline preserves them, and whether defenders notice when visibility changes.
Red teams put those assumptions under pressure. That is fundamentally different from asking whether the organization owns an EDR license or whether the agent is deployed. So is scoring well in a controlled benchmark.
The relevant question is operational. When an attacker deliberately tries to reduce the visibility your defenders depend on, what can your security team still see — and what can they still prove?
That is the gap offensive validation should expose.
What Security Leaders Should Ask
For CISOs and security leaders, the most useful conversations are not about individual bypass techniques. They are about structural assumptions.
Start with visibility. Which endpoint signals are critical to your current detection strategy? Which detections rely heavily on one telemetry source? What happens if that source disappears or becomes unreliable?
Then look at resilience. Do security teams monitor the health and reporting status of endpoint agents? Are vulnerable-driver protections actually enforced? Can analysts correlate endpoint events with identity, network, and cloud telemetry? Have detections been tested against variations of the behaviors they are meant to identify?
Finally, ask the question that matters most: has any of this been validated against an operator actively trying to evade it?
That is where red teaming becomes more than another penetration test. It measures whether the organization’s defensive assumptions hold up against a real adversary.
Want to know how your endpoint defenses hold up under realistic adversarial pressure? Contact wizlynx group to discuss your threat model and detection architecture.
Frequently Asked Questions (FAQs)
What is EDR evasion?
EDR evasion refers to techniques that reduce, distort, or avoid the telemetry and detections generated by Endpoint Detection and Response products. This includes changing how operations reach the Windows kernel, manipulating execution context, and altering memory state. It can also mean avoiding known behavioral patterns or impairing security tooling directly
Can attackers completely bypass EDR?
There is no universal EDR bypass. Products observe different telemetry, use different detection logic, and change over time. A technique that avoids one monitoring mechanism may create another detectable artifact elsewhere. A public demonstration does not prove that the same technique defeats every product or configuration.
How do offensive tools bypass security monitoring using system calls?
System calls provide the transition between user-mode applications and kernel functionality. Offensive tooling can attempt to invoke them through paths that avoid user-mode functions instrumented by security products. Modern defenders can detect behavioral and execution artifacts associated with these approaches. That is why syscall techniques remain part of an ongoing detection-evasion cycle.
What is sleep obfuscation?
Many implants spend significant periods inactive between operations. Sleep-obfuscation techniques alter code, data, memory permissions, or execution state during those inactive periods. A memory inspection may therefore see something different from what exists while the implant is actively executing. The broader defensive lesson is that memory state is not static — it changes over time.
What is BYOVD?
Bring Your Own Vulnerable Driver (BYOVD) is a technique in which an attacker introduces and abuses a vulnerable kernel driver, often one that is legitimately signed. Its effect depends on the vulnerability, access to the driver, and whether the system permits it to load. Depending on those conditions, the resulting capability may enable privilege escalation or interference with security controls.
Does EDR evasion mean organizations should replace EDR?
No. EDR remains an important detection and response layer. The lesson from evasion research is straightforward: no individual security product should be treated as an infallible source of truth. Endpoint telemetry works best as part of a wider detection architecture. It should combine multiple signals and be tested under realistic adversarial conditions.
About wizlynx group
wizlynx group is a CREST-accredited offensive security company helping organizations understand how their security controls perform against realistic attacker behavior. Headquartered in Switzerland, with a presence across Europe, North America, Latin America, and Asia, the firm specializes in penetration testing, red teaming and adversary simulation, social engineering, and advanced security assessments.
EDR deployment tells you that endpoint protection is in place. Red teaming tells you what happens when someone tries to get past it.
Contact wizlynx group to find out what your endpoint defenses look like when an authorized team actively tries to evade them.
This article was co-authored with Lei Yeh, Consultant at wizlynx group. Lei specialises in offensive security, with a focus on web application exploitation and Red Teaming. Their areas of expertise also include AI-generated deepfakes, AI-assisted threat actors, detection and response, and system hardening. Their work explores how AI-enabled deception can challenge existing security controls and how organisations can strengthen detection resilience against increasingly adaptive attack techniques.