No magic: how loaders slip past EDR.

#The wall that isn't

Endpoint detection and response is the most important security control on most modern estates, and it is routinely misunderstood as a wall: install it, and attackers bounce off. It is not a wall. It is a sensor grid, a set of instruments watching the places attacker activity tends to show up, feeding a detection engine that scores what it sees. Getting past it is not a zero-day and not magic; it is the craft of operating in the gaps between the sensors, or of quietly turning a sensor off.

This piece is deliberately conceptual. It names the families of evasion technique and, for each, the defensive move that beats it. There is no loader code here and nothing to copy-paste, the goal is to change how you buy, tune, and trust an EDR, not to arm anyone.

#How EDR actually sees

An EDR builds its picture from a handful of vantage points. Understanding them is the whole game, because every evasion class targets one of them:

• Userland API hooks. The agent injects into processes and intercepts sensitive calls (process creation, memory allocation, injection primitives) by redirecting them through its own inspection code first.
• Kernel callbacks. Registered notifications from the operating system when processes start, images load, or threads are created, harder for an attacker to touch from userland.
• ETW and scan interfaces. Event Tracing for Windows and the Antimalware Scan Interface (AMSI) give the agent a feed of what scripting engines and the .NET runtime are doing.
• Behavioural correlation. The engine stitches individual events into sequences and scores the pattern, not the single call. This is where good EDR earns its keep.

#The evasion classes, and what each defeats

The lesson is in the right-hand column. No single evasion defeats the whole grid; each one trades a loud sensor for a quieter one. A layered EDR, and a defender who watches the sensors themselves, forces an attacker to defeat several at once, which is where the craft gets expensive and the noise gets unavoidable.

#Userland hooks and why they are brittle

The most discussed evasion class targets userland hooks. Because the agent's inspection code lives inside the process it is watching, code running in that same process can, in principle, notice the hooks and route around them, calling deeper into the operating system than the hook sits, so the inspection never runs. This is the family that includes direct and indirect system calls and various “unhooking” approaches.

The defensive point is that this only blinds one sensor. The kernel callbacks still fire when a process or thread is created; ETW may still emit; and, crucially, the act of tampering with a process's own memory in these ways is itself anomalous and detectable. Vendors that lean entirely on userland hooking are the most exposed here, which is a concrete question to put to yours.

#Blinding the telemetry: AMSI and ETW

Rather than dodge a sensor, an attacker can try to switch it off. AMSI and ETW are the usual targets: both expose interfaces that, if tampered with in the attacker's own process, stop delivering the events the agent expects. Historically this has been the most reliable way to run malicious scripts and .NET tooling without the runtime narrating every move to the defender.

Here the defence is elegant: the silence is the signal. A mature EDR monitors the integrity of AMSI and ETW and treats tampering as a high-confidence detection in its own right. An attacker who patches the scan interface to go quiet has, paradoxically, made a loud noise, if you are watching for it. Products vary enormously in whether they do.

#Living in memory

Signature antivirus is a file scanner, so the oldest evasion is simply to never write the payload to disk. Modern offensive tooling loads and runs code entirely in memory, reflective loading, process injection, and related techniques, precisely to stay off the one surface legacy tools watch best.

This is where EDR pulled decisively ahead of antivirus. Good products scan process memory, flag suspicious memory regions (executable-and-writable allocations, private memory that looks like a loaded image), and correlate injection primitives across processes. In-memory execution defeats a file scanner; it does not defeat a memory scanner paired with behavioural correlation. We treat the antivirus-versus-EDR gap at length in Antivirus is a floor, not a ceiling.

#Bringing your own vulnerable driver

The most powerful class attacks the kernel sensors themselves. In a bring-your-own-vulnerable-driver (BYOVD) attack, the operator loads a legitimately signed but vulnerable driver and abuses it to gain kernel-level actions, from which the EDR's own kernel components can be blinded or unloaded. It is the closest thing to actually knocking a hole in the wall, and it is comparatively rare because it is noisy, risky, and increasingly well defended.

The defences are concrete and available: Microsoft's vulnerable driver blocklist, hypervisor-protected code integrity (HVCI), and telemetry on driver loads. An estate with these enabled forces an attacker toward a much shorter list of usable drivers, each of which is a known, huntable indicator.

#What actually raises the bar

• Do not rely on one sensor. Prefer EDR that combines kernel callbacks, ETW, and memory scanning with behavioural correlation, so no single bypass is decisive.
• Watch the sensors themselves. AMSI/ETW tampering, unexpected driver loads, and hook removal should be first-class detections, not afterthoughts.
• Turn on the platform defences. HVCI, the vulnerable-driver blocklist, attack-surface-reduction rules, and constrained language modes remove whole evasion classes for free.
• Correlate beyond the endpoint. Identity, network, and cloud signals catch what a blinded endpoint agent cannot; an attacker who silences the host still has to authenticate and move.
• Test it adversarially. The only way to know which sensors your product really leans on is to have someone try, under contract, to slip custom tooling past it, and report which detections fired.

#What this means for you

• EDR is necessary and not sufficient. It raises the cost of an intrusion enormously; it does not make one impossible.
• Configuration is most of the value. A well-tuned mid-tier product with platform defences enabled routinely outperforms a flagship left on defaults.
• The gap is knowable. Every technique above maps to a sensor and a counter. An adversarial test tells you which gaps are yours, specifically, rather than in the abstract.