When malware headlines periodicals, we are asked about the potential outcome should an endpoint with AppGuard face that malware. Let’s look at a simple example regarding recent reports of ransomware called Mallox. The first 3rd party report we saw had all of the attack tree information we needed to make an affirmative call that AppGuard would readily stop such an attack with default policies. This blog will introduce readers to the concepts of how AppGuard makes these assessments without diving into the technical details. Readers will better understand the difference between malware detection-based defenses versus those that AppGuard stops by blocking malware technique activities with controls, without having to detect and recognize the malware itself.

Why Most Malware Analyses Lack Vital Information

The world is dominated by detection-based endpoint protection tools. They only succeed if and when they recognize something about the malware attacking the host. Some kind of pattern-matching must succeed. Antivirus is known for signatures (aka, hash checksums). There are many other ephemeral (ie, ever-changing) patterns from files, communications, behavior, and more. These change almost literally with each attack variant. Hence, detection tools are said to be faced with the challenge of parsing infinite possibilities between bad and good.

Controls-based tools neither detect nor pattern-match. All are blocking malware technique activities, whether the vendors realize this or not. Malware getting into an endpoint does not accomplish malware’s goals; to do that, malware must successfully complete a series of actions. Controls-based endpoint protection tools (eg, AppGuard) strive to block such actions.

AppGuard applies zero trust principles WITHIN endpoints. That means that AppGuard assumes something bad inevitably gets into the endpoint. AppGuard’s answer is to not let that malware do what it needs to do. Stopping one action is usually enough to defeat an entire malware attack. This doesn’t require recognizing a file, an IP address, or a behavior pattern, the ephemeral things detection tools seek.

Malware analyses written by malware detection vendors devote much content to identifying what file was written to disk, what registry key was added, or what domain/IP was addressed, instead of what application (ie, process) performed those actions. 

The ‘Need to Know’ for Stopping Malware: Actor, Target, Action (ATA)

Every malware attack consists of an attack tree that consists of one or more malware techniques, which consist of one or more actions by an actor (eg, an application process) upon a target. 

For example, consider a zero-day exploit attack involving Google Chrome where Chrome consumes something ‘bad’. Malicious instructions are then executed by Chrome, the actor, causing Chrome to maybe write (action) a file to the “Downloads” folder, and then launch this executable file (another action). There are actually two ATAs here: 1) Chrome (actor) writes (action) an executable file to disk (target); 2) Chrome (actor) launches (action) the file (target) in the Downloads folder. This is one branch spawning another branch of the attack tree.

Let’s say Chrome also wrote a script file to another location and yet another file (eg, a DLL) to yet another location. As all of these are intended to execute malicious activities, each would be depicted as a branch stemming from Chrome. Depending on what they do, each of these can stem other branches that can stem yet others. Ultimately, the attack consists of a tree with many branches. Each branch consists of an actor, target, and action (ATA).

Looking at ATAs to Project a Controls-based Protection Outcome

Before looking at Mallox, let's finish looking at this Chrome example from an AppGuard controls perspective. AppGuard would allow Chrome to write the first file to the “Downloads” folder because Chrome is useless if users cannot write files to user folders. This branch spawns another branch where Chrome triggers the launching of this executable file located in the “Downloads” folder. AppGuard would not allow this launch because it prohibits launches of anything not digitally signed by a trusted publisher from high-risk folders such as “Downloads”. This part of the attack is stopped by AppGuard.

Next, the 2nd file is a script file, such as PowerShell, located in another high-risk user folder such as Desktop. AppGuard would not allow PowerShell to load this script file because of its location in a high-risk folder. This part of the attack is stopped by AppGuard.

Finally, the 3rd file is a dynamic link library that Chrome was instructed to write in the same folder as the Chrome application itself. AppGuard would not allow Chrome to write this file to that location because AppGuard “contains” high-risk applications such as Chrome, restricting where and what Chrome can read and write. This part of the attack is stopped by AppGuard. And as this was the last of the branches, this entire attack has been stopped. And, AppGuard stopped it all without having to recognize the malware attack itself.

Mallow Ransomware Attack Tree Created by “Unit 42”

Let’s apply AppGuard controls to each branch or stage of this attack tree.

Thus far we have looked at two scenarios. The first was where the attack was stopped because cmd.exe is prohibited on servers that do not need it running. The second scenario was where cmd.exe is allowed to run but run while “contained” by AppGuard.

The analysis doesn’t stop yet because then we start looking at ‘what if’ questions. For example, if WMIC.exe were not prohibited, then AppGuard would not allow the resulting tzt.exe to launch from where it was located. Even so, we see further use of cmd.exe to the right where different OS utilities are used to do harm. Other AppGuard attack surface reduction policies prohibit many OS utilities from running to snuff-out attacks like this. There’s mention of cmd.exe writing a script file (.bat) into a Windows folder. AppGuard containment would stop that. There’s also mention of a registry key modification to defeat Raccine anti-ransomware. AppGuard would not allow cmd.exe or any other “contained” process to do so.

With all the ‘what if’ scenarios we have already investigated, we haven’t yet explored them all. We left out AppGuard’s “isolation” controls. Let’s go back to that registry key modification for a moment. An AppGuard “isolation” rule can stop that modification by any actor process. AppGuard “containment” protects the host from “high risk” applications. AppGuard “isolation” protects parts of the host from the rest of the host to mitigate risks from unknown or unanticipated actors, even those not “contained” by AppGuard. 

Conclusion

AppGuard can defeat the Mallox ransomware in not just one but many different ways. None of these require recognizing something that can change from attack to attack. Instead, AppGuard is applying zero trust principles within endpoints in the form of controls-based endpoint protection software to stop attacks without having to recognize the malware itself. 

AppGuard employs three fundamental controls: “launch”, “contain”, and “isolate”. “Launch” prohibits launches of potentially dangerous things from high-risk places as well as prohibits launches of dangerous but unnecessary OS utilities (ie, attack surface reduction). “Contain” protects the host from its high-risk applications. “Isolate” protects parts of the host from the rest of the host, specifically the unknown or unanticipated malicious process. The combination of these fundamental controls enable AppGuard to defeat malware attacks that AV, EDR, XDR, and other detection-based defenses fail to detect or detect too late. 

AppGuard is an essential layer of protection that not only protects the enterprise from what is not detected but also reduces the operational costs of detection-based protection by eliminating attacks before alerts or incidents occur.