Cynet's 24/7 MDR with the latest security updates and reportsDownload the Cyops Solution Brief
By: Max Malyutin
Over the last couple of days, Cynet CyOps and Research teams have been engaged in another wave of the infamous Emotet trojan. This time, with some tweaks and changes under its belt, Emotet keeps reminding us that it is here to stay.
In this article I will briefly cover the Emotet banking trojan evolution over the years followed by discoveries in the recent Emotet malware wave observed by Cynet CyOps.
According to statistics provided by MalwareBazaar and ANY.RUN, Emotet banking trojan is now in the infamous first place of the most popular threats:
The first Emotet banking trojan sample was identified in 2014 and was classified as a trojan that steals banking credentials by hooking Internet traffic of the online banking sessions. Over the years, Emotet has upgraded its capabilities and modules.
Since 2017, Emotet has been observed as more than a banking trojan and seems to have evolved into the most dangerous “Dropper”. Emotet packs some extremely sophisticated capabilities utilizing different tactics, techniques, and procedures (TTPs), which turned it into the “most serious” threat up until today.
In 2019, Emotet became the most common module in the spread (botnet infrastructure) of banking trojans and ransomware such as Trickbot, Qbot, Ursnif, Ryuk, and Megacortex. You can find additional references in our article covering the 2019 Emotet wave.
Points to note regarding recent malware:
After a short period of time with little activity, a new wave of Emotet campaigns strike again. This Emotet threat actor uses a new chain of execution that has evolved and switched the EXE file of the Emotet binary to a DLL file, which is loaded through the Rundll32 process. In addition, Emotet has now added fake error messages to weaponized Microsoft Office documents.
Over the past few days we discovered yet another wave of Emotet that lures its victims by spreading phishing emails with Christmas Day cards and COVID-19 report attachments. In most cases the observed phishing emails were in Italian, English, and German.
Emotet threat actors are abusing the COVID-19 epidemic and have invested significant resources in social engineering to lure victims to open and execute the attachment doc file inside the phishing email.
Cynet360 detection mechanisms can detect and prevent both the new Emotet wave as well as the old ones!
A fake Microsoft Office document error message:
The Cynet360 platform has become intimately familiar with Emotet trojan activities in the last few years and provides full protection and prevention capabilities against these Emotet waves as demonstrated here.
The following is one of the latest samples of Emotet Malicious Office Document and DLLs that were detected by Cynet360:
Additionally, CyAI (Cynet’s built-in NGAV solution) classified a “fresh” Emotet DLL binary as malicious and scored it 100/100. This Emotet detection sample was uploaded to VirusTotal on 22/12/2020.
The following new Emotet campaign activities were detected by Cynet 360 recently in European regions, mainly in Italy:
Cynet detected malicious Emotet activity and triggered a high severity alert.
Emotet process tree flow:
The Cynet 360 platform enables our customers to perform a remote action on the malicious file or on the infected host.
File/Process actions can be sent when a malicious file is detected.
These actions immediately delete/quarantine/kill the file/process from all the infected hosts.
There are more actions that our customers can use such as sending suspicious/malicious files to our CyOps team, sending the files to Cynet’s internal sandbox, or pulling the files from the host.
Furthermore, there is a range of remedial actions related to the hosts that can be used in the event of an incident response investigation:
This time, it seems that Emotet’s new wave goes back to its origins, dropping the Trickbot banker trojan on the infected hosts.
Initial Access T1566.001—Phishing: Spearphishing Attachment:
The most common initial foothold on a victim’s machine are Spearphishing emails.
MITRE – “Adversaries may send spearphishing emails with a malicious attachment in an attempt to gain access to victim systems. Spearphishing attachment is a specific variant of spearphishing. Spearphishing attachment is different from other forms of spearphishing in that it employs the use of malware attached to an email.”
“Who needs Zero-days when you have Outlook?”
The Emotet campaigns begin with a malspam email that contains Malicious Office Documents (weaponized Microsoft Office documents), or hyperlinks attached to the phishing email, which is widely distributed and lures victims into opening malicious attachments. The weaponized Office document has a highly obfuscated VBA code and AutoOpen macro for its execution. The Emotet group lures its victims to enable the macros and this is the only user interaction required to initiate the attack. This user interaction enables bypassing sandboxes tests and verifications.
MITRE ATT&CK MATRIX – Emotet TTPs
In most cases, the initial stage consists of a Word document weaponized with a malicious VBA macro code or variability, which is used to exploit, for example, the EQUDENT exploit.
The main purpose is to download or drop a second loader.
The general flow of the initial stage is as follows:
Malicious word document –> macros are executed by autoopen() function –> High obfuscation macros –> next stage (second loader)
Emotet weaponized Microsoft Office document analysis:
Emotet actors attached an embedded image to the body of the document of a fake Office 365 message, “THIS DOCUMENT IS PROTECTED” that requested the victim to click on the “ENABLE EDITING” link to disable Microsoft Word read-only mode and then click on “ENABLE CONTENT”. The enable content then automatically executes the malicious obfuscated VBA code.
Malicious Office Document attachment of Emotet from 22\12\2020:
Malicious Office Document attachment of Emotet from 2/April/2020
ENABLE CONTENT security warning:
The fake office 365 message:
Emotet contains highly obfuscated VBA code extracted using the OLEVBA tool as there are too many macro streams in the Emotet Malicious Office Documents. The interesting function that popped up Document_Open() enables the macro to run. The OLEBVA description for the Document_Open() function runs when the Word or Publisher document opens.
Emotet actors use a different technique of hiding malicious code/strings such as URLs, IPs, commands, or even shellcode inside the malicious document. They use the UserForms object.
UserForm is a window or dialog box.
Highly obfuscated VBA functions:
Once the Enabled Content is clicked by the victim, the malicious VBA code executes and the following error pops up:
This message seems to be part of the Office Microsoft application, but it is a fake error message that is popped up by the malicious VBA code, which is described in more detail below.
Most of the malicious documents open either a CMD child process, a PowerShell, or a malicious EXE.
In this case, the Emotet actors used a sophisticated technique of execution enabling them to bypass a basic detection rule that checks for child processes of Office applications.
By using a monitoring tool, we have figured out that the Emotet execution uses the “not my parent” technique enabling it to break the process tree execution.
As we can see, no child process was created by the malicious document, with zero results for “process creation”:
We know that in the last year, all Emotet waves used WMI tasks for processes by using Win32_Process and Win32_ProcessStartup classes, which enabled them to create new processes.
This technique is deployed to avoid behavioral detection of the parent and child processes.
Emotet VBA code – 2/4/2020:
We found that Emotet uses a WMI class to spoof the process execution tree that the created process then executes under WmiprvSE.exe.
WmiprvSE.exe is a DCOM server and is spawned under the DCOM service host svchost.exe, which is executed with the following parameters:
C:\WINDOWS\system32\svchost.exe -k DcomLaunch
Emotet new wave process tree flow:
Emotet process tree execution from 2\4\2020:
The infection process starts with the cmd.exe process that runs the following command:
This command contains two execution phases. The first one is the msg %username% /v Word experienced an error trying to open the file, and the second is a PowerShell command.
This is the fake message that pops up when we executed the malicious document:
PowerShell instance executed with the following bas64 command:
After decoding the base64 format we found a high PowerShell command.
The obfuscated PowerShell code attempts to download the Emotet from different domains. The Emotet binary downloads a new directory in the user path and the Emotet payload this time is a DLL file.
23/12/2020 The Emotet executed via Rundll32 command:
Malicious Emotet distribution URLs list:
End of 2019, the Emotet PowerShell command looked as follows:
Emotet execution via [Diagnostic.Process]::”Start command
Early 2020, the Emotet PowerShell command looked as follows:
Emotet execution via ([wmiclass]’win32_Process’).”cReATe” command.
We know that the PowerShell command is responsible for downloading the Emotet payload. When monitoring the network traffic, we found the following HTTP TCP packet:
Here we can see one of the URLs that we spotted in the PowerShell command:
Also, we found that the PowerShell instance writes a new file (Emotet payload). This activity is part of the PowerShell command.
Emotet DLL metadata:
The Emotet DLL is executed through the Rundll32 by using “#1” that executes the first function.
Normally the use of rundll32 is to provide the function name.
The next process is another Rundll32 instance, but this time we have a different file located in the AppData\Local\ directory and the file extension is “knn” and not a DLL.
Emotet renamed and copied the initial DLL to a new location.
The new dropped payload:
Example of anther Emotet new wave sample:
Emotet gains persistence by modifying the autorun registry key “Computer\HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Run”
creating a new value with a random name and configuring the Rundll32 to execute the Emotet payload.
This enables the Emotet payload to be executed with each reboot of the compromised host.
The following screenshot is another new Emotet wave sample that we investigated in our labs.
The new instance of the Rundll32 stays alive and every few minutes sends a POST request to different C2 (Command & Control) servers. This is the final stage of Emotet before it downloads the next stage payload. As mentioned above, the new Emotet wave drops the Trickbot banking trojan on the infected host.
For example, Trickbot created (downloaded) by the Rundll32 instance:
With each new wave, Emotet proves it can evolve and adapt in face of the ever-growing efforts to detect and block its malicious activities. Cynet expects this trend to continue as Emotet provides a highly capable and malleable “platform” from which threat actors are able to craft innovative changes that refresh the malware’s ability to avoid detection.
Fortunately, Cynet detection mechanisms, coupled with ongoing research by our CyOps team ensure that Cynet customers will continue to be protected from this, and future waves of Emotet. Cynet’s CyOps team is always available to answer any questions or provide any support needed for Cynet’s customers.