Why Attacks From LOLBin Malware Bypass EDRs

Join us as we do a deep threat analysis into the vulnerability and exploitation of LOLBin attacks like Flax Typhoon and why these attacks easily bypass EDRs.

When I read this article about the Flax Typhoon attack, amongst other things, it reminded me that when EDRs first appeared on the horizon, they pointed out that the signature-based approach used by AV vendors to detect malware could stop 95% of the then-conventional malware-driven attacks. Yet, the 5% attacks that escaped could inflict existential damage to the enterprise platform. The ease with which the Chinese Threat Actors associated with Flax Typhoon cut through the defenses made me wonder if the EDRs have also met their Waterloo. With that in mind, it would be instructive to unpack the Flax Typhoon attack and how EDRs do their business.

What is a LOLBin attack, and why does it bypass EDRs? Unlike executable malware (such as malware.exe), LOLBin malware involves some typical executable, such as the OS-provided PowerShell (Windows) or bash (Linux) runtime utility. The Threat Actor triggers a command like PowerShell + <Malicious_Command_String>. It is challenging for an EDR to discern if the application or the threat actor issued the offending command. This ambiguity leads to the EDR doing nothing and the attack succeeding.

The nexus between LOBIN Malware and CISA’s Known Exploited Vulnerabilities (KEVs): On reading the advisories CISA issues following the KEV disclosure, it should be evident that almost all vulnerabilities have either:

1. Remote Code Execution (RCE) attributes: Vulnerabilities with RCE attributes abet the Threat Actor in infiltrating the vulnerable workload and gaining the ability to execute arbitrary code of their choosing or,
2. Privilege Escalation attributes: A Threat Actor can use such a vulnerability to execute a series of commands that will allow them to bump their privileges and execute arbitrary commands that they could not run otherwise.

What is interesting to note is that in both cases, the threat actor ultimately acquires the ability to execute arbitrary code of their choosing, which is very different from what the application wants to do. As discussed above, EDRs lack the context to make this distinction.

How Does an EDR work? The typical EDR leverages a simple principle encapsulated in the phrase Default-Allow-Block-On-Threat. Of course, it does some sanitizing and doesn’t allow blatantly known malware to execute. The next question we should be asking is …

How Does an EDR Detect Threats? There are two discrete techniques as described below:

1. MITRE TTP: Please recall that any host-based security solution is always trying to find out if the code currently executing was issued by a Threat Actor or by a legitimate process. One class of EDRs associates a series of OS System Calls with each MITRE TTP. When a process issues these series of OS System Calls at run time, the EDR bumps up its suspicion score. When the process executes a sufficiently large number of MITRE TTPs, the EDR convinces itself that the process is under attack and proceeds to terminate it. Such EDRs do not rely on signature or threat feeds.
   
   
   
   
2. Threat Feeds: Other EDRs rely on threats like Alien Vault’s OPX threat feed. We show a snippet of the OTX Threat Feed for Flax Typhoon below:

What is Millisecond Malware, and how does it Impact EDRs? Millisecond malware can disable, bypass, or otherwise adversely impair EDRs within the first few seconds of execution. With the EDR bypassed, disabled, or otherwise impaired, it would be unable to detect and respond to any threats beyond the first few milliseconds.

Given that:

1. The MITRE TTP approach used by EDRs, as described above, is imprecise and
2. The Threat Feed approach relies on circumstantial evidence that an attacker can easily manipulate to their advantage

It should be no surprise that EDRs get bypassed by determined threat actors, especially regarding fast-acting malware that can terminate or blindside EDRs in milliseconds.

This analysis leads me back to the question we started with. Have EDRs finally met their Waterloo at the hands of determined threat actors, and they are no longer the gold standard they once were?

What would an effective host-based security control MUST do? An effective security control that can challenge even accomplished threat actors needs to do the following two things:

1. Load Time Protection: Instead of relying on the Default-Allow-Block-On-Threat approach, it should leverage the Default-Deny-Allow-On-Trust approach. This approach means any code not explicitly trusted by the user should not be allowed to run. Unknown code can be millisecond malware that can terminate or blindside the Default-Allow-Block-On-Threat approach subsumed in the EDR.
2. Run Time Protection: When a new thread or child process is created, the security control should keep asking whether this code came from an attacker or the application. A security control that can identify the origin of the code can then block threats in a very deterministic manner.

Conclusion: Virsec’s VSP leverages a Host Memory Monitor engine for load time protection and the Application Control Engine for runtime protection.

Summary

The Virsec Security Platform (VSP) leverages a Host Memory Monitor engine for load time protection and the Application Control Engine for runtime protection. By deploying VSP, a positive security control workloads, organizations can achieve cyber hygiene that is impossible with EDR technology. Learn more about Virsec's Positive Security Model in this blog.

To learn more about the Virsec Security Platform (VSP), please visit us at www.virsec.com

Don't miss our security insights, and subscribe to our blog now.