{ "id": "a10a1c9b-3aeb-456a-9993-5bec36d05578", "created_at": "2026-04-06T00:22:26.106229Z", "updated_at": "2026-04-10T03:20:38.150631Z", "deleted_at": null, "sha1_hash": "372d770a04e24b0dbee66b8d5271f34085dad24f", "title": "Emotet Config Redux", "llm_title": "", "authors": "", "file_creation_date": "0001-01-01T00:00:00Z", "file_modification_date": "0001-01-01T00:00:00Z", "file_size": 448763, "plain_text": "Emotet Config Redux\r\nBy Oleg Boyarchuk, Stefano Ortolani\r\nPublished: 2022-05-25 · Archived: 2026-04-05 18:00:28 UTC\r\nIt is no mystery that Emotet’s development recently picked up. After its resurrection (some researchers pointing to\r\nTrickBot as the threat actor responsible), it bootstrapped two new botnets (Epoch 4 and Epoch 5), and it recently\r\nlooked at replacing its own modules with native 64-bit implementations. Tracking its network infrastructure is\r\nhowever linked to the ability of decrypting and extracting its configuration file containing, besides the encryption\r\nkeys that can be in turn used to identify the botnet, a list of compromised hosts that the payload would connect to\r\nupon execution. Unfortunately, either willingly or as a side-effect of other changes (or rather, some obfuscation\r\nimprovements), since mid-May Emotet samples have started to transition to a new method of storing the\r\nconfiguration data within the binary: not anymore as a single blob of data, but as a split collection of fragments,\r\neach one obfuscated separately.\r\nIn this blogpost we briefly detail this change and show how to keep extracting the list of network indicators\r\ndespite this new obfuscation technique.\r\nObfuscation Improvements\r\nTo provide actionable threat intelligence, many vendors of dynamic analysis systems often decide to add routines\r\nto automatically extract C2 configuration data of known malware families, including Emotet. For a very long time\r\nEmotet kept its encrypted C2 config in the beginning of .data section of the PE module. As we noticed in our\r\nprevious blog post, this did not change when Emotet decided to migrate to pure 64-bit binaries: each and every\r\nsample had a function which was responsible for config decryption (see Figure 1).\r\nhttps://blogs.vmware.com/security/2022/05/emotet-config-redux.html\r\nPage 1 of 7\n\nFigure 1: Encrypted C2 config passed as a parameter to the decryption routine\r\n(c6fe1cf52c7f3299f07a1e1c05e19e2013330e4c).\r\nhttps://blogs.vmware.com/security/2022/05/emotet-config-redux.html\r\nPage 2 of 7\n\nFigure 2: Decrypted C2 config is an array of IP:port pairs (c6fe1cf52c7f3299f07a1e1c05e19e2013330e4c).\r\nUnfortunately, that is not the case anymore: in a recent wave of Emotet samples, the configuration data is not\r\nembedded in the binary in one single blob; rather, each new sample now features an accumulator function (see\r\nFigure 3) which returns a pointer to an array of function pointers, each returning a single C2 IP address and port\r\n(see Figure 4).\r\nhttps://blogs.vmware.com/security/2022/05/emotet-config-redux.html\r\nPage 3 of 7\n\nFigure 3: C2 accumulator function from the new wave (b409ca9851fecca61e6cb0aaaa56fdaafc7242f5).\r\nThis means that it is now impossible to statically retrieve a blob of data from a sample, decrypt it, and extract a list\r\nof IP addresses, as the C2 configuration is now spread across the code. Another challenge is that IP address and\r\nport cannot be extracted from a static view of the disassembled code because of some newly added obfuscation, as\r\nshown in Figure 4: the code now performs a series of mathematical operations on a set of hardcoded values before\r\nleading to what are the actual values representing IP address and port.\r\nhttps://blogs.vmware.com/security/2022/05/emotet-config-redux.html\r\nPage 4 of 7\n\nFigure 4: Obfuscated C2 function from the new wave which returns 212.24.98.99:8080\r\n(b409ca9851fecca61e6cb0aaaa56fdaafc7242f5).\r\nHow to Defeat Obfuscation\r\nA straightforward approach to deal with this kind of obfuscations is to use code decompilers (for example Hex-Rays). An often-underestimated advantage of decompilers is the ability to also reduce code complexity as a by-product of lifting the binary code to higher level languages; Figure 5 shows an example of a decompiled and\r\ndeobfuscated code fragment. While ideal for manual analysis, decompilers are expensive and are not guaranteed\r\nto work in the general case (deobfuscation tends to be hit-or-miss).\r\nhttps://blogs.vmware.com/security/2022/05/emotet-config-redux.html\r\nPage 5 of 7\n\nFigure 5: C2 function from the new wave deobfuscated by Hex-Rays\r\n(b409ca9851fecca61e6cb0aaaa56fdaafc7242f5).\r\nRunning the code in a code emulator such as QEMU or Qiling (both free for commercial use) is often a more\r\nreliable way to extract the required data because they can emulate both the CPU and the underlying OS\r\nenvironment. In this scenario, the starting point needs to be the inner DLL extracted as shown in our blog post.\r\nOnce that is done, static analysis can be used to identify the accumulator function, and thereby obtain the full list\r\nof functions used to decode the C2 data. The last step is computing the physical offset within the module and\r\nfeeding it to the emulator as a starting instruction. Figure 6 contains a quick implementation to decode the C2 data\r\nfrom the function shown in Figure 5 (i.e., sub_7FFA1B6AEAA4); in this case the physical offset was 0x1DEA4.\r\nFigure 6: Small program to decode a single network indicator given a physical offset.\r\nConclusions\r\nWhile a reader might start to conclude (as we predicted) that Emotet has finally resumed playing cat and mouse\r\ngames with security researchers, we still believe these improvements to be part of a more comprehensive\r\nrefactoring, and that payloads will likely keep evolving following internal roadmaps yet to become clear to the\r\npublic. Unfortunately, all these changes are the only signal that security defenders can use to improve detectors\r\nand keep users safe from this ever-evolving threat.\r\nhttps://blogs.vmware.com/security/2022/05/emotet-config-redux.html\r\nPage 6 of 7\n\nSource: https://blogs.vmware.com/security/2022/05/emotet-config-redux.html\r\nhttps://blogs.vmware.com/security/2022/05/emotet-config-redux.html\r\nPage 7 of 7", "extraction_quality": 1, "language": "EN", "sources": [ "Malpedia" ], "references": [ "https://blogs.vmware.com/security/2022/05/emotet-config-redux.html" ], "report_names": [ "emotet-config-redux.html" ], "threat_actors": [], "ts_created_at": 1775434946, "ts_updated_at": 1775791238, "ts_creation_date": 0, "ts_modification_date": 0, "files": { "pdf": "https://archive.orkl.eu/372d770a04e24b0dbee66b8d5271f34085dad24f.pdf", "text": "https://archive.orkl.eu/372d770a04e24b0dbee66b8d5271f34085dad24f.txt", "img": "https://archive.orkl.eu/372d770a04e24b0dbee66b8d5271f34085dad24f.jpg" } }