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

Tuesday, December 30, 2008

Jing - OS X Screen Capture & Metasploit Route

I was trying out jing over the weekend and I like it. Its free screen capture software for your Macintosh. It allows you to capture a movie from your desktop and give it a voice over. Then you can save the contents as an adobe flash movie. It integrates with www.screencast.com and allows you to upload and share files with the world. All for free as long as you stay beneath 2 GB per month. One draw back is it doesn't come with editing software. So unless you use a separate tool you need to get it right in one take. Check it out here.. http://www.jingproject.com

To try it out I made a video (one take) of using Metasploit's route statement to accomplish a true pivot. Route is a command that can be run from within the Metasploit console. It routes attacks through an existing meterpreter session. The route statement is not altering the routing tables on the attacking host. This is also different that the route statement which alters the client host when your are in the Meterpreter session. This route statement alters the routing tables used by Metasploit (see lib/rex/socket/switch_board.rb). Not all Metasploit tools will honor the routes. It seems that those that are built on "Session" objects which uses the "Comm" object honor the routes. Some components (such as auxiliary modules) do not inherit the comm and/or switchboard objects and thus do not honor the routes.

Check the video out here.

Monday, December 1, 2008

msfencoding tips and SANS CDI presentation

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.