EDR, Telemetry & Evasion: Know Your Sensors

Every conversation about "EDR bypass" that treats the EDR as a monolith is starting from the wrong place. An EDR is a collection of independent telemetry sources — some in the kernel, some in userland, some on the wire — whose outputs are stitched together into a picture of what a process is doing. The strategic question for a defender is not "can this one sensor be evaded?" (almost any single sensor can) but "if it is, what still sees the activity?" This article names the major sensors, explains the broad families of evasion at a conceptual level, and makes the case for defence in depth. It maps naturally onto the Defense Evasion tactic in MITRE ATT&CK.

Kernel callbacks — the ground truth

The operating-system kernel offers registered callback notifications: the EDR asks to be told when a process is created, when a thread starts, when an image (a DLL or driver) is loaded, and when certain handles are opened. Because these fire from inside the kernel, they are difficult for userland malware to suppress and represent some of the highest-integrity telemetry an EDR has. Process-creation events in particular, with full command lines and parent-child lineage, are the backbone of most behavioural detections.

ETW — the event firehose

Event Tracing for Windows (ETW) is a built-in, high-volume instrumentation framework. Providers across the OS and .NET runtime emit structured events — assembly loads, network activity, PowerShell script blocks, and much more — that an EDR subscribes to. ETW gives extraordinary breadth, which is exactly why it is a target for tampering. The defensive counter is to treat a gap in an expected ETW stream as itself suspicious: when a normally chatty provider suddenly goes quiet on a host, that silence is a signal.

AMSI — inspecting content at runtime

The Anti-Malware Scan Interface (AMSI) lets scripting engines and other applications submit content — a script about to be interpreted, a macro, a buffer — to the installed anti-malware product for inspection at the moment it is used, defeating simple on-disk obfuscation. Because AMSI runs in the same process as the script it inspects, it is a frequent tampering target; and, as with ETW, the manipulation of AMSI is often noisier than the payload it was meant to hide.

Userland hooks — visibility inside the process

Many EDRs inject a monitoring module into user processes that hooks key API functions, redirecting them through the sensor so calls can be inspected before they reach the OS. This gives fine-grained visibility into what a process asks the system to do. It is also the most exposed sensor: it lives in memory the target process controls.

Why unhooking is loud

Techniques that restore or bypass these hooks — reloading a clean copy of a system library, or calling into the kernel by a route that skips the hooked functions — can indeed blind the userland sensor. But they leave their own marks: an anomalous fresh mapping of a core system DLL, or system calls issued from an address that is not inside the module that should own them. A mature EDR watches for the act of unhooking, not just for the calls the hooks were meant to catch. This is the recurring lesson: evasion converts one signal into a different, often rarer, one.

Blinding a sensor is never free. The manipulation needed to silence one telemetry source almost always trips another — the defender's job is to make sure a second sensor is watching.

Network sensors — the layer the host cannot touch

Finally, telemetry gathered off the host — at a firewall, proxy, or network tap — sits entirely outside the endpoint the attacker has compromised. No amount of userland or even kernel manipulation on the victim changes what the wire records. Beaconing rhythm, unusual egress, and TLS or DNS anomalies (covered in our C2 article) are visible here regardless of on-host evasion, which is why network detection is such a valuable backstop.

The three families of evasion

Stripped of specifics, host-level evasion falls into three conceptual families:

• Blinding — tampering with a sensor so it stops reporting (unhooking, disabling a provider). Detectable as the tamper action itself, or as a suspicious telemetry gap.
• Avoidance — choosing execution paths a given sensor does not observe. Detectable when a second sensor covers the same activity from another angle.
• Blending — imitating legitimate activity so events look benign. Countered by behavioural baselining and cross-event correlation rather than any single rule.

Notice that the counter to every family is the same: more than one sensor, correlated. No individual family survives a defence that refuses to rely on a single point of observation.

Designing for graceful degradation

The practical takeaway for a blue team is to architect detection so that losing one sensor does not lose the detection. Pair kernel-integrity telemetry with network analytics; treat provider silence and unhooking as first-class alerts; and use authorised red teaming to deliberately blind sensors one at a time and confirm the others still fire. A detection strategy that degrades gracefully under partial evasion is worth far more than any product's marketing about a single unbeatable sensor.