{ "id": "337981b4-8054-4514-9aa0-eedc343f4e6a", "created_at": "2026-04-06T00:13:39.711756Z", "updated_at": "2026-04-10T13:11:33.097388Z", "deleted_at": null, "sha1_hash": "e210f62853e52310dfc7269a9b700254633b89ac", "title": "Dissecting Emotet - Part 2", "llm_title": "", "authors": "", "file_creation_date": "0001-01-01T00:00:00Z", "file_modification_date": "0001-01-01T00:00:00Z", "file_size": 43860, "plain_text": "Dissecting Emotet - Part 2\r\nBy Deutsche Telekom AG\r\nPublished: 2020-03-06 · Archived: 2026-04-05 21:48:44 UTC\r\nReady to follow me further into the details of Emotet? That's right, it's about one of the biggest malware threats in the world.\r\nEmotet is mainly spread through spam campaigns. In the first part of this blog post I introduced the modular structure and\r\nindividual elements in more detail. It makes sense to read this classification first and then continue at this point.\r\nEmotet became world famous in 2019 and is still very active\r\nFirst of all, I would like to show this time which tricks this malware uses to protect itself from being detected via so-called\r\nhash values. And before we finally turn to the evolution of the modules, I will talk about the consequences for us as\r\ndefenders. \r\nReady? Let's do it!\r\n\"Rehashing\" of Modules\r\nEven though there are only a couple of unique modules, there are many versions with different hashes. This makes a hash-based detection of them not very efficient. In order to detect them, we need the latest version of a module. However, since\r\nthese modules are only memory resident, it may take some time for them to get to AV companies or to public platforms like\r\nVirusTotal.\r\nLet us have a look at the \"rehashing\" feature of Emotet's Command and Control (C2) servers. There are two classes of\r\nmodules: those that change their hash value every couple of hours and those that do not change their hash value for months.\r\nSo, the interesting question is: why does this happen?\r\nAt first, I consider the modules that continuously rehash. When byte comparing the outlook mail harvester modules that I\r\nfetched from Epoch 3 on 2019-11-04 and 2019-11-05, then it becomes clear that only a handful of bytes are different.\r\nThe area, where those two binaries differ, holds the set of C2 addresses. Only three of the four addresses are different. The\r\nfirst address (96 4E 3F B2 90 1F) stayed the same. Furthermore, both binaries comprise the same compilation timestamp\r\n(2019-10-15 04:31:32). Replacing the C2 addresses does not require any recompilation. It is probable that the C2 server\r\ndoes this fully automatically by directly writing to a fixed file offset (e.g. in this case 0xD300). From the operator’s point of\r\nview, the good thing is that these modules continuously rehash so that hash-only based solutions fail to detect them. \r\nNow I regard two examples of the second case: the modules that do not change their hash values in months. I was able to\r\nobtain the administrative shares spreader module by all three epochs on several consecutive days (2019-11-05 - 2019-11-08).\r\nThe modules always had the same hash (f8dd847ab1565aa460875c782f44a003a5b2c20b0e76a6672cfe3cd952a38727) and\r\nthey all had a creation timestamp of 2019-03-31 10:59:43, which I believe to be correct. Its first submission to VirusTotal\r\nwas on 2019-05-14 07:35:47. Under the assumption that the timestamps are correct then this would be six weeks after\r\ncompilation and after their subsequent distribution within the botnet. I observed the same for the network password\r\nbruteforcer (d714eca8a485b86cfa40dacfdedcd164877bf9d0e0d704ea325718b14498ba02): its creation time is 2019-04-24\r\n17:53:50 and its first submission to VirusTotal was on 2019-05-17 19:44:25. \r\nThe reason that those modules do not rehash is that they do not depend on fresh C2 addresses. They just spread the Emotet\r\nloader laterally. Since the loader has a set of C2 addresses, these modules can stay as they are and the Emotet operators do\r\nnot have to bother to change these modules. For us as defenders this means that we can detect them either with Yara\r\nsignatures or by using fuzzy hashes that are not affected by a couple of bit flips.\r\nhttps://www.telekom.com/en/blog/group/article/cybersecurity-dissecting-emotet-part-two-596128\r\nPage 1 of 4\n\nEvolution of Modules\r\nIn the previous section, I stated that the timestamps found in the modules' PE headers are reasonable. It is very likely that the\r\nEmotet operators did not tamper with them. Therefore, I utilized them to cluster the modules.\r\nD00rt published a corpus of Emotet modules along with his blog post on Emotet's network protocol. Even though the corpus\r\nwas collected within a limited time frame, i.e. around one month, there are more than 600 DLLs included. This is a\r\nwonderful opportunity to dig a little bit deeper in the recent evolution of Emotet's modules.  \r\nI clustered the over 600 DLLs of D00rt's corpus by timestamp and got 15 clusters. We can see that there are five modules\r\nthat the Emotet operators compiled on 2019-03-31. Another batch of modules was compiled in April 2019. Finally, there are\r\nsome modules that were compiled in October 2019. The following table summarizes the clusters. It holds the cluster's\r\ntimestamp, the module that I associate with this cluster, the number of modules in this cluster, and a cluster representative\r\nfor future research.\r\nTimestamp Module\r\nCluster\r\nSize \r\nCluster Representative \r\n2019-03-\r\n31\r\n10:48:35\r\nwrapper\r\nWebBrowserPassView\r\n102 1334b5c6025151c92abaa08adff7a0f04bf6e5d9a2b04d55e6c73bbe8a6a5983\r\n2019-03-\r\n31\r\n10:48:40\r\nC2 traffic proxy 102 d45eb10428eb2b262a6bedd275e070618f36288dc8a872445456834e6c938d4\r\n2019-03-\r\n31\r\n10:48:52\r\nwrapper\r\nMailPassView\r\n102 4a23a1a24421b50570d840e1aade7d6304674707d81155be0818f8ac2f8bef1e\r\n2019-03-\r\n31\r\n10:48:55\r\nOutlook contact\r\nharvester\r\n117 49bce46b7931a52c655f9d9ba83ce47be6f07263b8053bb009f9ea6a7216ca91\r\n2019-03-\r\n31\r\n10:49:11\r\nOutlook mail\r\nharvester\r\n117 e9a077d388e98316af074d109e8d8f93cd07fe67073a585027fef0d640eff1f6\r\n2019-03-\r\n31\r\n10:59:43\r\nadministrative share\r\nspreader\r\n30 f8dd847ab1565aa460875c782f44a003a5b2c20b0e76a6672cfe3cd952a38727\r\nhttps://www.telekom.com/en/blog/group/article/cybersecurity-dissecting-emotet-part-two-596128\r\nPage 2 of 4\n\n2019-04-\r\n08\r\n16:38:38\r\nspammer 23 b7ff07953428feb7d629b407158ce1fa896169ffd108d2a7a6c45e541167d4eb\r\n2019-04-\r\n24\r\n17:53:50\r\nnetwork password\r\nbruteforcer\r\n39 d714eca8a485b86cfa40dacfdedcd164877bf9d0e0d704ea325718b14498ba02\r\n2019-04-\r\n24\r\n18:17:09\r\nspammer 23 77c04e8a66efe29b56e9ef7c615776c0559872ca99c3db7fc80ef5a540c43b0a\r\n2019-10-\r\n02\r\n06:38:18\r\nspammer 8 cbebc09364704b9078f6463eed723c31c384920f5f65ff1caf702f136d2ea93a\r\n2019-10-\r\n04\r\n23:19:53\r\nOutlook contact\r\nharvester\r\n15 918e4e36ced6d131ebd30fbcc2206823d14b702f448780afcbd06d60aae375f8\r\n2019-10-\r\n04\r\n23:20:39\r\nOutlook mail\r\nharvester\r\n15 3706c6ce387f803517464754bc6e04ddd3711401b07535cc9ca25008f321ff36\r\n2019-10-\r\n14\r\n20:45:29\r\nspammer 2 54be4115e54b6dcb2986ff953b271202de0b3c64b4b18714f49e0febddba3c0c\r\n2019-10-\r\n15\r\n04:31:43\r\nOutlook contact\r\nharvester\r\n9 2f360761d5bc5505fa4ebf80281ba724e8027b923300aeb6da2799d21035720c\r\n2019-10-\r\n15\r\n04:31:32\r\nOutlook mail\r\nharvester\r\n9 5638f3f14cb916ac6f3debf1838822f789fbd760ea63981d7e3fb454b8afb95e\r\nThere are some interesting points to note. First, the Emotet operators compiled at least six modules on 2019-03-31. Since\r\nthey were all compiled within two minutes, I assume that they belong to one (Visual Studio) solution, which got built on this\r\ndate. \r\nhttps://www.telekom.com/en/blog/group/article/cybersecurity-dissecting-emotet-part-two-596128\r\nPage 3 of 4\n\nSecond, there was some activity in April, when two versions of the spammer module and one version of the network\r\npassword bruteforcer got compiled. In the case of the network password bruteforcer I assume that it got recompiled because\r\nthe bruteforce dictionary was exchanged. It seems that there were no modules compiled in Summer 2019, which coincides\r\nwith the reports on Emotet's summer break from June until September 2019.\r\nThird, tracking these modules is (still) easy given several facts that I showed in this blog post: the timestamps seem to be\r\nreliable, there is no real packing of the modules, and only a small number of bytes of each module may change due to binary\r\npatching. Therefore, it is enough to match new modules against the fuzzy hash (e.g. ssdeep) of a cluster representative. \r\nConclusion\r\nThis blog post concludes my two-part series on the internals of Emotet's modules. I have described the \"rehashing\" of some\r\nof Emotet's modules, which is just a byproduct of binary patching new C2 addresses into already compiled modules. Next, I\r\nhave analyzed D00rt's corpus of Emotet modules by clustering them by their timestamp. This has yielded only a couple of\r\nclusters and gives a good insight in the development of Emotet modules within the last months. Furthermore, I have\r\ndiscussed the possibility to detect modules by utilizing fuzzy hashes.\r\nSource: https://www.telekom.com/en/blog/group/article/cybersecurity-dissecting-emotet-part-two-596128\r\nhttps://www.telekom.com/en/blog/group/article/cybersecurity-dissecting-emotet-part-two-596128\r\nPage 4 of 4", "extraction_quality": 1, "language": "EN", "sources": [ "Malpedia" ], "origins": [ "web" ], "references": [ "https://www.telekom.com/en/blog/group/article/cybersecurity-dissecting-emotet-part-two-596128" ], "report_names": [ "cybersecurity-dissecting-emotet-part-two-596128" ], "threat_actors": [ { "id": "81dde5cc-c29f-430d-8c6e-e5e92d5015e7", "created_at": "2022-10-25T16:07:23.704358Z", "updated_at": "2026-04-10T02:00:04.718034Z", "deleted_at": null, "main_name": "Harvester", "aliases": [], "source_name": "ETDA:Harvester", "tools": [ "Agentemis", "Cobalt Strike", "CobaltStrike", "Graphon", "Metasploit", "cobeacon" ], "source_id": "ETDA", "reports": null } ], "ts_created_at": 1775434419, "ts_updated_at": 1775826693, "ts_creation_date": 0, "ts_modification_date": 0, "files": { "pdf": "https://archive.orkl.eu/e210f62853e52310dfc7269a9b700254633b89ac.pdf", "text": "https://archive.orkl.eu/e210f62853e52310dfc7269a9b700254633b89ac.txt", "img": "https://archive.orkl.eu/e210f62853e52310dfc7269a9b700254633b89ac.jpg" } }