Antivirus vs EDR

Nowadays, antivirus engines use static and dynamic analysis, as well as detection based on heuristics in order to detect and block endpoint threats. Their main limitation is the lack of detection regarding post-exploitation actions. Indeed, when the attacker execute a malware successfully on a host, he wins.

This is the reason why EDRs’ detection capabilities are based on TTPs [1]. They attempt to detect misbehavior that slightly deviates from the baseline, by continuously analyze the memory for inter-process interactions. While a few so-called “EDRs” are still strongly based on signatures for detection, others opt for behavioral analysis only.

Deploying EDRs is not enough to benefit from their detection capabilities. The installed software is often misconfigured and does not send its logs to a centralized management console. As the EDR branding (“Endpoint Detection and Response”) is based on detection more than prevention, they require a proper configuration and an incident response team in order to handle the alerts.

Consequently, an attacker will adapt the TTPs depending on the type of detection engine, the vendor, and the response team capabilities by performing a situational awareness phase.

Blinding the EDR agent via sinkholing

In order to be effective, the centralized management console needs to communicate with its agents. In other words, all the agents installed on the systems will need to callback to command and control server (C2).

Generally, the C2 is exposed on the Internet in order to be accessible from remote access. When the C2 has a domain, it is possible to send the callback traffic to a sinkhole. On Windows, as on Linux, before any DNS query, the operating system will check the cache and local entries. With administrator rights on a system, an attacker is able to modify the local entries. Moreover, he’s also able to force the C2 domain to point to the localhost. This technique blinds the EDR agent, as he cannot communicate with the console.

This can completely remove the analyst detection from the equation, or this can give some time to the attacker when an alert arises due to the impossibility to contact an agent for an extended time period. However, this alert may occur quite often and will still need to be investigated.

Unhooking the EDR process injection

For memory-based detections, an EDR will need to inspect process actions and will most probably inject itself in every process.

Attackers have the possibility to detect and block this process injection. Based on the same legitimate techniques that sensitive processes use to prevent the injections, the malware running in memory makes the detection engine blind .

Spoofing techniques pushing back the EDR from detection

A usual hunt technique is to instrument a host to report all new/unknown processes, their arguments, and the parent process. The following attacks tend to push back the EDR from the detection and to fool the analyst during the investigation.

Process argument spoofing

This technique is an evade detection method that looks for malicious process arguments. It uses Win32 API calls to read the data structure of the running process, extract its memory, and create a copy by modifying its command line.

Consequently, this technique relies on reading and writing to memory in a process. It remains an indicator of suspicious activity. Nevertheless, this still masks the activity from the analyst.

PPID spoofing

The analyst and the EDR always try to suppress the noise and highlight interesting events. One way to do it is to look for odd parent-child process relationships.

This feature takes advantage of the standard process creation API that permits to launch elevated processes with the non-elevated process as parents. This is how UAC [2] works. It is used to mimic a legitimate behavior and hides malware under legitimate processes avoiding nonsense such as notepad.exe spawning cmd.exe and communicating with the Internet.

Binary signature spoofing

The goal is to masquerade the malicious binary with a Windows system binary using digital signatures. It consists of modifying the binary’s metadata.

It is possible to make Mimikatz looks like a signed Microsoft binary by stealing the signature of a trusted binary. The binary is modified in a way to always respond to the EDR checks with the expected right answers, like a legitimate and trusted binary, even if the underlying signature is invalid. For example, in order to check the binary trust level, the EDR can perform system calls to verify if the binary is signed by a trusted authority.

Denial of service

Depending on the EDR configuration, when the analyst considers a host as infected, he generally isolates it from the network.

An attacker with high privileges inside a network can take advantage of this mechanism to perform a massive denial of service or target a critical server.

EDR as an attack vector

An EDR is potentially a malware the IT department controls. It has capabilities similar to Trojans: code execution, file extraction, and memory dump.

An attacker with access to the centralized management console can be able to create exclusions to establish persistence and execute malicious code on hosts placed in sensor networks that may not be accessible from the user LAN. Indeed, as the agents perform callbacks to the console, they bypass all potential network restrictions.

Conclusion

Seasoned attackers will always try to adapt the attack, depending on the detection engine and incident response capabilities. They will take advantage of a permissive or too restrictive configuration and will try to fool the analysts by sending false information. In other words, depending on the configuration, when they cannot fool the EDR, they still can try to fool the analysts.

Therefore, since trusting a compromised host only from the EDR outputs is not always possible, hunt operators are needed to deep dive into alerts and more generally into endpoint security.