{
	"id": "b65cff69-fc65-47c8-a608-ec862122f6fa",
	"created_at": "2026-04-06T00:15:38.312373Z",
	"updated_at": "2026-04-10T03:21:26.41347Z",
	"deleted_at": null,
	"sha1_hash": "26dc48ca54daa70440cde34f77710355003488a5",
	"title": "Emutet",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 767809,
	"plain_text": "Emutet\r\nArchived: 2026-04-05 13:25:28 UTC\r\nSummary\r\nEmotet is one of the most active malwares nowadays, every day you can find new campaigns and new binaries.\r\nEmotet is a downloader that is able to download new modules with new features.\r\nEmotet is also used to download third party malware on infected machines. Over the last few years Emotet has\r\nbeen seen distributing malware such as IceID, Trickbot and Ursnif.\r\nAll these malware have the capability to steal bank information from infected computers. Emotet consists of more\r\nthan 1 botnet extended worldwide and everyone is aware of the new movements of this botnet, to such an extent\r\nthat almost every day a new article talking about Emotet is published.\r\nRepository content\r\nThis repository has been created with the idea of helping the community of cybersecurity researchers and malware\r\nresearchers. It explains in detail how the network communication protocol used by Emotet to communicate with\r\nthe C\u0026Cs works.\r\nKnowing all these details, it should be relatively easy to emulate the communication, and obtain the new modules\r\nand distributed malware directly from the c\u0026c.\r\nThat’s why in this repository there is also the code used to emulate Emotet’s communication. This code is\r\nintegrated with https://www.capesandbox.com. In this way we only have to pass as argument the ID of a CAPE\r\nanalysis, to automatically instantiate an Emotet bot that will try to download new modules.\r\nUsage\r\nRemember to install all requeriments first\r\nTriage Given the following triage analysis https://tria.ge/reports/191017-h6k7yj8vq6/task1\r\ncd emutet\r\npython emutet.py -T --triage 191017-h6k7yj8vq6\r\nCAPE Given the following cape analysis https://www.capesandbox.com/analysis/3062/\r\ncd emutet\r\npython emutet.py -T --cape 3062\r\nFor more info read this\r\nhttps://d00rt.github.io/emotet_network_protocol/\r\nPage 1 of 14\n\nIn case of success something similar to the following will appear on the screen:\r\nIn this way it is possible to track in real time the servers controlled by the attackers and anticipate new attacks.\r\nThe following section explains in detail how the network protocol works.\r\nNetwork Protocol\r\nOnce a host has been infected with Emotet, the host waits for commands from the control panel. One important\r\nthing to keep in mind is that each Emotet binary has a configuration. This configuration has two elements:\r\nA list of IPs and ports. These IPs are directly the C\u0026Cs, from which the different modules and/or malware\r\nto be distributed at that given moment will be downloaded.\r\nA RSA public key. This RSA public key is used to encrypt the symmetric session key.\r\nTo extract this configuration we can use tools like CAPE (https://capesandbox.com) or Triage (https://tria.ge)\r\nwhich extract them automatically. Or we can set up our own sandboxing environment and add the necessary\r\nprocesses to extract this information.\r\nHatching/Triage - https://tria.ge/reports/191013-xrcw9krzfj/task1\r\nhttps://d00rt.github.io/emotet_network_protocol/\r\nPage 2 of 14\n\nCAPE sandbox - https://capesandbox.com/analysis/2974/\r\nUsing this list together with the public key, communication between the infected host and the control panel takes\r\nplace.\r\nSummary\r\nIf a system has been infected correctly and the C\u0026Cs are active, the communication from the infected machine to\r\nthe C\u0026C controlled by the attackers is done in the following way.\r\nhttps://d00rt.github.io/emotet_network_protocol/\r\nPage 3 of 14\n\nCommunication consists of 4 steps. The encryption of the communication as well as the detailed content of each\r\npacket is described in the following sections. Each step could be summarized as follows:\r\n1. This packet contains the user name, system architecture, the list of processes running in the system…\r\n2. The server responds with a PE executable file. This file is used as a session token. The file is hashed using\r\nthe CRC32 algorithm and this value is added in future packages sent by the infected host. If this value is\r\nwrong when the packets are sent, step (4) will never happen, since this value works as a session token.\r\n3. The same information is sent again as in step (1) , but this time the value obtained in step (2) is\r\nadded (session token).\r\n4. This packet contains a list of PE files. This list usually contains different Emotet modules. Although from\r\ntime to time, in case they are distributing malware, it also contains an additional file, corresponding to the\r\nmalware that is being distributed at that moment. Emotet modules are DLLs and are loaded directly into\r\nmemory so they are not saved into disk and are often difficult to obtain them.\r\nBelow is a Wireshark screenshot of a request from a host infected by Emotet.\r\nhttps://d00rt.github.io/emotet_network_protocol/\r\nPage 4 of 14\n\nThis capture corresponds to step (3) or step (4) , Analyzing a little the response of the server you can see\r\nthat it is very small, so you can guess that it has not received any module. This could mean 2 things.\r\n1. The correct request has not been made and the server does not respond with the modules. This is a way for\r\nthem to protect themselves against bots and curious people…\r\n2. The country the request was made from is not among Emotet’s targets.\r\nIn the case of receiving some module, the response of the server would be much bigger.\r\nSome fields of the request header should be highlighted. Since probably if these fields are misconfigured the\r\ncontrol panel will not respond correctly. This is a typical measure used by attackers control panels to go unnoticed\r\nand not raise suspicions.\r\nIt’s a POST request.\r\nhttps://d00rt.github.io/emotet_network_protocol/\r\nPage 5 of 14\n\nThe request is made to a specific path in this case to /mult/vermont/odbc. This path varies as it is randomly\r\ngenerated by Emotet.\r\nThe Referer field is also added exclusively by Emotet.\r\nThe Content-Type field does not vary between requests as it is hardcoded in the Emotet code.\r\nThe DNT field is also hardcoded by Emotet.\r\nFinally to emphasize would be the payload of the request, in this case you see a variable that is assigned\r\ndata in base64. The name of the variable in this case is t1PfmD50asc and varies between requests as it is\r\nrandomly generated by Emotet. However the data in base64 is data related to the infected host.\r\nThis article tries to explain how this data is generated and sent/received to/from the server. Also to learn how the\r\nEmotet communication protocol works internally and to be able to create a bot that emulates this communication\r\nand to be capable of communicating directly with the control panels. (Although this emulator is already provided\r\nin this repository)\r\nThe data that is finally sent and received from the server is basically generated as shown below:\r\nhttps://d00rt.github.io/emotet_network_protocol/\r\nPage 6 of 14\n\nThe data is encoded and encrypted before being sent. The following sections explain how this data is encoded and\r\nthen encrypted\r\nEncoding\r\nThis section focuses on how packets sent from the infected host to the server are encoded. Although the process is\r\nsimilar for packets sent from the server to the infected host, we will not go into detail as these are encoded on the\r\nserver to which we do not have access. However, the server’s response is discussed below.\r\nAll packets before being encrypted are encoded in a specific way. In this case Emotet uses the protobufs to encode\r\nthe data it sends, both from the infected host to the server and from the server to the infected host.\r\nBelow is the definition of these protobuf:\r\nsyntax = \"proto2\";\r\nmessage HostInfo {\r\n required int32 scmanager = 1;\r\n required string bot_id = 2;\r\n required int32 arch = 3;\r\n required int32 session_id = 4;\r\n required fixed32 file_crc32 = 5;\r\n required string proccess_list = 6;\r\n required string unknown = 7;\r\n}\r\nmessage C2Request {\r\n required int32 command = 1;\r\n required bytes data = 2; //HostInfo compressed by zlib\r\n}\r\nhttps://d00rt.github.io/emotet_network_protocol/\r\nPage 7 of 14\n\nmessage C2Response {\r\n required int32 status = 1;\r\n optional bytes file = 2;\r\n optional bytes modules = 3;\r\n}\r\nmessage Module {\r\n required int32 id = 1;\r\n required int32 action = 2;\r\n required bytes data = 3;\r\n}\r\nRequests that are sent from the infected host to the server ( steps (1) and (3) ) are composed as follows:\r\nThe server responses are built in the same way, but in this case what the server sends is a list of modules.\r\nAfter encode the data, it’s encrypted as explained below.\r\nEncryption\r\nOnce the packets are encoded as explained in the previous section, the packer is encrypted using the following\r\nencryption scheme:\r\nA 128-bit AES key is generated with which the encoded data is encrypted. In this case the AES CBC mode\r\nis used for encryption.\r\nThe encrypted data is hashed using the SHA-128 algorithm.\r\nThe AES key used to encrypt the data is encrypted (exported) using the RSA key that contains the binary.\r\nThis key can be obtained automatically using Triage or CAPE as explained above.\r\nThe encryption scheme used is similar to the one defined by GPG.\r\nhttps://d00rt.github.io/emotet_network_protocol/\r\nPage 8 of 14\n\nIn the case of requests from the infected host to the server, this data will be encoded using base64 and sent in the\r\nPOST request, while the requests from the server to the infected host will be sent in raw. As shown in the\r\nWireshark image\r\nEmotet tracking\r\nhttps://d00rt.github.io/emotet_network_protocol/\r\nPage 9 of 14\n\nIn this section I explain how I have been tracking Emotet for a few weeks since I made the bot. In this\r\nsection there are technical things but also my personal opinion, because I have done this job in my spare\r\ntime, I have not had nor do I have much time to devote 100% to it and everything is not technically\r\nverified. Another thing to keep in mind, is that all the tests I have done are black box, because I do not\r\nhave access to the code of the servers, so in this section you will find many assumptions created under\r\nmy experience that do not have to be 100% real.\r\nUsing the bot found in this repository, I’ve been tracing the different Emotet botnets for a couple of weeks and\r\nhere are some conclusions I’ve reached.\r\nAs shown in protobuf definition, emotet modules have 3 fields\r\nmessage Module {\r\n required int32 id = 1;\r\n required int32 action = 2;\r\n required bytes data = 3;\r\n}\r\nid field. This id identifies the module type. I didn’t find a good explanaition about this field. But it\r\nfollows a pattern. This id is always a value between 300 and 2000. Usually the DLLs have a lower value\r\nthan the EXEs.\r\naction field. This field indicates how the module should be executed. We can find 2 values during the\r\ntime the tracking has lasted, 1 and 3 . If the value is 3 it means that the module must be loaded in\r\nmemory using a loader Emotet has. If the value is 1 it means it is gonna be stored in disk and executed as\r\na new process. The Emotet modules (DLLs) usually have the value 3 whereas the malware they are\r\nspreading (which are EXE files) have the value 1\r\ndata field. A DLL or an EXE file.\r\nThe collected files from the botnet that are in this repository are ordered by id and action. This way maybe\r\nsomeone can guess the real meaning of this id field\r\nDownloaded modules (DLL files)\r\nDuring these weeks of analysis, I have obtained about 600 unique files distributed inside Emotet’s botnets. Most\r\nof these files are not in VirusTotal as Emotet does not save them to disk and they are difficult to get if you don’t\r\nhave a bot. The file emotet_botnet_modules_and_malware.zip contains these files. The password is d00rt-emotet .\r\nEvery time a request is made to download the modules, in case of success, they are always received in groups of\r\nbetween 3 and 13 modules. If these requests are made on different days the hash of these modules will be different\r\nbut they will still come in packs of between 3 and 13 modules.\r\nhttps://d00rt.github.io/emotet_network_protocol/\r\nPage 10 of 14\n\nI guess (I didn’t have time to analyze all of them) that the functionality of the modules remains the same but\r\nchanges its hash. This way it is more difficult to detect them by the antivirus.\r\nAlthough looking at the hash of the modules obtained there are more than 600 different modules, really, I think\r\nthere are only about 13 unique modules. Simply the modules are updated to change the hash and thus bypass the\r\nantivirus.\r\nDistributed malware\r\nNot all files downloaded from the botnet are modules of Emotet itself. Executable files can also be found. These\r\nfiles are other malwares distributed by Emotet. During the weeks the botnet has been tracketed only samples of\r\nTrickbot and Ursnif have been obtained.\r\nThe file emotet_botnet_malware.zip contains these files. The password is d00rt-emotet .\r\nSHA-1 FAMILY REPORT\r\n1aea1121475df57b5802c84583c4dc89500baa75 Trickbot View report\r\n1bbbae729c33ea1ff7f99ddca6317e05a4242d63 Ursnif View report\r\n2eb72c4993a981c9480427c83338105bcd0d863d Trickbot View report\r\n2f8b0b6435ca18da75e8ae2e6745718124a26f66 Trickbot View report\r\n30ebf4174d1703dd66d867ba65cd015d3604c938 Trickbot View report\r\n36c09a576e35a70e5400c545c19f3ad5420e4c33 Trickbot View report\r\n3ab810973efe13af16639485547817bf1a84bb84 Trickbot View report\r\n41ed194a7310eae9620d1b4facfbc33fb246c079 Trickbot View report\r\n428f9a2b4cbc33879806996a030c02f0e60521b9 Trickbot View report\r\n42cb5218b9b949231f3c601715e80aab3d416f91 Ursnif View report\r\n4fa87ea1426e9d02c0aebe5fdefd03b42cb6640a Trickbot View report\r\n5abdb8b16f503976c3e726521c1f93b927931c00 Ursnif View report\r\nhttps://d00rt.github.io/emotet_network_protocol/\r\nPage 11 of 14\n\nSHA-1 FAMILY REPORT\r\n60ae3209413136b40ab2b4fcd11884d6dfeb330b Trickbot View report\r\n74e9f572b117ae54bbe6d3055332117071bc6e40 Trickbot View report\r\n8ad35f111142e94599955379dad6fe8040789f0b Ursnif View report\r\n8ec9d7a0c950e4f013f9afc76d807e597d7cad9a Ursnif View report\r\n9193eaeff8fff6c8b09dc370b9e60ddab5b121a3 Ursnif View report\r\n9957fe40ae9a7a2630593fd82544d4ea39ca47d7 Trickbot View report\r\na038cf5f99d17df1e223aaf2f5f80b4b4a440a4e Ursnif View report\r\nb70119e477f01a901a14a0378ced471f93cee7f6 Trickbot View report\r\nd0a308811bd0cf98b7f3c13328f34e192ae9f07c Ursnif View report\r\necf315df8321b5bee5395cff7add2206d385dab0 Trickbot View report\r\need62d01218a450c4130ca196256b90cb815a987 Trickbot View report\r\nf0a6bef71d57feee7c036899edc337bc1fb69160 Trickbot View report\r\nfec98b8cdd890124ce5c203a64b38050f5459801 Trickbot View report\r\nCountry\r\nOne important thing to keep in mind is that it depends on the country from which we make the request the botnet\r\nwill serve some files or others. So for the tracking has been used a VPN to make the request from different\r\ncountries.\r\nThree different scenarios can happen when we connect from a specific country:\r\n1. The country from which we connect is not among Emotet’s objectives and we do not receive any module.\r\n2. The Country from which we connect only receives modules but not malware. In this case, it can be said\r\nthat this Country is a possible target of Emotet and at that moment it is not distributing malware for that\r\nCountry.\r\n3. The Country from which we connect receives the modules and the malware. In this case it can be said\r\n100% that this country is a target of Emotet and that they are currently spreading malware in their botnet.\r\nWrong approach but cool map\r\nAfter a few days inside Emotet’s botnet I noticed the following, each bot registered in the botnet is uniquely\r\nidentified by the bot_id that is sent to the server (it makes sense) and is identified in all botnets.\r\nhttps://d00rt.github.io/emotet_network_protocol/\r\nPage 12 of 14\n\nWhat does this mean in terms of tracking? Once a bot is registered in the botnet it will always receive the same\r\nfiles regardless of the Country from which it connects and regardless of which of the 3 knoen botnets it connects.\r\nFor example:\r\nYou create a bot using the emulator with the bot id D00RT_PC\r\nYou connect from Japan to botnet 1\r\nYou receive 3 modules and 1 malware\r\nFrom that moment if you connect again with the bot id D00RT_PC from any country and to any botnet, the same\r\nmodules and the same malware will always be received.\r\nWhen I started to track Emotet I didn’t know this, so my first approach was to always use the same bot id and\r\nconnect from all countries.\r\nAs already explained this approach is not valid … but as I lost time in making this cool map and I like it, I leave\r\nhere a video :D\r\nThe correct way of tracking Emotet is to create a new bot id every time we connect to the botnet. Although this\r\ndoes not always work as explained in the next section and can generate a lot of noise in the servers controlled by\r\nthe actors.\r\nProblems communicating with the botnet\r\nhttps://d00rt.github.io/emotet_network_protocol/\r\nPage 13 of 14\n\nEven having all the knowledge of how the protocol works (from the client side) certain problems have been\r\nencountered when communicating with the C\u0026C. Here is a list of things to keep in mind in order to make a\r\nsuccessful communication:\r\nThe bot id. This field is decisive because sometimes I think I have been banned based on the bot id. I have\r\nalso had the feeling that once a bot has been served with a malware, it has a few days of use and then it is\r\nbanned from the botnet to not distribute more malware (this is just a theory based on my experience).\r\nCountry. It is important to connect from a country that is among the targets of Emotet. otherwise we will\r\nnot get an answer.\r\nTime and day. I noticed that on weekends the botnets are not usually active so you have to take this into\r\naccount. Also the time at which you connect can also affect the time to have an answer or another from the\r\nC\u0026C.\r\nInteresting related articles\r\n1. [Analysis of Emotet v4](https://www.cert.pl/en/news/single/analysis-of-emotet-v4/) - Paweł Srokosz\r\n2. Exploring Emotet, an elaborate everyday enigma - Luca Nagy\r\n3. Emotet: The Tricky Trojan that ‘Git Clones - Ofer Caspi, Ben Herzog\r\nLast notes\r\nThe Emotet network protocol may change after this release, sorry to all researchers who will have to modify the\r\nbot. I’ve seen how the protocol has changed 3 times since I’ve been following this family, so if not for this reason\r\nthey would change it for another reason.\r\nI hope at least that it helps the community to trace this family (until the protocol changes) and that people who are\r\nstarting in this world know how these advanced malwares work and how to trace them.\r\nI want to give a shout-out to Cryptolaemus, Joseph Roosen and the group of researchers for the excellent job\r\ntracking the documents, links and binaries that are distributed every day by SPAM or whatever by Emotet actors.\r\nAlso thanks to CAPE and Triage for suppoting Emotet config extractor :D\r\nI don’t have much time to maintain this repository although I’m open to improvements and suggestions. I will try\r\nto answer questions when I can. Sorry, I don’t think I can update the repository very often. Bills don’t pay\r\nthemselves.\r\nThanks for reading to the end and I hope you enjoyed it as much as I enjoyed doing the bot.\r\n– d00rt –\r\nSource: https://d00rt.github.io/emotet_network_protocol/\r\nhttps://d00rt.github.io/emotet_network_protocol/\r\nPage 14 of 14",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"Malpedia"
	],
	"references": [
		"https://d00rt.github.io/emotet_network_protocol/"
	],
	"report_names": [
		"emotet_network_protocol"
	],
	"threat_actors": [],
	"ts_created_at": 1775434538,
	"ts_updated_at": 1775791286,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/26dc48ca54daa70440cde34f77710355003488a5.pdf",
		"text": "https://archive.orkl.eu/26dc48ca54daa70440cde34f77710355003488a5.txt",
		"img": "https://archive.orkl.eu/26dc48ca54daa70440cde34f77710355003488a5.jpg"
	}
}