Cybersecurity: how EDR protects itself against attacks

An EDR is one of the solutions available to protect workstations and servers, and for obvious reasons, attackers will seek to circumvent or even “kill” them to achieve their ends (ransomware, data theft, spying…).

But how? And how does an EDR protect itself? We explain.

Areas where attackers can intervene to disable an EDR

User space

This is where the majority of user actions take place, and it’s also the most accessible space for attackers.

Kernel space

Kernel is much more protected than user space. As a result, it’s much more difficult to access, since you need a lot of rights to access it, and operating systems (OS). Specifically, Windows, does not allow the loading of non-Microsoft signed kernel components..

“An EDR and cybersecurity solutions market in general is growing, with more and more companies and organizations being equipped. As it is becoming increasingly rare to come across unprotected IT assets, the success rate of attacks is falling. And because attackers want to get their way, the kernel is increasingly being targeted.”
Benoit Maïzi, Cybersecurity Engineer – HarfangLab

How an attacker can attempt to bypass an EDR

An EDR detects events on a system by acquiring system events through sensors across the system, events which are then sent to the detection engines, which will use rules to determine if the action is legitimate and whether block it or not. If the attacker succeeds in blocking these sensors in user or kernel space, the associated system events cannot be fed to the agent, nor an alert generated.

In this way, an attacker can try to prevent an EDR from detecting events likely to trigger an alert, by blocking the sensors.

In a user space, events can be intercepted, for example, by bypassing userland hooking.

Userland hooking is a method used by security solutions to intercept system events in user space. By bypassing userland hooks, the attacker seeks to prevent security solutions from intercepting events that enable detection.

On Windows, attackers can also attempt to bypass AMSI (Antimalware Scan Interface) or ETW (Event Tracing for Windows), or even auditd on Linux and Endpoint Security for macOS. But this tactic is risky, as they can easily be spotted trying to bypass these heavily protected features, and can also be detected by signature-based rules (such as YARA) if the file performing the action is already known, or behavioral rules (such as Sigma).

“Since the early 2020s, attacks have increasingly targeted the kernel – Windows in particular – and these attacks are no longer just perpetrated by advanced attackers. More basic attackers are also turning to these tactics, forcing vendors to strengthen in this direction.”
Benoit Maïzi, Cybersecurity Engineer – HarfangLab

As we mentioned earlier, kernel space is much more protected than user space and therefore more difficult to access, but having said that, if an attacker manages to get in, their possibilities are very wide.

They can then attempt to:

disable the EDR – but with a very high risk of being detected, especially as EDR is designed to recover;
prevent EDR from intercepting system events (process or thread creation, registry or file system modifications, etc.).

Preventing EDRs from catching system events is particularly devious, because unlike an attack marked by an incident (endpoints out of service, ransom message…), the information system will keep on running, giving the organization the impression that everything is “normal”.

In any case, whatever the strategy employed by the attacker, EDR must be able to protect itself in order to remain active and ensure the security of an IT infrastructure.

Let’s take a look at how HarfangLab’s EDR agent self-protection works.

EDR: how agent self-protection works

HarfangLab’s EDR is protected by its own driver, which intercepts all types of access to its process and the files associated with the EDR, and checks whether the process is legitimate or not.

For optimum protection, the case where the user is the administrator of his own machine is taken into account: even as the administrator of his own workstation, a user cannot delete the EDR.

To secure the kernel, sensors are deployed to identify the presence of any third-party components attempting to alter detection capabilities, and to alert users if necessary.

As we pointed out earlier, an OS does not allow to execute anything and everything in the kernel, as the executable must first be recognized. This is an obstacle for attackers, who are not supposed to be able to create their own code and load it wherever they like, unlike Linux, for example.

But then again, they’re looking for the flaw, which brings us to the subject of vulnerable drivers.

Vulnerable drivers: the basis of kernel attacks

As an important component in a kernel, the driver is a binary that can be targeted by an attack if identified as vulnerable. To address this threat, lists of vulnerable drivers are maintained by security vendors and the Open Source community, so that policies can be adapted to block what needs to be blocked.

Since attackers can’t load their own drivers, they use vulnerabilities as a mean of gaining access to the kernel, in an attempt to attack security tools and load their own code. In this way, the vulnerable driver remains a well-known and readily used path. Indeed, if they manage to identify a driver that is not present in the blocking list, or if the list is not configured as blocking, they will attempt a so-called “Bring Your Own Vulnerable Driver” attack.

In concrete terms, attackers who have gained access to a machine by executing a malicious binary will then attempt to load a driver that will enable them to increase their privileges on the infected system, and bypass existing security solutions. This method is becoming increasingly popular, and the development of the Open Source ecosystem means that less advanced attackers can access these methods, which EDR also protects against.

In conclusion, attackers can try to intervene in two spaces: userland and kernel land, to attempt to delete files, kill EDR process, alter its communications with its manager, prevent it from performing its detection and alert functions…

In all cases, the agent is designed to protect itself: