Analyzing a Malicious Spreadsheet Dropping a DLL

Introduction
This week, we received a suspicious spreadsheet which was used as a malware dropper in a phishing campaign. The spreadsheet writes a DLL file to disk and subsequently executes it. In this blog post, we perform the full analysis of the suspicious spreadsheet.

Analyzing the document
The analysis of this Excel file starts with open-source tool oledump.py:

In this report, we can see 22 streams, several of these contain VBA macros (streams 12, 13, 14, 20 and 22). And one stream (4) has an O indicator: stream 4 contains an embedded object.

Streams with embedded objects also contain metadata, that can be displayed by selecting the stream (-s 4) and using option -i:

The extension of the filename and the MAGIC header identify this embedded file as a PNG file. PNG files are often used by malware authors to append a malicious payload, like a Windows executable (PE file). This is something that can be easily tested using YARA rule contains_pe_file. Option -y is used to scan each stream with the given YARA rule(s), and report matches:

There’s a match for this rule with the content of stream 4, the embedded PNG file.

This provides us with strong evidence that this spreadsheet is malicious: it contains VBA macros and a PNG file with a hidden Windows executable.

pecheck.py is an open-source tool to analyze PE files. It has an option (-l –locate) to search and select embedded PE files. Using option -l P on the embedded PNG file provides us with an overview of all embedded PE files:

2 PE files were found: a 32-bit DLL and a 64-bit DLL.

The first DLL starts at position 0x00002ebb inside the PNG file, and ends at position 0x00016eba. End position 0x00016eba is the end of the PE file without any potential overlay.

An overlay is data appended to the end of a PE file, that is not referenced in the headers/data structures of the PE file. Since PE files have no end-of-file marker, it’s not trivial to identify the presence of a potential overlay when carving PE files.

Since end position 0x00016eba is right before start position 0x00016ebb of the second DLL, it’s probable that the first DLL has no overlay (unless the second DLL is the overlay of the first DLL).

The second DLL starts at position 0x00016ebb inside the PNG file, and ends at position 0x000270ba. End position 0x000270ba is the end of the PE file without any potential overlay, but also the end of the PNG file (EOF indicator). Hence the second DLL has no overlay.

Analyzing the first PE file in detail with pecheck.py can be done using option -l 1: this carves the first PE file out of the PNG file from its start position to the end of the PNG file.

This DLL, without overlay can be found on VirusTotal: 3bd4fcbee95711392260549669df7236

Analysis of the second DLL is done the same way:

This DLL too can be found on VirusTotal: 6eede113112f85b0ae99a2210e07cdd0

To execute the code inside a DLL, a DLL has to be loaded inside an existing process. There are various ways to do this: using a file and Win32 API function LoadLibrary, fileless reflective loading, …

When we look at the VBA code, it becomes clear that what this malicious spreadsheet does:

The VBA code extracts the proper DLL to disk (exchange1.dll or exchange2.dll), loads it inside the Excel process with API call LoadLibrary and then calls exported function Amway (more on this in a later blog post). This is done using code that was made public about a year ago.

Remark that there are 2 DLLs, one 32-bit and another 64-bit, because of the various environments where the malware has to operate. Microsoft Office comes in 2 flavors: 32-bit Office and 64-bit Office. A 32-bit process uses 32-bit DLLs, and a 64-bit process uses 64-bit DLLs. Depending on the bitness of the Office process, the corresponding DLL will be written to disk and then loaded into the Excel process.

For an attacker, the use of a DLL can offer the advantage of bypassing application whitelisting, depending on the technology used. Not all application whitelisting solutions take DLLs into account. For example, in its default configuration, AppLocker will not prevent loading of DLLs. Whitelisting of DLLs has to be configured explicitly.

Conclusion
Unlike most malicious documents that drop a malicious EXE and create a new process, this spreadsheet drops a malicious DLL and does not create a new process. If you protect your machines with an application whitelisting solution, make sure it handles DLLs too.

About the authors
Didier Stevens is a malware expert working for NVISO. Didier is a SANS Internet Storm Center senior handler and Microsoft MVP, and has developed numerous popular tools to assist with malware analysis. You can find Didier on Twitter and LinkedIn.

Didier will be teaching a class on malicious documents for red teams at BruCON in October.