Attackers keep finding new ways to bypass Endpoint Detection and Response (EDR) tools.
Every few months, a new technique emerges. Indirect syscalls, call-stack manipulation, memory evasion, telemetry tampering, vulnerable drivers — each one designed to execute without triggering the endpoint controls expected to catch it.
It is tempting to view this as a continuing race between more sophisticated malware and more capable detection.
It is the familiar cat-and-mouse dynamic between offensive operators and EDR developers: defenders identify suspicious behaviour, attackers change how that behaviour appears, and detection methods adapt in response. But focusing only on this cycle misses the more important issue.
EDR visibility is conditional. Attackers increasingly target the telemetry assumptions on which detection depends.
An Endpoint Detection and Response platform does not inherently know that an attack is taking place. On Windows, it observes activity through multiple operating system layers — process creation, memory operations, API activity, files, registry changes, network connections, kernel callbacks, Event Tracing for Windows (ETW), and other telemetry. From those observations, it reconstructs behavior.
That distinction matters.
When a signal changes, disappears, lacks sufficient context, or resembles legitimate activity closely enough, the resulting security decision can change with it.
For CISOs, this makes EDR evasion more than a malware problem. It becomes a visibility assurance problem.
The question is no longer simply: Does our EDR detect malicious software?
It becomes: Which assumptions must remain true for our endpoint controls to see what we expect them to see?
Executive Summary
- EDR remains a critical security control, but deployment does not equal complete visibility. Endpoint platforms reconstruct attacks from multiple telemetry sources, each with its own operating conditions and limitations.
- Modern evasion increasingly targets observation rather than signatures alone. Offensive research demonstrates techniques designed around API monitoring, call stacks, memory characteristics, ETW-related telemetry, kernel callbacks, and other signals defenders use to identify suspicious behavior.
- Attackers can move deeper when defenders move deeper. As endpoint visibility extends beyond user-mode hooks into kernel telemetry, adversaries can pursue kernel-level techniques — such as abusing legitimate but vulnerable signed drivers.
- Real-world red-team evidence shows the organizational consequence. In a CISA assessment of a U.S. critical-infrastructure organization, its EDR solutions detected only a limited portion of the red team’s payloads, while the organization relied too heavily on endpoint controls without sufficient complementary network-layer protections.
- Telemetry impairment is itself attacker behavior. MITRE ATT&CK documents adversary attempts to disable, degrade, or modify security tooling and the visibility those tools provide.
- AI-assisted offensive research could accelerate the cycle. Emerging 2026 research suggests multi-agent systems can automate parts of the experimentation and refinement traditionally required to test EDR resilience. This research is recent and should not be interpreted as evidence that such capabilities are already commonplace among threat actors.
- CISOs (Chief Information Security Officers) should require visibility to be tested, not assumed. Red teams should validate whether meaningful attacker behavior remains observable when individual telemetry paths, signatures, or detection assumptions fail.
EDR Bypass Is Not One Thing
“EDR bypass” has become convenient shorthand. Technically, however, it describes very different conditions — and those differences matter.
One payload may avoid a known static signature. Another may alter its execution pattern so behavioral rules no longer match. A third may avoid an API path a security product monitors. Another may manipulate memory characteristics or call-stack context. Still another may interfere directly with a security sensor or its telemetry. And another may operate entirely through legitimate tools, creating activity that is visible but difficult to distinguish from normal administration.
These are not equivalent failures.
In some cases, the EDR receives less information. In others, it receives the information but lacks the context needed to classify it correctly. Sometimes the attacker never disables the endpoint product at all. They simply operate outside one of the assumptions on which a particular detection depends.
This is why mature EDR evasion research increasingly asks a different question from traditional malware obfuscation: What exactly is the defender observing?
Independent research into EDR telemetry architecture describes Windows activity as a collection of separate state transitions observed through different mechanisms — not as a single authoritative stream of malicious behavior. The EDR must correlate those observations and infer what is happening.
That is a critical distinction for leadership. An installed sensor provides access to telemetry. It does not automatically provide complete interpretation of attacker activity.
What an EDR Actually Sees
Consider something as simple as one process interacting with another.
From the attacker’s perspective, it may be a single objective. From Windows’ perspective, that same activity can generate multiple observable events: process and thread operations, handle access, memory allocation, memory-protection changes, module activity, API calls, and other state transitions. Different endpoint products collect and correlate different combinations of those signals.
One important Windows telemetry mechanism is Event Tracing for Windows, or ETW. Microsoft describes ETW as an event-tracing architecture consisting of providers, which generate events; controllers, which manage tracing sessions; and consumers, which receive those events.
Even at this foundational level, telemetry has operating conditions. Microsoft documents circumstances in which ETW events can be lost — for example, because of event or buffer sizes, or because a real-time consumer cannot process events quickly enough.
That does not mean ETW is unreliable. It illustrates a broader principle: security telemetry is produced, transported, consumed, and interpreted through systems that have technical boundaries. Endpoint security is built on top of those boundaries. Understanding them is increasingly part of understanding endpoint risk.
Attackers Study the Observation Point
This is where the familiar relationship between red teams and EDR developers becomes more interesting.
On Windows, early endpoint-evasion conversations centered heavily on user-mode API hooking. An EDR can monitor sensitive Windows API activity by placing instrumentation around functions commonly used for memory management or process manipulation. From a defensive perspective, that provides useful visibility into behavior associated with many attack techniques.
From an offensive perspective, however, it also creates an identifiable observation point.
If the defender expects execution to pass through a particular path, the red-team question becomes: Can the same objective be achieved through a different path?
The HookChain research presented at DEF CON 32 demonstrated this principle by combining techniques including Import Address Table redirection, dynamic syscall-number resolution, and indirect system calls. The research specifically targeted security products that depended heavily on monitoring activity through ntdll.dll.
The important takeaway for a CISO is not the implementation. It is the dependency.
HookChain did not demonstrate that “EDR does not work.” It demonstrated that visibility dependent on one observation layer can be challenged when an operator understands that layer well enough. This is why evaluating endpoint resilience against last year’s malware samples tells an organization relatively little about how a capable operator may behave tomorrow.
The attacker is not only testing the malware against the product. They are testing the product’s assumptions.
Defenders Moved Deeper Into Windows — and Attackers Followed
Endpoint vendors did not stop at user-mode hooks.
Modern endpoint visibility can draw from deeper operating-system telemetry, including kernel callbacks and Microsoft’s Threat Intelligence ETW provider. Independent research from 0xflux examining Event Tracing for Windows Threat Intelligence demonstrates the type of activity ETW-TI can expose — including memory allocation and protection changes, APC activity, and process or thread operations.
That matters because changing the user-mode route used to perform an operation does not necessarily eliminate evidence generated elsewhere in the operating system.
This is a recurring pattern. Defenders identify a blind spot and add another source of visibility. Red teams learn what that source observes. They then determine which behavior is essential to the objective and which behavior exists only because of the current implementation. The offensive goal becomes reducing or reshaping suspicious signals without sacrificing the underlying objective.
Research such as S3cur3Th1sSh1t’s Cat & Mouse — or Chess? illustrates this progression across user-mode monitoring, kernel-level detection, stack analysis, and attempts to interfere with EDR component initialization.
More recent independent research from Lorenzo Meacci, Bypassing EDR in a Crystal Clear Way, examines runtime characteristics such as call-stack context, reflective loading, memory characteristics, and sleep behavior.
The individual technique determines the immediate exposure. The broader lesson is that detection and evasion can both depend on runtime context — and as one becomes more contextual, so does the other.
The Attacker Does Not Always Need to Blind the EDR
One of the easiest mistakes in discussing EDR evasion is assuming success means completely disabling the endpoint sensor. Often, it does not.
If a security product looks for a particular combination of suspicious characteristics, an operator may only need to remove enough of those characteristics to stay below the detection threshold. That could mean changing how code enters memory, where it executes, the call stack around an operation, or which process performs the activity. It could also mean relying on a legitimate system component already expected to exist within the environment.
This connects directly to the offensive principle behind Living off the Land attacks. The attacker does not always win by making malicious activity invisible. Sometimes they win by making it look sufficiently normal.
For defensive teams, that shifts the challenge considerably. Collecting an event is only the first step. The harder question is whether enough surrounding context exists to distinguish malicious use from legitimate use.
When Attackers Target the Telemetry Itself
There is a more direct version of the problem.
Instead of adapting behavior around security telemetry, attackers can attempt to impair the defensive tooling that generates or consumes it. MITRE ATT&CK’s Disable or Modify Tools covers adversaries degrading or tampering with security products — including EDR, antivirus, IDS, logging agents, and sensors — to reduce defensive visibility.
That distinction deserves more attention from security leaders.
A security control can fail because it does not recognize an attack. But it can also fail because the attacker changes the conditions under which the control operates. That turns defensive telemetry into an attack surface of its own.
What a Sophisticated Attacker Asks Before Moving Forward
A sophisticated attacker may approach your environment with a very specific line of inquiry. Which processes belong to the EDR, and which drivers provide its kernel visibility? Which callbacks does the product depend on? What Windows telemetry providers does it consume, and which services must remain operational? Critically — what happens if one of those inputs disappears?
None of these questions require defeating every endpoint capability. The attacker only needs to create enough asymmetry to complete the next objective.
When the Fight Reaches the Kernel
Defenders can make user-mode manipulation less meaningful by relying on deeper operating-system visibility. Attackers can respond by trying to operate at that same depth.
One important example is the abuse of legitimate but vulnerable signed drivers — commonly associated with Bring Your Own Vulnerable Driver, or BYOVD, techniques.
Microsoft explicitly warns in its recommended vulnerable-driver block rules that malicious actors exploit vulnerabilities in legitimate, signed kernel drivers to obtain kernel-level capabilities. The trust relationship is precisely what makes the technique attractive.
Windows needs drivers. Many legitimate drivers require privileged kernel execution. A driver may therefore be properly signed while still containing a vulnerability that can be abused. Once an attacker can exercise dangerous functionality in kernel context, the defensive implications become substantially more serious — because endpoint security products themselves rely on kernel-level mechanisms for visibility and protection.
Microsoft consequently maintains a vulnerable-driver blocklist and recommends controls including Hypervisor-Protected Code Integrity and an Attack Surface Reduction rule intended to restrict abuse of exploited vulnerable signed drivers.
This is another example of an attacker targeting the trust assumptions surrounding the defensive architecture — not simply trying to make a malicious executable harder to scan.
This Behavior Exists Outside the Laboratory
EDR evasion is easy to dismiss when examples come exclusively from conference presentations or red-team tooling. Real threat actors also target defensive visibility.
MITRE ATT&CK documents SplatCloak, malware associated with Mustang Panda that identifies and disables API callback capabilities used by Windows Defender and Kaspersky. It is significant not because it represents the most sophisticated EDR-evasion capability ever observed. It demonstrates the objective clearly: disable part of the defender’s ability to observe you, then continue operating.
That should shift how security leaders interpret defense-evasion techniques. Telemetry is not simply evidence generated after an attack. For the adversary, it can be infrastructure worth targeting before the next stage begins.
Beyond Windows: A Note on Scope
The techniques discussed in this article — ETW manipulation, user-mode hooking, kernel callbacks, BYOVD — are specific to Windows environments. That is not because the problem is exclusive to Windows. Linux and macOS deployments face analogous visibility challenges through different mechanisms: eBPF-based telemetry, the macOS Endpoint Security framework, auditd, and kernel module abuse each carry their own assumptions and limitations. A future article will examine how the same conditional-visibility principle plays out across those platforms. For now, organizations running mixed environments should not assume that the Windows-specific framing here exempts their Linux servers or macOS endpoints from equivalent scrutiny.
What Happens When EDR Becomes the Entire Strategy
The organizational consequences come into focus through CISA’s red-team assessment of a U.S. critical-infrastructure organization.
CISA’s team compromised the organization’s domain and several sensitive business systems. Among its lessons learned, CISA concluded that the organization had relied too heavily on host-based EDR without sufficient network-layer protections. The endpoint tools did not provide the safety net leadership had expected.
CISA reported that the organization’s EDR solutions detected only a limited number of the red team’s payloads across its Windows and Linux environments. In one instance where EDR did detect and block an initial phishing payload, the resulting alert was not acted upon by the defenders.
That distinction matters. There were failures of technology. There were also failures of operations.
Security visibility is only valuable when the organization can generate it, preserve it, correlate it, recognize its significance, and respond to it. The CISA assessment therefore exposes a larger problem than EDR bypass. It demonstrates the risk of turning a defensive layer into a defensive assumption.
EDR Is Essential. EDR Dependence Is the Problem.
None of this is an argument against EDR. Quite the opposite.
Endpoint telemetry remains one of the most valuable sources of behavioral evidence available to defenders. The mistake is treating deployment coverage as confirmation that the endpoint layer is comprehensively observable.
An organization may report 98% EDR deployment, 95% sensor health, and 100% coverage of critical servers. These are useful operational metrics. But they do not answer whether an attacker can pursue a critical objective without generating the signals defenders depend on. Nor do they establish whether telemetry remains available if the endpoint control itself becomes a target.
This creates an important distinction for security leadership. Coverage measures where the control exists. Assurance measures whether the control works under adversarial conditions. CISOs need both — and right now, most organizations are measuring only one.
Detection Needs Independent Layers
If endpoint visibility can be reduced, bypassed, manipulated, or simply misunderstood, deploying three EDR products to every workstation is not the answer.
The answer is ensuring that critical attacker behavior creates evidence somewhere else too.
An endpoint event may correlate with identity telemetry. Authentication activity may appear in a domain controller or identity provider. A lateral-movement action may generate network evidence. Access to cloud resources may create control-plane logs. DNS activity may expose communications that are ambiguous from the endpoint alone. A privileged action may be visible in application or infrastructure audit logs.
This is defense in depth at the telemetry level — not simply at the product level.
It also explains why offensive testing should span control boundaries. An endpoint may appear resilient when tested in isolation. An identity platform may appear resilient when reviewed independently. A network-control architecture may pass its own assessment. But attackers chain systems together.
As we have discussed in our work on hybrid identity attack paths, the relationships between otherwise well-defended systems can create the path that matters. Endpoint visibility should be evaluated the same way.
What Happens When AI Accelerates the Cycle?
There is another development security leaders should watch carefully.
Traditionally, sophisticated EDR evasion has required considerable specialist knowledge. An operator may need to understand Windows internals, reverse engineering, endpoint telemetry, and compiler behavior. Add malware development and the characteristics of individual endpoint products. That is a significant barrier. Emerging research suggests automation may reduce some of it.
The August 2026 arXiv preprint Mutate to Bypass: Autonomous Endpoint Evasion via Knowledge-Driven Multi-Agent Orchestration describes AutoBypass — a multi-agent framework designed to automate parts of EDR-resilience assessment. The researchers combined a knowledge base of public evasion techniques with agents capable of planning, generating code, and compiling candidates. Those agents also interpreted telemetry and refined subsequent attempts. Under the researchers’ experimental methodology, the framework produced evasive results against all seven commercial endpoint-security platforms in the evaluation. Success rates varied across products.
This deserves attention. It also deserves restraint.
What This Research Does — and Does Not — Imply
The paper was published as an arXiv preprint in August 2026. Its results should not be interpreted as evidence that autonomous EDR evasion is already widely deployed by threat actors, nor as a general measurement of all commercial endpoint platforms.
The strategic implication is narrower but still important. Automation can potentially reduce the cost of iteration. The cat-and-mouse game has traditionally required an operator to modify a payload, test it, study the result, understand why detection occurred, and build another version. If parts of that experimentation loop can be automated, defenders may eventually face more variations in less time — and that changes the economics of evasion, even if none of the underlying techniques are fundamentally new.
Why This Matters to CISOs
The security question is not whether EDR vendors can eventually detect HookChain, a particular memory-loader design, a known vulnerable driver, or another published technique. They can adapt. And attackers adapt again.
The strategic problem is the loop itself.
Telemetry leads to detection. Detection prompts offensive research. Offensive research produces evasion. Evasion drives new telemetry. The cycle continues — and organizations buying endpoint security sit inside that loop whether they acknowledge it or not.
That means the objective cannot be to acquire an endpoint product that attackers are incapable of bypassing. That is the wrong assurance standard.
The objective is to build an environment where bypassing one detection mechanism does not provide a silent path to the organization’s critical assets.
What Security Leaders Should Require
Know Which Telemetry Your Detections Depend On
Security teams should understand the principal endpoint telemetry sources behind high-value detections. This does not require a CISO to reverse engineer the EDR agent. It requires enough transparency to answer three questions: What does this detection depend on? What happens if that signal disappears? What secondary telemetry should confirm the same activity?
Monitor the Health of Visibility, Not Just the Health of the Agent
A running EDR process is not necessarily equivalent to complete telemetry. Security operations should identify abnormal reductions in expected endpoint logging, sensor communication, security-service state, driver activity, or other relevant signals. A sudden absence of expected evidence can itself be evidence.
Reduce Unnecessary Kernel Attack Surface
Signed code should not automatically be interpreted as safe code. Organizations should maintain controls around vulnerable drivers and apply platform protections where operationally appropriate. Driver inventories, block policies, operating-system protections, and vulnerability management all affect whether attackers can convert a legitimate kernel component into a defensive blind spot.
Correlate Endpoint Activity With Independent Telemetry
Endpoint evidence should be reinforced through identity, network, cloud, DNS, authentication, application, and infrastructure telemetry where business risk justifies it. If one layer becomes unreliable, another should still expose the attacker’s objective.
Test Legitimate Tools as Aggressively as Malware
Red teams should not rely exclusively on custom payloads. Attackers routinely exploit legitimate capabilities because those capabilities already fit the environment’s expectations. As our previous analysis of Living off the Land attacks demonstrated, trusted binaries and native capabilities blur the line between legitimate administrative activity and malicious execution. That ambiguity is precisely what detection engineering must confront.
Test What Happens After the First Missed Detection
The most important red-team finding may not be that EDR failed to detect payload X. It may be that after EDR failed to detect payload X, the operator reached the identity tier and obtained credentials. They then moved laterally and accessed a critical system — without another control creating an actionable signal. This is where endpoint testing becomes business-risk testing. And remediation should follow the same logic. As discussed in our article on attacker persistence after remediation, addressing the initial technique does not establish that every downstream consequence has been removed.
Measure EDR Resilience Adversarially
Detection coverage should be tested against realistic operator behavior — not inferred from product configuration, dashboards, or known-malware detection rates alone. A capable red team can vary execution paths, use legitimate tooling, manipulate indicators, challenge telemetry assumptions, and determine whether defensive teams can still reconstruct the attack. The objective is not to beat the EDR. It is to determine what the organization still sees when the EDR does not behave exactly as expected.
Red Teaming Should Test the Assumptions Behind the Sensor
A conventional endpoint assessment asks whether known attack techniques generate alerts. A stronger assessment asks why they do.
Which behavior was detected? Which telemetry source exposed it? Did another system independently observe the same objective? Would changing the execution path change the result? Would defenders notice if part of the expected telemetry disappeared? Could an operator continue toward a critical business objective after one endpoint detection failed?
These questions move red teaming from product validation to control-system validation. That is where the exercise becomes useful to leadership.
Because the CISO does not ultimately need proof that the EDR can detect a particular tool. They need evidence that the organization can detect and respond to the attacker’s objective — even when the technique changes.
Frequently Asked Questions
Can modern EDR solutions be bypassed?
Yes, under some conditions. Published offensive-security research demonstrates techniques that can evade particular endpoint detections or observation mechanisms. That said, EDR bypass is not a universal state. A technique may evade one product, configuration, or telemetry source while still creating observable evidence elsewhere. The more useful question is which attacker behaviors remain visible when an individual detection mechanism fails.
Does an EDR see everything happening on an endpoint?
No. EDR platforms derive visibility from multiple operating-system and product-specific telemetry sources. Different activities can be observed at different layers and with different levels of context. The endpoint product then correlates that information to identify suspicious behavior. This makes endpoint visibility broad and valuable — but not omniscient.
What is ETW, and why does it matter to EDR?
Event Tracing for Windows is a Windows telemetry architecture through which providers generate events that can be collected and consumed by other components. Endpoint products use ETW and related Windows telemetry as part of their behavioral visibility. From an offensive-security perspective, understanding which telemetry exposes an operation helps researchers determine whether changing the implementation affects what defenders observe.
What is ETW-TI?
ETW-TI refers to Microsoft’s Threat Intelligence ETW provider, which exposes security-relevant operating-system telemetry associated with activities including memory and process operations. Because this telemetry originates deeper in Windows than ordinary user-mode API instrumentation, avoiding a user-mode hook does not necessarily remove the underlying evidence.
What is BYOVD?
Bring Your Own Vulnerable Driver or Device (BYOD) is a technique in which an attacker abuses vulnerabilities in legitimate, often properly signed kernel drivers to obtain privileged kernel capabilities. Microsoft maintains vulnerable-driver blocking guidance specifically because signed drivers can still be abused by malicious actors. For defenders, BYOVD demonstrates why software trust and software safety are not the same thing.
Does bypassing EDR require disabling it?
No. An operator may evade a specific detection without stopping the EDR product entirely. They may change execution behavior, reduce suspicious characteristics, avoid a monitored pathway, abuse legitimate tools, or operate in a way that produces insufficient context for a detection. Directly disabling or modifying defensive tooling is only one category of defense evasion.
Why are legitimate tools relevant to EDR evasion?
Because legitimate administrative tools already exist within the expected operating environment. Their use may generate telemetry, but that telemetry can be harder to classify as malicious without additional context. This is why detection programs need to understand intent and sequences of behavior — not only whether an executable is known to be malicious.
Is EDR still worth investing in?
Yes. EDR provides critical endpoint visibility, behavioral detection, investigation, containment, and response capabilities. The problem is not EDR. The problem is assuming that deploying EDR removes the need for independent telemetry, detection engineering, network visibility, identity monitoring, and adversarial validation.
How should a CISO measure EDR effectiveness?
Deployment percentage and sensor-health metrics remain useful but are incomplete. Organizations should also evaluate detection and response under realistic adversarial conditions — whether high-risk behavior is observable, whether telemetry impairment is identified, whether analysts respond correctly, and whether independent controls expose activity that one endpoint mechanism misses.
Can AI automate EDR evasion?
A 2026 arXiv preprint demonstrates a multi-agent framework capable of automating parts of EDR-resilience testing and iterative evasion under laboratory conditions. This is promising research, but it should not be treated as evidence that autonomous EDR evasion is currently widespread among real-world attackers. The more immediate leadership implication is that automation could reduce the time and expertise required to iterate against detection systems.
What should a red-team assessment test?
A mature assessment should test more than whether a payload executes. It should determine whether realistic attacker objectives can be completed when specific endpoint detections are bypassed, whether defensive telemetry remains available elsewhere, whether defenders recognize degraded visibility, and whether the organization can contain the attack before material business impact occurs.
The Endpoint Is Visible Only While the Signals Hold
Attackers keep finding ways to bypass EDR because detection is not static.
Defenders change what they observe. Attackers change how they behave. Defenders collect deeper telemetry. Attackers investigate those telemetry sources. Detection moves from signatures to behavior, from behavior to context, and from user mode deeper into the operating system. The cycle continues.
That does not make EDR ineffective. It makes absolute confidence in any single visibility layer indefensible.
For CISOs, the objective should not be to find an endpoint platform that claims to see everything. It should be to build and test an environment in which losing one signal does not mean losing the attacker.
EDR coverage tells you where the sensor is installed. Adversarial testing tells you what the organization can actually see. That is the gap offensive security should close.
If your organization relies on endpoint controls to detect and contain sophisticated attacks, contact wizlynx group to test whether your defensive visibility holds when realistic operators challenge the assumptions behind it.
About wizlynx group
wizlynx group is a CREST-accredited offensive security company headquartered in Switzerland, operating across Europe, North America, Latin America, and Asia. wizlynx group specialises in penetration testing, red teaming, adversary simulation, social engineering, and advanced security assessments for enterprise clients.
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.