Earlier this week we came across an interesting spam email. It was targeted at one of our customers in the retail industry. It contained a Microsoft Word document (MD5 = b74604d0081e68e91d64b361601d79c4) with a rather small macro in it. All that macro did was save a copy of the document as RTF, open it and then launch an executable from user’s temp folder. The interesting bit is that it did not explicitly drop or download the executable, it was just supposed to be there somehow. Turns out the malicious executable was embedded into the document as a package and dropped by MS Office itself. For the full details read on.
First, let’s look at the macro. When de-obfuscated the macro can be reduced to the following code:
The diagram below describes the behavior of this macro:
Two observations about that workflow can be made:
- It saves the document as .RTF and opens it and doesn’t do anything with it afterwards.
- It executes %temp%\lof4.exe which is supposed to be there somehow, but there’s no code that downloads and drops it there.
Whoever crafted this document might have been inspired by this article. The article describes in great detail how to embed a malicious executable into an email message. The approach allegedly allows to bypass a lot of spam filters.
A trick used by the attacker is rather simple. You can embed pretty much anything into an Office document by inserting a package (Insert -> Object -> Package). Normally a user must double click on the icon of the package, then Office pops a warning and if the user clicks “OK” it executes the package, like so:
So wouldn’t it be nice for attackers to execute the embedded malware from a macro without too much of user interaction? It would, but first they must somehow drop it into the victim’s file system.
Turns out, if you save your document as .RTF and then open it – the packaged EXE will be dropped into the user’s temporary folder (a.k.a. %TEMP%). That’s exactly what this macro is doing. Malware binary is dropped into the victim’s file system by MS Word itself.
In case you’re wondering why didn’t they send it as RTF to begin with – it’s because RTF does not support macros.
Ok, the explanation so far might be a bit confusing, so please have a look at the diagram illustrating the attack end to end:
Of course this particular document will be caught by the majority of anti-viruses, because the PE EXE is blatantly “visible” in the .DOC file. But this attack can be modified to be stealthier. For example, the malware can be encrypted or even concealed in an image and then decrypted or extracted by a macro.
User still must allow the macro to run, so the social engineering part of the attack did not go anywhere. Perhaps attackers hoped that some defenses would overlook an executable file inside an OLE document?
This doesn’t look to be a very serious issue, but still a curious trick worth mentioning. We checked with Microsoft – they are aware of this behavior, here’s what their response was:
“This is not a new malware sample and is not doing anything out of the ordinary. If this gets passed Anti-malware software, Defender already catches this and it has a high detection ratio on VirusTotal, it still requires the user to enable Macros (social engineering), I would make sure to call that out specifically in your article.”
UPDATE: This behavior has been looked into by Haifei Li from McAfee (link)