Analyzing a Japanese Language Malicious Word Document

18 Jan 2019

Seems harmless right?

Rundown

I stumbled upon this document thanks to https://urlhaus.abuse.ch . Being in Japan so long I love anytime I can find malware or a malicious document where the creator didn’t obviously use Google Translate. At first, I thought this was just another Emotet variant as it seems that every compromised Japanese IP is hosting one of the variants.

This document is hosted at hxxp://file.tancyo.blog.shinobi.jp

Upon opening the document, the user is presented with the above Word document. Roughly translated, the malicious document is an invoice for services. In the top text box with reddish font, the document instructs the user to accept and enable macros by clicking through the prompts.

There are two pictures embedded in the document that appear to be the same type of invoice. I could not find anything malicious about either image.

Figure 1

Executing the document

Not surprisingly, Windows Defender immediately alerts on the document and displays what type of malware may be infecting the system.

Figure 2

Since we know the document is malicious, we can move on and start looking at some tell-tale signs from within Word itself. Utilizing the Developer tab in Microsoft Word, not only can we view the macros, but we can also run them and even set breakpoints.

Figure 3

AutoOpen is used by malware writers to automate the launch of their code upon the user opening the document. It should be noted, that the subroutine also has legitimate purposes, but should be considered dangerous.

Upon further review of the macros, we get another sure sign that this document is up to no good.

Figure 4 Notice the “Interaction.Shell”. We will come back to that later.

Deep Dive

The Developer is great to use, but researching inside Word is a little messy to me. I will move the file to an installed Remnux (https://remnux.org) VM for analysis. Hopefully you are already aware of Remnux, if not please check it out along with FlareVM for your research needs.

The Python oletools allow a researcher to do just about everything they need to crack open a malicious document and learn more about it. First things first, lets run old faithful; the file command.

Figure 5 Nothing shocking here, moving on

Starting with olemeta and oleid, we can attempt to get some more information on the file itself as well as confirm our suspicions on the VBA macros.

Figure 6. Booo!! Nothing interesting here either
Figure 7

Taking a closer look at the information returned for oleid, we can confirm that VBA Macros are present (represented by the True value) as well as embedded OLE objects. We saw a preview of the macros used while in the document, lets use oledump to get a better picture.

Figure 8. A whole lot going on here.

In the above image, you can see what appear to be base64 and hex encoded values on lines 28 and 29. We will dig deeper into those in a few. The streams with lowercase m’s next to them indicates VBA code containing only attribute statements. The capital M indicates code with other types of statements. In other words, the capital M’s are where the juicy information is so check their first.

Taking a look at the two streams with capital M’s we get:

Figure 9 Stream 16
Figure 10 Stream 25

In figure nine, you can see a large number of obfuscated code with VBA Select Case statements (https://docs.microsoft.com/en-us/dotnet/visual-basic/language-reference/statements/select-case-statement). Also visible are a number of Fix and Oct functions. The Oct function converts an integer to octal notation and returns a string.

More interestingly further down, we see the code assigning variables to an array an Interaction.Shell method, as well as a TextBox object. The Interaction.Shell method (https://docs.microsoft.com/en-us/dotnet/api/microsoft.visualbasic.interaction.shell?view=netframework-4.7.2) allows for a program to be executed and return the process ID. The TextBox object (https://docs.microsoft.com/en-us/office/vba/api/access.textbox) can be used to display data or results.

Figure 10 displays the VBA Project Root, the attribute name, and the autoopen() subroutine.

Enough of the tutorials, lets get to the nitty gritty! We know that this Word document is doing something fishy with a shell, which is not good for our user or network at all. Utilizing olevba’s decode option we can attempt to get a better picture at what is going on in the code.

Figure 11

So I still haven’t been able to piece together or de-obfuscate what exactly is going on in the VBA code or with the above hex and base64 strings. Luckily we can turn to another great tool in Windows, Sysmon.

Figure 12

Now as researchers we can start putting the pieces together after banging our heads against the wall wondering about the shell command. But once again the command line that is run is heavily obfuscated save for some DOS commands.

You probably already know the echo command, but maybe not FOR /f. This command is essentially a loop with syntax that fits to what we can see in the image: FOR /F [options] %%(parameter (above it is identified as %%z)) IN (file) Do something.

These commands are probably useful when attempting to check information on a client system, and then execute another program.

More Behavior

Behind the scenes while I was researching this document, there were a number of .tmp files and .dat files that were created. In addition looking at another great tool, Regshot showed some interesting registry activity. A number of checks to HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Office to ensure Microsoft Office was installed as well as processes set to NOOPENFILEERRORBOX. This would disable error messages and allow for somewhat easier opening of the file.

There was tons more registry and process activity, which leads me to believe there may be additional checking of the infected system going on.

Networking

Unfortunately there was not a lot happening in regards to the networking component of this malware. This may be due to the system checks that were done while the malware was running, or the domain where the binary was hosted is offline.

Figure 13

There is one simple DNS lookup for hxxp://free.diegoalex[.]com/3289fkjsdfyu3[.]bin . Following the TCP stream in Wireshark leads us nowhere.

Uploading both the document and the site where the binary is being served gave us about the same as the TCP stream.

Figure 14
Figure 15

While both the document and the binary have pretty low scores on VirusTotal, it is obvious there is something evil going on. I will attempt to put together another Windows VM according to what the document checked for and see if we can get the binary to fire.

Apologies for the long post, hopefully this was helpful and educational. I found it quite fun and interesting. If anyone out there is well versed in de-obfuscation techniques, shout me out and give me a few pointers on that VBA macro code.

Have a great one!