The Mechanics of Defense Evasion

Dig, if you will, the picture of you and I engaged in a stress.

Being on the receiving end of defense evasion is stressful. I get stressed. Excited, but stressed nonetheless.

Continuing our series on defense evasion (read part one), I would like to share this stress. 

In this article, we’re going to descend into the Huntress dungeon and peruse some caged cases that are all to do with defense evasion. We’ll bring some friends along for the journey and get their insight. 

Hopefully, after showing you in detail how adversarial defense evasion works and how easy it is to evade full stop, you’ll feel just as stressed out as I do.😊 😊 😊

Case One: Impairing Defenses

Threat actors, as the big cheese John Ferrell (we affectionately call him JDF) said in our previous installment, use what works til it don’t. At Huntress, we’ve seen threat actors ‘evade’ defenses by simply pressing the various built-in buttons that undermine a security solution’s visibility. Taxonomized as T1562.001 in ATT&CK, threat actors can use the legitimate functionality of security tools to impair their efficacy. 

In a recent webinar, my colleague, Matt Anderson, detailed a case where the threat actor brought over a huge malicious PowerShell script. The beginning of this PowerShell script leveraged the built-in functionality of Defender to modify what kind of paths, processes and files Defender would and wouldn’t alert on. 

It’s not that Defender is switched off here. Rather, the threat actor has kindly requested that Defender pay attention to everything but a select number of things that will benefit their campaign.

We can take a look under the hood at this manipulation of Defender, to see that it’s woefully simple and anti-climatic to reconfigure what will be seen, with a privileged PowerShell prompt:

And this isn’t a Defender-only problem. Exclusions are a necessary evil for all security solutions, and they are used by sysadmins legitimately for a multitude of reasons.

Weaponising exclusions works well for adversaries because it appears the security solution is working on the surface, but under the hood it has been neutralized from opposing the machinations of the malicious attacker. Threat actors are adept at knowing how to leverage our own tooling against us, selectively poking the eyes of the Argus that is supposed to be our panoptic sentinel. 

Case Two: Impairing Defenses by Turning Things Off

At Huntress, we collect a ton of telemetry from adversarial activities. I am sometimes in awe at the incredible techniques and speed that our enemies move with.

And then sometimes, I shake my head at the stupidity of our enemies - like in this case.

We had a case where the threat actor was attempting to manipulate and impair the Huntress agent. They partially succeeded in executing the uninstall process of our agent(s). 

What was awesome about this is that the threat actor did not use any enumeration commands to identify which security solutions were present. Instead, they gunned straight for us. It’s nice to know we strike fear in our enemies! 

I was amused and stressed at this turn in the adversaries’ campaign. Here, I’ll show you an in-situ snapshot of my stress levels:

What was stupid in this case is that the threat actor tried to blind Huntress after they had executed much of their malice; trying to uninstall our agent was one of the last things they did on the host. Like, why?! Wouldn’t you bust the CCTV camera off the wall first before you commit the crime?! 

In another case Matt Anderson worked recently, he encountered an adversary who had the sense to subvert security solutions earlier in their campaign. An especially insidious tool, Backstab, was leveraged by the threat actor to blind particular key facets of a security solution. Specifically, Backstab uses a legitimate component from the SysInternals suite of tools to kill the ‘protected’ process of the AVs and EDRs, thus gifting a threat actor a machine bereft of its automated guardians.

Backstab isn’t a particularly stealthy tool, and neither is the method of ‘killing’ the processes of EDRs and AVs….but attackers do be like that sometimes.

I asked general awesome human being and Lead Product Owner, the Ninja Sharon Martin about the above: 

Case Three: Obfuscate, Frustrate

Some threat actors are incredibly creative. They subvert and push tooling in ways that defenders could not have imagined. 

One method of defense subversion we at Huntress often encounter involves incredibly obfuscated malicious scripts—attributed as T1027. This technique denies the human observer and security solution the ability to read the intent of the scripts, and instead deploys layers of encoding, encryption and evasion to exasperate defenses.

They can get really annoying sometimes.

In this case, we had a nonsensical bit of PowerShell that a defender could only shrug their shoulders at on first look. This kind of obfuscated PowerShell is attempting to evade the defender and their security tooling to execute something malicious. 

When unraveled, we see the relatively simple task of adding a malicious user to the domain with some basic AMSI evasion (more on this in case five):

On other (annoying) occasions, the malicious file in question deploys so many layers of obfuscation that as a defender unraveling the script is working hard not working smart. In this instance below, decoding this script is actually not worth it. 

‍

Instead, we can dynamically execute the script in a sandbox—which betrayed that the script was a byte-heavy variant of ASYNCRAT, which tried to reach out to the domain new50[.]noip[.]me.

And if we were feeling REAL lazy, we could just look at the last four lines of the script. This was not obfuscated and the aspnet_compiler.exe line is a known technique of AsyncRAT to compile the malicious executable once it had reached the target machine (T1027.004).

My colleague John Hammond is somewhat of a connoisseur of obfuscated and difficult scripts. I asked John for his thoughts:

Case Four: LNK to EXE

I love offensive security. As a member of the blue team, I appreciate my red counterparts pushing and innovating new techniques that challenge our assumptions. One particular offensive security technique I enjoyed unraveling involved an executable hidden within a LNK file (T1036). 

The tweet thread goes into detail on dissection and detection, but what is fascinating about this technique is that it borders the cognitive and technical manipulation that we spoke about in the first installment. 

On initial scrutiny, this is a good old fashion shortcut—if this appeared on a user’s desktop, with the icon replaced as Chrome or Spotify, why wouldn’t a user click on that which they feel to be familiar and safe?

But under closer inspection, you and I begin to see that something is not quite right here. What we’re seeing here is @x86matthew’s brilliant technique to fly under the defensive radar, by embedding an executable in this shortcut, and masquerading it as legitimate and harmless.

Under the lens of the human eye and security solution, this kind of technique may succeed in evading.

There are other techniques wrapped up in this LNK -> EXE, such as some light XOR encryption (T1140) that encrypts and then decrypts the bytes of the EXE, to evade detection. But most interesting to me about this technique is that it enrolls the human user; it lulls them into a false sense of security by leveraging shortcuts and specific icons to trick them into executing (T1204.001).

Users are busy trying to get their good work done for the organization. Threat actors take advantage of that, knowing a security-aware user expects a threat from emails, but not from the shortcuts on their own desktop?! I spoke with Megan Broom, an account executive at Huntress, to get her take on this sneaky technique:

Case Five: AMSI Bypass

Another fascinating technique from the red team involves completely sidestepping the security foundations put in place to monitor.

Event Tracing for Windows (ETW) and Anti Malware Scanning Interface (AMSI) are staples of the modern security architecture that Windows offers (ETW is not strictly devoted to security, serving diagnostic logging purposes, too). There is a range of adversarial techniques that seek to slip by these security components and undermine their visibility. 

In this specific technique, a PowerShell prompt is conjured that is free of the shackles of AMSI and ETW, and can therefore run malicious one-liners that would otherwise be shut down and logged. 

In a Twitter thread, I dissected this technique and offered some notes on detection. But what is interesting about this defense evasion technique is that it has to bring an executable on to disk to work—so in order to run unshackled, evasive PowerShell, a threat actor must be able to run a malicious executable that itself must ALSO be evaded!

A fortunate thing about defense evasion is that—like any stage of the attacker’s campaign—there are areas for monitoring, detecting and alerting. For advanced techniques like this that are able to thwart and subvert a fundamental security apparatus (ETW and AMSI), the tradeoff is an initiating executable that you’ll catch, amongst other things you’ll catch for this technique, if you’re getting the basics right of security monitoring.

Stay tuned for our next installment where we’ll dwell a bit more on the practicals of monitoring, detecting, and defending against evasion.

Case Six: Layer Eight Attack

You know the OSI model right? When you start in IT, they teach you to troubleshoot a problem according to the various layers. From layer one to eight. You know layer eight, right?

Layer eight is the user layer, the human layer. Just like how some help desks are devoted to only ever solving layer eight problems, there are threat actors who target their attacks to layer eight—to users. These are the scams, the phishing emails, the malicious attachments that pretend to be an invoice you were expecting. All of these are gunning for the user. 

We had a case brought to our attention by a partner. The threat actor compromised a machine, planted a number of insidious persistence roots, masqueraded as accounting software QuickBooks….all to end up with a pop up:

How fascinating. The threat actor had all the time in the world to do all manner of things—compromise the domain controller, install a cryptominer (or maybe it’s a bad time to be in crypto huh), or even ransomware the network. Instead, they decided to use their malicious access to instigate a pop-up.

The partner had conducted some initial investigation, which on corroboration was fascinating to unravel. The insidious ‘quickbooks’ program was signed with a certificate, but not a legitimate QuickBooks signer but instead this clearly ridiculous @ Gmail domain. 

This method of defense evasion is completely user-oriented (T1204). Similar to the LNK / shortcut case we spoke about earlier, this false QuickBooks was all an attempt to target the user to call the attacker-controlled mobile number when ‘QuickBooks’ would fail to load.

I spoke with the investigator of this case my colleague Cat Contillo:

Case Seven: Reflective Loading

I asked Matt Anderson for his thoughts on something particularly sneaky and cool. He shared this case:

Another way to avoid detection is to weaponize known good applications to do the dirty work. This way, even if you see the process running, it doesn’t look bad because it’s normal.  

There are many different ways to accomplish this deed, and we often see reflective loading (T1620),where malware starts up a legitimate Windows binary and leverages the memory space of this executable and swapping in a malicious payload. 

In a recent case seen by Huntress, a payload was injected into CasPol.exe—a legitimate, trusted binary. This means that no alarms are usually tripped, and no attention brought on by using a trusted Microsoft binary—a sort of bait-and-switch trick used by the adversary. The extract of malware below shows how the adversary specifically names the file they want to start up (CasPol.exe).

The process tree from Sysinternals Process Monitor below visually demonstrates the impact of the malicious payload that was injected into the memory of CasPol.exe.

The malicious activity included making TCP connections, thus suggesting some kind of C2, as well as dropping files on the host, like .BAT scripts. 

Reflective loading, like process injection, takes advantage of the already existing allocated memory for a process. These kinds of tasks stay ‘in memory,’ and do not have ‘touch disk’ or leave a noisy trace on the filesystem - which makes monitoring and detecting by the blue team that bit more complex.

Security solutions are getting better at in-memory monitoring, but in the meantime, threat actors are still innovating and abusing our machine’s RAM against us. 

A Stress Indeed

Did I convey these cases well enough that you get why I'm so stressed out? 😅

I hope you enjoyed poking and prodding our captive cases of defense evasion. I hope through reading this article, you’ve found a number things resonate with the themes we identified in our first installment—that defense evasion can be deeply technical as much as it can be cognitive and social; a psychological evasion. 

But woven through the cases here, I have tried to communicate that there is hope for the blue team yet! This was a whirlwind tour, with snippets of detecting and monitoring as we went through. In our next installment, I’d like to focus on the blue team tips—how we can defend our network’s honor against those who evade our protections. 

Thanks to all the friends who came along for this article and contributed their comments, as well as our red team friends whose techniques we have discussed. Read part three of our series on defense evasion!