{ "id": "1876538a-c103-4bc9-8afa-dd62185a1def", "created_at": "2026-04-06T00:12:25.691383Z", "updated_at": "2026-04-10T03:28:20.540899Z", "deleted_at": null, "sha1_hash": "48cf9f52bd2a3c432ff5fcb9f23f2e7d34713575", "title": "Dissecting Emotet – Part 1", "llm_title": "", "authors": "", "file_creation_date": "0001-01-01T00:00:00Z", "file_modification_date": "0001-01-01T00:00:00Z", "file_size": 51493, "plain_text": "Dissecting Emotet – Part 1\r\nBy Deutsche Telekom AG\r\nPublished: 2020-02-03 · Archived: 2026-04-02 10:46:55 UTC\r\nI bet you've heard of Emotet, a modular botnet that is active at least since 2014. Since many years it is considered\r\none of the most costly and destructive malware family affecting the public and private sectors as well as\r\nindividuals. For those who do not know the background to Emotet yet: It started off as a banking Trojan but\r\nchanged its modus operandi in 2017 to the distribution of third party malicious payloads. Recently, researchers\r\nhave observed Emotet to deliver TrickBot and the ransomware Ryuk as secondary payloads.\r\nThomas' path led from research to business. He regularly shares his findings in this blog.\r\n© Deutsche Telekom AG\r\nThis botnet comprises its own spreading mechanism. Most infections are achieved by sending out spam with links\r\nto malicious documents. If the target actively interacts with such a document, Emotet's loader is installed. The\r\nloader is very limited in its capabilities from my point of view. Its main purpose is to persist Emotet on a target\r\nsystem, contact its Command \u0026 Control Servers, which steer the attack (C2 servers), and download as well as\r\nexecute further payloads. These payloads are either Emotet modules or further secondary payloads like TrickBot.\r\nThe interesting functionality of Emotet is implemented in its modules such as spamming, lateral movement, or\r\ncredential theft. This modular structure makes Emotet very flexible and effective. \r\nEmotet's modules do not persist on a target system. This has several consequences. First, it is forensically hard to\r\ntell what kind of data an Emotet infection stole. Since modules are distributed to a target system based on an\r\nunknown selection algorithm, the number of modules that are deployed on a target system varies. Second, there\r\ntends to be a delay of up to a couple of weeks in the emergence of such modules on public online scan engines\r\nlike VirusTotal. This results in a short period of time where these modules fly under the radar. \r\nIn this multi part blog post, I will now dive deep into Emotet's modules internals. In the first part, I will give an\r\noverview of the currently distributed modules and the way how some of these modules encrypt their payloads.\r\nThen I will describe how and why some of these modules are constantly changing their hash values and I will\r\ndiscuss the evolution of Emotet's modules in the last couple of months. \r\nEmotet - from the big picture to the detail\r\nThe Emotet loader downloads modules from its C2 server and executes them. These modules are implemented as\r\nWindows libraries (PE DLLs). They do not export any functions besides a DLL entry point. They may directly\r\nimport additional functions from Windows libraries like 'kernel32.dll'. The Emotet loader executes a module in a\r\nnew thread within its process space. In order to do so, it resolves any imported functions and applies relocations.\r\nSubsequently, it starts a new thread at the DLL's entry point. I found that modules work independently of the main\r\nmodule and hence they are easy to debug in isolation.\r\nhttps://www.telekom.com/en/blog/group/article/cybersecurity-dissecting-emotet-part-one-592612\r\nPage 1 of 4\n\nThe obfuscation techniques of Emotet's modules are equal to its loader: they dynamically resolve most of the\r\nWindows API addresses via API hashing and they utilize a simple string encryption. Cafe Babe described Emotet's\r\nAPI hashing and string encryption in detail last year, which has not significantly changed since then. Note that\r\nEmotet's modules do not come in packed form. However, many of them are just wrappers around another payload.\r\nFor instance, there is a wrapper module around NirSoft's WebBrowserPassView, which is a recovery tool for\r\npasswords stored in web browsers. This module decrypts WebBrowserPassView first and then it starts it in its own\r\nprocess.\r\nI observed that some of these wrappers carry a 32 bit and a 64 bit payload. Depending on the system's\r\narchitecture, the corresponding module gets decrypted and executed. The payloads are encrypted using a simple\r\neXclusive OR cipher (XOR) with a hard-coded key, which I will explain later on.\r\nTable 1 lists the payloads that I observed recently while tracking Emotet's infrastructure. Our findings are\r\n congruent with other public sources like Lucy Nagy's VirusBulletin 2019 paper.\r\nModule\r\nIs\r\nWrapper\r\nModule?\r\nRepresentative Hash\r\nspammer No 54be4115e54b6dcb2986ff953b271202de0b3c64b4b18714f49e0febddba3c0c\r\nadministrative\r\nhare spreader\r\nNo f8dd847ab1565aa460875c782f44a003a5b2c20b0e76a6672cfe3cd952a38727\r\nnetwork\r\npassword\r\nbruteforcer\r\nNo d714eca8a485b86cfa40dacfdedcd164877bf9d0e0d704ea325718b14498ba02\r\nWebBrowser-PassView\r\nYes 7f11dabe46bf0af8973ce849194a587bd0ba1452e165faf028983f85b2b624c2\r\nMailPassView Yes 400b411a9bffd687c5e74f51d43b7dc92cdb8d5ca9f674456b75a5d37587d342\r\nOutlook\r\ncontact\r\nharvester\r\nYes fb541624735a03a1a72aebf80847403aa68d7278f6fea101d2ea9afc568b3b46\r\nhttps://www.telekom.com/en/blog/group/article/cybersecurity-dissecting-emotet-part-one-592612\r\nPage 2 of 4\n\nOutlook mail\r\nharvester\r\nYes 404652e82de15d9c6436d49cd9a2b46bc8b3a66f0a6530574e50ae165a5619e1\r\nC2 traffic\r\nproxy\r\nNo 902bac124f2926e6a345f393f292136a02b3cf523f9c156f40223a0343f0869c\r\nThese modules keep the Emotet machinery running. The first three modules (spammer, administrative share\r\nspreader, and network password bruteforcer) spread Emotet to other machines. The spammer module carries out\r\nthe spreading via email on a global scale. The administrative share spreader and the network password bruteforcer\r\nhelp to spread Emotet laterally within an infected organization. The administrative share spreader tries to spread\r\nEmotet to network shares that are accessible to the local administrator. The network password bruteforcer tries to\r\nbrute force accounts of local network resources and subsequently execute the Emotet loader. Researchers observed\r\nthis module to use a list of 10.000 passwords earlier this year. However, I found out that the latest known version\r\nfrom 2019-04-24 17:53:50 utilizes a brute force dictionary similar to the one reported to be used by QuackBot.\r\nThe modules for credential harvesting (WebBrowserPassView and MailPassView) allow for monitarization of\r\nstolen account data. Furthermore, they feed the spam module with new mail accounts. The Outlook contact\r\nharvester finds fresh target email addresses to be used by the spammer module. The Outlook mail harvester is a\r\ntargeted way of spreading Emotet by highjacking email threads. Finally, the C2 traffic proxy module ensures\r\nresilience of the botnet. It accepts C2 traffic of other infected machines and sends it to the C2 server.\r\nWrapper Module Payload Decryption\r\nEarlier I stated that there are some modules that are wrappers around another payload. For instance, there is a\r\nwrapper that contains the Nirsoft tool WebBrowserPassView as payload. The wrapper decrypts this payload and\r\ninjects it into another process in order to harvest credentials stored by local web browsers.\r\nThe payload decryption algorithm is actually very similar to the string decryption algorithm that Cafe Babe\r\ndescribed. In a nutshell, the decrypted payload is stored in a binary blob. Logically, this blob consists of four byte\r\nblocks. The blocks are encrypted with an eXclusive OR cipher (XOR). The XOR key is hardcoded in the binary.\r\nThe first block contains the payload size. Therefore, this block must be decrypted first. Afterwards, the following\r\nblocks can be sequentially decrypted.\r\nA major difference between the payload decryption and string decryption as described by Cafe Babe is that the\r\npayload decryption algorithm utilizes Intel's Streaming SIMD Extensions (SSE) to decrypt the blocks. By doing\r\nso, Emotet can decrypt four blocks at a time, i.e. 128 bits or 16 bytes. First, it loads the key into the XMM register\r\n'xmm1'. The key repeats the same DWORD four times. \r\nNext, it repeatedly utilizes the instruction 'pxor' to decrypt four blocks at a time until there are less than four\r\nblocks left.\r\nEmotet can decrypt four blocks at a time. © Deutsche Telekom AG\r\nhttps://www.telekom.com/en/blog/group/article/cybersecurity-dissecting-emotet-part-one-592612\r\nPage 3 of 4\n\nIt decrypts these remainder blocks with a sequential xor. Whether the usage of SSE is done due to emulation\r\nevasion or due to optimization considerations is unclear. However, I tend to believe that this should yield\r\nperformance improvement.\r\nThe following algorithm implements the payload decryption as pseudo code. Note that I do not need to implement\r\nit using SSE because decrypting the blocks sequentially or in parallel is semantically equivalent.\r\nThat's how the payload decryption is implemented as pseudo code. © Deutsche Telekom AG\r\nSome wrapper modules like the WebBrowserPassView wrapper contain only one payload. But there are some\r\nwrapper modules that contain two payloads: a 32 bit and 64 bit payload. Depending on the target system's\r\narchitecture the corresponding payload gets decrypted. An example for such a wrapper module is the Outlook mail\r\nharvester wrapper (ebb9f0920f08ffd6d7a05da35ecf57a13d15fe9c79f1b39d48a53099794f4274). The first payload\r\nis the 32 bit version of the Outlook mail harvester\r\n(404652e82de15d9c6436d49cd9a2b46bc8b3a66f0a6530574e50ae165a5619e1) and the second payload is the 64\r\nbit version of the Outlook mail harvester\r\n(b074d13f218633803e419f4e72d134a129b15d5c21a9474d2f5665a3be194c9c).\r\nConclusion\r\nIn this first blog post, I have discussed the heart of Emotet: its modular structure and its modules. I have given an\r\noverview of the eight modules that are currently distributed. These modules fall into three categories: spreading\r\n(spammer, password bruteforcer, network spreader), data exfiltration (outlook contact harvester, outlook mail\r\nharvester, wrapper WebBrowserPassView, wrapper MailPassView), and botnet resilience (C2 traffic proxy).\r\nThe modules are implemented as PE DLLs and they are executed first in a new thread within the same process\r\nspace as the Emotet loader. Some modules are just wrapper around another payload like Nirsoft's MailPassView.\r\nThese wrappers may inject their payload into another process in order to execute them. Emotet's modules live only\r\nin memory and they are not persisted on a target system. Consequently, this delays their appearance on public\r\nplatforms like VirusTotal by up to a couple of weeks. \r\nFrom a botnet author's point of view, this modular structure makes sense: it makes its analysis harder, the botnet\r\nmore flexible and testable, and in the end, it also increases its efficiency. In our next blog post, I will investigate\r\nthe rehashing of modules and the evolution of Emotet's modules within the last couple of months.\r\n \r\nSource: https://www.telekom.com/en/blog/group/article/cybersecurity-dissecting-emotet-part-one-592612\r\nhttps://www.telekom.com/en/blog/group/article/cybersecurity-dissecting-emotet-part-one-592612\r\nPage 4 of 4", "extraction_quality": 1, "language": "EN", "sources": [ "Malpedia" ], "references": [ "https://www.telekom.com/en/blog/group/article/cybersecurity-dissecting-emotet-part-one-592612" ], "report_names": [ "cybersecurity-dissecting-emotet-part-one-592612" ], "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": 1775434345, "ts_updated_at": 1775791700, "ts_creation_date": 0, "ts_modification_date": 0, "files": { "pdf": "https://archive.orkl.eu/48cf9f52bd2a3c432ff5fcb9f23f2e7d34713575.pdf", "text": "https://archive.orkl.eu/48cf9f52bd2a3c432ff5fcb9f23f2e7d34713575.txt", "img": "https://archive.orkl.eu/48cf9f52bd2a3c432ff5fcb9f23f2e7d34713575.jpg" } }