DeDOSfuscation Shortcut - Guest Post!

Security REsearch by Shane Andrews

This analysis was based on an Emotet Word Document dropper that I had a chance to look at. I learned a lot while trying to figure out what the document was doing and being forced to look up cmd line commands. Emotet is a well known malware banking Trojan, but with this post I hope to show a little bit of a shortcut for Dosfuscated code. The set-up was pretty standard with a word document containing macros in 3 different streams. A couple things stuck out for me when trying to work through the sample that I will highlight. The original document contained the following three obfuscated macro streams that I found with oledump.py.

It was pretty standard in its obfuscation technique, surrounding the actual code with a bunch of dead code. The most important part being found here:

The “ Shell% VtcNajLSC, CInt(msoBarTypeNormal) ” line is the set up for final cmd code. One interesting part was the second argument passed of “ CInt(msoBarTypeNormal) “ which is saying give me the integer value of the “msoBarTypeNormal.” This can be found on MSDN as the value of 0:

Zero as the second argument in the Shell function will create a hidden window as seen from MSDN here:

With that established I needed to find out what was going to be passed as the “pathname” argument. I decided to let the code do the job for me by creating a .vbs script that just threw the 3 streams of code together without even removing the dead code but making sure to replace the Shell call with a Wscript.Echo. I had to remove all the attributes and the AutoOpen() line. I quickly learned that was not enough to get the code to run however, because I had an error thrown for the keystring() function in stream 14! Turns out that it is a Microsoft Word function and will not run in a straight .vbs file. Luckily it only shows up twice and after looking at MSDN to see what it was trying to do I was able to just hard code the return value it was looking for. The code looks like this - KeyString(jdoiQ + iqCHM + 4 + 6 + 1 + 5 + 51 + tqqrG + dzGGPqB) + sPQLM + AMZbVd + KeyString(vUmDpCO + aCjib + 4 + 7 + 1 + 6 + 59 + BuiKswP + WpihCLA) - and only the numbers are valid (the variables in between have no values and get ignored, so nice of VB to allow that…) so essentially it is looking for - KeyString(67)  + KeyString(77) - which turns out to be:

Or alternatively a clever way of saying “CM” in the CMd it was about to call. After replacing the keystring() function calls with a hardcoded “C” + “M” the code spit out the following:

First let's remove all those pesky carrots, I figure if cmd.exe ignores them we should too. After some notepad++ magic it looks like this:

The messy highlighting is to point out what I hope I can help others who get tripped up by this popular dosfuscation method. With careful eyes (or good friends like James Haughom) you can just make out the reversed letters of p o w e r s h e l l at the end of the long string before the “for” loop is entered at the end. With that we could probably use some bash powertools like “rev” and “sed” to pull out some indicators like URLs, but I wanted to see if I could again let the code itself do the heavy-lifting for me and make sure I didn’t miss or accidently replace something I needed. So I had to start googling what this code was actually doing. It uses some well placed “set” commands to replace the values of certain lines and eventually at the end uses the “for” loop to do the final string finagling to pass the variable ‘ %,\#:*,\#!=% ‘ to the “call” command. This meant that the “secrets” lay within whatever the ‘ %,\#:*,\#!=% ‘ variable value was. I originally only replaced the “call” command with an “echo” command and got the following result:

Okay…..that literally just echoed what I wanted the value of! So back to google I went and found the following information:

So it appears the highlighted /V was important, and according to this i would have to surround the variable name like this - !var! - to be able to see what it’s “expanded” value is. Let’s try that:

As you can see, when the % signs were replaced with !’s the echo command that we used to replace the call command did exactly what we wanted and spit out the PowerShell code that the Malicious Word Document was trying to run all along. This happened to be an Emotet dropper trying to pull down an executable it was going to place in the “env:public” directory and name 475.exe. It then uses “Invoke-Item” to execute it. Hopefully this will help out with deobfuscating future Dosfuscated scripts, and thanks for you time!