A deep-dive analysis

Introduction

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

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

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

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

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

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 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

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

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