I am playing with some malicious MS Word documents which exploit a vulnerability in Word 2k3/2k7 to launch the shellcode. I am able to run it dynamically and get the drop-bys. However, I am interested in extracting the shellcode statically. I have tried to use Malscanner and some custom scripts for OLE to identify the start of the shellcode, so far no luck. Eventually I wanna do an ancient EB FE patching for easy debugging in Word.

Does anyone have experience playing with malicious docs? Or have a better way of debugging Word?


3 Answers 3


Carving out the shellcode statically can be a little tricky in the Windows Compound Binary File Format. The first question to store is how is the shellcode stored? Is it binary or hex ascii? The second question to ask is where is it stored? Microsoft documents support many many different formats. The shellcode could be stored in an OLE structure or could be possible found using a hex editor. I'd recommend the hex editor route first. You might get lucky and find a large amount of NOPs. You can use dism-this.py to quickly view if some bytes are valid shellcode or not. Note, download the source from the repo. Disclaimer I wrote the script.

The best way I have found to find where the shellcode is stored is to backtrace through a debugger. First figure out where the shellcode is executed in memory, then figure out where the shellcode is called from, then figure out how the shellcode is loaded into memory and then figure out where that is stored in the file. It's not always the easiest task but it's kind of fun.

  • ran dism-this.py on the doc file, it outputed 1 Static Offset Count, is there any way to find out in which offset it has found the static offset? and what is the static offset?
    – Malach
    Nov 12, 2013 at 13:14
  • @Malach The static offset is for testing if data is valid assembly. It's likely not if it's a singe value. The assembly prediction can be a little tricky. I'd recommend using the disassembler feature and reading the instructions manually.
    – alexanderh
    Nov 13, 2013 at 17:44

This might not be the best way to do this. But as Malicious files don't use the format the way it was indented (as-in they exploit a field) I never use interpret programs for this kind of work.

I would suggest, looking up the format and loading it in 010 Editor (or any other hexeditor). This one supports templates that you can use to determine what they overflowed/exploited.

  • 010 Editor does not seem to have template for *.doc
    – Malach
    Nov 7, 2013 at 7:01
  • You can make a template for *.doc In order to debug a MS Word file you need to hook to MS Word :) so you can try that if a hexeditor is to much of an effort.
    – Stolas
    Nov 7, 2013 at 7:17

Given that you can get the exploit code to run dynamically, I'd recommend using an API logger (like http://www.rohitab.com/apimonitor) on the Word process to see what API calls are made by the shellcode. You can then restart Word with a debugger attached, set breakpoints on those API calls that you saw made by the shellcode, and wait until those breakpoints are hit via the shellcode. You'll now have the process suspended in the middle of the shellcode execution and can "look backwards" to find the beginning of the shellcode.

Note that this approach is useful even when the malicious document uses ROP instead of actual shellcode, in which case your debugger would break in the middle of the ROP chain instead of in the middle of the shellcode itself. Either way it would help you find the malicious content in the target file.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.