New Emotet Spam Wave 24.8.2017

Background story

On Thursday multiple customers contacted me about emails from business partners or colleagues that contained scans or invoices. The emails itself weren't really well done but most customers were afraid of having been breached because it looked like someone from within the company send them the mails. I started with a quick google search and could calm them down immediately because I found several similar looking emails.

You can find example emails here example mails (german)

Stage 1 - Macro Word Downloader

I noticed that each email contained an URL behind each was a download to a word document. Opening the document leads to the following image which contains a description on how to enable the content and macros.

word macro dropper

One of the first steps after just enabling macros and monitoring the network traffic, is to open the build in VBA Editor and try to debug the embedded macros. I noticed that the macros aren't password protected and that the document contains an autoopen function. The autoopen function calls another function which does all the important work. (I noticed this by just quickly stepping through it and monitoring network connections)

I added a few Debug.Print statements and could quickly figure out that the macro creates a wscript.shell object to execute a base64 encoded powershell command. The next figure contains the main macro function with a few deobfuscated strings.

Partly deobfuscated macro

The next step is to analyze the powershell and try to extract some IOCs.

Stage 2 - Base64 encoded powershell

The next step is to base64decode the powershell command to see what it does


[System.Text.Encoding]::Unicode.GetString([System.Convert]::FromBase64String("JAB7AH..."))

base64 decoded powershell

I reformat the powershell a bit and dumb variables using Write-Host. (info: Declaring a variable like ${PA`TH} the ` gets ignored and one can just use Write-Host ${PATH} to get the content)
Which shows an array of 5 URLs where the script tries to download from.
The downloads are saved in %TEMP% with a random name in range(65536) + .exe. Afterwards the script tries to run the downloaded file.

beautified powershell

On successful download we get an executable. The script contains 5 URLs some of them are still working:

http://e-thesis.com/hpV/
http://jonjun.com/vVKbiCUJ/
http://cvif.org/CsGXp/
http://daze.com.hk/yaeRXq/
http://funkystudio.org/lEYJk/

Stage 3 - Final Payload

Running the executable I figured out two possible scenarios. The executable copies itself to %LOCALAPPDATA%\Microsoft\Windows or %SYSTEMROOT%\SYSWOW64.

running without admin rights

In the first case there seems to be no persistence as the executable won't start again on reboot.
In case 2 the executable creates a service with the executable name as name and restarts on reboot.
I noticed that even though my account is an administrator I have to explicitly start the program as administrator to observe case 2.

running with administrator rights

The service is disguised as Bitlocker Drive Encryption Service Hoster by telling the user that disabling the service would prevent Bitlocker usage.

service used for persistence

Figuring out the malware family

Monitoring the network connections I could see a request to an IP every 30 to 60 seconds. These callback to IP addresses combined with the fact that the executable name seems to rely on existing software on the computer immediately reminded me of the Infostealer/Banking Trojan Emotet.

Having a look at older analyses from Emotet v4 (https://blog.fortinet.com/2017/05/03/deep-analysis-of-new-emotet-variant-part-1) earlier this year, the samples show a similar pattern, even though the persistence mechanism is different.

In short: The old version created a new process and inserted it's code into it. The second thread had a hidden window with a WindowProc handler that determined which function should be run. These were generated using WM_TIMER messages. Running the executable and watching in Process Explorer, I noticed a similar behavior. The process started a new process and the old process stopped.

As the behavior of the new executable is quite similar I expected to find another WindowProc function somewhere. I tried my old method of extracting the C&C IP addresses of Emotet by running the malware and dumping the final stage. Then I could simply use IDA Pro or Python itself to extract the addresses. Emotet saves them in plain hex and extracts them using %u %u %u %u format strings.

I tried to use the same approach and noticed that byte patterns for callback IPs I monitored weren't in the executable. So I decided to attach a debugger.

Extracting the callback IPs

Upon attaching a debugger I noticed new threads being created every 30 seconds (in sync with new callbacks).

Having a look at the callbacks one can see that WinHttpRequests are used. These rely on creating new threats for requests.

The next step is to set breakpoints on kernel32.CreateThread and wait till the breakpoint is hit. On break just have a look at the stack. A callback address, this looks promising.

The call stack in x64 debug shows only return addresses in dlls. So I scroll further down on the stack. The first address I find outside the dlls, is pointing right after a call to HttpSendRequestW.

The next and final step is to find the IP addresses structure in memory and extract all IPs.
Therefore just run until the next return is hit and step out of the function. Right above I noticed a printf call which is used to convert the hex to decimal values.

Before the call to printf notice the 4 movzx eax, push eax instructions. Following the base address 325B298 leads to the array of callback IPs.

Each callback consists of 4 bytes for the IP and 4 bytes for the port. Converting them back leads to the following IP addresses.

173.212.227.54:443

104.236.252.178:8080

162.243.159.58:443

45.33.55.157:8080

77.244.245.37:7080

192.81.212.79:443

173.212.192.45:8080

103.16.131.20:8080