Microsoft Office RTF Exploit : CVE 2015-1641 Dissecting the Shellcode

Few days back , I came across interesting RTF exploit floating around, eventually concluded as CVE -2015-1641 vulnerability. I was particularly interested in knowing about the DEP / ASLR bypass mechanisms and shellcode used in this exploit . I decided to dig little deeper into this exploit to figure out how it overcomes the windows mitigation mechanisms.

First step for me to start with analysing any MS Office exploit is to run it through my own developed static analysis framework for Office exploits , which can precisely extract the embedded streams, locate the shellcode and can do bunch of other analysis stuff. Notice that 4 embedded binary objects has been extracted out of the RTF exploit.





Looking at the log file , we'll observe few stuff which is worth further investigation.
















It has also extracted 2 Open Office XML document embedded within the RTF exploit. Static analysis framework further has the ability to re-analyse extracted OOXML files. If we take a look at the anlaysis.log file for the extracted_ooxml_1, it has detected a shellcode in the embedded object activeX1.bin












and similar for the extracted_ooxml_2










Below graphical representation of the shellcode apparently indicates the API address resolving code , parisng the export table as you'd normally see in most of the exploits.
















Lets take a look at the interesting embedded binary objects.

ASLR Bypass - object_00000020.bin






otkloadr.WRAssembly.1 is the ProgID that loads otkloadr.dll. This DLL is linked to another MS Office component MSVCR71.dll , that will get loaded once the exploit is executed and the one which is used to bypass ASLR. MSVCR71.dll is shipped along with the MS Office and it is not compiled with /DYNAMICBASE which makes possible to hardcode the addresses for ROP chain.











object_000000E6.bin

This object contains the embedded OpenOffice XML document which includes activex1.bin that is used to perform the heap spray before the vulnerability is triggered. This technique is similar to the one used in CVE-2013-3906.








Following structure of the activex1.bin used for Heap Spray clearly reveals the shellcode. This structure of RET sledge + ROP chain + NOP + Shellcode is repeated every 0x20000 bytes

















object_000187A1.bin is responsible for triggering the vulnerability. I wont't be digging much into the vunerability details since it has already been covered in greater depth in the blog over here

object_0002802c.bin also has OOXML document embedded and activex1.bin inside it leads to believe that EIP will be overwritten with 0x08080808 after the vulnerability is exploited. It is yet unidentified at what point this happens but the structure of the binary object is apparent. This can be confirmed by launching the exploit in the debugger as exposed in the next section.


















One of the fact to note about this exploit is that it crashes several times when the execution is transferred to the heap at address 0x08080808, where the shellcode doesn't exist. Once we launch the exploit in the debugger , we can check out the non-aslr module MSVCR71.dll loaded by otkloadr.dll







After the exploit is launched , it performs the heap spray and subsequently,vulnerability is triggered to redirect the execution control to the heap , overwriting EIP with 0x08080808.

Shellcode Analysis - 1st Stage

1. Beginning of the 1st stage shellcode, as we would usually see in most of the exploits, parses the Process Environment Block ( PEB ) and deternines the base address of kernel32.dll. It then parses the export table of kernel32.dll to resolve the address of VirtualAlloc( ) API.












2 . Calls VirtualAlloc ( ) to allocate the buffer and copies the hashes of the APIs to be resolved further, and then again returns to the export table parsing routine to resolve address of GetFileSize ( ) , CreateFileMapping ( ) and MapViewofFile ( )











3 . Next, the shellcode tries to locate itself in the memory by incrementally passing the file handles to the GetFileSize in the looped code. If the file size is greater than 40KB and less than 2MB, it calls CreateFileMapping and MapViewofFile ( ) to map the file into the address space of the calling process and matches the first 4 bytes of the file to check the RTF header.










4 . Subsequently, it adds the offset 0x10000h to the beginning of the file and searches for the 2nd stage shellcode marker 0xFEFEFEFE and 0xFFFFFFFF and eventually jumps to execute it.










Shellcode Analysis - 2nd Stage

1 . At an offset 0x2E from the start of the 2nd stage shellcode , it XORes 0x3CC bytes of the shellcode with the single byte XOR key 0xFC.











2 . Calls NtQueryVirtualMemory( ) API to retrieve the original name of the exploit document , converts the filename to ASCII using WideChartoMultibyte ( ) and then calls GetLogicalDriveStringsA ( ) to append the current logical drive to the document name



3 . Searches for the marker 0xBABABABA, subsequently decodes the XORed encoded executable with 4 byte XOR key 0xCAFEBABE , calls GetTempPathA ( ) and writes the decoded executable to the %temp% directory with the name svchost.exe















4. Next part of the shellcode searches for the marker 0xBCBCBCBC , XOR decodes the decoy document with the 4 byte XOR key 0xBAADF00D and then calls previously resolved API UnmapViewOfFile ( ) to unmap the original exploit file from the process's address space,writes the decoy file to the original exploit document and eventually executes it using WinExec ( )
















5. Invokes cmd.exe to delete the registry key "HKCU\Software\Microsoft\Office\12.0\Word\Resiliency" with /F switch to force delete and suppress the error messages from Winword.exe














Decoy document :









At the time of writing this analysis, dropped executable connected to the C&C server login.loginto.me resolving to 58.158.177.102. Based on the passive DNS records this domain also resolved to 23.249.225.140