{ "id": "923649ac-c13f-404e-bbdf-d593b26727ca", "created_at": "2026-04-06T00:19:02.969093Z", "updated_at": "2026-04-10T13:11:35.620607Z", "deleted_at": null, "sha1_hash": "33a1cfe083d2825325c133f5d5dba0c16951f725", "title": "Fantastic payloads and where we find them", "llm_title": "", "authors": "", "file_creation_date": "0001-01-01T00:00:00Z", "file_modification_date": "0001-01-01T00:00:00Z", "file_size": 2249773, "plain_text": "Fantastic payloads and where we find them\r\nBy Michael Kajiloti\r\nPublished: 2020-03-30 · Archived: 2026-04-02 10:49:22 UTC\r\nAttackers have long used evasion features in their malware to avoid detection by security products and analysis\r\nsystems. One of the most common anti-analysis tricks we have seen in today’s Windows malware is the use of\r\npackers. Packers often complicate the analysis and detection of binary files by hiding the malware’s real code and\r\ndata; often referred to as the payload.\r\nThe most common solution to overcome packing is the use of dynamic analysis (sandboxes) and emulation\r\nsystems. However, as these solutions have become more mainstream, packers have started to incorporate new\r\nanti-analysis methods to both detect and evade these systems.\r\nOne such anti-analysis method which is becoming increasingly popular is the malformation or complete removal\r\nof the Windows PE header from unpacked malicious payloads. This can make both finding the malware payload\r\nand properly analyzing its code more challenging.\r\nWhile removal of Windows PE headers from malicious payloads is not an entirely new method, we are seeing\r\nsome of the most popular and sophisticated crimeware families fully incorporate this approach into their packers.\r\nBelow we will present some examples that demonstrate this trend through our Genetic Malware Analysis\r\nplatform, Intezer Analyze.\r\nOn packers and payloads\r\nWhen we investigate a packed malware file, the malware (payload) itself is encrypted or encoded and therefore we\r\ncan’t access its real code and data. Typically, in order to analyze the malware’s code, we must execute the file in a\r\nsandboxed environment, let it unpack itself, and then grab the payload from memory.\r\nWhile various malware and packers operate in different ways, an abstraction of a typical unpacking flow looks\r\nlike this:\r\nhttps://intezer.com/blog/intezer-analyze/fantastic-payloads-and-where-we-find-them\r\nPage 1 of 8\n\nIn this flow we can see that the packer will decode and execute a shellcode component that will in turn decode and\r\nexecute the real payload. This is just a common scenario; some packers will not use a shellcode loader and instead\r\nthey will unpack the payload directly. It’s worth noting that unlike the packer’s code, which is designed to be\r\nobfuscated and appear random, we have observed that these shellcode components are often reused. This means\r\nthat these components generally have more value than the packer itself when investigating them with code reuse\r\nanalysis. Therefore, detecting and analyzing this component’s code can be worthwhile for us.\r\nWith that said, finding and analyzing the malware module itself is by far the most effective way to properly detect\r\nand classify packed malware. The most common way to identify malware payloads in memory is to search for PE\r\nheader artifacts. Knowing this, many attackers try to stay undetected by removing these artifacts from the PE\r\nHeader of the payload, or by using no PE header at all, as we’ll see soon in the examples presented in this article.\r\nThe many faces of Emotet\r\nEmotet is one of the most widespread malware in the crimeware ecosystem which has undergone a number of\r\nupdates since its inception. In particular, we have noticed that this malware is constantly evolving and adapting,\r\nboth in the malware code itself, and in the packers it uses. While switching the packer is relatively inexpensive for\r\nthe attacker and happens frequently, modifying the malware’s code is much more costly and happens rarely.\r\nAn interesting example of this can be seen when we compare the following Emotet samples:\r\nEmotet sample from June 2019:\r\n8e5089260064a955819a92ebccc43d05520e32d234dd3c176bed5f6d0665ebdb\r\nEmotet sample from December 2019:\r\n3e8a273f80575ab6079d6512008bb6355b59de978fabc2a9a66c0ed148b94fef\r\nWhen looking at the code of the packed files themselves, we can see just how different these samples are, showing\r\nno apparent connections to one another:\r\nPacker (June 2019) – 8e5089260064a955819a92ebccc43d05520e32d234dd3c176bed5f6d0665ebdb\r\nhttps://intezer.com/blog/intezer-analyze/fantastic-payloads-and-where-we-find-them\r\nPage 2 of 8\n\nPacker (December 2019) – 3e8a273f80575ab6079d6512008bb6355b59de978fabc2a9a66c0ed148b94fef\r\nBut if we look at the unpacked memory module payloads after undergoing dynamic analysis, we can see that they\r\nare nearly identical from a binary code perspective:\r\nPayload (June 2019) – 8e5089260064a955819a92ebccc43d05520e32d234dd3c176bed5f6d0665ebdb\r\nhttps://intezer.com/blog/intezer-analyze/fantastic-payloads-and-where-we-find-them\r\nPage 3 of 8\n\nPayload (December 2019) – 3e8a273f80575ab6079d6512008bb6355b59de978fabc2a9a66c0ed148b94fef\r\nThere is one notable exception: in the December 2019 sample, the payload memory module has a “malformed\r\nheader” tag. In this case, this indicates that the packer loaded the module with a PE Header that’s missing certain\r\nPE artifacts, such as the “MZ” magic or other PE Header constants. This is usually done in an attempt to make it\r\nmore difficult to find these modules in memory, since the most common method of finding PE memory modules is\r\nby scanning for these artifacts.\r\nIt is worth mentioning that in Intezer Analyze we repair the malformed header as part of our analysis process.\r\nDownloading and examining the memory module will reveal that it has a full PE header.\r\nIt is also important to note that even in the instance of a constantly evolving threat such as Emotet, when the\r\nattacker modifies the code of the malware itself, there are still parts that remain unchanged. Therefore, when\r\nIntezer Analyze executes the malware, finds its payload, and then analyzes its code, we can still detect those traces\r\nto Emotet’s code that have not been modified.\r\nThis can be observed when we investigate a recent sample of Emotet from March 2020. Looking at the packer’s\r\ncode, we can see that it is different yet again, and has no relations to any code we have seen previously:\r\nPacker (March 2020) – C6684aa4af41685ffc584c1b1bb78855c894b3dae7f6fae4fb572bc02525102f\r\nHowever, when we look at the memory module payload itself, we can see that some of the code is new and has\r\nbeen modified from previous versions. Most importantly, a substantial part of the code has been reused from\r\nprevious Emotet variants that we have seen before:\r\nPayload (March 2020) – C6684aa4af41685ffc584c1b1bb78855c894b3dae7f6fae4fb572bc02525102f\r\nhttps://intezer.com/blog/intezer-analyze/fantastic-payloads-and-where-we-find-them\r\nPage 4 of 8\n\nWhen less is more\r\nWhile using a malformed PE Header is a relatively simple trick, using no PE header at all is a more sophisticated\r\nand complicated affair. It takes more than just removing a few unused magic constants from the header in order to\r\nconceal it. This method requires loading and executing the payload just like shellcode.\r\nWhen malware authors write and compile the malware payload itself, it is usually compiled and built into the form\r\nof standard PE files, not position independent shellcode. Directly converting a sophisticated malware’s codebase\r\nsuch as Dridex or TrickBot to run like shellcode can be complicated.\r\nMost malware authors choose a simpler option, using a packer that unpacks and loads the payload module without\r\nusing its PE Header at load time. These packers typically store the relevant information from the PE header, such\r\nas API import and relocations data, in a custom structure during packing time. The packer then uses that structure\r\nduring the unpacking process in order to properly load the malware code.\r\nSame Dridex, new tricks\r\nAn example of a popular malware that has recently adopted such a packer is the Dridex banking trojan. Let’s\r\ncompare two recent Dridex samples from February 2020:\r\n9b6ffb05ec826b3fbff7db04ebd187e2f956a5730af1d36e10a9f56ee1bb767a\r\n45e0408d3ae2647cb9be835a5277eb7de41c83d8e473d22d5b3772c2f65305fb\r\nSimilar to Emotet, these packed files are very different from one another at the code level, showing no\r\nresemblance:\r\nPacker – 9b6ffb05ec826b3fbff7db04ebd187e2f956a5730af1d36e10a9f56ee1bb767a\r\nPacker – 45e0408d3ae2647cb9be835a5277eb7de41c83d8e473d22d5b3772c2f65305fb\r\nHowever, when we look at the payloads themselves, we can see again that they are actually very similar:\r\nhttps://intezer.com/blog/intezer-analyze/fantastic-payloads-and-where-we-find-them\r\nPage 5 of 8\n\nPayload – 9b6ffb05ec826b3fbff7db04ebd187e2f956a5730af1d36e10a9f56ee1bb767a\r\nPayload – 45e0408d3ae2647cb9be835a5277eb7de41c83d8e473d22d5b3772c2f65305fb\r\nThere is one notable exception here as well, but in this case it is much more substantial. In the second payload we\r\ncan see the “fileless_code” tag, which indicates this module has no PE header. Downloading and examining this\r\nmodule will make it known that it is indeed a binary file with no structure.\r\nIntezer Analyze detects these modules during dynamic analysis and analyzes their code even though no PE Header\r\nis present. It will also detect any other shellcode pieces that are used by the malware.\r\nLook ma! No heads!\r\nTo demonstrate how prevalent this trend is, let’s look at the analyses of recent samples of the Ursnif and TrickBot\r\nmalware. When looking at the dynamic analysis modules, we see several different malicious modules that are\r\ndetected and analyzed:\r\nhttps://intezer.com/blog/intezer-analyze/fantastic-payloads-and-where-we-find-them\r\nPage 6 of 8\n\nIf we review them more closely, we will see that all of them  — minus copies of the original packer file — have\r\nthe “fileless_code” tag, indicating that they are all shellcode-style modules with no PE header:\r\nTrickBot – 26d61225f07e39d9e35880631c5043626eb8e3846a526a44015d3a5d03642d55\r\nhttps://intezer.com/blog/intezer-analyze/fantastic-payloads-and-where-we-find-them\r\nPage 7 of 8\n\nConclusion\r\nThe use of pure shellcode and shellcode-style components in modern malware seems to be a growing trend, one\r\nthat is being adopted by some of the most successful malware developers. At the same time, when we identify and\r\nanalyze these components using code reuse analysis, we can see that they are mostly just a different version of the\r\nsame thing. We encourage you to analyze your files using the free Intezer Analyze community edition. You might\r\ndetect malicious payloads that you didn’t expect to find!\r\nSource: https://intezer.com/blog/intezer-analyze/fantastic-payloads-and-where-we-find-them\r\nhttps://intezer.com/blog/intezer-analyze/fantastic-payloads-and-where-we-find-them\r\nPage 8 of 8", "extraction_quality": 1, "language": "EN", "sources": [ "Malpedia" ], "origins": [ "web" ], "references": [ "https://intezer.com/blog/intezer-analyze/fantastic-payloads-and-where-we-find-them" ], "report_names": [ "fantastic-payloads-and-where-we-find-them" ], "threat_actors": [ { "id": "77b28afd-8187-4917-a453-1d5a279cb5e4", "created_at": "2022-10-25T15:50:23.768278Z", "updated_at": "2026-04-10T02:00:05.266635Z", "deleted_at": null, "main_name": "Inception", "aliases": [ "Inception Framework", "Cloud Atlas" ], "source_name": "MITRE:Inception", "tools": [ "PowerShower", "VBShower", "LaZagne" ], "source_id": "MITRE", "reports": null } ], "ts_created_at": 1775434742, "ts_updated_at": 1775826695, "ts_creation_date": 0, "ts_modification_date": 0, "files": { "pdf": "https://archive.orkl.eu/33a1cfe083d2825325c133f5d5dba0c16951f725.pdf", "text": "https://archive.orkl.eu/33a1cfe083d2825325c133f5d5dba0c16951f725.txt", "img": "https://archive.orkl.eu/33a1cfe083d2825325c133f5d5dba0c16951f725.jpg" } }