HD Moore and the team at Metasploits are constantly updating the framework. The programs, scripts and approaches I document In my SANS paper on the Effectiveness of Antivirus in Detecting Metasploit Payloads have changed significantly. If you haven't read my paper you may find it interesting. Its here
In the document I showed how an attacker can create standalone executable payloads of any of the available payloads in the framework. I showed how to you can use msfencode to alter the payload to avoid detection by antivirus. One difficulty at the time was that msfencode didn't make an executable. That all changed on 9-26! HDM make the some changes to both the template that is used by msfpayload and msfencode (among other things). It now much easier to avoid antivirus. Now msfencode will create an EXE! It doesn't show up in the options when you do msfencode -h but it works! So the following:
./msfpayload windows/meterpreter/bind_tcp R | ./msfencode -t exe
will encode the standalone meterpreter with the default encoder Shikata_ga_nai. It works great!! REMEMBER: msfencode wants machine language code as input (RAW output from msfpayload) If you tell msfpayload to generate an EXE then pipe that to msfencode, msfencode will encode the Win32 PE headers and you end up with binary that will not run. Give msfencode C source code and it will produce encoded C source code. But that source code won't run and better than the unecoded one. msfencode needs RAW input. msfencode will also generate RAW output, so you should be able to chain multiple payload encodes. This works great too!
# ./msfpayload windows/shell_bind_tcp R | ./msfencode -e x86/fnstenv_mov -t raw | ./msfencode -t exe > doubleencoded.exe
[*] x86/fnstenv_mov succeeded, final size 342
[*] x86/shikata_ga_nai succeeded, final size 369
UPDATE: I have been unable to reproduce this result again. Encoding binaries a second time has resulted in corruption. I'm not sure what I did wrong last night. I probably tested my single encoded binary thinking it was my double encoded.
Things have change quite a bit since february. A straight payload with no encoding is detected by 3 antivirus products, Avast, AVG and GData. But none of them detect it as a metasploit payload. Instead they detect a generic "dropper". These are NOT the same antivirus products that detected payloads back in february. Those two products (Kasperski and Webgateway) don't detect anything now. Seems we are relying on dumb luck
Unencoded payload is detected by 3 antivirus products, Avast, AVG and GData
Single encoded (shikata_ga_nia) is detected by 3 antivirus products, Avast, AVG and GData
Double encoded (fnstenv_mov + shikata_ga_nia) is detected by 1 Antivirus product, AVG
Additionally HD changed the template that is used. When msfpayload and msfencode create an executable they rather elegantly do a merge of the payload text with the binary /data/template.exe. HD change the template to make it more difficult for antivirus to detect the payloads. It now stores the payloads in the .rdata section rather than the .data section and employes some techniques to avoid detection.
Lets pretend for a minute that antivirus was able to detect the payloads BEFORE these changes. That task just got a whole lot harder for the antivirus vendors.
Pauldotcom.com did some some similar work on metasploit payloads in September of this year. Check out his stuff here.