The reality behind bypassing EDR attempts

Endpoint detection and response tools are an integral component of any organization's security program. Yet, hackers have developed EDR evasion techniques to slip past these tools to attack endpoints and networks.

This then begs the questions: Just how successful are EDR evasion attacks? Do EDR tools not detect them? Is it a race between the attacker getting in and out of the network before the security operations center (SOC) can respond?

To help security practitioners and red teamers understand how EDR tools function and acknowledge threats, Matt Hand, author and principal security engineer at cybersecurity vendor Prelude, penned Evading EDR: The Definitive Guide to Defeating Endpoint Detection Systems. The book provides SOC members and offensive security teams a breakdown of EDR systems and how they handle evasion attempts, such as process injection.

Hand spoke with TechTarget Editorial to offer an overview of EDR, the types of attacks malicious actors use in EDR evasion and common outcomes of such attacks.

Editor's note: The following interview has been edited for clarity and length.

To set the stage, could you provide a quick explainer on how EDR works?

Click to learn more about
Evading EDR: The
Definitive Guide to
Defeating Endpoint
Detection Systems by
Matt Hand.

Matt Hand: When you walk into a doctor's office, you see different tools -- stethoscope, blood pressure monitor, etc. One observes your heart rate, another measures blood pressure and so on. These different tools provide doctors a way to evaluate your overall health.

EDR tools are similar; they have multiple individual components and sensors, each designed to pick up specific things other EDR components either aren't able to do or can't do as efficiently. These components produce massive amounts of data on the well-being of an organization's systems. The EDR agent orchestrates and synthesizes the data at a host level and then makes a determination about different events based off the data -- for example, whether an event is malicious or is benign enough to let be.

All EDR tools do this basic functionality, though some have differences depending on the vendor. It's about collecting a massive amount of data on everything happening on a system from different tools and then consolidating and correlating that data.

How do malicious actors bypass EDR systems?

Hand: One attack technique involves syscalls, a standard function that involves how a program interacts with the OS -- for example, assembly instructions that tell the kernel to do something on your behalf. Attackers use direct syscalls to call those assembly instructions directly, thereby preventing an EDR that is monitoring executions of these specific syscall functions from noticing. Essentially, this attack uses an indirect route to achieve the same task as part of the attack.

Another technique that got a lot of play from attackers over the past few years used an antivirus and EDR evasion tool called SysWhispers. This caught everyone off guard with how seemingly effective it was and how much sense it made. While it's not unusual to see an attacker use it, however, it doesn't actually work. The data sources that EDR systems use can detect these attacks. A chief engineer at CrowdStrike said when the tool first debuted that EDR vendors don't care about that data either and have better ways of catching attacks, so this technique doesn't really affect them at all. It was this funny blind-leading-the-blind problem.

Other attacks to bypass EDR systems include using command-and-control frameworks, such as ones that use Fork&Run, which spawns sacrificial processes to do something malicious. Even if both the sacrificial process and the malicious action die, the attacker has the output already and has moved on. The problem for attackers is that, when they create a new process and inject their tooling into it, there are a lot of indicators that come with it -- and EDR tools catch remote process injection, which this attack model requires to function.

You wrote in Evading EDR that many attackers -- for example, those without the expertise or time -- rely on publicly published attacks for their EDR bypass attempts. Why is that?

Hand: EDR evasion is hard -- it's a full-time job. Nonpublic evasions are where mature red teams and the real threat actors live. If you have an evasion that works reliably, it's counterintuitive to disclose it. All it takes is an EDR vendor that monitors X, formerly known as Twitter, to see the publicly disclosed attack and ask its threat intelligence group to beat it. It's an arms race between EDR vendors and people evading EDR -- whether for money, malicious intent or national security-related. Any publicly posted attacks are used by the rest of the attackers -- and defenders -- out there.

Why is it so difficult for malicious attackers to successfully bypass EDR?

Hand: To put it simply, EDRs are good pieces of software. I grew up in the age of antivirus. You'd install it and then everything broke -- like, you couldn't download a browser toolbar. It was hilariously bad. Antivirus can't handle people using legitimate native Windows functionality, so the attackers adapted to that. It was easy to beat the living daylights out of antivirus day in and day out. People today sometimes view EDR as antivirus++ -- like it's the next antivirus iteration -- when it's an entirely different ecosystem.

An EDR system knows anytime a user touches the file system or creates a process or new thread. The amount of data I have worked with from EDR tools is massive -- and that's from a single host. Imagine the amount of data from an entire enterprise.

EDR vendors also have access not just to one customer's data, but everyone's data, and they use it to make correlations about activity. For example, if I install never-before-seen malware onto a computer, it's going to raise EDR flags, especially if it's used twice. The EDR will question what is happening and whether the application is doing other activity on the network.

That said, there are ways to take advantage of this. EDR vendors have to make concessions for things like system performance, usability, reductions of false positives and customer needs. If EDR engineers had their way, they would collect an infinite amount of data and process it all, but that doesn't work in the real world. Tens of thousands of registry operations are happening every second on a host; if you introduce a 5 millisecond delay, you slow the system down to beyond unusable -- it'll look frozen.

Security teams should be selective about which registry operations their EDR tools monitor. EDR software might ignore certain areas where attacks aren't typically conducted. This is where an attacker or red teamer can hide attack attempts.

Will an EDR eventually catch a malicious event, even if it ignores it initially?

Hand: This has a nuanced answer. Let's say an objectively malicious event happens. The EDR tool monitoring that system catches the event and observes that data before passing it through the agent. It knows the event appears malicious but won't necessarily make a determination. It forwards that info to the SOC as an alert.

How the EDR proceeds from there depends on the EDR vendor -- they all have different philosophies about handling events. One vendor might have its EDR track the specific event like it is malicious and collect every bit of information about it. Or it might limit the amount of harm the potentially malicious event can do by shutting down activity across other customers and hosts. Another vendor's EDR might take a sit-and-wait approach without intervening, while another tool might respond aggressively by immediately shutting down the event and firing off an alert.

Also, consider what the SLA [service-level agreement] is for reacting to an event. Can the EDR system act immediately without any human interaction, or does it produce an alert? This can add time between an event and when it is stopped. Some vendors may have a 24-hour SLA -- by that time, the event and attacker could be long gone and the damage done. We're beholden to how a vendor's EDR works unless we enhance it ourselves.

How can SOCs enhance their EDR tools?

Hand: Teams need to test and validate the EDR systems at their organization. Vendors have made a lot of improvements to their products over the years, but an out-of-the-box EDR isn't ideal for every customer.

For example, every organization has a different tolerance when it comes to handling false positives and false negatives. A mom-and-pop store might lose a small amount of money if its payment system temporarily goes down, but it won't hurt them too much overall. Compare that to a major power corporation that services millions of customers. If an issue crops up, it has to tackle it immediately.

Test and validate that your organization's EDR tool does what it needs to do. From there, create custom detection rules that work for your organization's use cases. For me, I don't want to miss anything ever, even if that means getting more information or false positives than I'd like. Creating custom detection rules is where I see a lot of security programs moving in the future.

Kyle Johnson is technology editor for TechTarget Security.