A Guide to Reversing and Evading EDRs: Part 1


Two months ago, I had the opportunity to privately present a two-hour talk on reversing and evasion techniques that can be abstracted to multiple EDR products. I had some requests to publish the material, so I started putting this series together.

This is slightly more watered-down than the original material because I can't publish certain product-specific details. Instead, I'll discuss my general methodology and thought process.

The intended audience is for red teams and offensive developers, and I think defenders will benefit too. Getting into the weeds of these products can be daunting, so hopefully this demystifies unknown-unknowns to known-unknowns.

Evasion Concepts

Endpoint Detection and Response (EDR) products monitor programs during execution to detect/respond to suspicious behaviours. This complements traditional AV functionality which uses signatures and heuristics to block unwanted programs prior to execution. Some of the top players in the EDR space include Microsoft, CrowdStrike, Cylance, Carbon Black, and FireEye.

While evasion can be a broad term, attacker responses to EDR typically fall into these buckets:

  1. Avoidance: furthering mission goals on systems that don't have the product installed or enabled (e.g. operating from an unprovisioned endpoint, or proxying traffic through a provisioned endpoint).
  2. Blending In: hiding in the noise of what's commonly recorded by EDR sensors (e.g. using common parent-child process relationships).
  3. Abusing Blind Spots: taking advantage of areas that the sensor doesn't capture or report on (e.g. using certain APIs not being logged, removing hooks, making direct syscalls).
  4. Tampering Sensors: altering sensor behaviour to the attacker's advantage (e.g. patching the sensor so malicious behavior is not reported and/or collected).

Problem Statement & Topics

When it comes to measuring the effectiveness of EDR bypass techniques, many operators do this anecdotally, i.e. based on whether they were detected or not during operations. This highlights an asymmetry in visibility between offensive teams and defenders, where the exact technical reasons for a bypass' success or failure is difficult for the operator to deduce without access to the telemetry and detection queries.

If an operator could gain independent access to sensor telemetry, that could serve as a catalyst in not only measuring bypass efficacy, but also for finding new blind spots or ways to blend in, and validate sensor tampering efforts.

I see this as a natural step in evolving offensive tradecraft and will examine the following topics:

  1. Reverse engineer sensors to gain access to sensor telemetry without phoning home.
  2. Use telemetry as a feedback loop, to find blind spots or ways to blend in.
  3. Explore a range of increasingly sophisticated tampering techniques to mute the sensor.
  4. Repurpose response features to make the sensor function as a RAT (for fun).

The suggested approach I'll describe in this series is to set up a lab with the EDR sensor installed, but tweaked to send the telemetry over to custom infrastructure so it doesn't phone home. This opens up opportunities for A/B testing to get a sense of what behaviours could trigger detections and identify options to blend in or find blind spots. Those options can be used to fly under the radar to a degree. When they have been exhausted, sensor tampering techniques can be used instead to mute the collection and/or reporting of events.


I had not looked closely into EDRs prior to this year, and it was overwhelming at first to be honest. I could not have learned how to do all of this without the generosity of those willing to share their knowledge. Below is a list of security product subversion readings I found relevant:

I would also like to thank the following people for their contributions and feedback to this series: Shogun Lab, Lincoln, and unnamed others.