Article Blog Image

What does "bad" look like in your network? - Emotet

Network Monitoring

A large number of events happen in your systems every day. In this article, we’ll examine what “bad” events show up in the network when the Emotet malware is executed in your systems.

The network traffic sample has been downloaded from malware-traffic-analysis.net. It is an excellent site to find different types of malwares and the corresponding traffic. The specific malware sample we will use in this article were collected originally by Palo Alto’s Unit42 Threat Intelligence and Security Consulting Team.


Analyzing a PCAP

Recorded network traffic is stored in a PCAP-file, also called a packet capture. To analyze a PCAP-file a number of different tools can be used. Wireshark is probably the most known desktop application. This will visualize which packets are contained in the PCAP-file. Two other tools that can be used for PCAP-file analysis but also for continued network monitoring are Suricata and Zeek.

Suricata will take a set of signatures of known bad indicators and produce alarms by matching the indicators to the network traffic. Zeek will do general metadata extraction of network traffic and produce data about what is going on at connection level. Zeek resembles Wireshark but works on a level higher – packet streams collected to connections instead of individual packets.

In our analysis, we will use Angle by Derant, which is a SaaS platform that uses Suricata and Zeek. After uploading the PCAP-file, it will be processed by Suricata and Zeek, where it automatically can open an alarm. In this article, we will analyze and examine the raw results.

If you wish to reproduce the steps of following along while reading the article, you can sign up here for free: angle.derant.com

Raw events

By default, Angle uses the ET Open signature data set for Suricata and standard configuration for Zeek.

Signature-based events from Suricata: 824 General metadata events from Zeek: 2676 (across 14 different output file types)

Article Blog Image

Signature-based detection

Signature-based detection works by matching existing “known bad” signatures up against the traffic being analyzed. This has the strength of being a quick and easy way to produce alarms. The limitation is that it is difficult to find unknown bad events as these will not have signatures.

Signatures come in various forms, with some of the good ones having high confidence and low false-positive rate while others produce more questionable alarms with a lot of false-positives. Combining alarms can sometimes give higher confidence in bad things happening.

Alarms from Suricata / ET Open

The alarms from Suricata can be categorized in 3 categories:

1. Cobalt Strike activity

2. JA3 Dridex hashes

3. Generic Windows activity

Based on our experiences, the Cobalt Strike activity is a high signal/low noise alarm that warrants immediate action. It has a very low false-positive rate and is uniquely associated with malicious behaviour. It can be seen in pentesting exercises but should be assumed to be the real deal. Starting up the prepared incident processes for a major incident is recommended.

Article Blog Image

The Dridex JA3 hashes are also a high-risk alarm. In general, JA3 hashes have a lot of false-positive hits, which is why it is good practice to use them as a signal combined with other alarms to verify that this is a real incident.

Article Blog Image

The generic Windows activity are low-value alarms in themselves, providing low signal-to-noise ratio. These will pop up very regularly on normal networks and should not be taken as alarms you prioritize by themselves.

Article Blog Image

Anomaly detection

Anomaly detection is the detection of events that differ from a baseline. Defining a baseline requires some knowledge of the usual or correct functioning of the system that is the source of the events. We can’t define an actual baseline of this analysis, as the PCAP file is created and based on unusual behavior. What we can do, however, is to define pseudo baselines, which would catch the malware being analyzed here.

Mimicking legitimate traffic

The malware tries to hide its C2 traffic as HTTP traffic, fetching the jquery javascript library with a somewhat valid referrer. The User-Agent string varies between “Windows NT 10.0” and “Windows NT 6.3”. These events are difficult to model a baseline for as a lot of legitimate traffic fetches jquery from various sites and also as User-Agents are sometimes changed to allow browsers to get different content than is typically served to them as a workaround.

Article Blog Image

Self-signed certificates

A number of the used certificates used by the creator of the malware are self-signed. This is particularly true for the TLS connections on port 8080 where the certificate is (self-)issued to example.com. This can be an indicator in itself (and thereby actually be a signature-based detection). There are a number of seemingly legitimate certificates that are non-valid also though, so the heuristic isn’t fool-proof.

Article Blog Image

Connections and Domans

Depending on whether we want to baseline the traffic from servers or clients, using connections and domains will produce the best result in our experience. For example, if the baselined host is a server, it would usually be possible to define which egress ports and domains the server is communicating out on. Defining this would make it possible to detect the sudden surge in outbound traffic to ports 8080, 25, 465, 587, and also outbound traffic to the C2 domain for most server profiles.

An interesting observation here is that this configuration of the signature-based detection with Suricata entirely misses the spambot traffic which is observed on ports 25, 465, and 587.

Article Blog Image

Article Blog Image

Netflow vs. Zeek - problems with netflow

This malware is easier to detect as it communicates out on unusual ports for most servers. Had the malware only used port 443 - probably the most common port used by many servers when communicating outwards - it would be harder to detect. In that instance, what would be needed would be a way to differentiate TLS connections from each other. This can be done by looking at the IP being communicated to. Often this communication will be from a generic cloud provider. TLS details such as sni / server name, certificate details and JA3(s) hashes will become important. These details are not present in basic network telemetry such as Netflow but are in the Zeek output used here.

Conclusion

The Emotet sample analyzed here is rather noisy, with the payload being a mail spam campaign. Detection is definitely possible on the network level, both with signature-based and anomaly-based detection. Follow us for more analysis of both bad and good network traffic.

Author: Rasmus Have Co-founder and IT-security specialist at Derant Rasmus has 20+ years of experience doing operational blue- and red-team work in various organisations.

Tags: