In our last post, “A Modern Phishing Attack: Part 1 – Malware Delivery”, we discussed how a sophisticated phishing attack can use a number of tactics to increase trust, and therefore likelihood of success of the initial delivery. In this post we will look at the malware itself using a very simple malware analysis workflow to get a quick understanding of how it works. VDA has many different ways of examining malware, but in this case we were aiming for a quick picture of what was going on.
Simple Malware Analysis with OfficeMalScanner
OfficeMalScanner is a free tool that allows you to examine macros and other malicious payloads in Office documents. You can get a copy at http://www.reconstructer.org/. To use the scanner, you follow this pattern: “OfficeMalScanner FILENAME command“. In this case we ran the “scan” command:
The output above shows that OfficeMalScanner discovered that our .doc file was actually a .docx – the more modern XML based file format. (Remember from pt. 1 when we said that the “older version of Word” trick was a lie?). In order to examine a .docx file, you need to run the “inflate command” like it directs – below is the output from the “Inflate” command.
The inflate command extracts the components of the .docx file, and places them in a designated folder on your disk. It also specifies the binary file that was included in the docx, which it suspects might be malicious. You then have to attempt to run the “Scan+Brute” commands, and “INFO” command against this binary file. The output of “INFO” is below:
It looks like OfficeMalScanner has decompressed the macros within the .BIN file, so now we can inspect them. Great! Unfortunately though, upon inspection, we can see some pretty heavily obfuscated code. And by obfuscated I mean written in a language I don’t know – either Italian or Portugese. A snippet of this is below.
Regardless of the language, we can see a few things here that look suspicious. Mainly:
- The “Wscript.Shell” object running, with a “vbHide” parameter
- The “AutoClose()” method
These things alone are warning bells for sure, but figuring out exactly what the code does might take more time than it’s worth given the language barrier, so let’s move on to another tactic!
In our next post we will move on from manually analyzing what this malware is doing to actual observation – in a safe environment.