Emotet, once described as the “world’s most dangerous malware”, was first discovered as a banking Trojan in 2014 and over the years has evolved into the go-to solution for cybercriminals. What made Emotet so dangerous? It was offered for hire to other cybercriminals to install additional types of malware, such as banking Trojans or ransomware, onto a victim’s computer.
The infection occurs via a macro-enabled document file, spreading through spam emails (malspam). Emotet utilizes social engineering tricks to look legitimate and lure the victim into downloading the malicious Office file and enabling macros.
Emotet was originally designed as a banking malware that attempted to steal sensitive and private information from the victim’s computer. Later versions of the software saw the addition of spamming and malware delivery services—including other banking Trojans.
Emotet attempts to avoid detection by using a password-protected VBA project and obfuscated macros. It also uses C2 servers to receive updates. This works in the same way as the operating system updates to a PC and can happen seamlessly and without the user noticing. This allows the attackers to install updated versions of the software, install additional malware, or steal information such as user credentials and email addresses.
Considered the world’s largest malware botnet, Emotet was taken down by global law enforcement in early 2021. Unfortunately, cyber attackers don’t rest on their laurels and it was back starting November 2021.
The video below demonstrates examples of a recent Emotet attack detected and stopped by Datto SaaS Defense:
Outlining the Emotet infection process:
Datto SaaS Defense has detected Emotet via spam emails arriving at our clients, that contained a malicious docm file.
To tempt the unassuming user to enable VBA macro execution, the infected Word document shows a message requesting to ‘enable content’ in the top bar and allows the macro to run. Doing so, the VBA code runs and utilizes cmd.exe to run Powershell code, which sends the HTTP request in an attempt to fetch the Emotet payload.
The VBA project contains a ‘Document Open’ function that runs as soon as the victim opens the Office file. The ‘Document Open’ function calls a variable “dgfjalfhkaugwikgfuol3wgnacoi3u5taboi3ut5roai3u5go3wugaolisdrgfso8i7wejwdoljgf” in another function that contains an obfuscated string. There are two variable assignments in this function—the first “s2” contains a list of 7 URLs of compromised websites hosting the Emotet payload and the second “s2” contains the command to download and execute the payload. The commands can be decoded by simply performing a replace on the string “Cew” (as we can see in the screenshot below).
After removing the string “Cew” we get the decoded Powershell command that executes –
The Infection traffic for Emotet is similar to what we saw before the takedown in January 2021. As of now, only one of the URLs was active.
The Emotet DLL was first stored as a random file name with a .dll extension under the C:\ProgramData directory. Then it was moved to a randomly-named directory under the infected user’s AppData\Local folder.
Emotet gains persistence by modifying the autorun registry key “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, as shown below. This enables the Emotet payload to be executed with each reboot of the victim host.
At this point of infection, the malware communicates with multiple C2 servers. Investigation of this communication showed HTTPS requests come from various places in the world (18 different IP addresses).
As the last execution step, Emotet waits for commands from the C2 servers.
This DLL has a unique export: “Control_RunDLL”. This makes it possible to detect Emotet infections. If the process rundll32.exe was started with a parameter that matches the export, the system would be infected.
Unpacking the malware:
Emotet attempts to hide its malicious code by using a customized packer. Packed programs are a subset of obfuscated programs in which the malicious program is compressed and cannot be analyzed.
Dynamic analysis can be used to unpack it, by letting the malware do the unpacking and grabbing the next stage out of memory. The process will need to allocate memory for the next stage, so it’s a good assumption that we will see a call to VirtualAlloc. After the call to VirtualAlloc, the EDX register (.text section) will contain the base address of the allocated region.
After seeing the memory has been populated, we can dump the memory to a file.
The screenshot below shows the address where the unpacked malware is located as well as the protection level that has been allocated to that area in memory: Read/Write. This is a great indicator that this is the unpacked malware as the memory allocated for the malware needs to be executable and writable.
After dumping the file we need to clean it up by looking for the ‘MZ’ signature and removing all of the hexadecimal code appended before it. This gives us the unpacked Emotet malware.
With detection in Datto SaaS Defense, we can see the full process tree starting from a malicious docm file that spawns Powershell via CMD to the rundll32 process execution. SaaS Defense is different from other third-party solutions in that it does not rely on third-party software, signatures, or malware reports. SaaS Defense was designed to analyze the composition of a safe email, chat, or document, making its detection rates and time to detection superior to those in the market today. SaaS Defense stops zero-day threats and their invasion techniques, such as Emotet, at first encounter, without manual interference or end-client disruption.
Don’t let an Emotet attack harm your business or your clients. With Datto SaaS Defense, you can proactively protect your clients’ data with our advanced threat protection solution that detects zero-day threats at the first encounter instead of days later.
Request a demo to discover a better way to secure clients from Emotet.
This content was originally published here.