EDR Solutions From Top Vendor Still Vulnerable But EDR Will Continue to Evolve

In October 2021 I read an article from The Journal of CyberSecurity and Privacy titled:  “An Empirical Assessment of Endpoint Detection and Response Systems against Advanced Persistent Threats Attack Vectors” while writing an article about EDR/XDR solutions and how they have evolved the strategy for threat hunting over traditional methods.  You can read that article here.   I think now is a good time to revisit that research paper and describe what was uncovered. More specifically: what type of TTPs are still able to circumvent top of the line EDR solutions built by the world’s top vendors of security products? One reason for this revisit is because I saw an article by Recorded Future discussing the same paper and wanted to contribute my take on it.

The full paper is available for download here: https://arxiv.org/pdf/2108.10422.pdf, and the published version is available by searching Google for the article title “An Empirical Assessment of Endpoint Detection and Response Systems against Advanced Persistent Threats Attack Vectors”.

The ultimate take-away from this mid-2021 research paper is that EDR/XDR solutions are not fully effective and mature.  There is still significant work to be done with respect to blocking the numerous attack vectors presented by a MicroSoft Windows 10 (MSW10) installation.  There are significant components and attack surfaces in MSW10 including legacy DLLs, and support that is not used by most legitimate modern software applications, and instead mostly serve to allow malware to “live off the land” (LOTL).  LOTL allows malware to avoid the need download its own tools to conduct an attack.  Instead, the malware can use tools already built into an operating system.  MSW10 or future versions of MS Windows allowed custom installation to remove legacy DLL support, organization’s networks would be more secure.  Let’s take a look at the research approach and findings.

The researchers sought to answer the following questions:

  • Can state-of-the-art EDR detect common APT attack methods?
  • Which are the blind spots of state-of-the-art EDRs?
  • What information is reported by EDRs and which is their significance?
  • How can one decrease the significance of reported events or even prevent the reporting?

Four real world attack scenarios were used that were modelled from the MITRE ATT&CK framework.  The goal was to minimize the threat score reported by the various EDRs tested thereby either not triggering a security alert, or triggering one with the lowest score possible.  4 attacks were used:

  1. A .cpl file: A DLL file which can be executed by double-clicking under the context of the rundll32 LOLBINS which can execute code maliciously under its context. The file was crafted using CPLResourceRunner (https://github.com/rvrsh3ll/CPLResourceRunner accessed on 8 July 2021). To this end, the researchers used a shellcode storage technique using Memory-mapped files (MMF) and then trigger it using delegates.
  2. A legitimate Microsoft (MS) Teams installation that will load a malicious DLL. In this regard, DLL side-loading (https://attack.mitre.org/techniques/T1574/002/accessed on 8 July 2021) will lead to a self-injection, thus allowing attackers to “live” under a signed binary. To achieve this, we used the AQUARMOURY-Brownie (https://github.com/slaeryan/AQUARMOURY accessed on 8 July 2021).
  3. An unsigned PE executable file; from now on referred to as EXE, that will execute process injection using the “Early Bird” technique of AQUARMOURY into werfault.exe. For this, researchers spoofed the parent of explorer.exe using the PROC_THREAD_ATTRIBUTE_MITIGATION_POLICY flag to protect their malware from an unsigned by Microsoft DLL event that is commonly used by EDRs for processes monitoring.
  4. An HTA file. Once the user visits a harmless HTML page containing an IFrame, he will be redirected and prompted to run an HTML file infused with executable VBS code that will load the .NET code provided in Listing 2 and perform self-injection under the context of mshta.exe.

The researchers simulated APT attacks using an experimental network setup against 20 Endpoint Security products, and the results are shown in the table below:

Table 1. Aggregated results of the attacks for each EDR. Notation: : ✓ Successful attack,<> Successful attack, raised medium alert, •: Successful attack, raised minor alert, ⋆: Successful attack, alert was raised ◦:Unsuccessful attack, no alert raised, ✗: failed attack, alerts were raised. † In two experiments supplied by the vendor, in the first it was detected after five hours, in the second it was detected after 25 minutes. ⊙ Initial test was blocked due to file signature, second one was successful with another application.

EDR Product Test Results

Generated by wpDataTables

Leave a comment

Your email address will not be published.


This site uses Akismet to reduce spam. Learn how your comment data is processed.