Emotet: The Story of Disposable C2 Servers

Google Cloud networking in depth: Faster, more reliable connectivity with HA VPN and 100 Gbps Dedicated Interconnect
May 16, 2019
Azure Webinar Series: How to Easily Create Modern IoT Applications
May 16, 2019

Files aren’t always what they seem, but they are all special snowflakes that deserve to be admired. With the rise of modular downloaders such as Emotet also comes the rise of advanced threats such as TrickBot, Ursnif, Ryuk, and Megacortex ransomware. These attacks all start from a single breach and lead to disaster. With Emotet remaining in the spotlight, we will continue with another investigation into the Emotet ecosystem and how quick bursts of availability are not only the standard but also an effective tactic to bypass mitigation tactics such as IP ACLs and Domain filtering.

Static Analysis of the Sample

These files were examined by the SentinelOne Vigilance Team. While the file was flagged as malicious, we wanted to know a little more about what it did and how if it operates differently from other strains of Emotet we have observed. What we see is an XML file:

image of file type

The entropy of the file is around 6 so it might be hiding something of value ( keep in mind that Office documents naturally tend to have high entropy and high entropy alone does not indicate malicious content):

image of file entropy

Looking at the file headers contained within the file we can verify that this XML is attempting to mimic a DOC file:

image of file headers

Extracting Encrypted PowerShell

Now we can use OLETools to extract the embedded macro and see what this file is doing.

image of OLE tools

This macro is actually pretty huge, but if you dump it to a file it makes it easier to search results. It is heavily obfuscated, but we can see a pattern in the way it uses strings. There is an enormous amount of small strings being concatenated together using ” + ” so we can use sed to remove this part of the obfuscation:

$: sed 's/" + "//g' <Filename>

The goal here is not to make a functional script. All that I want is to be able to brute force search for strings to see what’s going on. The best place to start is always “powershell.”

$: sed 's/" + "//g' | grep -i powershell

This returns absolutely nothing, but that’s fine. The macro is not 100% de-obfuscated, so again we’re taking more of a brute force approach here. Let’s start removing letters:

$: sed 's/" + "//g' <Filename> | grep -i owershell

Looks like we got a hit:

    zkAJGDhw = "oWersheLL -e JABEAFkAaQBhAGYAUw"

Recompiling the base64 string can be a bit tedious if you do not have a proper test environment, but in this case I’ll show you the easiest method.

  • Fire up your Test Lab VM.
  • Install Office.
  • Save the malicious Doc to the VM’s hard drive and open it.
  • Open procmon.

Good old ProcMon. Use Ctrl+t to open the tree view and find WINWORD.EXE and you’ll see the PowerShell command that is spawned.

image of procmon

From here we can extract the base64 encoded command syntax:

image of base64 encoded powershell command

Now we can decode and pretty up the syntax to see what it’s doing:

image of decoded powershell command

With the exception of unique variable and URLs this is an extremely common Emotet dropper command. It typically will contain 5 hard coded URLs to fetch the final payload from:

image of decoded URLs

Having multiple URLs to pull from not only allows for failover logic but also can be used for rapid alterations to the host IPs with a quick change of the DNS record. If your networking equipment is not capable of filtering at the DNS level and relies solely on IP, these attacks will surely go undetected and will remain easily bypassed.

Verifying C2 Servers, Searching for Additional Payloads

We can use cURL to make head requests to the URLs and see what’s still active:

image of 1 using curl

The above URL does have a 302 redirect but does ultimately return a 200 response for the Emotet payload.

image 2 of using curl

This second URL is no longer serving the payload. The 403 forbidden response suggests it is potentially still active, but note that a 403 can also be due to the hosting provider taking down the content.

image 3 of using curl

This third URL is no longer serving the payload but is potentially still active as indicated by the 404 response code.

image 4 of using curl

It would appear that the fourth URL is also still actively serving the Emotet payload.

image 5 of using curl

The fifth and final URL is showing the same behavior as the second and third URLS.

Of the two that are still active, we do get the final payloads:

image of shasum of payload

Both files are known and appear to generally be related to Emotet:

Executing the Payload

The initial process is terminated after re-initializing itself:

image of terminated process

The payload is executed; it will duplicate itself to the User’s “AppData” folder under a new name.

image of executing payload

Persistence is then established via the Registry:

image of persistence in registry

The key executes the newly created payload in the User’s AppData folder:

image of registry editor

Finally the secondary process is terminated and the cycle is repeated with the duplicate payload from the User’s AppData folder:

image of second process terminated

Sometimes this is easier to understand when reviewing the basic Procmon process tree:

image of procmon tree

After this, it will simply put itself in a loop connecting to a few different remote sites; however, there is one thing that really stands out. Multiple attempts to connect to a remote server over FTPS:

image of ftps requests

These connections are important to note because they are allowing not only the possibility of encrypted file downloads but also encrypted data exfiltration.

With the help of a few other tools like RiskIQ you can check the IP’s history:

image of IP history

RiskIQ is a great resource for checking unknown Domains/IPs. If you are lucky enough to pair it with VT the two really are great for recon work.

Revealing Disposable Servers

From this data we can see some very odd behavior. The server behind this IP is really only available for one to four days at a time with long gaps in between uptime. There are also a slew of hashes associated with this IP and upon review they all appear to not only be malicious but also appear to be classified as Emotet.

image of virus total detections

While this payload has a different hash the basic behavior is identical:

image of 200.exe
image of create file
image of tcp connections

These short bursts of availability allow the Command and Control server to remain under the radar. With the exception of a widespread outbreak these network calls can often go overlooked if they only occur for a few days. A singular infection can give rise to a larger attack vector if the attacker can manage to bypass traditional endpoint protection products while keeping their network traffic to a minimum.


Emotet continues to evolve in response to mitigation tactics deployed by defenders and security tools. In these samples, we’ve seen how the threat actors spin up short-lived servers for brief bursts of activity and then take them down for long periods. These small blips in an otherwise flat line of inactivity could easily be missed by some security software solutions, particularly those that generate separate alerts for every event. A single alert indicating short-lived, network traffic like this could easily get lost in a blizzard of other alerts. To avoid that possibility, use an automated, ActiveEDR solution like SentinelOne that never misses a thing and contextualizes all attacks into an entire storyline. If you’re not already protected by SentinelOne, contact us for a free demo.

Like this article? Follow us on LinkedIn, Twitter, YouTube or Facebook to see the content we post.

Read more about Cyber Security

Leave a Reply

Your email address will not be published. Required fields are marked *