Emotet is back

9 min readSep 11, 2020

A deep-dive analysis

Introduction

On July 21, 2020, Malwarebytes announced the return of the emotet trojan after almost 5 months. The malware was spotted in a spam campaign targeting hundreds of thousands of Microsoft Office users. The trojan which was first spotted in 2014 is still targeting users worldwide primarily through spam emails. These emails usually include certain designs with familiar branding which makes these spam emails look legit, and has either a malicious link or documents infected with malicious scripts. These files/links are represented in such a way to tempt the user in opening them, like for example billing invoices.

Emotet has a history of alliances with other APT Groups for not just for enhancing the capability of their malware but to also drop other trojans, info stealers, ransomware etc. In February 2020, researchers discovered a malware sample which could spread to insecure Wi-Fi networks that are located near an infected device.

Infection and Loading of the Trojan

Currently, the widely used way for the distribution of Emotet is through spam emails which include malicious files attached or links included in the content of the emails. The attached files are mostly in Zip format containing the Emotet loader. These files would be represented in such a way that the user might consider the email to be legit and would even open the executable present in the Zip file, these executables usually have long names to hide the .exe extension and make the user open it. One more reason for delivering through a Zip file is to avoid the executable file’s detection even before the user opens it. Like in the case of Google Chrome, it detects harmful files during download thus warning the user about it. Anti-virus programs could be evaded by this away in some cases as well.

Once opened the Trojan executes a cryptor which is used to evade anti-virus programs from detecting the Emotet loader. Once the cryptor processes the content of the file, the program finally starts with the execution of the loader’s modules and connect with the C2 server for downloading other modules for post-exploitation. One interesting thing to note here is that Emotet has certain functionalities to detect Virtual Machines and if it detects that the Trojan is running inside a VM instance, it would connect to a different C2 server which makes the analysis of the samples even harder.

Analysis of an Emotet Sample

I decided to analyse a random malware sample and that’s when I found an emote sample with an executable extension. The SHA256 hash was 8a8187cdef2f7ec88b86f118dfb87920f43c994c3862c44cd79721f66fdba4da

and this sample can be found on MalwareBazaar. Even though the malware is widely spread in the doc format but well we can’t ignore other types which carry almost the same properties and connect to the same C2 servers.

Analysing the network traffic during execution

When I opened this malware sample’s executable file, the first thing that I noticed was that the file was deleted automatically after the execution of the program. You may think that this was done by some antivirus program but to confirm this I decided to keep Wireshark enabled when I execute the file. I saw multiple requests being made to 2 IP addresses, which were most likely the C2 servers.

I found 2 IP addresses here as you can see in the above image:

118.2.218.1

51.254.140.91

We will ignore 10.0.2.15 as it is part of our private network and has nothing to do with this analysis of our malware sample. The IP addresses of the C2 servers I mentioned above belonged to Japan and France respectively if we check the whois data.

As you can see in the above 2 images, the whois data shows the IPs belonging to the respective countries. One unique thing to note here is that these servers were used in multiple samples and the second one was even used for document-based samples in a few cases. I analysed the requests made to these IP addresses and in the HTTP objects I even found a new IP address which was “45.230.228.26” and was used in other samples as well, the IP address was from Brazil in this case. The HTTP objects tab shows a couple of requests made having form-data properties. Strangely these servers are still active and have the services running. In most cases, the port 80 was left with the default apache page and the actual files were present in other directories with random characters so as to make the directory discovery harder for researchers.

The above image shows the requests made to the C2 servers. The first IP address has the actual web server running on a different port “7080” with port 80 having the default Apache config page.

These C2 servers serve as the source for the storage of the post-exploitation components and other modules to be delivered to the target system once the Emotet sample makes the requests.

Here’s an example of one such data-form’s content which was requested during the program execution:

— — — — — — — — -2JHvcy17ZcsBo17 Content-Disposition: form-data; name=”xjxsieht”; filename=”rlvmhonnz” Content-Type: application/octet-stream a¾£TTÀª

Just in case you are wondering what octet-stream is, it is a subtype is used to indicate that a body/file has arbitrary binary data present in it.

Analysing the malicious process being created during the execution

The malware creates a malicious process called mssvp.exe (original name: cmdcmxcfg.exe), this process has been detected in multiple malware samples. It was made to work as a “Context menu handler that makes it easier to work with paths, command windows, and program arguments from within Explorer. ~ according to the developer Shaun Harrington” but was ultimately used by the malware authors to use in Emotet. How did I found the other name of the process you may ask, well i checked the file with exiftool and found this:

Company Name : Shaun Harrington

File Description : CMDCMX Configuration Application

File Version : 1.0.0.1

Internal Name : cmdcmxcfg.exe

Legal Copyright : Free to redistribute!

Original File Name : cmdcmxcfg.exe

Product Name : CMDCMX

Product Version : 1.0.0.1

This process serves the purpose of connecting to the Command and Control server and specifically connected with the IP address we found earlier (51.254.140.91). The process was detected while reading the internet cache settings.

As the process is created only for a few seconds we decided to use https://app.any.run/ which can help us to record the process being created during the execution and as you can see it detects the process as a malicious with a whole 100/100 score as well as verifies what we found earlier, the process is indeed used for connecting to the CnC (or C2) server.

Reverse engineering the sample

The last part of this analysis was to reverse engineer the sample using Ghidra (A software reverse engineering (SRE) suite of tools developed by NSA’s Research Directorate in support of the Cybersecurity mission).

Please note that I am still learning assembly language so it’s a bit hard for me to understand everything present in the sample so I will try to cover the important stuff here which I was able to find.

The first thing that I discovered as you can see in the above image was a reference made to the CWinApp class which is used to derive a Windows application object. The TypeDescriptor name was set to AVCWinApp and this was most likely a LoLBin (binary supplied by the operating system that is normally used for legitimate purposes but can also be abused by malicious actors) used to evade Antivirus programs. The name used here “AVCWinApp” was referenced in some other malware samples as well so we will consider this to be a custom name used specifically for emotet or some standard library used for this malware family.

The other reference I discovered was related to the cmdcmxcfg.exe that we found earlier, as you can see in the above image this TypeDescriptor has a different name as well which is

“?AVCcmdcmxcfgDlg@@”

This reference was also used in some other samples found on online sandboxes, and like we discussed earlier cmdcmxcfg.exe was used as “mssvp.exe” for making requests to the C2 server.

Writing a YARA Rule

Before proceeding to our blog post’s conclusion let’s write a very simple YARA Rule to detect such malware samples. For those who don’t know what YARA is, it is a tool primarily used in malware research and detection. It provides a rule-based approach to create descriptions of malware families based on textual or binary patterns.

I wrote a very simple YARA Rule which checks for certain conditions to be true (present) in the file. If you would like to download this YARA Rule along with few other rules for different malware samples, you can check out my Github Repository (https://github.com/umair9747/yara-rules), the repository is still in its initial stage of development so any contributions will be appreciated!

In the above image, the Yara rule file is looking for certain strings present in the file. The strings we have mentioned are unique and restricted to only malware samples rather than being any library-related functions. These strings will help us in identifying files who possess similar strings. Such rules can be helpful when we are searching for malware samples in a big directory containing multiple files.

As you can see in the above screenshot, we scanned our malicious executable sample with our YARA rule and the -rs flag displayed all the conditions and strings which were matched with their respective memory addresses.

Conclusion

So far we analysed the network traffic during execution, found the IP addresses used for the C2 servers, analysed the malicious process created during execution, reverse engineered the sample and found 2 interesting entries from the sample, we even wrote a YARA based rule to detect similar malware samples possessing similar strings in the files.

Like I said earlier, even though the file we analysed was an executable and emotet widely targets users through document-based malware, these files contain the similar characteristics and have been using same C2 servers like that of document-based malware samples.

Emotet seems to be targeting users globally rather than targeting specific regions, its collaborations with other APT groups have helped to make emotet stealthier especially with having a custom cryptor which processes the code for the Emotet loader.

It is advised to open attachments carefully and to avoid opening any executable/document files present in any attached zip files. Always double-check the email source of the email before opening any files/links just to be sure that the email is legit.

by Umair Nehri

Cyber Security Research Intern

Andy InfoSec