Emotet is one of the most active malwares nowadays, every day you can find new campaigns and new binaries. Emotet is a downloader that is able to download new modules with new features.

Emotet is also used to download third party malware on infected machines. Over the last few years Emotet has been seen distributing malware such as IceID, Trickbot and Ursnif.

All these malware have the capability to steal bank information from infected computers. Emotet consists of more than 1 botnet extended worldwide and everyone is aware of the new movements of this botnet, to such an extent that almost every day a new article talking about Emotet is published.

Repository content

This repository has been created with the idea of helping the community of cybersecurity researchers and malware researchers. It explains in detail how the network communication protocol used by Emotet to communicate with the C&Cs works.

Knowing all these details, it should be relatively easy to emulate the communication, and obtain the new modules and distributed malware directly from the c&c.

That’s why in this repository there is also the code used to emulate Emotet’s communication. This code is integrated with https://www.capesandbox.com. In this way we only have to pass as argument the ID of a CAPE analysis, to automatically instantiate an Emotet bot that will try to download new modules.


Remember to install all requeriments first

Triage Given the following triage analysis https://tria.ge/reports/191017-h6k7yj8vq6/task1

cd emutet
python emutet.py -T --triage 191017-h6k7yj8vq6

CAPE Given the following cape analysis https://www.capesandbox.com/analysis/3062/

cd emutet
python emutet.py -T --cape 3062

For more info read this

In case of success something similar to the following will appear on the screen:


In this way it is possible to track in real time the servers controlled by the attackers and anticipate new attacks.

The following section explains in detail how the network protocol works.

Network Protocol

Once a host has been infected with Emotet, the host waits for commands from the control panel. One important thing to keep in mind is that each Emotet binary has a configuration. This configuration has two elements:

To extract this configuration we can use tools like CAPE (https://capesandbox.com) or Triage (https://tria.ge) which extract them automatically. Or we can set up our own sandboxing environment and add the necessary processes to extract this information.

Hatching/Triage - https://tria.ge/reports/191013-xrcw9krzfj/task1

Alt text

CAPE sandbox - https://capesandbox.com/analysis/2974/

Alt text

Using this list together with the public key, communication between the infected host and the control panel takes place.


If a system has been infected correctly and the C&Cs are active, the communication from the infected machine to the C&C controlled by the attackers is done in the following way.

Alt text

Communication consists of 4 steps. The encryption of the communication as well as the detailed content of each packet is described in the following sections. Each step could be summarized as follows:

  1. This packet contains the user name, system architecture, the list of processes running in the system…
  2. The server responds with a PE executable file. This file is used as a session token. The file is hashed using the CRC32 algorithm and this value is added in future packages sent by the infected host. If this value is wrong when the packets are sent, step (4) will never happen, since this value works as a session token.
  3. The same information is sent again as in step (1), but this time the value obtained in step (2) is added (session token).
  4. This packet contains a list of PE files. This list usually contains different Emotet modules. Although from time to time, in case they are distributing malware, it also contains an additional file, corresponding to the malware that is being distributed at that moment. Emotet modules are DLLs and are loaded directly into memory so they are not saved into disk and are often difficult to obtain them.

Below is a Wireshark screenshot of a request from a host infected by Emotet.

Alt text

This capture corresponds to step (3) or step (4), Analyzing a little the response of the server you can see that it is very small, so you can guess that it has not received any module. This could mean 2 things.

  1. The correct request has not been made and the server does not respond with the modules. This is a way for them to protect themselves against bots and curious people…
  2. The country the request was made from is not among Emotet’s targets.

In the case of receiving some module, the response of the server would be much bigger.

Some fields of the request header should be highlighted. Since probably if these fields are misconfigured the control panel will not respond correctly. This is a typical measure used by attackers control panels to go unnoticed and not raise suspicions.

This article tries to explain how this data is generated and sent/received to/from the server. Also to learn how the Emotet communication protocol works internally and to be able to create a bot that emulates this communication and to be capable of communicating directly with the control panels. (Although this emulator is already provided in this repository)

The data that is finally sent and received from the server is basically generated as shown below:

Alt text

Alt text

The data is encoded and encrypted before being sent. The following sections explain how this data is encoded and then encrypted


This section focuses on how packets sent from the infected host to the server are encoded. Although the process is similar for packets sent from the server to the infected host, we will not go into detail as these are encoded on the server to which we do not have access. However, the server’s response is discussed below.

All packets before being encrypted are encoded in a specific way. In this case Emotet uses the protobufs to encode the data it sends, both from the infected host to the server and from the server to the infected host.

Below is the definition of these protobuf:

syntax = "proto2";

message HostInfo {
    required int32 scmanager = 1;
    required string bot_id = 2;
    required int32 arch = 3;
    required int32 session_id = 4;
    required fixed32 file_crc32 = 5;
    required string proccess_list = 6;
    required string unknown = 7;

message C2Request {
    required int32 command = 1;
    required bytes data = 2; //HostInfo compressed by zlib

message C2Response {
    required int32 status = 1;
    optional bytes file = 2;
    optional bytes modules = 3;

message Module {
    required int32 id = 1;
    required int32 action = 2;
    required bytes data = 3;

Requests that are sent from the infected host to the server ( steps (1) and (3) ) are composed as follows:

The server responses are built in the same way, but in this case what the server sends is a list of modules.

After encode the data, it’s encrypted as explained below.


Once the packets are encoded as explained in the previous section, the packer is encrypted using the following encryption scheme:

The encryption scheme used is similar to the one defined by GPG.

Alt text

Alt text

In the case of requests from the infected host to the server, this data will be encoded using base64 and sent in the POST request, while the requests from the server to the infected host will be sent in raw. As shown in the Wireshark image

Emotet tracking

In this section I explain how I have been tracking Emotet for a few weeks since I made the bot. In this section there are technical things but also my personal opinion, because I have done this job in my spare time, I have not had nor do I have much time to devote 100% to it and everything is not technically verified. Another thing to keep in mind, is that all the tests I have done are black box, because I do not have access to the code of the servers, so in this section you will find many assumptions created under my experience that do not have to be 100% real.

Using the bot found in this repository, I’ve been tracing the different Emotet botnets for a couple of weeks and here are some conclusions I’ve reached.

As shown in protobuf definition, emotet modules have 3 fields

message Module {
    required int32 id = 1;
    required int32 action = 2;
    required bytes data = 3;

The collected files from the botnet that are in this repository are ordered by id and action. This way maybe someone can guess the real meaning of this id field

Downloaded modules (DLL files)

During these weeks of analysis, I have obtained about 600 unique files distributed inside Emotet’s botnets. Most of these files are not in VirusTotal as Emotet does not save them to disk and they are difficult to get if you don’t have a bot. The file emotet_botnet_modules_and_malware.zip contains these files. The password is d00rt-emotet.

Every time a request is made to download the modules, in case of success, they are always received in groups of between 3 and 13 modules. If these requests are made on different days the hash of these modules will be different but they will still come in packs of between 3 and 13 modules.

Alt text

Alt text

I guess (I didn’t have time to analyze all of them) that the functionality of the modules remains the same but changes its hash. This way it is more difficult to detect them by the antivirus.

Although looking at the hash of the modules obtained there are more than 600 different modules, really, I think there are only about 13 unique modules. Simply the modules are updated to change the hash and thus bypass the antivirus.

Distributed malware

Not all files downloaded from the botnet are modules of Emotet itself. Executable files can also be found. These files are other malwares distributed by Emotet. During the weeks the botnet has been tracketed only samples of Trickbot and Ursnif have been obtained.

The file emotet_botnet_malware.zip contains these files. The password is d00rt-emotet.

1aea1121475df57b5802c84583c4dc89500baa75 Trickbot View report
1bbbae729c33ea1ff7f99ddca6317e05a4242d63 Ursnif View report
2eb72c4993a981c9480427c83338105bcd0d863d Trickbot View report
2f8b0b6435ca18da75e8ae2e6745718124a26f66 Trickbot View report
30ebf4174d1703dd66d867ba65cd015d3604c938 Trickbot View report
36c09a576e35a70e5400c545c19f3ad5420e4c33 Trickbot View report
3ab810973efe13af16639485547817bf1a84bb84 Trickbot View report
41ed194a7310eae9620d1b4facfbc33fb246c079 Trickbot View report
428f9a2b4cbc33879806996a030c02f0e60521b9 Trickbot View report
42cb5218b9b949231f3c601715e80aab3d416f91 Ursnif View report
4fa87ea1426e9d02c0aebe5fdefd03b42cb6640a Trickbot View report
5abdb8b16f503976c3e726521c1f93b927931c00 Ursnif View report
60ae3209413136b40ab2b4fcd11884d6dfeb330b Trickbot View report
74e9f572b117ae54bbe6d3055332117071bc6e40 Trickbot View report
8ad35f111142e94599955379dad6fe8040789f0b Ursnif View report
8ec9d7a0c950e4f013f9afc76d807e597d7cad9a Ursnif View report
9193eaeff8fff6c8b09dc370b9e60ddab5b121a3 Ursnif View report
9957fe40ae9a7a2630593fd82544d4ea39ca47d7 Trickbot View report
a038cf5f99d17df1e223aaf2f5f80b4b4a440a4e Ursnif View report
b70119e477f01a901a14a0378ced471f93cee7f6 Trickbot View report
d0a308811bd0cf98b7f3c13328f34e192ae9f07c Ursnif View report
ecf315df8321b5bee5395cff7add2206d385dab0 Trickbot View report
eed62d01218a450c4130ca196256b90cb815a987 Trickbot View report
f0a6bef71d57feee7c036899edc337bc1fb69160 Trickbot View report
fec98b8cdd890124ce5c203a64b38050f5459801 Trickbot View report


One important thing to keep in mind is that it depends on the country from which we make the request the botnet will serve some files or others. So for the tracking has been used a VPN to make the request from different countries.

Three different scenarios can happen when we connect from a specific country:

  1. The country from which we connect is not among Emotet’s objectives and we do not receive any module.
  2. The Country from which we connect only receives modules but not malware. In this case, it can be said that this Country is a possible target of Emotet and at that moment it is not distributing malware for that Country.
  3. The Country from which we connect receives the modules and the malware. In this case it can be said 100% that this country is a target of Emotet and that they are currently spreading malware in their botnet.

Wrong approach but cool map

After a few days inside Emotet’s botnet I noticed the following, each bot registered in the botnet is uniquely identified by the bot_id that is sent to the server (it makes sense) and is identified in all botnets.

What does this mean in terms of tracking? Once a bot is registered in the botnet it will always receive the same files regardless of the Country from which it connects and regardless of which of the 3 knoen botnets it connects.

For example:

From that moment if you connect again with the bot id D00RT_PC from any country and to any botnet, the same modules and the same malware will always be received.

When I started to track Emotet I didn’t know this, so my first approach was to always use the same bot id and connect from all countries.

Alt text

As already explained this approach is not valid … but as I lost time in making this cool map and I like it, I leave here a video :D

The correct way of tracking Emotet is to create a new bot id every time we connect to the botnet. Although this does not always work as explained in the next section and can generate a lot of noise in the servers controlled by the actors.

Problems communicating with the botnet

Even having all the knowledge of how the protocol works (from the client side) certain problems have been encountered when communicating with the C&C. Here is a list of things to keep in mind in order to make a successful communication:

Interesting related articles

  1. [Analysis of Emotet v4](https://www.cert.pl/en/news/single/analysis-of-emotet-v4/) - Paweł Srokosz
  2. Exploring Emotet, an elaborate everyday enigma - Luca Nagy

  3. Emotet: The Tricky Trojan that ‘Git Clones - Ofer Caspi, Ben Herzog

Last notes

The Emotet network protocol may change after this release, sorry to all researchers who will have to modify the bot. I’ve seen how the protocol has changed 3 times since I’ve been following this family, so if not for this reason they would change it for another reason.

I hope at least that it helps the community to trace this family (until the protocol changes) and that people who are starting in this world know how these advanced malwares work and how to trace them.

I want to give a shout-out to Cryptolaemus, Joseph Roosen and the group of researchers for the excellent job tracking the documents, links and binaries that are distributed every day by SPAM or whatever by Emotet actors. Also thanks to CAPE and Triage for suppoting Emotet config extractor :D

I don’t have much time to maintain this repository although I’m open to improvements and suggestions. I will try to answer questions when I can. Sorry, I don’t think I can update the repository very often. Bills don’t pay themselves.

Thanks for reading to the end and I hope you enjoyed it as much as I enjoyed doing the bot.