{
	"id": "6f4ce741-a303-4b58-a411-7fbb34be2d15",
	"created_at": "2026-04-06T00:22:06.762194Z",
	"updated_at": "2026-04-10T13:13:04.051901Z",
	"deleted_at": null,
	"sha1_hash": "36d29757d15807abeb39d7a3b2b9118d2a4c0624",
	"title": "Emotet Analysis: Why Emotet's Latest Wave is Harder to Catch",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 787651,
	"plain_text": "Emotet Analysis: Why Emotet's Latest Wave is Harder to Catch\r\nBy Ron Ben YizhakSecurity Researcher\r\nPublished: 2020-08-12 · Archived: 2026-04-05 19:49:55 UTC\r\nAfter five months of inactivity, the prolific and well-known Emotet botnet re-emerged on July 17th. The purpose\r\nof this botnet is to steal sensitive information from victims or provide an installation base for additional malware\r\nsuch as TrickBot, which then in many cases will drop ransomware or other malware. So far, in the current wave, it\r\nwas observed delivering QakBot.\r\nIn this blog post, we reveal some novel evasion techniques which assist the new wave of Emotet to avoid\r\ndetection. We discovered how its evasion techniques work and how to overcome them. The first part of the\r\nmalware execution is the loader which is examined in this article, with an emphasis on the unpacking process. We\r\nalso partition the current wave into several clusters, each cluster has some unique shared properties among the\r\nsamples.\r\nClustering the samples\r\nA dataset of 38 thousand samples was created using data collected by the Cryptolaemus group, from July 17th to\r\nJuly 28th. This group divides the samples into three epochs, which are separate botnets that operate independently\r\nfrom one another.\r\nStatic information was extracted from each sample in order to find consistent patterns across the entire data set.\r\nThe information that is relevant to identify patterns includes the size and entropy of the .text, .data, .rsrc sections,\r\nand the size of the whole file, so this information was extracted from all the files. We started our analysis with two\r\nsamples, an overview for which is provided in the image below. By looking at each file size we can see that the\r\nratio of these sections remains the same, and the entropy differs very little between the files.\r\nhttps://www.deepinstinct.com/2020/08/12/why-emotets-latest-wave-is-harder-to-catch-than-ever-before/\r\nPage 1 of 8\n\nImage shows different Emotet samples having sections with the same size and entropy\r\nThis also results in completely identical code. The two samples presented above were compared using the\r\ndiaphora plugin for IDA, and all the functions were identical.\r\nComparing the code of the two samples shows they share the exact same subroutines\r\nGrouping the entire dataset by the size of the files resulted in 272 unique sizes of files. The files matching each\r\nsize were then checked to see if they have the same static information. This way we discovered 102 templates of\r\nEmotet samples.\r\nEach sample in the dataset that matched a template was tagged with a template ID and with an epoch number, as\r\nindicated by the Cryptolaemus group. This means that the operators behind each epoch have their own Emotet\r\nloaders. The various templates might help reduce the detection rate of the samples used by the entire operation. If\r\na specific template has a unique feature that can be signed, it won’t affect samples belonging to other templates\r\nand epochs.\r\nMost packers today provide features such as various encryption algorithms, integrity checks and evasion\r\ntechniques. These templates are most likely the result of different combinations of flags and parameters in the\r\npacking software. Each epoch has different configurations for the packing software resulting in clusters of files\r\nthat have the same static information.\r\nIdentifying benign code\r\nThe Emotet loader contains a lot of benign code as part of its evasion. A.I. based security products rely on both\r\nmalicious and benign features when classifying a file. In order to bypass products like that, malware authors can\r\ninsert benign code into their executable files to reduce the chance of them being detected. This is called an\r\nadversarial attack and its effectiveness is seen in security solutions based on machine learning.\r\nBy looking at the analysis done by Intezer on a specific Emotet sample from the new wave, we can see that the\r\nbenign code might be taken from Microsoft DLL files that are part of the Visual C++ runtime environment.\r\nAlternatively, the benign software could be completely unrelated to the functioning of the sample.\r\nThe following screenshot shows the similarities between the previous sample and a benign Microsoft DLL file,\r\nusing the diaphora plugin:\r\nhttps://www.deepinstinct.com/2020/08/12/why-emotets-latest-wave-is-harder-to-catch-than-ever-before/\r\nPage 2 of 8\n\nThe Emotet loader contains benign code taken from a Microsoft DLL\r\nUnder the column “Name” there are functions from the malware, and under the column “Name 2” there are\r\nfunctions from the benign file. As we can see, the malware contains much benign code which isn’t necessarily\r\nneeded.\r\nThe next step is to check how much of the code is actually used. This can be done using the tool drcov by\r\nDynamoRIO. This tool executes binary file and tracks which parts of the code are used. The log produced by this\r\ntool can later be processed by the lighthouse plugin for IDA. This plugin integrates the execution log into the IDA\r\ndatabase in order to visualize which functions are used. The analysis was performed on the sample shown so far,\r\nthe result is that just 16.22% of the code is executed\r\nThe report produced by the lighthouse plugin showing which functions were executed\r\nhttps://www.deepinstinct.com/2020/08/12/why-emotets-latest-wave-is-harder-to-catch-than-ever-before/\r\nPage 3 of 8\n\nAfter we filtered out benign code that was injected into the executable, we can compare the code of different\r\nvariants to locate the malicious functions which exist in every sample.\r\nDiagram shows code from different clusters sharing the same malicious functionality.\r\nFiltering out benign functions helps to reveal the malicious code, but it can also be found using dynamic analysis,\r\nwhich will be discussed in the next section.\r\nFinding the encrypted payload\r\nThe executable previously shown is an Emotet loader. The main purpose of the loader is to decrypt the payload\r\nhidden in the sample and execute it. The payload consists of a PE file and a shellcode that loads it. The encrypted\r\npayload will cause the section it resides in to have high entropy. Based on the dataset we collected, 87% of the\r\nfiles had the payload in the .data section and 13% of the files had the payload in the .rsrc section. Tools like\r\npestudio show the entropy of each section and each resource. For example, the resources of a sample with the\r\npayload lies encrypted in the “9248” resource:\r\nIn order to find the code that decrypts the resource, we can put a hardware breakpoint at the start of the resource.\r\nPestudio showing the resources with the highest entropy in the Emotet loader\r\nIn cases where the payload is inside the .data section, it’s unclear where it starts. We can approximate it by\r\ncalculating the entropy for small bulks of the section and find where the score starts to rise.\r\nhttps://www.deepinstinct.com/2020/08/12/why-emotets-latest-wave-is-harder-to-catch-than-ever-before/\r\nPage 4 of 8\n\nimport sysimport mathimport pefile\nBULK_SIZE = 256def entropy(byteArr):\n arrSize = len(byteArr)\n freqList = [] for b in range(256)\n ctr = 0 for byte in byteArr: if byte == b:\n ctr += 1\n freqList.append(float(ctr) / arrSize)\n ent = 0.0 for freq in freqList: if freq \u003e 0:\n ent = ent + freq * math.log(freq, 2)\n ent = -ent return ent\npe_file = pefile.PE(sys.argv[1])\ndata_section = next(section forlen(data_section_buffer)\nbulks = [data_section_buffer[i:i+BULK_SIZE] for i in for i, bulk in enumerate(bu print(hex(data_secti\nPython script that calculates the entropy of small portions of the .data section\nOnce we know where the payload is located, we’ll be able to find the code that decrypts it, and that is where the\nmalicious action starts.\nAnalyzing the malicious code\nFor this part, we’ll look at the sample:\n249269aae1e8a9c52f7f6ae93eb0466a5069870b14bf50ac22dc14099c2655db.\nIn this sample, the script indicates that the beginning of the data section contains the payload although it may vary\nin other samples. We will put the breakpoint at the address 0x406100. The breakpoint was hit at the address\n0x40218C which is in the function sub_401F80. After looking at this function, we notice a few suspicious things:\nhttps://www.deepinstinct.com/2020/08/12/why-emotets-latest-wave-is-harder-to-catch-than-ever-before/\nPage 5 of 8\n\n1. This function builds strings on the stack in order to hide its intents. It uses GetProcAddress to find the address\r\nof VirtualAllocExNuma and calls it to allocate memory for the payload.\r\nThe loader conceals suspicious API calls\r\n2. It calculates the parameters for VirtualAllocExNuma during runtime, to hide the allocation of RWX memory.\r\nThe function atoi is being used to convert the string “64” to int, which is PAGE_EXECUTE_READWRITE. Also,\r\nthe string “8192” is converted to 0x3000 which means the memory is allocated with the flags MEM_COMMIT\r\nand MEM_RESERVE.\r\nhttps://www.deepinstinct.com/2020/08/12/why-emotets-latest-wave-is-harder-to-catch-than-ever-before/\r\nPage 6 of 8\n\nThe parameters were saved as strings to obfuscate the API call\r\nThe payload is then copied from the .data section to the RWX memory (that is where our breakpoint hit). The\r\ndecryption routine is being called and then the shellcode is being executed.\r\nThe loader decrypts the payload and continues to the next step in the execution of the malware\r\nIn this blog post we looked at the static information of the new Emotet loader, revealed how to cluster similar\r\nsamples, and found how to locate the malicious code and its payload. In addition, we exposed how the loader\r\nevades detection; primarily the loader hides the malicious API calls using obfuscation, but it also injects benign\r\ncode to manipulate the algorithms of AI-based security products. Both processes have been shown to reduce the\r\nchance of the file being detected. The cumulative effect of these techniques makes the Emotet group one of the\r\nmost advanced campaigns in the threat landscape.\r\nUpdate\r\nRead more about the hidden payload in the Emotet loader that is decrypted and then executed to successfully\r\navoid being detected.\r\nhttps://www.deepinstinct.com/2020/08/12/why-emotets-latest-wave-is-harder-to-catch-than-ever-before/\r\nPage 7 of 8\n\nSource: https://www.deepinstinct.com/2020/08/12/why-emotets-latest-wave-is-harder-to-catch-than-ever-before/\r\nhttps://www.deepinstinct.com/2020/08/12/why-emotets-latest-wave-is-harder-to-catch-than-ever-before/\r\nPage 8 of 8",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"ETDA",
		"Malpedia"
	],
	"origins": [
		"web"
	],
	"references": [
		"https://www.deepinstinct.com/2020/08/12/why-emotets-latest-wave-is-harder-to-catch-than-ever-before/"
	],
	"report_names": [
		"why-emotets-latest-wave-is-harder-to-catch-than-ever-before"
	],
	"threat_actors": [],
	"ts_created_at": 1775434926,
	"ts_updated_at": 1775826784,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/36d29757d15807abeb39d7a3b2b9118d2a4c0624.pdf",
		"text": "https://archive.orkl.eu/36d29757d15807abeb39d7a3b2b9118d2a4c0624.txt",
		"img": "https://archive.orkl.eu/36d29757d15807abeb39d7a3b2b9118d2a4c0624.jpg"
	}
}