New Wave of Emotet – When Project X Turns Into Y

A Brief History of Emotet

Emotet threat group members collaborated in the past with Trickbot’s operators by deploying each other’s payloads during infections. Before the takedown, the Emotet kill-chain flow consisted of dropping Trickbot’s payload which led to ransomware infection by Ryuk (CONTI). The first indication of the return of Emotet on Nov 15, 2021, was discovered by cyber security researchers that noticed that Trickbot payloads are dropping Emotet’s loader. After a month, on December 15, we discovered that Emotet started deploying Cobalt Strike beacons on the compromised hosts. This is new behavior of Emotet might indicate that additional new capabilities and strategies might be used as well.

Summary

Since the return, Emotet struck with a diverse arsenal of TTPs, such as malicious documents, in both Word and Excel formats, that contain either VBA or XLM macros. Likewise, we also observed different LOLBins abused by Emotet such as mshta, PowerShell, wscript, rundll32, and more. We will cover the changes (TTPs) Emotet underwent since its return in November 15 in a separate article. In the current article, we will review the recent (February 21, 2022) Emotet campaign’s infection activity which consists of new TTPs and the new Y.dll payload.

Initial Access and Execution Flow:

Initial access was delivered via malspam email with an attachment of password-protected zip that contains an Excel malicious document. We have observed two types of Excel documents, one has protected VBA macro and the second has XLM version 4.0 macros. In both cases, the user needs to enable macros to start the infection. Shown in figure 1-2:

The document with the XLM macros

Figure 1: Shows the Emotet malicious document XLM macro, hidden sheets and AutoOpen function

Figure 1.1: Shows XLM macro code that utilizes native API functions to download and execute Emotet payload

The document with the VBA macros

Figure 2: Shows the Emotet malicious document with a new fake message that deceives the user to enable the VBA macros

Figure 2.1: Shows the protected malicious VBA macro code

Figure 2.2: Shows obfuscated VBA macro code from the Workbook_Open function

After the user enables the macros to run (User Execution, T1204), the infection continues with the execution by abusing LOLBins. Same as before, each document has its unique flow as explained below:

The document with the XLM macros

As shown in figure 3, the execution continues with the abuse of the LOLBin (Living Off the Land Binaries), regsvr32:

Figure 3: Execution flow of the XLM macros document

We observed a repeated pattern in the regsvr32 command lines in all the samples that we analyzed.

In case the document is not opened with an Administrator privilege, as part of the execution, the payload is copied and executed from the %LOCALAPPDATA% directory:

regsvr32.exe /s ..\{random_payload_name}.ocx
└── regsvr32.exe /s “C:\Users\{user_name}\AppData\Local\{random_directory}\{random_payload_name}.{random_extension}”

In case the document is opened with an Administrator privilege, as part of the execution, the payload is copied and executed from the SysWoW64 directory in %WINDIR%:

regsvr32.exe /s ..\{random_payload_name}.ocx
└── regsvr32.exe /s “regsvr32.exe /s C:\Windows\SysWOW64\{random_directory}\{random_payload_name}.{random_extension}”

All the patterns above can be used for both threat hunting and detection purposes.

The document with the VBA macros

As shown in figure 3, the execution continues with the abuse of the various LOLBins:

Figure 4: Execution flow of the VBA macros document

Also here, we observed a repeated pattern in the command lines of the LOLBins that take part in the execution flow.

wscript c:\programdata\{random_payload_name}.vbs
├── powershell.exe -command …
└── cmd.exe /c start /B c:\windows\syswow64\regsvr32.exe /s c:\programdata\{random_payload_name}.dll
———-└── regsvr32.exe /s c:\programdata\{random_payload_name}.dll
———————└── regsvr32.exe /s “C:\Users\{user_name}\AppData\Local\{random_directory}\{random_payload_name}.{random_extension}”

The VBScript code, which is executed by wscript, and the PowerShell command are shown in figures 5 and 6:

Figure 5: Shows the VBS (Visual Basic Script) file contents that are is obfuscated by the replace method and concatenation. This is the code that eventually executes the PowerShell command

Figure 6: Shows the PowerShell command that executed as a one-liner via the PowerShell process

The above PowerShell command is responsible for both downloading the Emotet payload from a list of compromised URLs. The execution of the Emotet payload is performed by the CMD process.

Persistence and Privilege Escalation

After the Emotet payload is copied to a new location (%WINDIR%/SysWoW64 or %APPDATALOCAL%), it attempts to create persistence on the compromised host. The payload utilizes different persistence techniques and the differences between them is based on the user privilege.

In the unprivileged case, the payload achieves persistence by creating a Run key in the Registry (Boot or Logon Autostart Execution: Registry Run Keys, T1547.001), as shown in figures 7.1 and 7.2:

Figure 7.1: Shows the Registry Run key with the payload execution command

Figure 7.2: Shows the Emotet payload in the %APPDATALOCAL% path

In the Administrator-privileged case, the payload achieves persistence by creating a service (Create or Modify System Process: Windows Service, T1543.003), as shown in figures 8.1 and 8.2:

Figure 8.1: Shows the service’s key in the Registry which contains the payload execution command

Figure 8.2: Shows the Emotet payload in the SysWoW64 path

Differences between Project X and Project Y

In the previous campaign, Emotet’s core module was named X.dll. In the new campaign (February 21, 2022) We have observed a different name for the core module, Y.dll. The core module comes with the export function DllRegisterServer. This naming convention could be an indicator for new Emotet variants. We are still investigating this assumption.

Both X.dll and Y.dll core modules are unpacked inside regsvr32 memory and can be extracted from it, as shown in the figure below:

Figure 9: Shows the unpacked Emotet payload inside the memory

We have compared both core modules, X.dll and Y.dll, and found some differences, as shown in figures 10-11:

Figure 10: Shows X.dll with the time stamp 31.01.2022

Figure 11: Shows the Y.dll with the time stamp 21.02.2022

As can be seen in figures 12-13, both core modules are exporting the DllRegisterServer function, which is executed by the regsvr32 as part of the execution flow:

Figure 12: Shows the DllRegisterServer export function inside X.dll

Figure 13: Shows the DllRegisterServer export function inside Y.dll

MITRE Techniques

Spearphishing Attachment – T1566.001

Windows Command Shell – T1059.003

PowerShell – T1059.001

Visual Basic – T1059.005

Dynamic Data Exchange – T1559.002

Native API – T1106

Malicious File – T1204.002

Registry Run Keys / Startup Folder – T1547.001

Windows Service – T1543.003

Service Execution – T1569.002

Regsvr32 – T1218.010

Indicators of Compromise

Distribution URLs

Emotet C2 servers