Welcome to In Depth Defense. In Depth Defense LLC is a privately owned Information Security Consulting company owned and operated by Mark Baggett. In Depth Defense specializes in Penetration Testing and Incident Response. At this time In Depth Defense is not accepting any new client work, but we are happy to speak to you and point you to other resources in the community.

Mark Baggett has been active in Information Security for 18+ years. I've served in a variety of roles from software developer to CISO. You can find archives of older blog entries below and read my newer posts on http://www.pauldotcom.com, http://isc.sans.edu and http://pen-testing.sans.org

Sunday, October 12, 2008

Metasploit updates to msfencode and exe template

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.