Emotet: The Story of Disposable C2 Servers

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:

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):

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

Extracting Encrypted PowerShell

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

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.

From here we can extract the base64 encoded command syntax:

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

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:

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:

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

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.

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

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

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:

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

Executing the Payload

The initial process is terminated after re-initializing itself:

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

Persistence is then established via the Registry:

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

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

Sometimes this is easier to understand when reviewing the basic Procmon process 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:

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:

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.

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

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.

Conclusion

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