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:
Date: 2018/05/14 15:07:23
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.
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
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:
Let’s beautify a bit this XML code with Ultraedit. Looking through it I saw something that caught my attention:
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.
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).
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.
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.