One beautiful and sunny evening, I happened to be poking around VirusTotal – because that’s what I do with sunny evenings – and I happened to come across an interesting CV-themed document. It was an Excel document entitled “Chantay’s Resume.xlsm”. This caught my eye mostly because resume’s should almost never be in Excel format. Unless you are applying for an accountant role, perhaps – I’m not sure what those people do.

I decided to poke around at this file a bit:

Upon opening this document in Excel, I received a helpful message from the job applicant. Good thing Chantay provided instructions for his resume file, otherwise I wouldn’t be able to see his prior work experience and educational credentials somewhere embedded in this CV.

I pressed the Enable Macros button at the top, as Chantay nicely instructed, and I received this popup error message:

It looks as if Chantay’s resume attempts to download a DLL file from the Internet and then executes it . However, my malware analysis virtual machine is not connected to the Internet, so this process failed. Capturing this download request in a web proxy, such as Fiddler, proved this to be correct:

A connection attempt was made to “hxxp://205.185.125[.]104/7kWZLZ”. This URL is likely hosting Chantay’s malicious DLL.

I also captured this activity in ProcMon (ProcessMonitor). Let’s inspect this activity:

It seems that Excel is attempting to download this DLL from 205.185.125.104, write the file (WriteFile) to a directory in my C: drive, and then load the file using rundll32.exe (ProcessCreate). This is a fairly common method of downloading and executing a payload from the Internet.

How is Excel doing all this, you may ask? I have no idea. There appears to be no VBA macro code in this document, nor p-code, or any other sneaky ways of obfuscating code in Office documents. But let’s dig a bit deeper.

The objects within this Excel document, like many Office documents, can be extracted simply by using a Zip utility such as 7zip. I used 7zip to extract all the embedded objects and one item specifically stood out:

“sheet1.xml” is 481kb, which is a substantial size given that this Excel document appears to only have one page of text and not much else. Inspecting this file a bit more revealed some code, which is likely hidden in the Excel spreadsheet itself:

What we know now is that there is hidden code in this document somewhere, we are just not sure where. Olevba, my go-to tool for Microsoft Office document analysis, displays the following:

So we know that this is an OpenXML formatted document and it contains no typical VBA macros. Let’s open Excel back up and see if we can find the hidden code.

If we navigate to the “Formulas” menu in Excel, there is an option for “Name Manager”. The Name Manager holds information relating to MS Excel formulas. I suspect this document is utilizing formulas for code execution, since this is what we observed when inspecting the XML files above. Name Manger will allow us to see the values of these formulas.

The Name Manager definitely contains some interesting strings worth investigating:

We can see a file path to a DLL, several Windows API functions (CreateDirectoryA, Download File, …), and a URL. Finally, there is an Auto_Open function. This function will execute when Excel is opened on the victim machine and after macros are enabled. We can jump to this location in the Excel workbook by double-clicking this Auto_Open entry in the list.

These functions are obfuscated – Excel needs to “calculate” these values before they can be seen in cleartext. When this Excel document is opened by a victim, the formulas will be calculated and the malicious code will execute.

Luckily for us, the built-in Excel debugger can be utilized to inspect this code. We can do this by right-clicking an interesting cell, selecting “Run”, and then “Step Into”, which will allow us to step into the formula and inspect its output:

After stepping though some of the code, we can see interesting strings such as a file being downloaded and saved to the C: drive as a DLL file.

To save time, and because I’m such as nice guy, I de-obfuscated the code for you, using the methods I outlined earlier. This Excel document:

1. Loads kernel32.dll and invokes CreateDirectoryA to create a new directory under the C: drive in format C:<random>\<random>.
2. Loads URLMON.dll and invokes DownloadToFileA to download the payload DLL file from hxxp://205.185.125[.]104/kWZLZ.
3. Starts rundll32.exe to execute the downloaded DLL.

Let’s grab this DLL from the web server and look into it a bit further.

Bullocks. We are presented with a “default campaign not found” message, and the payloads appear to be no longer hosted here. Unfortunately, we won’t be able to grab this payload in this manner.

I turned instead to my friend VirusTotal. A brief search on VirusTotal shows that there are (or were, at one point) several DLL files hosted on this IP address:

In addition, there appears to be many other “resume” files that point to this same IP, including “Ying Rume.xlsm”, “Rose Carron CV.doc”, “Federico CV.xls”, among others:

Circling back to the DLL files, let’s inspect a few of these. Many of these DLL’S have interesting properties. Let’s choose one that looks interesting:

This DLL is called “Google ipdate”, a very legitimate-sounding DLL file, likely straight from Google.

Let’s take a look at the static properties of this DLL file:

A few interesting things about this sample are that it is coded in Borland Delphi, which is a bit strange for a DLL file. Also, as we already saw previously, we have the classic “Google Inc.” and “Google ipdate” meta data.

The original DLL being dropped and executed by the resume Excel document was executed with the parameter of “DllRegisterServer”. I know this because I saw this in the ProcMon output. So, to execute this DLL file in, say, x64dbg, we can run it with the command:

rundll32.exe <dll_file.dll>,DllRegisterServer

After about 1 minute of execution time, msiexec.exe is spawned.

If we attach to the new MSI process in x64dbg and dump its process memory, we can better understand what malware family this sample resides in. Strings are a good place to start with this. We are able to see here some interesting URL strings in memory:

Leveraging Fiddler (or any other web proxy), I was able to confirm that this malware sample is attempting to contact the URLs I saw in memory.

These are likely C2 addresses. After a bit of research on the format of these URLs, there appears to be one malware family that is notorious for using a URI of “post.php”. Dum dum dum… Zloader.

ZLoader is a form of Downloader malware that establishes a connection with one or multiple C2’s, and then attempts to drop additional modules, implants, and other malware. So, it seems that at least one of the DLL’s being delivered in this campaign is ZLoader. Below, we can see part of this infrastructure, mapped out in VirusTotal:

Summary

Well, there you have it. To summarize, Chantay’s nice resume utilizes hidden XLM macros in order to download and execute a DLL payload. The DLL payload, in my case, was a ZLoader variant. Very tricky, Chantay. Hope you at least got that job you were applying for.

Key takeaways: Be careful with resume files sent directly to you, and even more careful if they are in a non-standard format. Resume’s should almost always be in .doc, .docx, .rtf, or possible .pdf… But almost never in .xls/.xlsx fromat 🙂

As always, thanks for reading! If you enjoyed this post, follow me on Twitter (@d4rksystem).

Malware Samples Used

Resume document

b87f733efc95172621e267293ea60c41758ddcd9e005028df22af7e0a199cca8

DLL File

d36366666b407fe5527b96696377ee7ba9b609c8ef4561fa76af218ddd764dec