UPDATE 1-21-2009: HD Moore delivered this patched on Christmas Eve. I don't want to start any rumors, but has anyone ever seen HD Moore and Santa Claus in the room at the same time? Google certainly seems to indicate some type of relationship..Hmm
Original Post:
On Dec 15th I am giving a presentation at SANS CDI on my whitepaper on the Effectiveness of Antivirus detecting Metasploit payloads. Metasploit changes CONSTANTLY and I want to be sure my presentation is up to date. So I've been spending some time updating my reasearch. Here is what I learned.First, when I wrote my paper, msfencode wouldn't produce an EXE. In my paper I described three techniques for creating an EXE. Since then, metasploit added the ability to create an EXE, but it still has a few kinks. First, msfencode doesn't actually encode the payload. Today it just changes the base address and adds a 0x0A to the end of the payload. I've reported the bug to the development team today. Given that the guys on that team seem to exhale highly functional code I suspect it will be fixed long before anyone reads my blog. I suggest you wait for their fix, but here is what I found.
msfencode has this line where it sets the encoded payload to the variable "RAW"..
# Encode it up
raw = enc.encode(buf, badchars)
Then when it creates its payload it does this call...
exe = Rex::Text.to_win32pe(buf, "")
But "BUF" is the unencrypted payload. Yep. It does nothing. Every EXE you've encoded since the update on Sept 26th (when the EXE encoding option was introduced) hasn't been encoded. "But the MD5 hash changed", you say? Yep. The to_win32pe method of the TEXT object used by msfpayload and msfencode also changes the base memory load address of the binary randomly. So it changes the EXE by a couple of bytes. While waiting on the real fix from the metasploit team you can use one of the three methods describe in my paper or you can make this change...
exe = Rex::Text.to_win32pe(raw, "")
And guess what... msfencode encodes now! BUT the payloads still don't work. If you encode a payload it doesn't run. So we take a look at our new binary in OLLYDBG and see that when the new exe reaches the XOR function to decrypt the payload it generates a Memory Access Violation. I suspect this was the result of the fact that 3.2 moved the actual payload the the .rdata section of the executable. So I reverted the EXE template to the one that came with the 3.1 version. The template that is used for the payload is located in the /data/template/template.exe If you revert to the TEMPLATE.EXE from 3.1 then everything works great. You can encode your payloads (Remember msfencode requires RAW input, see my paper for details) like this...
./msfpayload windows/shell_bind_tcp R | ./msfencode -t exe -o ~/winbindencoded.exe
Hungry for more? Lets have some real fun and double encode it!
./msfpayload windows/shell_bind_tcp R | ./msfencode -e x86/countdown -t raw | ./msfencode -t exe -o ~/winbinddoubleencode.exe
This encrypts the payload once with the countdown xor engine and then wraps that in a shikata_na_gia encoding. Double encoding. Cool! BUT perhaps not very helpful in avoiding antivirus. Encoding something twice will likely just result in the avoidance of the outer encoding algorithm. Oh well.
Here are some numbers from submitting them to www.virustotal.com:
Bindshell = 3/37
Bindshell + countdown = 6/37
Bindshell + Shikata_na_gia encoding = Detected by 6/37
Bindshell + countdown encoding + Shikata_na_gia encoding = Detected by 6/37
I'll talk about this some more at my SANS CDI talk.