During the past few weeks I received several emails asking how to dissect Office Payloads. While I was thinking on how to answer to such a questions I received a MalSpam with a Microsoft Office document attached by sheer coincidence, so I decided to write little bit on it. This is not going to be a full path analysis so If you are interested on a more complete one, including dissection steps on final payloads, please refer to some of my previous analysis (HERE,HERE, HERE) or to Yoroi’s Blog.

Attached to a nice crafted MalSpam email hitting my inbox a malicious Office Document having a pretty neat “autoopen()” Macro. I am going to call this stage: stage1. The “autoopen()” trick is a pretty known one if you are a Dropper writer. Indeed once the user opens the document, Microsoft Office runs that function as the first one, as well as it will run the “onclose()” function as the last one, in case of implementation. Both of those tricks are quite well-known in the malware industry. The following image shows the autopen() content.

Stage1: autoopen() Macro in Malspam Attached campaign

The “autoopen()” function implements a “Resume Error” obfuscation technique. In other words when the running script hits any errors it resumes from next line of code without interrupting the execution flow. In such a way the attacker could exploits runtime errors to loop into functions. By switching between conditional jumps to code lines, the script builds-up a second stage invoked by powershell.exe. In order to follow the required steps – before getting into powershell encoded payload – (I will call it: stage2) the native Microsoft Office debugger would definitely help you. I would suggest to use conditional breakpoints (natively available on Office Macro editor) to “break if value change” on principal and non-jumping code line. The following image shows the decoded stage1 and welcomes the encoded representation of stage2.

stage2: powershell extraction

In this case I had to manipulate a little bit the original code in order to break atomic commands which would directly launch the stage2 without getting an easy and understandable string visualisation. Therefore you might see a,b,c,d and E variables which are not native on that sample and artificially introduced into that code to get the highlighted clear text value (blue highlight in the image). “Powershell -e” executes a base64 string representing the code to be run on the victim machine. We need to carve into such a string. In order to start a string manipulation I suggest CyberCheff, one of my favorite string manipulation tool ever ! On the top right of the following image, the stage1 extracted code is placed. On the Left side (on green) the manipulation function adopted to deobfuscate the stage2 payload.

String manipulation on stage2

The first manipulation step is to decode the string from it encoding representation on Base64. The attacker used a wide range of non alphabet chars which make very difficult to read the decoded payload. So you might ask to cybercheff to remove non-alphabet characters and to remove null bytes which avoid the correct parser interpretation (the “null byte remotion is a second step on the cybercheff decoding chain). Once you removed useless chars you might observe that attacker used a more noisy characters. In this specific case we see the char ‘+’ that is abused on each line. A find and replace module helped me a lot (third step in cybercheff decoding chain). Finally the online tool gives a nice and quite smart tool called syntax highlighter which makes a smooth code ready to be read. You have it on the bottom right on the same image. Now you have the stage2 in plain text ready to be read and debugged if you wish. From here you might decide to extract the dropper websites and block them on your firewall/proxy/etc.. but if you want to debug it, Microsoft ISE is a great tool. The following images shows stage2 on Microsoft ISE.

Deobfuscated Stage2 on debugger

A simple “foreach” loop is running through dropper websites waiting for the first response. Once a dropper website responds stage3 is downloaded and run. According to hash rate the dropped payload is a Emotet. The dropped Emotet used an opensource ofbuscation technique calle Movfuscator.

The M/o/Vfuscator (short ‘o’, sounds like “mobfuscator”) compiles programs into “mov” instructions, and only “mov” instructions. Arithmetic, comparisons, jumps, function calls, and everything else a program needs are all performed through mov operations; there is no self-modifying code, no transport-triggered calculation, and no other form of non-mov cheating.

Running the sample into a controlled environment and grabbing network communications is interesting to check connection patterns and eventually traffic contents. From the recorded traffic it’s possible to see the following patterns: a HTTP GET request with some encrypted information to download plugin/additional stages and finally a HTTP POST to send victim’s data directly on the “attacker side”. In the first case (HTTP GET) the Malware communicates to server through cookies, using a 6 digit numeric variable. The used variable holds a Base64 representation of encrypted data. On the second case (HTTP POST) the Malware communicates to the command and control using a Form variable. Even in this case the transmitted content is a Base64 representation of encrypted data. I will not get into dissecting stage3 and the following ones since my main topic is to answer to “how to deobfuscating office dropper”. If you are interested on follow a full detailed analysis path, please take a look to Yoroi’s Blog.

Traffic Patterns Stage3

IoC:

Hash: 21b2b7e92c8f7e405062af2ecca54753fb6fe4f93000d262cd1bae4f89c81310 ( INVOICE_DOC_[number].doc )

Hash: 78b24079bb6243c1db098f238aef726bad1eec427fe2e4d414fb1d38223775ac (executed powershell)

Hash: 895818b8bbccd92810494ca75a612bf63ccb184c34fc0048072c37fe6546dcf0 (emotet)

URL: hxxp://www.bilgiegitimonline.com/wp-admin/mXWp/ (dropper)

URL: hxxp://134.249.116.78/index.php (dropper)

URL: hxxp://apps.identrust.com/roots/dstrootcax3.p7c (dropper)

URL: hxxp://173.50.48.59:443/whoami.php (service)

URL: hxxp://173.50.48.59:443/ (C2)

URL: hxxp://173.50.48.59:443/ (C2)

URL: hxxp://82.73.220.225/results/iplk/ (C2)

URL: hxxp://82.73.220.225/jit/ (C2)

URL: hxxp://82.73.220.225/vermont/health/ (C2)