1-616-874-7810 info@vdalabs.com

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.

NOTE: If you are going to examine malware it is important to do so safely – using some kind of sandbox or virtual machine is the best option. The post below does not teach all steps that are necessary for protection, only a general workflow.

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!

Next time…

In our next post we will move on from manually analyzing what this malware is doing to actual observation – in a safe environment.