{
	"id": "23a4481c-d9f8-4948-b41e-e7f62772536a",
	"created_at": "2026-04-10T03:20:55.444568Z",
	"updated_at": "2026-04-10T03:22:18.796073Z",
	"deleted_at": null,
	"sha1_hash": "84b9861d2e2d57db06c6daf92dff28af8cb4ac35",
	"title": "Emotet C2 Configuration Extraction and Analysis",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 1275499,
	"plain_text": "Emotet C2 Configuration Extraction and Analysis\r\nBy Oleg Boyarchuk, Jason Zhang\r\nPublished: 2022-03-29 · Archived: 2026-04-10 03:00:41 UTC\r\nThe Emotet actors have re-gained their power to launch attacks since the Emotet botnet was taken down in 2021. VMware’s\r\nNSX Sandbox detected a series of attack waves of such attacks in January of this year. More details about the attacks can be\r\nfound in our recent reports (Emotet Is Not Dead (Yet) part 1 and part 2.)\r\nThe Emotet botnet is known to use many command-and-control (C2) servers to keep communication open between the\r\ninfected machines and the botnet’s herders.  Providing visibility into the C2 configuration of Emotet payloads can help in\r\nmany ways, from detection to threat hunting. In this report, we first discuss the steps on how to extract the C2 configuration\r\nfrom Emotet payloads via a combination of dynamic and static analysis, including decrypting and dumping the embedded\r\nEmotet payload from the initial DLL payload dropped by documents, and the actual extraction process of C2 configuration\r\ncontained in the decrypted Emotet payload. We then propose a process to automate the configuration extraction steps by\r\nleveraging the NSX Sandbox, which allows us to extract the C2 configuration from Emotet payloads at scale. In the final\r\npart, we provide an analysis of the most distinctive aspects of the C2 configurations extracted from recent Emotet\r\ncampaigns.\r\nExecutive Summary\r\nThis is a technical report containing our analysis on some Emotet attacks taking place in Q1 2022. In this report we detail:\r\nHow to decrypt and dump the internal DLL from the initial Emotet DLL payload.\r\nHow to extract C2 configuration contained in the internal DLL.\r\nAnalysis of the C2 configuration data extracted from over 2000 DLL dropped payloads.\r\nCharacterization of the network infrastructure of the botnets.\r\nEmotet is a sophisticated botnet that comprises a few subgroups or sub-botnets, called “epochs.” Each epoch has its own C2\r\ninfrastructure and distribution methods. As discussed in a report published in 2019, different epochs may be used to target\r\ndifferent countries with different payloads. At the time of writing, there are five epochs (labeled as Epoch 1, Epoch 2, and so\r\non). Epoch 1, Epoch 2, and Epoch 3 were mostly seen before the botnet was taken down in early 2020. Epoch 4 and Epoch 5\r\nwere introduced after Emotet resurfaced. The epoch number of a sample is typically identified by the public encryption\r\nkey(s) contained in the C2 configuration of the sample. Though Emotet samples of different epochs keep their configuration\r\ndata in different formats, they all share one common approach: their configuration is stored in an encrypted DLL (hereinafter\r\nreferred to as “the internal DLL”) that is embedded into the executable payload (called “the payload”).\r\nFigure 1 illustrates the C2 configuration extraction process for a given Emotet attack. The attacks are known to start with\r\nspam emails containing weaponized documents (e.g., Word or Excel files) leveraging embedded malicious VBA or Excel\r\n4.0 (XL4) macros. The execution of macros typically leads to the delivery of a DLL file (the payload) that, when executed\r\n(often by calling rundll32.exe or regsvr32.exe), decrypts an internal DLL into memory and executes it (as highlighted in\r\nFigure 1).\r\nhttps://blogs.vmware.com/security/2022/03/emotet-c2-configuration-extraction-and-analysis.html\r\nPage 1 of 18\n\nFigure 1: Emotet C2 configuration extraction pipeline.\r\nTherefore, the process of extracting the Emotet C2 configuration has two main steps:\r\n1. Decrypting and dumping the internal DLL from the initial DLL payload.\r\n2. Scanning the decrypted internal DLL to extract key C2 configuration data, such as the C2 servers’ IP:port pairs and\r\nthe public encryption key(s) (see Figure 1).\r\nIn the remaining of this section, we will focus our discussion on these two steps via manual analysis.\r\nDecrypting and Dumping the Internal DLL\r\nTo demonstrate this step, we analyze one of the Emotet samples\r\n(63996a39755e84ee8b5d3f47296991362a17afaaccf2ac43207a424a366f4cc9).\r\nThe DllMain function of this sample (and many others) has the following algorithm:\r\n1. Allocate ~ 100 MB of memory with malloc and fill it with random data. This stops the analysis of weak emulators\r\nnot willing to allocate large amounts of memory.\r\n2. Find the base address of kernel32.dll by PEB, PEB_LDR_DATA, etc. While normally this method is used to make\r\nthe reverse engineering process more difficult, statically imported functions are still used later in the code; we\r\nspeculate this to be a trick to also break emulation, as references to internal OS structures are rarely fully handled by\r\nemulators.\r\n3. Find VirtualAlloc and VirtualAllocExNuma with the help of an ad hoc version of GetProcAddress.\r\n4. Allocate memory with either VirtualAllocExNuma or VirtualAlloc, depending on\r\nwhich one is available. VirtualAlloc is supported starting with Windows XP whereas VirtualAllocExNuma is\r\nsupported starting with Windows Vista. This looks like another trick to stop weak emulators that do not support the\r\ncomplete set of Windows APIs.\r\n5. Copy the internal DLL into the allocated memory and then decrypt it.\r\n6. Map the sections of the internal DLL in memory, fix relocations and imports. This is achieved with the help of the\r\nstatically imported functions VirtualAlloc, LoadLibrary, and GetProcAddress.\r\nTo be able to decrypt and dump the internal DLL, it is first necessary to load the original DLL payload into a debugger, set\r\nbreakpoints on the invocation of VirtualAllocExNuma and VirtualAlloc, and then start execution. When the execution\r\nhttps://blogs.vmware.com/security/2022/03/emotet-c2-configuration-extraction-and-analysis.html\r\nPage 2 of 18\n\nreaches the breakpoint, one needs to trace the code until it returns a pointer to the allocated memory (in the image below the\r\naddress of the newly allocated memory is 0x00E7000).\r\nFigure 2: Memory, allocated with VirtualAllocExNuma.\r\nThe next step is to trace the code of DllMain until it copies the encrypted DLL into the allocated memory. In the figure\r\nbelow, one may see that the data of the Dump tab has changed from all zeros to random bytes.\r\nFigure 3: Embedded DLL copied into the allocated memory.\r\nOne can trace the code of DllMain a bit further until observing that the data of the Dump tab updates to a PE file with the\r\n“MZ” signature at the very beginning and the text “This program cannot be run in DOS mode”, as shown in the figure\r\nbelow.\r\nhttps://blogs.vmware.com/security/2022/03/emotet-c2-configuration-extraction-and-analysis.html\r\nPage 3 of 18\n\nFigure 4: Decrypted embedded DLL in allocated memory.\r\nAt this point, it is possible to dump the decrypted internal DLL.\r\nC2 Configuration Extraction\r\nThe next step is to locate the configuration data. The DLL is supposed to be executed with the help of rundll32; use the\r\nfollowing command line when debugging this artifact:\r\n“C:\\Windows\\system32\\rundll32.exe” “Path\\to\\dumped.dll”,DllRegisterServer\r\nThe internal DLL does not import any function. Instead, it retrieves pointers to the Windows API functions dynamically. In\r\naddition, some of the core functionality is obfuscated, which makes static analysis challenging. Under the hood the code\r\nobfuscation includes mathematical operations performed multiple times as shown in the figure below.\r\nFigure 5: Mathematical operations on a number in the obfuscated code.\r\nThe result of such calculations is passed to a function and then never used (see Figure 6).\r\nhttps://blogs.vmware.com/security/2022/03/emotet-c2-configuration-extraction-and-analysis.html\r\nPage 4 of 18\n\nFigure 6: Result of the mathematical operations passed as 6th parameter to a function.\r\nAs Figure 7 shows, the obfuscation also includes multiple conditional jumps that break the code flow of the decompiled\r\ncode.\r\nFigure 7: Conditional jumps in the obfuscated code.\r\nThe abundance of jumps is translated into nested while-loops in the decompiled obfuscated code (see Figure 8).\r\nhttps://blogs.vmware.com/security/2022/03/emotet-c2-configuration-extraction-and-analysis.html\r\nPage 5 of 18\n\nFigure 8: Nested while loops of the obfuscated code.\r\nEach API function has a wrapper that is called by the core functionality. For example, Figure 9 shows how DllMain calls the\r\nwrapper around the ExitProcess API.\r\nFigure 9: DllMain of the embedded DLL with highlighted wrapper over ExitProcess.\r\nThe figure below shows the implementation of the ExitProcess wrapper. It calls FindProcAddress which is also called by\r\nevery other API wrapper to retrieve the API function address by hash.\r\nhttps://blogs.vmware.com/security/2022/03/emotet-c2-configuration-extraction-and-analysis.html\r\nPage 6 of 18\n\nFigure 10: Wrapper over ExitProcess API in the embedded DLL.\r\nBy setting a breakpoint on FindProcAddress, one can extract all API wrappers and name them. We are particularly interested\r\nin the API functions that work with memory. They will help us find the key function responsible for memory allocation. This\r\nfunction is shown in the figure below.\r\nFigure 11: Memory allocation function of the embedded DLL.\r\nAllocateMemory is called by many functions, but we are particularly interested in its use within a function that resembles a\r\ndecoding cycle. Using manual analysis, we identified the following function:\r\nhttps://blogs.vmware.com/security/2022/03/emotet-c2-configuration-extraction-and-analysis.html\r\nPage 7 of 18\n\nFigure 12: Config decryption function of the embedded DLL.\r\nBy setting a breakpoint on this function, we can identify all the encrypted configs, which are passed in ECX (see Figure 13):\r\nhttps://blogs.vmware.com/security/2022/03/emotet-c2-configuration-extraction-and-analysis.html\r\nPage 8 of 18\n\nFigure 13: Pointer to the encrypted config passed to the decryption function in ECX.\r\nOnce the execution of this function ends, it returns a pointer to the decrypted config. In this case, we have the public key that\r\nis used in C2 communication, as highlighted in Figure 14.\r\nFigure 14: Decrypted C\u0026C public key.\r\nThe encrypted data is stored in the following format (this format was found in samples belonging to both Epoch 4 and\r\nEpoch 5):\r\nField Offset Size Description\r\nKey 0 4 Decryption key, little endian\r\nLength 4 4 Length of data, little endian\r\nhttps://blogs.vmware.com/security/2022/03/emotet-c2-configuration-extraction-and-analysis.html\r\nPage 9 of 18\n\nData 8 Variable Encrypted data, split into DWORDs, little endian\r\nThe length of the encrypted data can be retrieved by XORing the first DWORD of the encrypted data blob with the second\r\none. To decrypt the data with the retrieved data length, one needs to split the data into DWORDs and then XOR them with\r\nthe same first DWORD.\r\nThis way we decrypted the network keys, which are stored in the .text section of the extracted DLL. The keys extracted from\r\nthe sample (63996a39755e84ee8b5d3f47296991362a17afaaccf2ac43207a424a366f4cc9) belong to Epoch 4:\r\nECK1 (base64 encoded):\r\nRUNLMSAAAADzozW1Di4r9DVWzQpMKT588RDdy7BPILP6AiDOTLYMHkSWvrQO5slbmr1OvZ2Pz+AQWzRMggQmAtO6rPH7n\r\nECS1 (base64 encoded):\r\nRUNTMSAAAABAX3S2xNjcDD0fBno33Ln5t71eii+mofIPoXkNFOX1MeiwCh48iz97kB0mJjGGZXwardnDXKxI8GCHGNl0PFj5\r\nThe configuration containing C2 IP addresses and ports is normally stored at the very beginning of the .data section of the\r\nextracted DLL (see Figure 15). This configuration is encrypted with the same encryption method described previously.\r\nFigure 15: Encrypted list of IP:port pairs is stored at the beginning of .data section of the embedded DLL.\r\nThe decrypted configuration consists of an array of 8-byte elements, each with the following format:\r\nField Offset Size Description\r\nhttps://blogs.vmware.com/security/2022/03/emotet-c2-configuration-extraction-and-analysis.html\r\nPage 10 of 18\n\nIP 0 1 1st part of the IP address\r\n1 1 2nd part of the IP address\r\n2 1 3rd part of the IP address\r\n3 1 4th part of the IP address\r\nPort 4 2 Corresponding port, little endian\r\nValid 6 2 Always 1, presumably “valid” flag, little endian\r\nThe screenshot in Figure 16 shows the decrypted IP:port pairs:\r\nFigure 16: Decrypted list of IP:port pairs in binary format.\r\nThere are 37 IP:port pairs extracted from the sample, part of the list is shown below:\r\n131.100.24.231:80; 209.59.138.75:7080; 103.8.26.103:8080; 51.38.71.0:443; 212.237.17.99:8080;\r\nThe steps of the extraction pipeline discussed above are based on manual analysis. As our analysis shows, even though it is\r\npossible to extract the decrypted payload and configuration data statically, this process is not efficient and does not scale.\r\nTherefore, we decided to fully automate the process for both steps. This is achieved by leveraging the NSX Sandbox\r\nanalysis, which extracts and dumps the internal DLL artifact from the original Emotet DLL payload during execution (one\r\ncan use other controlled environments as well.) The dumped DLL is then fed into the C2 configuration extractor for\r\nscanning. The extractor supports different configuration formats seen in various epochs.\r\nWith the automated extraction pipeline discussed above, we were able to extract C2 configurations from recent Emotet\r\ncampaigns. In the following, we introduce the campaigns, and present our analysis of indicators of compromise (IoCs)\r\ncontained in the C2 configurations.\r\nRecent Emotet Campaigns\r\nFigure 17 shows a subset of VMware NSX telemetry data regarding Emotet attacks between January 1 and March 1, 2022.\r\nFollowing our earlier reports (Emotet Is Not Dead (Yet) part 1 and part 2) on the initial waves seen in the first four weeks of\r\nthis year, more attacks were detected in the next four weeks.\r\nhttps://blogs.vmware.com/security/2022/03/emotet-c2-configuration-extraction-and-analysis.html\r\nPage 11 of 18\n\nFigure 17: Excel document detection timeline of Emotet attacks.\r\nSome key statistics of the telemetry data are shown below:\r\nTotal documents: 17810.\r\nUnique documents: 9764. This number is smaller than the total document because a file could be submitted by\r\nvarious customers, resulting in multiple detections.\r\nUnique documents that successfully dropped DLL payloads from remote hosts and executed DLL payloads\r\nwithin NSX Sandbox controlled environment: 8888. If the remote hosts were taken down or not responding when\r\nthe malicious documents were analyzed, the documents would fail to deliver the DLL payloads.\r\nUnique DLL payloads: 3132. This implies that every unique DLL payload was dropped by 2.8 different documents\r\non average. Figure 18 shows the distribution of the top 20 DLL payloads. The most common DLL payload (with file\r\nsha256 starting with 22004) appeared in 174 (or 1.96%) of all 8888 documents.\r\nFigure 18: The distribution of top 20 Emotet DLL payloads.\r\nThere are various reasons that affect the availability of some DLLs for analysis. For instance, the NSX Sandbox detonation\r\nfailed to extract the internal DLLs in a limited number of cases. So, we decided to skip these documents and the\r\ncorresponding DLL payloads. The evaluation dataset used for the analysis in the next section contains 5941 unique\r\ndocuments which dropped the 2181 DLL payloads (representing 69.6% of the 3132 DLL payloads.)\r\nC2 Configuration Analysis\r\nUsing the C2 configuration extraction tool described above, we successfully extracted the C2 configuration data from all\r\n2181 Emotet DLL payloads. The C2 configuration data extracted from each DLL payload sample comprises a pair of\r\nencryption keys and a list of IP:port pairs. In this section, we analyze the configuration data and discuss some interesting\r\nfindings.\r\nEncryption Keys and Epoch Distribution\r\nPrior to the takedown of 2020, Emotet had three sub-botnets: Epoch 1, Epoch 2 and Epoch 3. All of them leveraged a single\r\nhard-coded RSA public key to encrypt an AES encryption key generated on-the-fly to encrypt network traffic between an\r\ninfected machine and the associated C2 servers. Differently, the samples from recent attacks use two keys in the\r\ncommunication protocols, labelled as ECK1 and ECS1, respectively. According to an early report, they are two Elliptic\r\nCurve Cryptography (ECC) public keys used for asymmetric encryption. ECK1 is a hard-coded Elliptic-curve Diffie-Hellman (ECDH) public key for encryption, and ECS1 a hard-coded Elliptic-curve Digital Signature Algorithm (ECDSA)\r\nhttps://blogs.vmware.com/security/2022/03/emotet-c2-configuration-extraction-and-analysis.html\r\nPage 12 of 18\n\npublic key for data validation. There are two distinct pairs of such public keys extracted from our dataset, which correspond\r\nto Epoch 4 and Epoch 5 botnets, respectively:\r\nEpoch4\r\nECK1:\r\nRUNLMSAAAADzozW1Di4r9DVWzQpMKT588RDdy7BPILP6AiDOTLYMHkSWvrQO5slbmr1OvZ2Pz+AQWzRMggQmAtO\r\nECS1:\r\nRUNTMSAAAABAX3S2xNjcDD0fBno33Ln5t71eii+mofIPoXkNFOX1MeiwCh48iz97kB0mJjGGZXwardnDXKxI8GCHGNl0P\r\nEpoch5\r\nECK1:\r\nRUNLMSAAAADYNZPXY4tQxd/N4Wn5sTYAm5tUOxY2ol1ELrI4MNhHNi640vSLasjYTHpFRBoG+o84vtr7AJachCzOHjaAJ\r\nECS1:\r\nRUNTMSAAAAD0LxqDNhonUYwk8sqo7IWuUllRdUiUBnACc6romsQoe1YJD7wIe4AheqYofpZFucPDXCZ0z9i+ooUffqeoLZ\r\nFigure 19 shows the breakdown in terms of IP addresses, DLL payloads, and the corresponding documents for Epoch 4 and\r\nEpoch 5. There are 134 unique IP addresses extracted from all 2181 DLL payloads. 57% of them were assigned to the Epoch\r\n4 botnet, while 41.5% of the IP addresses belonged to the Epoch 5 botnet. There is only one IP (217.182.143[.]207, with port\r\n443) that appeared in both botnets (see Figure 19 (A)). As a comparison, we also checked the distribution of IP:port pairs,\r\nwhich is identical to the distribution of IP addresses. For this reason, we only show the results from IP addresses. This\r\nlargely confirms the findings in a BeepingComputer’s report that each epoch has different C2 servers. The distinct C2\r\ninfrastructure by each epoch not only greatly increases the continuality of communication between bots and C2 servers, but\r\nit also makes it challenging in threat tracking. For instance, if one epoch is taken down or under maintenance, the Emotet\r\nactors can keep other epochs running. They can even move bots from one epoch to another according to the report from\r\nBeepingComputer.\r\nFigure 19: Epoch distribution.\r\nThe epoch distribution of IP addresses implies that Epoch 4 has been the main botnet of the recent attacks. Similar\r\nobservations can be seen from DLL and document epoch distributions, with 69.1% of DLLs and nearly 77% of documents\r\nassociated with Epoch 4 (see Figure 19 (B) and (C)).\r\nIP Address-Port Analysis\r\nIP count distribution\r\nOur analysis shows that the number of IP addresses or IP:port pairs extracted from C2 configuration data of a DLL payload\r\nvaries from 27 up to 49, which leads to 40 IP addresses or IP:port pairs per DLL on average. In terms of IP address count\r\ndistribution among all DLL payloads, the top count goes to IP address 217.182.143[.]207, which appeared 2181 times,\r\nmeaning all DLL payloads contain this IP. According to the IP address lookup, currently there are no hostnames resolving to\r\nthis IP address. Though we don’t know the underlying reason why this IP address has been included in all DLLs (both Epoch\r\n4 and Epoch 5), it could be possible that this host remained compromised all the time during the attacks, or it was added by\r\naccident to both epoch botnets. Other IP addresses were used between 14 and 1508 times among the DLL payloads. Figure\r\n20 shows the full distribution of the 134 IP addresses contained in the 2181 DLL payloads.\r\nhttps://blogs.vmware.com/security/2022/03/emotet-c2-configuration-extraction-and-analysis.html\r\nPage 13 of 18\n\nFigure 20: IP address distribution.\r\nIP Address Set Distribution\r\nApart from analyzing the distribution of individual IP addresses, we also examined how often a full set of C2 server IP\r\naddresses (or IP:port pairs) within a DLL payload appeared across all DLL payloads. This is achieved by concatenating the\r\nsorted IP addresses extracted from the DLL payload as a string and hashing the string. As a result, the distribution of IP list\r\nbecomes the distribution of hashes of the concatenated IP strings. There are 27 unique hashes of the IP strings, and most of\r\nthem appeared in the range of 50 to 150 times (see Figure 21).\r\nFigure 21: Distribution of hashes of C2 IP address set strings.\r\nIP Geographic Distribution\r\nWe analyzed the geographic distribution of the 134 IP addresses (see Figure 22) to understand which countries were used to\r\nhost the Emotet infrastructure. The analysis shows that most of the IP addresses were in the US (over 18%), followed by\r\nGermany and France. Other popular regions included South Asia, Brazil, Canada, and the United Kingdom.\r\nhttps://blogs.vmware.com/security/2022/03/emotet-c2-configuration-extraction-and-analysis.html\r\nPage 14 of 18\n\nFigure 22: IP distribution map.\r\nPort Distribution\r\nEvery C2 server IP address comes with a specific port number, which forms a collection of hard-coded IP:port pairs in the\r\nC2 configuration data, as previously discussed. There were four commonly used ports found in the 134 IP:port pairs (see\r\nFigure 23). The most common port is 8080, which accounted for over 50% of the total count of all ports, followed by the\r\n443 (HTTPS) port. Port 8080 is commonly used as a proxy port, suggesting that most of the C2 servers associated with the\r\nIP addresses were likely to be compromised legitimate servers used to proxy the real C2 servers. Using proxies to hide\r\nactual C2 servers is common in Emotet attacks. According to the findings of a report published in 2017, Emotet actors run\r\nan Nginx reverse proxy on a secondary port (e.g., 8080) of a compromised server, which then relays requests to the actual\r\nsever.\r\nFigure 23: Port distribution.\r\nJARM Fingerprint Distribution\r\nhttps://blogs.vmware.com/security/2022/03/emotet-c2-configuration-extraction-and-analysis.html\r\nPage 15 of 18\n\nJARM is an active Transport Layer Security (TLS) server fingerprinting tool to identify and cluster servers based on their\r\nTLS configuration.\r\nIn this section, we examine the distribution of JARM fingerprint hashes for the Emotet C2 server IP addresses. At the time\r\nof this analysis, most of the servers were offline, but we were able to obtain JARM fingerprints for 118 of the 134 IP\r\naddresses by querying the IP addresses on VirusTotal. The remaining 16 IP addresses were missing the JARM fingerprint.\r\nThe likely reason is that those C2 servers were offline at the time when VirusTotal checked their JARM fingerprints. We\r\nassume that the JARM fingerprint hashes obtained from VirusTotal were based on the C2 servers’ default standard port 443.\r\nTo verify this assumption, we scanned one of the C2 IP address-port pairs, 135.148.121[.]246:8080, with the JARM\r\nfingerprinting tool (see Figure 24). The tool allows one to specify a specific port (with option -p) when fingerprinting a\r\nserver. If a port is not specified, it uses the default port of the server.\r\nFigure 24: JARM fingerprinting IP address 135.148.121[.]246 with different ports.\r\nAs we can see from the figure above, the fingerprint hash\r\n(15d3fd16d29d29d00042d43d0000009ec686233a4398bea334ba5e62e34a01) is the same when scanning with the default\r\nport and port 443. This is the same JARM hash returned from VirusTotal when querying for the IP address. However, when\r\nscanning the IP address with port 8080 (as highlighted in the figure), JARM failed to fingerprint the server (the fingerprint\r\nhash string has all zeros). This means the server refused to respond to JARM fingerprinting messages on port 8080, as the\r\nport typically used for proxy service was closed (confirmed with Nmap port scanning, see Figure 25).\r\nFigure 25: Port scanning with Nmap.\r\nBy using the RiskIQ Community tool, we determined that the IP address belongs to OVH (highlighted in Figure 26). OVH\r\nis not an abuse well-known European Internet service provider (ISP) that provides server rental services. As we can see from\r\nFigure 26, there are a few domains currently pointing to the IP address since July 2021, which existed before Emotet\r\nresurfaced. So, we have a good reason to believe that this is probably a legitimate (compromised) web server.\r\nhttps://blogs.vmware.com/security/2022/03/emotet-c2-configuration-extraction-and-analysis.html\r\nPage 16 of 18\n\nFigure 26: RISKIQ lookup on IP: 135.148.121[.]246.\r\nThe findings from the investigation above suggest that if one uses JARM to fingerprint a server without specifying a port\r\nnumber, the resulting fingerprint could be misleading. Different services running on the same server but with different ports\r\ncan lead to different JARM fingerprints. This also means that when using JARM in threat hunting (such as hunting for C2\r\nservers) one should always specify the corresponding port numbers identified from the C2 configuration.\r\nAs a result, we only use the subset of C2 IP:port pairs that reference port 443 when analyzing the JARM fingerprints\r\nobtained from VirusTotal. According to the port distribution discussed above (see Figure 23), there are 48 such IP addresses,\r\nwith 40 of them having JARM fingerprints from VirusTotal. As Figure 27 shows, there are 7 unique JARM fingerprint\r\nhashes in total, and 31 IP addresses with port 443 share the same hash\r\n(2ad2ad0002ad2ad0002ad2ad2ad2ade1a3c0d7ca6ad8388057924be83dfc6a).\r\nFigure 27: JARM fingerprint hash distribution for IP addresses with port 443.\r\nIt is worth noting that, although JARM can be used to identify and cluster servers including malware C2 servers, it can lead\r\nto false positives (FPs) if not combined with other intelligence, such as IP address/domain history and reputation. For\r\nhttps://blogs.vmware.com/security/2022/03/emotet-c2-configuration-extraction-and-analysis.html\r\nPage 17 of 18\n\ninstance, a report from Cobalt Strike found that the JARM fingerprint of a Cobalt Strike server was the same as a Java\r\nserver. In addition, one can evade JARM fingerprinting by changing server-side configuration using a proxy.\r\nAS Number Distribution\r\nAn autonomous system (AS), which is identified by a unique number (e.g., OVH’s AS number is 16276, as shown in Figure\r\n26), refers to a large network or group of networks typically operated by a single large organization, such as an ISP or a\r\nlarge company. Therefore, by examining the distribution of AS numbers of the C2 IP addresses we can reveal the\r\norganizations that own or operate the corresponding servers.\r\nThere are 75 unique AS numbers associated with the 134 IP addresses (see Figure 28).  As the distribution shows, the most\r\ncommon AS number (139943 – located in Indonesia) is related to 16 IP addresses, and most of the AS numbers only have\r\none IP address each. The detailed AS numbers for all IP addresses can be found in the IoCs appendix section.\r\nFigure 28: IP address AS number distribution.\r\nConclusions\r\nIn this report, we first discussed the procedure to statically extract the internal DLL payload embedded in the original\r\nEmotet DLL payload delivered by a weaponized document. We then provided the detailed steps to extract the C2\r\nconfiguration contained in the decrypted DLL. To automate the process, we leverage the NSX Sandbox to dump the\r\ndecrypted internal DLL from memory during execution and feed it into our C2 configuration extractor for data extraction.\r\nThanks to our fully automated pipeline, we were able to successfully extract the C2 configuration data from all available\r\n2181 DLL payloads dropped by recent Emotet attacks that we observed in our telemetry. We then provided a comprehensive\r\nanalysis of the configuration data from epoch breakdown to the distributions of IP addresses, JARM fingerprints, ports and\r\nAS numbers, with interesting findings. For example, the epoch distribution shows that each epoch has almost distinct C2\r\nservers and Epoch 4 was the main botnet used in recent Emotet campaigns. In terms of port distribution, the secondary port\r\n8080 (commonly used by proxies) was the most used port. The JARM fingerprint distribution of the IP addresses with port\r\n443 implies that over 75% of the 40 evaluated servers shared the same fingerprint.\r\nAppendix: IoCs\r\nThe indicators of compromise identified from this report can be found on VMware TAU’s GitHub IoCs repository.\r\nSource: https://blogs.vmware.com/security/2022/03/emotet-c2-configuration-extraction-and-analysis.html\r\nhttps://blogs.vmware.com/security/2022/03/emotet-c2-configuration-extraction-and-analysis.html\r\nPage 18 of 18",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"Malpedia"
	],
	"references": [
		"https://blogs.vmware.com/security/2022/03/emotet-c2-configuration-extraction-and-analysis.html"
	],
	"report_names": [
		"emotet-c2-configuration-extraction-and-analysis.html"
	],
	"threat_actors": [],
	"ts_created_at": 1775791255,
	"ts_updated_at": 1775791338,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/84b9861d2e2d57db06c6daf92dff28af8cb4ac35.pdf",
		"text": "https://archive.orkl.eu/84b9861d2e2d57db06c6daf92dff28af8cb4ac35.txt",
		"img": "https://archive.orkl.eu/84b9861d2e2d57db06c6daf92dff28af8cb4ac35.jpg"
	}
}