NOVEMBER 30, 2021

The Re-Emergence of Emotet

Emotet, the malware botnet, has resurfaced after almost 10 months. The operation was originally taken down by multiple international law enforcement agencies this past January. These agencies took control of the infrastructure and scheduled an un-installation of the malware on April 25.

So what does the re-emergence of Emotet mean, and how can cyber professionals prepare for new threats? This blog will analyze the new DLL, break down a new unpacking technique and new features, and review similarities in the new variant with the previous version.

We will also explore a novel tool called “DeMotet” that automates the analysis of Emotet samples on a large scale and includes an unpacker for the latest loader and decryption scripts for the payload. It is used to detect any modification in the malware, and it is now publicly available.

Static Analysis
For this analysis, the following sample will be used:
76816ba1a506eba7151bce38b3e6d673362355063c8fd92444b6bec5ad106c21

As shown in our previous blog posts, the execution flow of Emotet consists of multiple stages that are unpacked in succession. As expected, this is still the case with the new variant. The DLL that is written to disk isn’t the actual payload that communicates with the C2 servers. This can be seen by a review of the static information of the resources.

image.png

The entropy of the bitmap resource is high, and it most likely contains encrypted information. To unpack the next stage, the decryption routine needs to be found.

This resource will be accessed before decryption starts. A breakpoint can be set on the “FindResourceA” function to reach this point.

Extracting the Next Stage
The malware reaches the breakpoint and then returns to the address 0x10005701.

image.png

The parameters for “FindResourceA” match the suspicious resource. This API is called through a register because it isn’t imported. The address is located in runtime to hinder static analysis. The function then allocates memory based on the size of the resource and goes through some decryption loops.

The return value is the next stage. The size of the file is specified in the code, which makes the extraction from memory even easier.

image.png

Comparing Variants
In the past, there was a middle stage between the loader and the payload. Based on our previous analysis of the Emotet payload, the file extracted is the payload itself and not a middle stage.

  1. The PE file has no imported API functions.
  2. There are barely any strings present.
  3. The malware utilizes the same code obfuscation techniques.

image.png

                                                                                    On the left: the new payload. On the right: a payload from January 2021

The payload conceals its capabilities by hiding information that is used for static analysis. The names of the API functions are stored in the code after they were hashed. Their address is located in run-time instead of using the Import Address Table. The strings are encrypted inside the file.

The code is obfuscated using Control Flow Flattening, which works as follows:

  1. A number is assigned to each basic block.
  2. The obfuscator introduces a block number variable, indicating which block should execute.
  3. Each block, instead of transferring control to a successor with a branch instruction, as usual, updates the block number variable to its chosen successor.
  4. The ordinary control flow is replaced with a switch statement over the block number variable, wrapped inside of a loop.

New imported functions from bcrypt.dll were added to the payload. The strings that represent constants for those functions were also added, such as “ECDH_P256” and “Microsoft Primitive Provider.” This is probably due to Emotet changing its communication protocol from HTTP to HTTPS.
The name hashing and strings decryption algorithms were kept. This means that “DeMotet” is still able to discover this information.

Introducing “DeMotet”
Deep Instinct has been closely following Emotet for some time. “DeMotet” was developed to automate the research performed on the malware. The tool is a static unpacker for the latest variant of the Emotet loader. It can extract the encrypted payload from the resource without executing the malware. Python scripts are also included in this tool. They reveal the hidden strings and API calls the payload uses. The first one is a standalone script that can be used to extract this information from a large number of payloads. The second one is an IDA plugin. It adds this information as comments in the code.

image.png

"DeMotet” can be used to track new variants of the malware. New samples of Emotet can be downloaded and unpacked regularly. Once the unpacking process of the malware is modified, the tool will fail.

This is an indication of a new variant. The variant will then be manually analyzed to update the tool so the automation can be restored. Finding new strings and imported functions in the payload is also indicative of a new feature.

The tool is available in this GitHub repository.

Summary
The notorious botnet Emotet is back, and we can expect that new tricks and evasion techniques will be implemented in the malware as the operation progresses, perhaps even returning to being a significant global threat. However, by using the techniques and tools presented in this article, the analysis of the malware can be simplified and automated.

Deep Instinct takes a prevention-first approach to stopping ransomware and other malware using the world’s first and only purpose built, deep learning cybersecurity framework. We predict and prevent known, unknown, and zero-day threats in <20 milliseconds, 750X faster than the fastest ransomware can encrypt.

If you’d like to learn more about our malware, ransomware, and zero-day prevention capabilities – including our industry best $3M no-ransomware guarantee – we’d be delighted to give you a demo.

IOC
Loaders SHA256
3b3b65d42e44bcc0df291ddab72f1351784f7e66357a4ec75ee5c982ef556149
6b477d63b3504c6eab3c35057b99d467039995783f5f14714ae6af4f83b9dcb3
442ff2de8a19c3f6cf793f9209ffd21da18aa7eb5b4c4c280222eb9f10a2c68a
9ac36258c63a5edfd29e3ed1882c61487ef2c70637192108cc84eb4ea27f7502
00ceb55abdb43042c6f7fabd327e6e1a6cdefed723dea6c4e90d159b9466518c