Deconstructing the Emotet C2 Protocol

Introduction

Emotet, first identified in 2014, has evolved significantly from its origins as a banking trojan into a premier Malware-as-a-Service (MaaS) infrastructure. Its primary function in the modern cybercrime ecosystem is to serve as a distribution network, providing initial access for other secondary payloads, including other banking trojans like TrickBot and Qakbot, and other precursors to ransomware attacks.

This report provides an exhaustive, network-centric analysis of the Emotet malware. The focus is exclusively on its “on-the-wire” characteristics: its command-and-control (C2) architecture, its communication protocols, and the network behaviours of its key modules. Endpoint artifacts and host-based indicators are deliberately omitted to serve the specific needs of network defenders, threat hunters, and intelligence analysts who are tasked with detecting and mitigating this threat at the network level.

The history of Emotet is marked by continuous evolution and a significant law enforcement takedown in January 2021, which serves as a critical demarcation point for analysis. This event, dubbed “Operation Ladybird,” provided a temporary reprieve, but the botnet’s re-emergence in late 2021 underscored the resilience of its design and the persistence of its operators.

The Emotet C2 Infrastructure

The Tiered Command Structure

Emotet’s C2 architecture is not a flat hierarchy but a multi-tiered system that obfuscates the true location of its core control servers. This design creates significant redundancy and makes it difficult for defenders to neutralize the entire botnet by targeting a few central points.

The infrastructure is primarily composed of three distinct tiers.

“Bot C2s” (Tier 1 Proxies - Infected Peers)

A crucial element of Emotet’s resilience is its use of other infected victim machines as a foundational C2 layer. These “Bot C2s” are not dedicated servers but are regular computers compromised by Emotet that have been co-opted into the botnet’s C2 fabric. They function as a vast, distributed network of proxies, relaying C2 traffic from newly infected bots toward the next tier.

Analysis by Lumen’s Black Lotus Labs revealed that at times, these Bot C2s, often located in dynamic broadband IP ranges across regions like Latin America, constituted over 80% of the active C2 IPs. Their ephemeral nature - constantly changing as machines are powered off or cleaned - makes traditional IP-based blocklisting an ineffective long-term strategy.

Tier 1 C2s (Tier 2 Proxies - Compromised Webhosts)

The next layer consists of legitimate but compromised web servers. These servers, often running common web server software like NGINX or Apache, act as a more stable, second layer of proxies. Their legitimate history and generally clean IP reputation help Emotet’s initial communications blend in with normal web traffic, evading reputation-based security filters. Traffic from the Bot C2s is forwarded to these Tier 1 servers.

Tier 2 C2s (Core Controllers)

This is the command layer from where the actual operators manage their assets and issue commands. Traffic from both the Bot C2s and Tier 1 C2s is ultimately forwarded to these core servers.

Identifying these Tier 2 servers requires large-scale network traffic analysis, as defenders must trace the outbound communications from a large, distributed pool of Tier 1 proxies to find common destinations.

Research from NTT Security successfully employed this method, identifying Tier 2 servers by their common web server configurations (e.g., NGINX on port 80 and Apache on port 8080) that were receiving traffic from numerous Tier 1 proxies.

This tiered architecture places a significant analytical burden on security researchers and law enforcement, requiring them to peel back multiple layers of proxies, many of which are transient, to uncover the core command infrastructure. This design demonstrates a clear understanding of defensive tactics and a proactive approach to building a botnet that can survive sustained disruption efforts.

The UPnP Module: Weaponizing Infected Hosts

The mechanism by which Emotet transforms a vast number of its victims into functional “Bot C2s” is its Universal Plug and Play (UPnP) module. UPnP is a set of networking protocols that permits networked devices to seamlessly discover each other’s presence on the network and establish functional network services. When Emotet infects a suitable host, it can deploy this module, which programmatically communicates with the local network’s gateway device (typically a SOHO router).

The module instructs the router, via the UPnP protocol, to open a port on its external-facing interface and forward all inbound traffic on that port to the newly infected Windows host. In other words, it uses port forwarding to effectively expose the compromised machine to the public internet, allowing it to accept connections from other Emotet bots and act as a proxy. This automated process is the engine that builds and maintains the massive, distributed “Bot C2” tier, ensuring a constant supply of new proxy nodes without any manual intervention from the operators.

Botnet Segmentation: The “Epoch” System

The Emotet botnet is not a single, monolithic entity. It is strategically divided into distinct, separately managed sub-botnets known as “Epochs”. Historically, these have been identified as Epoch 1, 2, and 3, with new Epochs 4 and 5 emerging after the 2021 takedown.

Each Epoch operates with its own independent infrastructure, including distinct sets of Tier 1 and Tier 2 C2 servers. Analysis has confirmed that there is no cross-communication between Epochs; for example, a Tier 1 C2 from Epoch 1 will only ever forward traffic to a Tier 2 C2 from Epoch 1.

This segmentation provides several strategic advantages to the operators:

• Resilience: A disruption or takedown of one Epoch’s C2 infrastructure does not impact the operation of the others. This decentralization makes a complete, simultaneous takedown of the entire Emotet operation exceptionally challenging.
• Operational Control: It allows operators to manage different sets of victims separately, potentially based on geography, victim type, or the specific campaigns they are used for.
• A/B Testing: Operators can test new malware versions, modules, or delivery techniques on a single Epoch without risking the stability or effectiveness of the entire botnet.

Post-Takedown Reconstitution: A Phoenix from the Ashes

In January 2021, a coordinated international law enforcement action, “Operation Ladybird,” successfully disrupted the Emotet infrastructure. Authorities seized control of the botnet’s C2 servers and, in a novel move, used the malware’s own update mechanism to push a custom module that would uninstall Emotet from infected hosts on April 25, 2021.

Despite this comprehensive action, Emotet re-emerged in November 2021, approximately 10 months after the takedown. The rebuilding of the botnet demonstrated the operators’ persistence and their symbiotic relationship with other major players in the cybercrime ecosystem. The new Emotet loader was initially distributed via the existing TrickBot botnet, which served as a delivery platform to seed a new generation of Emotet infections.

This rapid reconstitution involved establishing entirely new C2 infrastructure, which researchers quickly categorized into new Epochs (Epoch 4 and 5). The ability to leverage another major botnet for its rebirth highlights the interconnected and collaborative nature of modern cybercrime, where different threat actor groups provide services to one another, creating a resilient and dangerous ecosystem.

Dissecting the C2 Communication Protocol

Protocol and Port Analysis

Emotet primarily uses HTTP and HTTPS for its C2 communications. While it utilizes standard ports 80 (HTTP) and 443 (HTTPS), it frequently operates on a range of non-standard ports to evade basic port-based firewall rules and security solutions that may not inspect traffic on these alternative channels. Commonly observed non-standard ports include 7080, 8080, 8090, and 50000.

A particularly high-fidelity indicator of Emotet activity is the misuse of these protocols. Analysis from Sophos has shown that Emotet often sends unencrypted HTTP GET requests to ports normally reserved for encrypted HTTPS traffic, such as port 443.

Evasion via Encapsulation: C2 Communications within HTTP Cookies

One of Emotet’s most innovative evasion techniques is its method of data exfiltration. Instead of placing stolen data or bot status information in the body of an HTTP POST request - a field commonly monitored by Data Loss Prevention (DLP) systems - Emotet encapsulates its C2 data within an HTTP Cookie header.

The malware sends a standard HTTP GET request to one of its C2 servers. The entire malicious payload, after being serialized and encrypted, is Base64-encoded and placed as the value of the Cookie header. From the perspective of a simple packet inspector or firewall, this traffic appears to be a benign GET request from a web browser presenting a session cookie. This masquerading technique is highly effective at bypassing security controls that are not configured to inspect the content and length of cookie headers for anomalies.

Data Serialization: Protobuf Structure

To structure its C2 messages, Emotet uses Google’s Protocol Buffers (Protobuf), a binary serialization format that is efficient and not human-readable without a predefined schema. This choice makes casual analysis of captured traffic difficult and requires reverse engineering of the Emotet binary to understand the data structure.

Analysis has revealed a nested packet structure. A “base packet” contains the core data, which is structured as a series of entries. Each entry is tagged with metadata (a bitfield indicating the data type and an index number) and the data itself. This base packet is then encapsulated within a final “outer” packet for transmission.

The data serialized in the initial check-in beacon serves as both a heartbeat and a system profile, allowing operators to inventory and assess their compromised assets.

The Evolution of Emotet’s Cryptography

The cryptographic scheme used to protect Emotet’s C2 communications has evolved, with the 2021 takedown serving as a clear catalyst for significant architectural changes.

Pre-Takedown Implementation: RSA and AES

Prior to the 2021 takedown, Emotet employed a standard and robust hybrid encryption scheme.

• Asymmetric Encryption: The Emotet binary contained a hardcoded public RSA key belonging to the C2 infrastructure.
• Symmetric Encryption: For each communication session, the malware would dynamically generate a symmetric AES-128 key.
• Process: The Protobuf-serialized data was encrypted using the session-specific AES key. The AES key itself was then encrypted using the hardcoded RSA public key. The final payload sent to the C2 server contained both the RSA-encrypted AES key and the AES-encrypted data. This ensured that only the C2 server, which possessed the corresponding RSA private key, could decrypt the session key and, subsequently, the message’s content.

Post-Takedown Implementation: Elliptic Curve Cryptography (ECC)

Following its re-emergence in late 2021, Emotet was observed using a new, more modern cryptographic stack based on Elliptic Curve Cryptography (ECC).

• Key Exchange: The new version uses Elliptic Curve Diffie-Hellman (ECDH) for key exchange. The malware contains an embedded ECDH public key for the C2. To initiate a secure session, the bot generates its own ephemeral ECDH key pair, computes a shared secret with the C2’s public key, and then derives a symmetric AES key from this secret using a Key Derivation Function (KDF).

• C2 Response Verification: A critical addition in the post-takedown version is the use of the Elliptic Curve Digital Signature Algorithm (ECDSA) for C2 response verification. The malware now contains an embedded ECDSA public key. It uses this key to verify a digital signature attached to any response from the C2 server.

  This ensures that the bot will only accept and execute commands from a server that possesses the legitimate private ECDSA key. This change is a direct countermeasure to the tactic used in the 2021 takedown, where law enforcement pushed a malicious module to the bots from seized C2 servers. With ECDSA verification, such a hostile takeover of the C2 channel is significantly more difficult, as the authorities would need to possess the operators’ private signing key.

The shift to ECC represents a significant operational security upgrade. It not only provides cryptographic strength comparable to RSA with smaller key sizes and better performance but, more importantly, adds a layer of authentication that was missing, directly addressing the vulnerability that led to its previous disruption.

Network Behaviours of Key Emotet Modules

Emotet’s modular design allows it to perform a variety of malicious activities, each with its own distinct network footprint.

The Spamming Engine: Network Patterns of Malspam Distribution

Emotet’s primary method of propagation is through massive, sophisticated malspam campaigns. This is not a simple spamming function but a closed-loop system that fuels its own growth.

Email and Contact Stealing

Emotet deploys specialized modules to steal data from victims’ email clients. Initially targeting Microsoft Outlook, post-takedown versions added a module for Mozilla Thunderbird

These modules parse local email storage files, exfiltrating entire email bodies, subject lines, and contact lists. This stolen data is then sent back to the C2 infrastructure using the standard encrypted C2 channel.

Email Thread Hijacking

The exfiltrated email data is the cornerstone of Emotet’s highly effective “email thread hijacking” tactic. The spamming module uses this data to craft new phishing emails that appear as replies within existing, legitimate email conversations.

This makes the malicious emails appear highly credible to recipients, dramatically increasing the likelihood that a malicious link will be clicked or an attachment opened.

Spam Campaign Execution

The spam module (e.g., Module ID 29) communicates with its own dedicated C2 servers to download campaign data. This data includes the email templates crafted from stolen threads, lists of target email addresses, and stolen SMTP credentials.

Network Signature

From a network perspective, a host infected with the Emotet spam module will exhibit highly anomalous behavior. It will begin acting like a mail server, initiating a large number of outbound SMTP connections (typically on ports 25, 465, or 587) to a wide and diverse range of external mail servers belonging to its spam targets.

This activity is often preceded by DNS queries for the MX (Mail Exchange) records of the target domains. For any host that is not a designated mail server, this pattern is a very strong indicator of a spambot infection.

Information Theft: Exfiltration Protocols

Beyond email data, Emotet is a prolific information stealer.

Credential Theft

Modules like the WebBrowserPassView and MailPassView stealers are deployed to harvest credentials stored in web browsers and email clients.

System Profiling

As detailed in above, the initial C2 beacon contains a detailed profile of the infected system, including OS version, hardware details, and a list of running processes. This reconnaissance data is critical for the operators to identify high-value targets and to avoid executing on sandboxes or analysis machines.

Exfiltration Channel

All of this stolen data—credentials, system profiles, and harvested emails—is packaged using the Protobuf serialization format, encrypted using the active cryptographic scheme (AES over RSA or ECC), and exfiltrated over the primary C2 channel via the HTTP Cookie header method.

Downloader-as-a-Service: Network Signatures of Secondary Payload Delivery

Emotet also acts as a loader for other malware families.

Delivery Command

The Emotet C2 server can issue a specific command to an infected bot, instructing it to download and execute a secondary payload.

Network Signature

This action creates a distinct and critical network indicator. The Emotet-infected host, which has been communicating with its known C2 servers, will suddenly initiate a new HTTP or HTTPS connection to a different, previously unseen domain or IP address. This connection will result in the download of a Windows executable file (e.g., a .dll or .exe).

Known Payloads

Emotet is famously associated with delivering some of the most notorious malware families, including TrickBot, Qakbot, and IcedID. The presence of Emotet C2 traffic followed by network indicators associated with any of these families is a clear sign of a multi-stage, high-severity intrusion.

Conclusion

Emotet’s design reflects a deep understanding of enterprise network security controls and a continuous, iterative cycle of development aimed at circumventing them.

The key findings of this analysis are threefold:

1. Resilience Through Design: Emotet’s tiered C2 infrastructure, which leverages compromised victims as a distributed proxy layer, and its segmentation into independent “Epochs,” make it exceptionally resilient to disruption.
2. Stealth Through Masquerading: The C2 protocol’s use of HTTP/S, encapsulation of data within cookie headers, and use of Protocol Buffers serialization are all deliberate choices designed to make malicious traffic indistinguishable from benign activity.
3. Adaptation as a Core Principle: The cryptographic shift from RSA to ECC with signature verification following the 2021 takedown is definitive proof of the operators’ ability to adapt and harden their platform in response to defensive actions.

|TOC| |PREV| |NEXT|