Analyzing Malicious Password Protected Office Documents

Usr6 · August 8, 2017

ewc_libreofficepw.jpg?w=414&h=181&crop=1

June 29, 2017 ~ R3MRUM

Over the past year-or-so, there seems to have been an uptick of miscreants password protecting the malicious office documents that they send to their target victims. They do this in an effort to bypass detection and thwart analysis. This blog details a few different tools and methodologies that can be used to analyze such files.

Delivery & File Type

These malicious documents typically end up making their way to the end point via email. The email message typically consists of some ruse to entice the user to open the document and, conveniently, includes the password needed to decrypt it (Figure 1).

Figure 1: Example email with password protected MS Office document attached and password in message body.

The ‘m’ at the end of the ‘.dotm’ file extension, shown in Figure 1, tells you that the file attached is macro-enabled. In this instance, it is an MS Office Document Template file but it could have just as easily been a ‘.docm’ file, ‘.xlsm’ file, or any other macro-enabled file type supported by MS Office 2007 or newer. Feel free to read more about these file types on Microsoft’s website.

Figure 2 shows the prompt that you are presented with when you open a password protected Office document:

Figure 2: Password prompt received when opening a password protected office document.

Failed Analysis Method #1: Copy Macros

When I first encountered this type of malicious document, my first instinct was to launch the document in an isolated sandbox, enter in the password provided to me in the message body, and then copy the embedded VBA macro code from the document into notepad where I can then perform my analysis.

This technically could have worked if the miscreant did not also password protect the Visual Basic Project containing the malicious VBA code with a separate unknown password (Figure 3).

Figure 3: Password prompt received when attempting to gain access to macro code.

Failed Analysis Method #2: Re-Save Without Password

My second thought was: “After I open the document and enter in the initial password, I’ll just re-save the document without a password. Then I’ll be able to use my analysis tools to inspect the file’s contents.”

Unfortunately, this doesn’t work either due to the fact that the VB Project within the encrypted document is also password protected. If you attempt this method, the contents of the document (images, text, etc…) will still be present within the unencrypted copy of the document but any embedded macros will be stripped.

Successful Analysis Method #1: Decrypt with MSOffice-Crypt & Analyze w/ olevba|ViperMonkey

Let me introduce you to a nifty little tool called msoffice-crypt. This bad mama jama enables you to dump a decrypted version of the encrypted office document out to a file. As a bonus, it works in both Windows and Linux!

Figure 4: msoffice-crypt options & decrypting of encrypted Office document

In Figure 4, I ran msoffice-crypt.exe without any arguments so that you can see the different supported options. Then, in the highlighted section, I ran the following command, which decrypted smith.dotm using the password “6429”:

msoffice-crypt.exe -d -p 6429 smith.dotm

If you did not provide an output file name, msoffice-crypt will default to appending an “_d” to the file name, like so: smith_d.dotm.

Figure 5: Decrypted document created within the current working directory

Sure enough, we see in Figure 5 that the decrypted Office document has been created. Now, if we launch this newly created document (in an isolated environment, of course!), you should no longer received the password prompt.

Figure 6: Office document decrypted. Password no longer needed to open.

Voilà! No password prompt received! (Figure 6)

If you didn’t know, MS Office 2007+ documents are OpenXML format which means they are actually just compressed archives that you can decompress using you’re favorite archive extractor (WinZip, 7z, etc..).

We can also spot the difference between the encrypted and decrypted documents by comparing the decompressed contents of both.

Figure 7: Contents of decompressed encrypted Office document

Figure 7 shows the contents of my encrypted Office document whereas Figure 8 shows the contents of my decrypted Office document.

Figure 8: Contents of decompressed decrypted Office document

The contents depicted in both Figures 7 and 8 are typical and should match what you are seeing in whatever OpenXML formatted Office document you are analyzing; not just this sample.

This actually segues nicely into the next step, which is to extract out the VBA Macro code. If you recall, the malware author also password protected the VB Project containing the macro code. While I am not aware of any tool that will strip this protection from the document, it doesn’t matter as existing tools such as oletools, ViperMonkey, etc.. completely bypass it.

Back in the day (like 3 months ago), I would have extracted out the VBA code by decompressing the OpenXML archive, locating the OLE binary within the “word” folder (i.e vbaProject.bin), and then using something like OfficeMalScanner (Figures 9 & 10):

Figure 9: Running OfficeMalScanner against OLE binary found within OpenXML archive EWC_OfficeMalScannerVBA

Figure 10: VBA code extracted from OLE binary using OfficeMalScanner

… or olevba from the oletools suite (Figure 11):

Figure 11: VBA code extracted from OLE binary using olevba

But this is old-school. These days, all the kids are using ViperMonkey. ViperMonkey not only extracts the VBA for you but also emulates execution so that if the VBA is heavily obfuscation (in this case, it is not), you can quickly and safely derive what the code is actually doing. Also, it can handle OpenXML files so there is no need to extract the archive and locate the OLE binary.

Figure 12: Analysis of the decrypted Office document using ViperMoney

Figure 12 shows how ViperMoney not only extracts and displays the embedded VBA macro but it also gives you the execution flow of the malicious code in a quick and easy-to-ingest format. This dramatically reduces analysis time which, in turn, expedites time-to-respond.

If I ever meet Philippe Lagadec (@decalage2), I’m going to buy that man a beer!

Successful Analysis Method #2: Simply Open w/ LibreOffice

Your probably going to hate me for making you step through the entire blog before mentioning – what turns out to be – the most simplest (and laziest) solution for accessing the embedded VBA code within a password protected document/project.

Since REMNux doesn’t come packaged with LibreOffice, you’ll need to install it by simply running:

sudo apt-get install libreoffice

Once installed, open the encrypted Office document in LibreOffice by running:

libreoffice smith.dotm

Like when you opened the encrypted Office document within MS Office (Figure 2), you will be requested to enter in the document’s password (Figure 13).

Figure 13: LibreOffice password prompt

When you enter in the password, the document will successfully load. Now, you will be able to access the embedded VBA macro code by navigating to:

Tools –> Macros –> Organize Macros –> LibreOffice Basic

You will be presented with a pop-up window (Figure 14) where you will need to find the project containing the VBA code and hit the Edit button.

Figure 14: LibreOffice’s Macro Editor Dialogue

And BOOM! LibreOffice’s Basic Editor opens; giving you direct access to the VBA macro code without needing to also know the VB Project’s password (Figure 15):

Figure 15: LibreOffice’s Basic Editor providing access to embedded VBA code. Bypassing password.

That’s it! It’s that simple!

My personal preference is the first method as I’m a command-line junkie. But, if you are more comfortable with performing your analysis via a GUI, then the LibreOffice method might be a better fit for you!

Regardless, knowing multiple methods for solving single problem will only make you a better analyst.