I figured I'd better put this up before I keep having more ideas of how to improve it and never end up posting it.
What is it? Just over a month ago, a buddy (who's recently begun working for a BIG company that just happens to do some pentesting) was telling me about a pentest where they weren't allowed to upload software so he had to write something in a batch file. While we were chatting, I began telling him of the different ways I've seen attackers put files on Windows systems: tftp, ftp (with & without scripts), wget-like VBscript and echo.
While echo was integral in most of the above techniques (ftp script & VBscript), I'd seen a handful of hacks back in 2005 where an attacker used echo and pasted hex into a file. When the file was complete, he ran "debug < 123.hex". Renamed the resulting file to end with ".exe" and his tool was complete.
After digging through some really old incidents I'd investigated, I found some real world examples of the technique used during compromises. A little bit of Google-ing revealed these two links to a
forum post describing the technique in 2004 and mention in a
Phrack article.
After sitting in on part of Ed Skoudis' new Security 560 Penetration Testing class, I saw that his class didn't mention this technique but it covered just about all the others above. Since I would one day like to be efficient at writing ruby, I wrote
exe2hex.rb based on the C code from
Riftor.
Currently, due to a limitation in Microsoft's debug.exe, files must be smaller than 65,280 bytes. My next version will automatically split up files to be under the correct size and convert each one to hex. Once echo'd and converted on the target host, the individual files can be joined with "copy file1+file2+file3 /b dest /b" (or at least it should work that way...need to do more testing).
Where does this tool come in handy...I have some ideas but they'll have to wait. I need to pack things up here in the lab and head home.
How does Encase know? I thought it was based on the following dialog and I'd be able to change this within Encase by right-clicking on an entry but modifying the entries like those in the following image did nothing.
It turns out that Guidance Software has made an addition to the E01 file so that there is a new media type identifier, 0x10. Taking at look at a memory image created by winen, ewfinfo from the libefw project shows the Media Type as RAM.
