AV WARS: Fighting fire with fire [AV Bypass Technique]

Back when I started doing red team engagements for Komodo, bypassing AV solutions was quick and trivial, almost a ‘non-brainer.’ Just change some strings, recompile and you’re golden. However, over the last few years, things have changed. AV’s and other endpoint protection solutions have drastically improved and started analyzing execution in real-time instead of just verifying malware signatures. This poses new challenges. In addition, it’s not unusual to come across situations where recompiling is not so easy – whether the source code is unavailable, whether it contains commercially restricted libraries (such as with Benjamin Delphi’s Kekeo), or whether you just need to run a ‘signed’ binary (such as when using Kernel driver functions with Mimikatz).

Of course, ‘living off the land’ and executing code in memory can often be used to advance in a network without dropping any binaries. However, these methods have their own limitations. For one, blue-teamers have definitely learned that basically any PowerShell script is malicious until proven otherwise. Moreover, some things are just not really ‘suited to memory execution.’

In this post I’ll present a somewhat ‘unintuitive’ approach to dropping binaries and defeating an AV by installing another AV on your target machine.

Add security to break security

AV’s are signed software that run with Kernel access, which allows them to ‘hook’ into OS API calls when accessing the file system. But what happens when two different signed applications try to hook the same calls simultaneously? Imagine a scenario where the attacker lands on a machine, say with local admin permissions that runs some AV that he cannot bypass ‘traditionally.’ Can the attacker just install another AV to disrupt the activity of the first one? Afterall, installing an AV cannot be malicious activity… can it?

Lab set-up and initial results

Considering the vast amount of available AV’s and endpoint protection products, it would be impractical to include all of them in the test. I chose the following as a representable subset:

• Windows Defender

• AVAST

• MacAfee

• Kaspersky

Two important things to note:

1. I used the free (‘testing’) versions of the products for the test.

2. I used a ‘single instance’ configuration, i.e. the AV’s were not maintained centrally (as they typically would be in an Enterprise).

Straight from the get go it was clear that any AV installed on a machine immediately disables Windows defender. That is, of course, the expected result.

Things started getting more interesting when I installed a second AV. First, Microsoft didn’t really like it:

It was also quite clear that the AV’s also don’t really like it:

But OK, warning messages aside, what actually happens when using multiple AV’s at once?

Kaspersky reigns supreme

I’ve tried all possible combination set-ups of AV’s (from our subset of tested solutions). For each set-up, I tested what happens when dropping an EICAR test file to the system (I also dropped some Mimikatz binaries, just for the sake of it).

Across all set ups, there was not even one case in which more then one AV was able to pick-up a dropped file:

• When installing both Avast and MacAfee (without Kaspersky), the behavior was inconsistent. Some files were identified by Avast, some by MacAfee, and some were just not picked up at all.

• However, when combining Kaspersky with any other AV, Kaspersky consistently picked up the dropped files and basically disabled the other installed solutions (other AV’s remained unaware of any ‘threat’).

The AV murderer?

My initial intuition here was that Kaspersky was just ‘the first in line’ to flag the files and quarantine them, thus not giving the other AV’s a chance to work. I imagined that if Kaspersky misses the files, other AV’s would have a chance to act upon them. I put this theory to the test -> I created a folder, told Kaspersky to ignore it (essentially white-listed this location for Kaspersky), and then dropped some EICAR and Mimikatz inside, waiting to see Avast or MacAfee pick it up. But guess what? No alerts generated, no files quarantined, no threats detected.

I reran the test several times, uninstalled and reinstalled solutions in between, and did several OS restarts. The result remained the same. Installing Kaspersky simply killed the other AV’s completely, rendering them completely blind. In other words, an attacker that lands on an OS running MacAfee, Avast, or both (and probably some other solutions as well), can just install Kaspersky, white-list a folder, and drop his ‘off-the-shelf’ malware inside. At least according to the results in my lab setup, the malware will execute just fine without being picked up or flagged.

Few ‘real-world’ limitations

1. As mentioned, in an enterprise environment, AV’s are usually maintained centrally, which might skew the results.

2. Remember that we’re messing with Kernel level drivers here. While it did not happen to me, some AV’s might not fail as gracefully as they did in my lab, which might lead to blue-screens and other tragedies.

3. What if the target actually runs Kaspersky? What AV should we install to disable it?

Before considering this technique in an engagement, I would start with a test in a lab setup that matches the target environment.

Final thoughts

I believe further research should be conducted that includes more solutions and other setups. Perhaps I’ll dig into it more in the future, but for now I have convinced at least myself that this can be a valid approach for AV bypass.