{ "id": "eff80164-8c81-4fee-b482-5f97502e56e4", "created_at": "2026-04-06T00:11:14.613507Z", "updated_at": "2026-04-10T03:23:51.223319Z", "deleted_at": null, "sha1_hash": "56a855e1335e058dad9778dc5db25e81eeb13ac7", "title": "Why Emotet's Latest Wave is Harder to Catch Than Ever Before - Part2", "llm_title": "", "authors": "", "file_creation_date": "0001-01-01T00:00:00Z", "file_modification_date": "0001-01-01T00:00:00Z", "file_size": 260804, "plain_text": "Why Emotet's Latest Wave is Harder to Catch Than Ever Before -\r\nPart2\r\nBy Ron Ben YizhakSecurity Researcher\r\nPublished: 2020-10-12 · Archived: 2026-04-05 16:55:27 UTC\r\nEmotet, the largest malware botnet today, started in 2014 and continues to be one of the most challenging threats\r\nin today’s landscape. This botnet causes huge damage by spreading ransomware and info stealers to its infected\r\nsystems. Recently, a rise in the number of Emotet infections was observed in France, Japan, and New Zealand.\r\nThe high number of infections shows the effectiveness of the Emotet malware at staying undetected.\r\nThe previous wave of Emotet started in September 2019 and ended in February 2020. The activity was paused for\r\n5 months, and then, on July 17th, the current wave started. The creators behind Emotet are aware that\r\norganizations are getting more successful at detecting previous versions as they increase their infection rates.\r\nInevitably, the wave starts to drop as the industry gains a greater understanding and control of the threat.\r\nA point comes when the malware creators realize they need to go back to the lab. For a period of time, they go\r\nunder the radar completely as they start working on the next wave, making it as potent and evasive as possible.\r\nThe tactic seems to be working: After going dark for a few months, Emotet appears to have reemerged more\r\nevasive than before, this time with a payload delivered from a loader that security tools aren't equipped to handle.\r\nIn the previous article, we examined the Emotet loader. We revealed how it evades detection by inserting benign\r\ncode that subverts security products by obfuscating its malicious functionality. This loader contains a hidden\r\npayload that is decrypted and then executed. This payload uses new evasion techniques that were not seen in the\r\nloader, and it has some unique indicators that will lead us to the git repository used by the developers to generate\r\ntheir malware.\r\nWe collected reports published by cryptolaemus from July 17th, the beginning of the current wave, until\r\nSeptember 3rd. Based on this information 444,000 unique Emotet loaders were generated, with the peak occurring\r\nat the end of August.\r\nhttps://www.deepinstinct.com/2020/10/12/why-emotets-latest-wave-is-harder-to-catch-than-ever-before-part-2/\r\nPage 1 of 6\n\nIn this blog post, the writer investigates the payload that was encrypted inside the loader, analyzes the next steps in\r\nthe infection process, and discovers the techniques used to make this malware difficult to analyze.\r\nThe Shellcode\r\nIn the last step in the execution of the malware, a memory buffer was allocated, and the decrypted payload was\r\ncopied there. The payload consists of a shellcode followed by a PE file, and an overlay containing the string\r\n“dave”. The shellcode performs reflective loading on the PE file by executing the following steps:\r\n1. Read the PEB structure in order to locate the APIs necessary for its functionality such as LoadLibrary,\r\nVirtualAlloc, VirtualProtect, and more\r\n2. Allocate a memory buffer according to the value of SizeOfImage in the optional header\r\n3. Copy the image headers\r\n4. Copy the image sections and change the memory protection according to the section characteristics\r\n5. Retrieve the correct addresses of the functions listed in the IAT\r\n6. Perform relocations according to the relocations table\r\n7. Jump to the entry point\r\n8. Search a function whose name can be converted to the hash 0x30627745 and call it with the string “dave”\r\nfrom the overlay\r\nThis shellcode utilizes a malicious technique that loads the PE file in a way that makes it more difficult to detect\r\nusing memory forensics. It replaces the DOS header with zeroes in order to remove strings such as “MZ” and\r\n“This program cannot be run in DOS mode”. These strings can be used to detect PE files that were injected into\r\nmemory.\r\nhttps://www.deepinstinct.com/2020/10/12/why-emotets-latest-wave-is-harder-to-catch-than-ever-before-part-2/\r\nPage 2 of 6\n\nMemory comparison: on the left is the PE file after it is loaded by the shellcode and on the right is how it should\r\nlook.\r\nThere were a few unusual things about this shellcode:\r\n1. The shellcode searched the export table of the file for a function to call although it Isn’t a DLL and it\r\ncontains no exports.\r\n2. The string “dave” seemed out of place and meaningless.\r\n3. The hashing algorithm found is common among shellcodes and the hashes of the WinAPI used by the code\r\ncan be found in online repositories, but the hash of the exported function (0x30627745) didn’t appear there.\r\nSearching these indicators led to the git repository, which contains the source code for this shellcode. We found\r\nout that by default the shellcode searches for an export named “SayHello” in the file it loads and “dave” is a\r\nparameter that is sent to this function. The Emotet group didn’t change the default parameters in the script and that\r\nIOC led to the source code.\r\nNow that we know how the shellcode operates, we can move on to the PE file that was loaded, which is the final\r\npayload of the loader.\r\nThe Final Payload\r\nRemoving the shellcode and the overlay string from the data that was extracted from the loader resulted in this PE\r\nfile:\r\nD59853E61B8AD55C37FBA7D822701064A1F9CFAF609EE154EF0A56336ABA07C1\r\nCompared to the loader, which was disguised as a benign file, this file has clear malicious indicators:\r\n1. Code obfuscation – The malware’s developers used a complicated switch case to make the flow of code\r\ndifficult to understand. It contains many unnecessary jump instructions that make the debugging process\r\nlonger.\r\nhttps://www.deepinstinct.com/2020/10/12/why-emotets-latest-wave-is-harder-to-catch-than-ever-before-part-2/\r\nPage 3 of 6\n\nGraph overview of the main function generated using IDA, showing the code obfuscation.\r\n2. No strings – After performing static analysis on the sample, no meaningful strings were found. This is\r\nbecause the malware contains encrypted strings and decrypts them only when they are used. When\r\ndebugging the sample interesting strings were found such as registry keys used for persistence and format\r\nstrings used for HTTP requests.\r\n3. Avoid suspicious calls – Some API calls are known to be monitored by security products since many\r\nmalware strains abuse them. The malware needs to know if it runs with admin privileges in order to\r\ndetermine how deep inside the system it can install itself. Instead of using the simple API for it\r\n(IsUserAnAdmin), it tries to gain a handle with full access rights to the service control manager, which is\r\nonly accessible with admin rights. This method is less suspicious and might help the malware avoid certain\r\nheuristic detections used by security products.\r\n4. Empty import table – The malware hides its functionality and intents by not listing any API functions in its\r\nIAT. This way static analysis will not help us determine the malware capabilities and behavior. Instead, the\r\nmalware retrieves WinAPI addresses dynamically.\r\nMuch like the shellcode previously discussed, it reads the PEB structure, but it also uses a unique hashing\r\nalgorithm so standard hash dictionaries for WinAPI won’t help to convert the hashes the code uses back to strings.\r\nIn order to make the code easier to understand we’ll have to create our own dictionary.\r\nhttps://www.deepinstinct.com/2020/10/12/why-emotets-latest-wave-is-harder-to-catch-than-ever-before-part-2/\r\nPage 4 of 6\n\nWhen looking at the disassembly, the hashing algorithm looks complicated, but it contains a lot of mathematical\noperations that cancel each other out. Using IDA pseudo-code utility, we can convert it to a simple C code. This\ncode was used to create a dictionary with hashes of many DLL files and API names. We wrote a script that uses\nIDAPython in order to add the name of the dll files and APIs next to the hashes in the code.import idautilsimport json\nhashes_dict = json.load(open(\"emot\ndlls_set = set()\napis_set = set()for func in idautils.Functions():\n flags = idc.get_func_attr(func, FUNCATTR_FLAGS) # skip library \u0026 thunk functions if flags \u0026 FUNC_LIB or flags \u0026 FUNC_THUNK: continue dism_addr = list(idautils.FuncItems(func)) for ea in dism_addr: if idc.print_insn_mnem(ea) == # ecx contains the hash respresenting the dll if register == 'ecx'\u003c/ if value in hashes_dict[\"dlls\"][value]\n dlls_set.add(dll_name)\n idc.set_cmt(ea, dll_name, 0) # edx contains the hash respresenting the API elif register == \"edx if value in hashes_dict[\"apis\"][value]\n apis_set.add(api)\n idc.set_cmt(ea, api, 0)print(f\"{len(dlls_set)} DLLs and {IDAPython script that adds the hidden imports to the code The purpose of this malware is to send information to the C2 servers about the infected system and receive\ncommands as well as other files to execute. The file contains a list of IP addresses that are iterated over until a\nresponse is received from one of the servers.\nThe malware collects information such as the computer name and running processes, encrypts the data using AES,\nand sends it over HTTP. The server sends back malware such as ransomware and info stealers that are executed on\nthe infected system.\nhttps://www.deepinstinct.com/2020/10/12/why-emotets-latest-wave-is-harder-to-catch-than-ever-before-part-2/\nPage 5 of 6\n\nSummary\r\nIn this blog post, we analyzed the next steps in the execution of the Emotet malware. We discovered that the\r\nattackers used a publicly accessible shellcode generator, which contained unique indicators. Next, we looked at\r\nthe final payload of the loader that was responsible for communicating with the C2 servers and downloading\r\nadditional files. Although much effort was put into making the code hard to understand, we showed how to make\r\nit decipherable. By observing the entire infection process done by the Emotet malware, we can see how this botnet\r\nachieves going undetected for such long periods.\r\nSource: https://www.deepinstinct.com/2020/10/12/why-emotets-latest-wave-is-harder-to-catch-than-ever-before-part-2/\r\nhttps://www.deepinstinct.com/2020/10/12/why-emotets-latest-wave-is-harder-to-catch-than-ever-before-part-2/\r\nPage 6 of 6", "extraction_quality": 1, "language": "EN", "sources": [ "ETDA", "Malpedia" ], "references": [ "https://www.deepinstinct.com/2020/10/12/why-emotets-latest-wave-is-harder-to-catch-than-ever-before-part-2/" ], "report_names": [ "why-emotets-latest-wave-is-harder-to-catch-than-ever-before-part-2" ], "threat_actors": [ { "id": "d90307b6-14a9-4d0b-9156-89e453d6eb13", "created_at": "2022-10-25T16:07:23.773944Z", "updated_at": "2026-04-10T02:00:04.746188Z", "deleted_at": null, "main_name": "Lead", "aliases": [ "Casper", "TG-3279" ], "source_name": "ETDA:Lead", "tools": [ "Agentemis", "BleDoor", "Cobalt Strike", "CobaltStrike", "RbDoor", "RibDoor", "Winnti", "cobeacon" ], "source_id": "ETDA", "reports": null } ], "ts_created_at": 1775434274, "ts_updated_at": 1775791431, "ts_creation_date": 0, "ts_modification_date": 0, "files": { "pdf": "https://archive.orkl.eu/56a855e1335e058dad9778dc5db25e81eeb13ac7.pdf", "text": "https://archive.orkl.eu/56a855e1335e058dad9778dc5db25e81eeb13ac7.txt", "img": "https://archive.orkl.eu/56a855e1335e058dad9778dc5db25e81eeb13ac7.jpg" } }