Emotet: How It Might Infect Your PC (Part 1 of 3)
This is Part 1 of a 3-part series. Read part 2 here.
The most prolific malware that Bromium has been seeing in customer environments over the last three months has been Emotet. Since this appears to be the preferred malware campaign of the moment, I wanted to give a technical breakdown on how your PC might get infected by Emotet.
I won’t drill into every detail of exactly how Emotet works once it has taken hold of your system, that can be a topic for another time, but a quick high-level summary of Emotet is probably useful. Emotet is an executable that was originally created as a banking trojan. However in recent years it has evolved into a much more damaging distribution network for malware. Once the machine is infected, it can be used to perform email spam campaigns or to download other malware samples. Emotet is a very professional campaign, fully polymorphic, so signature look-ups are not likely to be effective.
When assessing the level of risk that Emotet poses to the enterprise, it is important to understand that because Bromium sits at the bottom of the security stack, it is only able to detect Emotet if it has been missed by every other security tool in the stack. If other security products, such as AV or perimeter defences, see the attack first, the file would be quarantined before it could reach Bromium. Our threat intelligence service is seeing a high volume of this attack in the wild, which indicates that the campaign is changing fast enough to be able to sneak past other defences on both the endpoint and the network.
The Infection Lifecycle
Emotet is principally delivered as part of an email phishing campaign. The user would receive a reasonably well-constructed email which claims to have an invoice, order, or unpaid bill. The user opens the document, which could be one of many malware types. The document will then invoke a batch script, followed by a PowerShell, to cycle through a number of URLs for hijacked websites to download the Emotet payload. The payload will run, persisting itself, and then get on with the job of being evil.
For this post I am going to work through the process that an evil document uses to infect your machine with Emotet.
In this example, the document comes in as an attachment to an email claiming to be about a large order the recipient has supposedly placed. The attachment is called ORDER_DETAILS_FILE.doc.
The document is constructed with a set of obfuscated macros which seem to remain mostly unchanged between attacks. The document itself uses a little social engineering in case the document has opened in the Microsoft Office Protected Mode by requesting that the user enables editing in order to be able to view or edit the document.
In the top left corner of the document is a tiny text box (Highlighted by a red circle in the image), so small it almost looks like a dead pixel on your screen. This edit box is where the changes for each malware infection are made. If you were to expand it, you would find the command line instructions that later get run in cmd.exe. The Macro grabs the contents of the edit box and then calls cmd.exe, passing the content of the edit box as a parameter.
The Batch Script
The command line is an obfuscated blob of batch script. It makes heavy use of environment variable expansion to build up the command it wants to run. This obfuscation serves two purposes: it makes it very hard for static analysis tools to figure out what the batch script is trying to do (which allows it to evade certain detection techniques), and it also gives a rudimentary but effective way to stop the malware executing in environments that are not standard, thus providing some additional anti-analysis capability.
An example of this can be seen in the batch script above (which has been de-obfuscated) where the environment variable “SESSIONNAME” is used in the first line of the script. When expanded, some letters of the content of this variable are used to build up the word PowerShell. If the environment variable is set to an unexpected value, the batch script will fail to build up the word “PowerShell”, and the malware will stop working. In a normal session, the value is “Console”, while in an RDP session, it would be something like “RDP-Tcp#1”. This allows the script to test very quickly if a real user session is running or if the document is being run from RDP session which is something a malware analyst might do. Sneaky.
The Batch script eventually produces a PowerShell script which is then invoked. This script cycles through a list of five URLs which have been highjacked to attempt to download the payload. It goes through each URL until it finds one that still has the payload available and then downloads “420.exe”. We have found that the actual numbers vary from one document to another, but generally it is always a three digit number for the name of the exe. The executable in our example downloads into C:\Users\Public, although in other samples we saw it download into C:\users\%username%\AppData\Local\Temp.
The Emotet is Running!
At this point, Emotet is running. To persist itself, it copies (and renames) the exe from the download location into C:\Windows\SysWOW64\reswalaska.exe. What happens next is a topic for another blog, but if Emotet has got this far, it now owns your system. The image below shows how the processes above link together to get to this point:
For an endpoint running Bromium Secure Platform, an attack of this kind is isolated within a uVM and thrown away as soon as the Word document is closed by the user. Provided that Bromium Secure Platform remains installed and enabled, there is no required remediation step. It is however good practice to remove the document from the machine anyway, just to prevent the file from being transferred to another machine.
It would also be prudent to remove the email from the mail server to avoid it accidentally being forwarded to another user or organisation which is not protected. It should also be removed if the user saved the file to the local file system, USB stick or a network file share. None of this is required, but it would be good practice.
What To Do for Endpoints Where Bromium Isn’t Installed
Is it recommended to remove the email from the mail server to avoid it accidentally being forwarded to another user or organisation. It should also be removed if the user saved the file to the local file system, USB stick or a network file share.
Machines which do not have Bromium Secure Platform should be checked for the Emotet payload itself which may reside in the following locations:
As a way of spotting if a machine has been infected, it might be possible to search proxy logs for the domains that the malware attempted to download the payload to. This will only be effective if there is already access to a sample to extract the domains from. This should be easy to do for a Bromium customer after malware has been detected inside the VM, as a precaution against it spreading to other endpoints that are not protected by Bromium.
At time of me writing this blog, at least one of these domains is still serving the malicious payload, so these links should be treated with care:
If signs of malware are spotted, it is best to isolate the computer from the network and reimage. Emotet can be used to download other unknown malware, and while relying on a scan from AV will eventually spot Emotet itself, it may take more time before whatever payload Emotet delivers is also detected.
Read Part 2 of this 3-part series, Emotet: Catch Me If You Can. Part two breaks down the behavioral analysis of a phishing campaign delivering Emotet, and takes a deep dive into its ability to drop a payload by running an obfuscated VBA macro from a Microsoft Word document.