Emotet was first found in the wild in 2014. Back then its main functionality was stealing user banking credentials. Since then it has survived numerous transformations, started delivering other malware and finally became a powerful botnet. In January 2021 Emotet was disrupted by a joint effort of different countries’ authorities. It took the threat actors almost 10 months to rebuild the infrastructure, whereupon Emotet returned in November. At that time, Trickbot malware was used to deliver Emotet. Now, Emotet is spreading by itself in malicious spam campaigns.
Based on recent Emotet protocol analysis and C2 responses, we can say that now Emotet can download 16 additional modules. We were able to retrieve 10 of them (including two different copies of the Spam module), used by Emotet for Credential/Password/Account/E-mail stealing and spamming. In this post, we provide a brief analysis of these modules, as well as statistics on recent Emotet attacks.
Emotet technical analysis
A typical Emotet infection begins with spam e-mails delivered with Microsoft Office (Word, Excel) attachments. Malicious macros are used to start PowerShell, and download and execute an Emotet DLL. Depending on the available access, Emotet creates a subdirectory with a random name in the %Windows%SysWOW64 or %User%AppDataLocal directory, and copies itself there under a randomly generated name and extension. The exported Control_RunDLL function is used to run the main activity of the Emotet DLL.
Emotet infection execution chain
After being run, the Emotet malware creates a service by calling the CreateServiceW() function. A randomly generated name and extension, which were used to create a copy, act as service names.
CreateServiceW() function with arguments
If the attempt to create a new service fails, Emotet creates a new registry key in HKEY_CURRENT_USERSOFTWAREMicrosoftWindowsCurrentVersionRun with the same names that were used when creating the service.
Autostart key in registry
As soon as the Emotet DLL is launched, it registers with one of the 20 C2 IPs that are hardcoded in encrypted form into the malware body. Downloaded modules can also include additional C2 IPs. The following data is used for bot registration:
Together with the registration data, the victim’s public key that is generated in every run is also sent to the C2. Unlike previous versions that used RSA to encrypt the generated AES key, this newest Emotet sample uses the ECDH (Elliptic curve Diffie–Hellman) algorithm, using the victim’s generated key pair together with Emotet’s public key hardcoded into the code to derive the AES key for encrypting the communication. This is done with use of the Windows API BCryptSecretAgreement.
During our monitoring we have observed that after registration the C2 replies with the Process List module payload. The module comes in the form of a DLL that is parsed and loaded directly into the Rundll32 process. Its entry point is called by passing a specific structure to its DllMain function. It is also worth noting that Emotet uses the ECDSA (Elliptic Curve Digital Signature Algorithm) to verify the payload integrity before loading it.
Pseudo code to load Emotet’s second-stage DLL directly into memory
Aside from loading the DLL into memory, there are other ways to run the payload. For example:
- write the DLL payload to disk and run it through regsvr32.exe -s “%s” or rundll32.exe “%s”,Control_RunDLL
- write the payload to disk and attempt to call CreateProcess or duplicate the user token to call CreateProcessAsUser
During communication, C2 returns the module bodies and configuration. Based on the configuration, the malware selects the way to run the payload module. During our research, all the modules we retrieved were launched in the parent process, but a separate thread is started for each new module. Each module has its own numeric ID, and contains its own C2 list. However, all the modules we retrieved contained the same list of C2, except the Spam module. Emotet modules are delivered on demand, and there are always a few junk bytes that vary in different samples of the same module. This is likely to avoid cloud scanning or file hash detection.
Random bytes changed between “Process List” module binaries
Process List module
This module sends the list of running processes back to C2. Usually C2 does not send any other modules until it gets a response from this one.
Emotet Process List module request
Mail PassView module
The module contains an embedded executable called Nir Sofer’s Mail PassView, a password recovery tool that reveals passwords and account details for various e-mail clients. In order to execute the password recovery tool, the Emotet module copies certutil.exe into a %Temp% directory under a random name with the .exe extension, starts the copied executable and uses the process hollowing technique to inject the password recovery tool executable into the newly created process. The CertUtil process is started with command line arguments to force the recovery tool to save the results to file.
CertUtil with command line for password recovery tool
According to the official website, the utility is capable of revealing passwords and other account details for various e-mail clients, including Outlook and Thunderbird.
WebBrowser PassView module
This module is mostly the same as the previous one, except it uses the Nir Sofer’s WebBrowser PassView password recovery tool for revealing passwords and account details in browsers.
According to the official website, the utility is capable of revealing passwords and other account details in various web browsers, including Internet Explorer, Mozilla Firefox, Google Chrome, Safari and Opera.
Pseudocode of function from WebBrowser PassView module
Emotet has used code obfuscation for years, and this module is no exception. In the figure above, we can see that the control flow obfuscation technique is used with the variable ‘state’ (yellow-colored). Also, all API calls are resolved during runtime. This is why this API resolution layer can use junk arguments (red-framed). Code listings can be larger and more obfuscated, which is why it makes no sense to show them for all modules.
Outlook Address Grabber module
A data exfiltration module for Outlook. The module uses the Outlook Messaging API interface, iterates through Outlook profiles and extracts all displayed names and mail addresses from each found mail. It then sends the collected e-mail addresses to C2.
Outlook E-mails Grabber module
A data exfiltration module for Outlook. The module uses the Outlook Messaging API interface, iterates through all personal folders (Inbox, Sent items, Deleted Items, etc), extracts all displayed names and mail addresses of sender and recipient, and extracts the e-mail subject and body. It then sends the collected e-mails to C2.
Thunderbird Address Grabber module
A data exfiltration module for Thunderbird. The module iterates through Thunderbird profiles located in %AppData%RoamingThunderbirdProfiles, parses Thunderbird data files and extracts displayed names and mail addresses. It then sends the collected e-mail addresses to C2.
Thunderbird E-mails Grabber module
A data exfiltration module for Thunderbird. The module iterates through Thunderbird profiles located in %AppData%RoamingThunderbirdProfiles, parses Thunderbird data files and extracts displayed names and mail addresses of sender and recipient, and extracts the e-mail subject and body. It then sends the collected e-mails to C2.
The module is responsible for sending spam. It queries C2 until it receives a response with a spam task that usually consist of three parts:
- A list of e-mail servers and compromised accounts to be used to send spam; dozens of compromised accounts are stored in a single task.
- A list of targeted e-mails, recipient e-mail and name, sender e-mail and name.
- A spam template with subject, body and attachments.
Redacted list of email servers, compromised accounts used for spamming
Two of the 10 modules we were able to obtain were spam modules. Their functionality is one and the same, but the module IDs differ.
An auxiliary module for testing the possibility of connecting to the infected system from the outside. In the settings of this module, which are sent by C2, together with the module itself, the external IP address of the infected system is transmitted. The first thing this module does is enumerate the network interfaces and compare their addresses with the IP address obtained from the module’s configuration settings. If a suitable network interface is found, the module opens ports for listening and waits for an incoming connection. The module can open the following ports: 80, 443, 8080, 8090, 7080, 8443, 20, 21, 22, 53, 143, 465, 990, 993, 995. If a suitable network interface is not found, it uses the SSDP protocol to find devices (modem, router, etc.) with Internet access. If suitable devices are found, the module tries to reconfigure them using AddPortMapping to allow port forwarding.
Example of AddPortMapping for 443 port forwarding
Since Emotet’s return in November 2021, we have observed its activity gradually increase. In March 2022, however, based on our telemetry, the number of attacked users shot up from 2,847 in February to 9,086 — more than threefold growth.
Dynamics of the number of attacked users in recent Emotet attacks, November 2021–March 2022 (download)
A similar upsurge we observed in March in the number of Emotet detections.
Dynamics of the number of Emotet detections, November 2021–March 2022 (download)
Emotet infects computers of companies and individual users all over the world. In Q1 2022, according to our telemetry, users of the following countries were most often targeted by Emotet: Italy (10.04%), Russia (9.87%), Japan (8.55%), Mexico (8.36%), Brazil (6.88%), Indonesia (4.92%), India (3.21%), Vietnam (2.70%), China (2.62), Germany (2.19%) and Malaysia (2.13%).
Geographical distribution of Emotet targets, Q1 2022 (download)
The current set of modules is capable of performing a large set of malicious actions: stealing e-mails, passwords and login data from various sources; sending spam. All these modules, except those for Thunderbird, in one form or another, have been used before by Emotet. However, there are still modules that we have not been able to obtain yet. In addition, our telemetry shows significant growth in the number of attacked users in March. We continue to actively monitor the Emotet family. More information about the malware we provide in our private reports on Kaspersky Threat Intelligence Portal.
Indicators of Compromise
Note: Because Emotet is polymorphic malware, there are no IOC hashes.
C2 IP addresses
This post appeared first on SecureList – Kaspersky Lab’s Cyberthreat Research and Reports