Emotet is a modular malware that has advanced capabilities to deliver other sophisticated threats. Emotet initially appeared in 2014 as banking trojan, has evolved now into more modularized version to carry out other malicious actions. Trickbot is banking trojan that once steals banking related information from the computer. Trickbot is also a modular malware, the threat actors use it to deploy their malicious codes. 

We have come upon a sample that belongs to the Emotet strain. Trickbot is embedded with the Emotet strain. Once Trickbot starts infection, it connects to a malicious domain to probably download other threats.

The Emotet have cost some of the government’s 1 million USD per incident to remediate.[2]

Emotet has polymorphic capabilities that we have observed in this strain too. Besides that, we have observed stealthy behaviors that are used to evade security technologies like antivirus solutions. 

The Trickbot is encrypted with RC4 and decrypted on the fly before triggering the execution. The malware uses Process Environment Block (PEB) to resolve API addresses. This we have seen in Zeus banking trojan. 

The Emotet starts by loading the encrypted payload into the memory. This payload consists of two parts, a loader and a PE binary. Loading and decryption happens via resolved APIs. Once the decryption happens, the control is given to the loader that is available in the form of shellcode. The loader takes the PE embedded on its tail. The loader utilizes code injection techniques before transferring the control to the PE block. The embedded PE file is flagged as Trojan Mikey, however the domain it connects is also used by Trickbot. Besides, we suspect that Emotet loader uses Return Oriented Programming (ROP) to achieve polymorphism and code flow obfuscation. However, this could also be the result of modern compiler techniques.

The overall flow of this threat is like this.

Figure 1 – the lifecycle of Emotet

Initial Analysis

Around 75 percent of the security products detected the sample as malicious. Some of the security products flagged the sample as Emotet.

Figure 2 – around 75 percent of the security technologies detects the sample as malicious

 

Figure 3 - flagged as Emotet

 

Figure 4 - flagged as Emotet

 

The initial process of the Emotet is to load the first stage of the payload. The payload is embedded in the form of shellcode and is encrypted using the RC4 algorithm. The shellcode is decrypted using series of cryptographic functions. The cryptographic key is derived using MD5 hash. First the MD5 object is created and used by the ‘CryptDeriveKey’ API to generate the key. From here the shellcode is decrypted.

 

Figure 5 - calling the function to begin the hash process

 

The address 0x18F60C holds the Algorithm ID. 0x00008003 refers to the MD5 hashing algorithm. This call prepares hashing of the data.

 

 Figure 6 - creation of the CSP hash object

 

The ‘CryptHashData’ function is called to create a CSP hash object. It is interesting to note that string ‘9Ml3cd{pH#e|9z3Y@k{GnWcnlJqyJqIyrZ’ is added to the hash data before generating the key.

Finally, after the hash object is created, the shellcode is decrypted using RC4 algorithm. The identifier 0x00006801 is used and it refers to RC4 stream encryption algorithm.

Initially, the encrypted shellcode is loaded into the region 0x003E0000. As shown below, the shellcode at this region is encrypted.

  Figure 7 - the routine that decrypts the shellcode. i.e. CryptEncrypt

 

 The encrypted shellcode is placed at this region using the ‘memcpy’ routine. 

  Figure 8 - encrypted shellcode placed at 0x003E0000

 

 Once the decryption step is completed, the shellcode becomes more meaningful.

  Figure 9 - after the decryption of the shellcode

 

As with most of the shellcode, the first two instructions find the address from where it is running. From this place, add 0x53A, we notice the presence of a PE block. Probably the 0x18D3A is the size of this PE.

  Figure 10 - the disassembly view of the shellcode placed at 0x003E0000

 

We cross-verified whether this region (0x003E0000) has the execution property. The property of this memory region is set to RWX. 

  Figure 11  - the property of the region set to RWX

 

Before decryption and transferring the control, this region is prepared by allocating memory and placing the encrypted shellcode. As with most of the malware, the ‘VirtualAlloc’ family of API is called to allocate the memory region.

  Figure 12 – allocation of new region to host the shellcode

 

Before the allocation, the region 0x003E0000 was not available within the process.

  Figure 13 – the region does not exist before all this

 

 After the allocation is completed, the memory is filled with NULL bytes. The initial view of the memory region before copying the encrypted shellcode.

  Figure 14 -the view of the region after the allocation

 

 Around 19000 bytes are copied into this region. Once the copy process is finished, this region is decrypted.

  Figure 15 – the encrypted shellcode is copied

 

 As any modern malware, Emotet creates a table of addresses for various APIs that it uses. The following region holds the Addresses for various APIs.

  Figure 16 – the table of addresses for various API

 

The above table is being referenced at multiple locations. During memory allocation and decryption of first of the shellcode, the required APIs are used from the above table. To name few, the APIs ‘GetCurrentProcess’, ‘ZwAllocateVirtualMemory’, and ‘memcpy’ are called from the populated address table. As shown below.

 Figure 17 – the table of addresses referenced at 3 places

 

After the initial shellcode is sprayed, decrypted and ready to execute, the start address of the shellcode is returned and the execution continues from there.

 Figure 18 – the function returns the address of the shellcode once it is prepared

 

The return address is retrieved. The next step is to jump to this area, and this is achieved here.

 Figure 19 – the control is handed over to the new region

 

From here the shellcode takes over the control.

 Figure 20 – landing at the shellcode

 

Trickbot Loader 

There were two important regions within this shellcode. The first region objective is to load the second region. The second region is a PE binary.

The first part of the loader belongs to Trickbot family or the Emotet loader. In Ryuk ransomware incidents [3], Emotet and Trickbot were extensively used together.

The execution of shellcode starts at 0x003E0000.

 

 Figure 21 – start of execution from new loader

 

The presence of the PE file can be found by observing the values of certain registers before calling 0x003E002D. The length of this PE file is 0x18D3A. Interesting that a string ‘dave’ is found at the end of the PE file.

 

 Figure 22 – presence of PE file within the newly created region

 

 This PE file was carved out and scanned through Virustotal. Many AV software flagged it as Trojan downloader.

 

 Figure 23 – PE file scanned through Virustotal

 

The shellcode contains a Trojan downloader in its tail. Some AV software flags this as Trojan Mikey. 

The first thing the shellcode does is it calls the ‘GetNativeSystemInfo’ function to collect various information about the system. At the address 0x0018F634 the system information is stored.

After this, a new memory region (0x005D0000) is created using ‘VirtualAlloc’. The loader prepares a table of addresses for various APIs. This behavior is very common to both Emotet and Trickbot families. The table is placed within the newly created region.

 

 Figure 24 - table of various API function addresses

 

Once the table is prepared, the next step is creating the section headers. The embedded PE file has five sections. 

 

  Figure 25 – The PE header of the binary embedded

 

The loader places these sections at different offsets and set these regions with different memory protection schemes. The loader places the sections at the new region created. We could see that loader is using the PE injection technique and preparing the stage two execution.

 

  Figure 26 - the five sections are created

  

The following part of the loader ensures that all the sections are copied into the new region. The total number of regions are stored in the ‘edx’ register.

 

  Figure 27 - routine responsible for copying the image if the embedded PE

 

The newly created memory region is set to run the injected PE. The following routine ensures that.

  Figure 28 -jump to the entry point of the injected PE

 

The jump happens to 0x005D1D95. The Entry point of the PE is 0x00001D95. The PE from the shellcode was initially loaded into 0x005D0000, plus the Entry point results in 0x005D1D95. 

  Figure 29 - the Address of Entry point from the optional header

 

PE binary Payload

We have already seen that this strain drops the Mikey Trojan. The Mikey Trojan uses the Microsoft Foundation Classes (MFC) instead of Win32 APIs.

In this portion of analysis, limited behavior of the Mikey Trojan is analyzed. 

The Trojan Mikey first tries to access the folders and files that are related to internet browsing.

 

Figure 30 – list of files and folders being accessed

 

A domain is contacted for sending the information. The parts of the domain are embedded in form of multiple characters. The domain string is formed at multiple places, to avoid detection. 

 

 Figure 31 – The domain generation

 

Once the domain string is formed, it is first contacted, and the current temporary path of the system is sent.

 

Figure 32 – The connection to the malicious domain

 

It is interesting to note that the domain is also used by Trickbot to download additional payloads. 

The malware while performing its actions, also displays MS Word like window. 

 

Figure 33 – routine that opens a window

 

Figure 34 – A new dialog window is opened

 

Figure 35 – The information parsed by the malware

 

The analysis was stopped at this point, as the domain it tries to connect was taken down. We believe that the motive of the threat actors is to download more threats or to steal information.

 

IOCs

83eb9dfc97cc24aabd529f188c51fc29

f097ca21830acec50af81eca913cab33

74bfc94b3745b708cce836ea7fc2b057

a943cdbbd7491cdfd98309757a752d84

4b144015167e713fa10851ddbba1cedd

aadb5441e704d27a4dbce1a3cfb4f53943437f83cde09bccf1329f923ba1de6a

e059780280c31c7f75ca6935eb154875793cdc0b7038a0107964b8590abb09c3

qfcallc[.]com/rtsdfv.encrypted

 

Conclusion

The threat actors go at lengths to carry out their actions. Emotet and Trickbot both belongs to modern malware threats. It is very rare to see threat actors utilize combination of two different threats to meet their objectives. We did not go further from where Trickbot or Trojan Mikey tries to download the next payload, as the domain it uses to connect is taken down. We have seen that, some of the Trickbot and Emotet malwares loads the Ryuk ransomware. Both Emotet and Trickbot started their operations to steal banking credentials and soon evolved to become providing Malware-as-a-service (MaaS).