Microsoft Office Exploits · Windows Exploits

New Microsoft Office Word 2007-2013 exploit (CVE-2015-1641) Analysis

[I have attached the sample files and supporting tools for the analysis. You can find the links at the bottom of this post]

This blog post is a detailed analysis and reconstruction of a document exploit that has been around for about a year now. The document file goes by the name “ammendment.doc” (MD5: ae6b65ca7cbd4ca0ba86c6278c834547). It exploits a Microsoft Office Memory Corruption Vulnerability (CVE-2015-1641, MS15-033) with one of its embedded objects in the document.

When you open the document with a text editor, you will see that it is an RTF file despite what the file extension says it is. If you previously studied the Rich Text Format Specification document, you can easily identify the control words and data in the document. However, I think it’s best if you scan it with RTFScan.exe than read the whole document yourself.

it is an rtf file

RTFScan tells us that there are four objects in this document and dumps the objects as separate files.

rtfscan result

As you can see, Object #1 does not have any embedded object but it has a reference to “otkloadr.WRAssembly.1” (ProgID). This object loads a non-ASLR module MSVCR71.dll for bypassing ASLR.


Object #2, with a ProgID of “Word.Document.12”, contains an embedded OLE document. In order to understand what this document is all about, you’ll need to open it with a program that understands the Compound File Binary File Format Specification. I use Structured Storage eXplorer.


The stream named “package” inside the “Root” storage contains a zip file, as you can see the header. Export the data to “” and then extract it. By now it’s very obvious that the zip file is actually a DOCX (Word 2007 file). So, you can rename it to “OLE1ExtractedDocument.docx”. Repeat this step for OLE2 and OLE3.

Let’s start with the second DOCX file. Attach Microsoft Office Word 2007 or 2010 with your favorite debugger and open “OLE2ExtractedDocument.docx”.


From the above crash we can tell that some code in the “WWLib” module of Microsoft Office is vulnerable (see EIP value). This is the document that actually triggers the vulnerability. You can disassemble the module and find out the code that causes this memory corruption by yourself. It is beyond the scope of this post.

64BF9F76   8B31             MOV ESI,DWORD PTR DS:[ECX]

An access violation occured when it’s trying to read from a memory location pointed by ECX (0x7C38BD50). If you try to search that address, you’ll know that it doesn’t exist. You’re probably saying “Ok, this is getting interesting, what’s next?”. Let’s put Object #1 along with Object #3 (the document that caused the crash) inside an RTF file as it’s in the original exploit document.


Attach word to a debugger and open this file.


This time it didn’t crash because it couldn’t read data located at an address pointed by ECX (0x7C38BD50). It crashed when it’s trying to execute instruction at address 0x08080808. This is usually an address in the heap memory area, which doesn’t exist in this case.

When you extract the contents of OLE1ExtractedDocument.docx, you’ll notice that the file contains an ActiveX object { word/activeX/activeX1.bin}. The activeX file is an OLE document file containing the followings repeatedly (16 times, after every 0x1ff00), with a carefully chosen size for spraying the heap so that the execution will reach the shellcode:

  • RET-sled with 0x7C342404 {RET from MSVCR71.dll}
  • ROP chain { again from MSVCR71.dll}
  • NOP sled
  • First stage shellcode


You can disassemble the first stage shellcode (with immunity debugger or online) and learn that it looks for a second stage shellcode in memory preceded by markers 0xFEFEFEFE, 0xFEFEFEFE and 0xFFFFFFFF (you can search for these markers in the document), copies it to a previously allocated executable buffer and then jumps to it.


At this point, you can replace the shellcode with your own, repack (zip) the file, replace the original data of OLE1’s DOCX with Structured Storage eXplorer, copy it’s content to a text editor in ASCII and you’ll have your own reconstructed CVE-2015-1641 exploit.

The disassembly of the first 46 (0x2E) bytes shows that the second stage shellcode decrypts itself by XORing each of the next 0x3CC bytes with 0xFC


After decrypting itself, it searches for an encrypted payload (an exe file) preceded by a marker 0xBABABABA in memory and then decodes it by XORing every DWORD with 0xCAFEBABE. Then it will drop it to …\AppData\Local\svchost.exe. Right after doing that, it will search for a an encrypted decoy document file embedded in the document preceded by a marker 0xBBBBBBBB in memory and then decodes it by XORing every DWORD with 0xBAADF00D. Then it will replace the original file with it so that it will avoid suspection when the victim opens the file for the second time (after successful exploitation).

If you can’t find an easy way to XOR DWORD size data with tools at your disposal (like I did), you can use the following simple python script I wrote for this purpose.




  • Exploit samples from here (password: degsew)
  • Structured Storage eXplorer from here
  • OfficeMalScanner from here


You are very welcomed to comment below 🙂

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s