Introduction

Emotet is dead. Long live Emotet!

The king has returned! After emotet got taken down 10months ago by a joint operation it is now back up and climbing the ladder to become number one ransomware once again. While I personally could not await to get my hands on a sample of the latest emotet-ransomware, this is really bad news for anyone else who does not work in IT-Security. Emotet has been known to be the most dangerous and most sophisticated ransomware you could come across.

The disastrous effects aside, I enjoyed analyzing each emotet-sample until now. The skills, techniques used and the knowledge about windows internals were always jaw-dropping and showed „great“ craftsmanship. While emotet was gone other groups took over, such as Conti, Ryuk and others and tried to fill the void but could not really replace emotet (or did not want to). The initial access was therefore more or less split into different groups and big players like Trickbot were left to use other ways to find their way onto victims machines.
But now emotet is back and I am excited to see what the authors have in store for the unlucky who will get infected. We will hopefully probably see a lot of different samples in the future so keep that in mind.

You got mail!

The sample I am looking at today is the following:

Hash:
MD5: fd08ef74dd2315c6b574ded888322230

The analysis will be split in several parts because I want to get into the nitty-gritty of the whole thing and try to find out as much as possible, to learn and possible take over some techniques for my RedTeaming-Activities. As most ransomware nowadays, emotet is coming via mail and includes a malicious .doc-file. Nothing unusual so far.

Looking at the macros we can see several obfuscated macros.

However, looking at those macros directly is not possible because they are password-protected.

First look

Running the file does not do anything so no screenshot here. This was about to be expected as I did not expect any visual sign that I got infected. Fear not though as we can use different tools to extract files from the .doc file itself. With oledump we can not only see the stream itself but also try to extract it.

After extraction we can see a lot of obfuscated code. From experience most obfuscated macros will just end in a powershell-script so this is the first thing I am looking for. If we skip to the end we can see the obvious signs for an obfuscated powershell-script with „IEX“ and words that could resemble „Get-“ and such. Obviously this is just a guess but usually works out. If we pretend that the last call is supposed to turn out to be something like „IEX $var“ then this variable is getting declared somewhere earlier. As it turns out this is the case here.

Be careful with this approach. This was very straightforward but could also have been a dead-end or simple code that does nothing or never gets called. With obfuscated code (IMHO) it is usually easier to just execute it and see what comes out on the other end because this is just the first stage and very likely not really interesting for us. This is what I did here after turning on powershell-logging.

Dll it is

Running the script we can see several urls and the mentioned „IEX“ at the end to run the whole thing. This seems to be very simple:

• download files from several different urls
• create random number $r1
• create random number $r2
• save all files to C:\ProgramData\[$r1].dll
• start process C:\Windows\SysWOW64\rundll32.exe
• File: C:\ProgramData\[$r1].dll
• Argument: f[$r2]

If we modify the powershell-script a bit we can see not only the urls but also one call to rundll32.exe with the correct arguments. Those may or may not be important later on.

Those dlls are at least in size the same except one with only 1kb in size. Taking a look at the file itself makes it clear why. The owner of the site took the server down to fix it/patch it. Others are not at that point yet.

Hashing the other files gives us at least one match. At this point it is unclear but I believe that the other files perform the same code but are only altered to either avoid detection or simply contain different urls or something benign.

Run it!

With the dll in hand and the corresponding function call we copy the file to C:\ProgramData and start the dll via rundll32.exe.

Visually nothing seems to happen (expected) but we can see that the dll. gets deleted after a short time and drops another seemingly random file in a random folder in C:\Windows\SysWOW64.

Comparing this file to any of the other files we can see that it is indeed the same file but in a different folder with a different name. The loader is probably checking the parent process and where it is coming from and then either drops the file into SysWOW64 or continues with the next steps. This is just a theory up until here however.

Next step

Alright, after another reset we prepare the files again. This time in C:\Windows\SysWOW64 with the right function call and while observing the file read/write operations. This leads us to another file this time written to C:\Windows\System32\[random folder name]\[random file name].

We seem to be getting closer as this seems to be the first not obfuscated function call so far. Opening the file in IDA we can see what is happening after calling the function „Control_RunDLL“. I already labeled one call that is probably the necessary decryption that needs to happen before anything interesting could be done.

Following the call we can see some form of loop going on which could be the decryption of some of the strings or just moving data from a to b. The increase at the end is the indicator for a loop.

Continued

To keep each blog post the time needed to write the post short I’ll stop here and upload the details in another part.

Cheers 🙂