Apparent bening DOCX decoy that delivers malware

Earlier this week someone sent me an email they thought to be suspicious. It was purporting to be a company complaint submitted to the “Companies House Webfiling Service”, very similar to the one in this link.

The email contained a DOCX file attachment with the same name as what seemed to be the submission number of the complaint: 48219829CPC.docx. Obviously, the first triage action was to check if it really was an OOXML (Office Open XML) file. It was indeed:

Hash: 417f016ae40152df7d1ce9d75723e5d4
Filename: 48219829CPC.docx.vir
Date: 2018/05/14 15:07:23
Magic: 504b0304
Filemagic: Zip archive data, at least v2.0 to extract

I checked the hash in VirusTotal. At that moment it only had 3 detections, currently it sits at 16. One of the detections had the string of a well-known CVE to me: CVE-2017-0199. I have blogged about a sample using this vulnerability in the past. In this case it made no sense to me that a vulnerability in the way Microsoft Office opens RTF files was present in a OOXML file, unless it had an RTF file embedded.

I started the analysis of the file using Didier Stevens tool for any PK file called zipdump. The output seemed that of a normal OOXML file:

Index Filename Encrypted Timestamp
1 [Content_Types].xml 0 1980-01-01 00:00:00
2 _rels/.rels 0 1980-01-01 00:00:00
3 word/_rels/document.xml.rels 0 1980-01-01 00:00:00
4 word/document.xml 0 1980-01-01 00:00:00
5 word/media/image1.emf 0 1980-01-01 00:00:00
6 word/theme/theme1.xml 0 1980-01-01 00:00:00
7 word/settings.xml 0 1980-01-01 00:00:00
8 word/webSettings.xml 0 1980-01-01 00:00:00
9 docProps/core.xml 0 1980-01-01 00:00:00
10 word/styles.xml 0 1980-01-01 00:00:00
11 word/fontTable.xml 0 1980-01-01 00:00:00
12 docProps/app.xml 0 1980-01-01 00:00:00

Zipdump_extended_output
Zipdump extended output (done with option -e)

Normally, the first thing I check when analyzing an OOXML file are potential anomalous objects contained or possible OLE files embedded (like in here). These were not present here. I also checked via a yara rule for potential presence of the DDE feature being abused (like in here), which was quite common in malware samples at the end of 2017, but I did not find anything either.

I had to dig deeper. When looking at Word OOXML files, the first item I always check is the main document.xml object, as it is usually where there is the most juicy findings. The output of this object was not really big:

Zipdump_object4_output

Let’s beautify a bit this XML code with Ultraedit. Looking through it I saw something that caught my attention:

Zipdump_object4_output_xml_beautified

There was an OLEObject component with a Link Type. We can find on MSDN more information about this type of OOXML class. By reading in the documentation we know this is typically used to embed OLE objects, but this other website was much more useful to find the information I was looking for.

OOXML_OleObject_elements

This told me basically that the embedded OLE object would probably be a link elsewhere and that this link would be opened automatically when opening the file. The perfect purpose for a dropper/downloader.

But where was the URL? The mention r:id in an OOXML file typically means this will be part of a relationships file. So I went to check object 3, the document.xml.rels file. And especially, its rId5 (relationship ID number 5).

Zipdump_object3_output

And there was the malicious link I was looking for. Unfortunately, at the time of this investigation the resource was not there anymore. But I figured this would be the file attempting to exploit the CVE-2017-0199 vulnerability mentioned before, and the reason for that detection. Thus, the downloader DOCX file acts as a decoy to be able to drop the real malicious document.

Curiously enough, the day after I found yet another example of a malicious link in a relationships element of an OOXML file. But this time it was just a phishing attempt to get Apple credentials.

phishing_url_example

I could not believe I was the first to find such kind of behavior, so I did some searching on Google. I soon found this article by Jerome Segura from Malwarebytes explaining about a similar mechanism to deliver malware back from October 2017.