Recently, I posted a blog about analyzing PDF files. In that post, we covered some basics of the PDF format and then examined an infected PDF to observe the malware infection.
In this post, we’re going to do something similar, except this time using Microsoft Office.Just like the PDF, most of you reading this are already familiar with Microsoft Office. If you've ever had to type a school paper, for example, you've likely used Microsoft Word sometime in your life. Perhaps you took a class on database design, so you may have use Microsoft Access to create and test custom database applications.
In Microsoft Office files, versions 97-03 uses a custom binary file format that is read by the associated Office program.
The technical specification for each format can be quite lengthy; for example, the Word specification (.doc) is over 600 pages long, while Excel (.xls) is at nearly 1200. Changes to these formats came in 2007, however, when Office 2007 debuted with a newer Office Open XML format. The Office Open XML format uses compression with PKZIP and offers an array of enhancements, one being increased security through macro elimination.
However, while you can make the Office file format more secure, Office programs that read these files need to be equally secure in order to be completely safe. The problem, of course, is that they’re not, and that’s why you have instance where older files can still target newer versions of Office.
Let’s get our hands dirty with Office malware by examining an Excel file that demonstrates CVE-2012-0158, aka MSCOMCTL.OCX Remote Code Execution (RCE) vulnerability. The file MSCOMCTL.OCX is the ActiveX common controls DLL for Windows. In this example, the “ListView” and “ListView2” ActiveX controls implemented in the DLL are vulnerable to the exploit, which leads to a malware infection.
For reference purposes, the md5 hash is 0ca16af39749f996df1c499dcda8c269. For our analysis environment, we will be using Office 2007, although other versions of Office are still vulnerable if unpatched, as well as many other applications (refer to CVE description for full list of applications affected).
When analyzing a new file (no matter the presumed type) it’s always wise to use a hex editor to observe the headers.
Now we’re going to need some tools. Arguably the best tool for analyzing malicious Office documents is OfficeMalScanner, written by Frank Boldewin. OfficeMalScanner is an “Office forensic tool to scan for malicious traces, like shellcode heuristics, PE-files or embedded OLE streams”.
OfficeMalScanner is a suite of applications and is very good at giving analysts a “lead” on where malicious activity (mostly shellcode) is occurring in the Office document. Let’s observe all the tools OfficeMalScanner gives the user.
OfficeMalScanner.exe is the main binary used to scan office documents for malicious behavior. The program is capable of scanning for shellcode, embedded PE files, OLE streams, and can also disassemble shellcode as well as brute force encrypted bytes (using ADD, XOR, and ROL).CVE-2010-3333, aka RTF Stack Buffer Overflow Vulnerability).
Now that we’ve explained our tools, we can scan the infected Excel file using OfficeMalScanner. If you refer to the picture above, you will notice there are three options—scan, info, and inflate—along with the switches, brute and debug.
Let’s first try the info option, to look for OLE objects and macro code.
OfficeMalScanner.exe [filename] info
OfficeMalScanner.exe [filename] scan brute debugOfficeMalScanner detected shellcode embedded within the Excel file starting at offset 0x1DE0B. However, some of these instructions don’t seem right, particularly the last instruction: mov [esp+ecx*8-288569B3h], gs. A few instructions prior, though, it can be seen that some bit manipulation is occurring, namely XOR (exclusive or) and ROR (rotate right). This could very well indicate the embedded shellcode performs on-the-fly de-obfuscation as it executes.
One option seems like an obvious solution to our problem: the MalHost-Setup tool. However, when using MalHost-Setup, you’ll eventually get an unhandled exception during execution. This is because the shellcode expects to be running in the context of EXCEL.EXE, and therefore some of the memory offsets don’t match when running under a separate parent process. While tools are always great, none of them are perfect.
The best way to handle this is to patch a few shellcode bytes. Commonly referred to the “EB FE trick”, this technique will patch two bytes with an infinite loop, allowing us to easily attach a debugger.
In x86 assembly language, the “0xEB” byte indicates a non-conditional jump instruction (JMP), while the second byte, “0xFE” indicates where to jump, which is the next instruction to execute, or EIP register. Refer to the picture below for help understanding this concept (this is a hard one, folks).
Thus an infinite loop is created. Now we need to patch the bytes in our shellcode.
When observing EXCEL.EXE in Process Explorer (or just the regular Task Manager), it can be seen that the infinite loop is causing a lot of CPU usage.
Let’s give our CPU a break and attach to EXCEL.EXE with OllyDbg. Once you attach, resume execution, and then pause again to land at our infinite jump.
While Excel is paused, let’s restore the original bytes (Ctrl + E). Now we can step through the shellcode and see what’s going on.
After stepping through a few instructions, it’s easy to see that more code is de-obfuscated on the fly. Each obfuscated byte is placed in the AL register with a ROR 0x5 and XOR 0x3F applied; afterward, the revealed code is executed.
The current user’s temp directory is retrieved (%temp%) and a new file called “set.xls” is created there. Next an embedded Excel file is revealed, obfuscated with a ROL 0x6 and XOR 0x37 applied to each byte.
This is a common technique seen in Office malware. The reason this occurs is the exploit typically crashes the host application (EXCEL.EXE in this case) and a new Excel process is created to make it appear the document opened correctly. In this case, that’s exactly what happens, as the file “set.xls” is opened using WinExec. The new file is filled with paragraphs of text to appear legitimate.
Finally, it appears we’ve made it to the good stuff, an embedded PE file.
This file will be named “ews.exe” and is also dropped in the current user’s temp directory. Looks like it’s a UPX-packed binary; if we want to analyze from here, we can use the UPX utility with the “-d” command to unpack.
Software exploits are very popular and are responsible for a large majority of malware infections. While it’s most important that you have anti-malware protection to prevent execution of malicious code should an exploit succeed, you might want to consider another layer of defense.
Malwarebytes Anti-Exploit works to stop an exploit before it even starts. The advantage here is that the malware doesn’t get installed and therefore never has a chance to execute.
The program is still in beta, but it currently blocks a wide range of exploits found in the wild, including CVE-2012-0158 (and also CVE-2010-0188, featured in my previous blog post). Should you attempt to open this Excel document with Anti-Exploit installed, the following dialog would appear:
You can download Malwarebytes Anti-Exploit for free here.
Stay tuned for more information from the archives.
Joshua Cannell is a Malware Intelligence Analyst at Malwarebytes where he performs research and in-depth analysis on current malware threats. He has over 5 years of experience working with US defense intelligence agencies where he analyzed malware and developed defense strategies through reverse engineering techniques. His articles on the Unpacked blog feature the latest news in malware as well as full-length technical analysis. Follow him on Twitter @joshcannell