{ "id": "7afe8f0b-fd7f-47a9-8bee-95801fcc0dc7", "created_at": "2026-04-06T00:16:42.018698Z", "updated_at": "2026-04-10T13:11:48.339227Z", "deleted_at": null, "sha1_hash": "145cee373c443f20adc6fd052185a5e7a04d95f8", "title": "Analysis of the latest wave of Emotet malicious documents", "llm_title": "", "authors": "", "file_creation_date": "0001-01-01T00:00:00Z", "file_modification_date": "0001-01-01T00:00:00Z", "file_size": 1581540, "plain_text": "Analysis of the latest wave of Emotet malicious documents\r\nBy Chris Campbell\r\nPublished: 2020-08-31 ยท Archived: 2026-04-05 14:27:14 UTC\r\nIn the first technical blog post from the Security Team, we're going to take a look at the latest wave of Emotet\r\nfrom a specific angle: the downloader document (or maldoc).\r\nDistributed as an attachment via malspam, the operators tend to play it fairly safely with the range of lures they\r\nemploy in emails - however they are still fairly advanced when compared to other large scale campaigns. Over the\r\npast week we've observed a fairly even spread of generic templates (e.g. shipping, invoices, scanned documents)\r\nand reply-to messages, with more effort seemingly being made to appear more geographically relevant. Messages\r\nalmost always leverage the names of legitimate organisations and employees from the same region. In the case of\r\nreply-to messages, email exfiltrated in past (or current) compromise is responded to via another compromised\r\naccount with a standard request to open the attachment - though it's not uncommon to encounter messages that\r\nonly have a signature.\r\nThe\r\nlatest document template, dubbed \"Red Dawn\", was first seen on 26th August NZT. It was at about this time that\r\nwe also saw the volume of Emotet mail hitting NZ customers significantly ramp up. Emotet consists of three\r\nbotnets known as Epoch 1, 2 and 3. In the most recent wave, we have only observed NZ targeted by Epoch 1 and\r\n2. While there are no notable differences in documents between the 3, email templates can vary depending on\r\nwhich botnet they come from and post-compromise behavior also differs.\r\nhttps://www.inde.nz/blog/analysis-of-the-latest-wave-of-emotet-malicious-documents\r\nPage 1 of 6\n\nAs\r\nseen above, the document requests for editing and content to be enabled to permit the macro to execute. Upon\r\nexecution, the Document_load() function is invoked, which calls a function in a custom form.\r\nAt first glance the function appears to be rather\r\ncomplex, however after following the code it becomes apparent that klEP6Sq and duFdpjP83 do absolutely\r\nnothing other than fill space. After each pairing of these variable declarations are commands that serve as the\r\nfunctional portion of the script (highlighted with breakpoints). For example, here an obfuscated string is declared\r\nas the variable that begins with \"Jcu\" which is then passed to the deobfuscation function (more on that in a\r\nmoment). This is used to define the Win32 Process object that will later be used to launch PowerShell.\r\nSimilar\r\nto the above, another function takes the value of the Control Tip for a tab on the form and passes it to the same\r\ndeobfuscation function. It is the output of this function that forms the PowerShell command that retrieves and\r\nexecutes the Emotet payload.\r\nhttps://www.inde.nz/blog/analysis-of-the-latest-wave-of-emotet-malicious-documents\r\nPage 2 of 6\n\nThe\r\ndeobfuscation function turns out to be fairly basic:\r\nTakes the input string and saves it as a variable.\r\nSplits the string into an array, defining a series of alphanumeric characters and parentheses as the separator.\r\nRe-joins the output of the array to form the output of the function.\r\nWhile\r\nbasic, doing this by hand would be time consuming, so let's automate it with Python. olevba is used to extract the\r\nControlTip text, from which the separator string is determined:\r\nThe\r\ndeobfuscated string is of the format \"powersheLL -e \u003cbase64 blob\u003e\". We only want the blob, so that's pulled off:\r\nhttps://www.inde.nz/blog/analysis-of-the-latest-wave-of-emotet-malicious-documents\r\nPage 3 of 6\n\nNaturally, the base64 is decoded and presents what looks a little more like a PowerShell script:\r\nObfuscation is removed, leaving a clean string that URLs can be extracted from:\r\nhttps://www.inde.nz/blog/analysis-of-the-latest-wave-of-emotet-malicious-documents\r\nPage 4 of 6\n\nThe same script works just fine for other\r\nrecent samples, too:\r\nIt's a\r\ncommonly observed mistake for analysts to throw Emotet maldocs into sandboxes and assume that the first URL\r\nthat gets requested is the only one for the document, where there should always be 5 or 7. Where one request fails,\r\nthe next URL from the list will be requested.\r\nAs has been illustrated, with a little work you can develop safer, faster and reusable analytical methods. While\r\nthere are methods also known for extracting the full URL set through dynamic analysis (and the same works for\r\ndiscovering the C2 set of the payload), static analysis is always going to be the safer approach as you're not having\r\nto touch adversary infrastructure. While the above method is only valid so long as the script used to generate the\r\nmacros doesn't change, it still serves as a reliable template for an approach and requires little work to adapt to\r\nchanging conditions.\r\nTo keep up to date with Emotet developments, we recommend following @Cryptolaemus1 on Twitter. Abuse.ch\r\nalso provide an excellent feed of Emotet indicators that can be ingested in a variety of formats:\r\nPayload URL\r\nPayload C2\r\nFile SHA256\r\nAll IndeSIEM customers benefit from these detections via integration with LogRhythm. We will also be\r\ncontinuing frequent testing of samples to ensure IndeEDR customers have full coverage.\r\nThose with an ANY.RUN account can download the sample described in this post here.\r\nhttps://www.inde.nz/blog/analysis-of-the-latest-wave-of-emotet-malicious-documents\r\nPage 5 of 6\n\nIf you'd like to find out more about how Inde can help detect these security threats, you can contact us here.\r\nChris Campbell\r\nChris was that notoriously disobedient kid who sat at the back of the class and always seemed bored, but\r\nsomehow still managed to ace all of his exams. Obsessed with the finer details and mechanics of everything in\r\nboth the physical and digital realms, Chris serves as the Technical Director within the Inde Security Team. His\r\nventures into computer security began at an early age and haven't slowed down since. After a decade spent across\r\nsecurity and operations, and evenings spent diving into the depths of malware and operating systems, he brings a\r\nwealth of knowledge to Inde along with a uniquely adversary focused approach to defence. Like many others at\r\nInde, Chris likes to unwind by hitting the bike trails or pretending to be a BBQ pitmaster. He is also heavily\r\ninvolved in the leadership of security events, trust groups and research projects.\r\nSource: https://www.inde.nz/blog/analysis-of-the-latest-wave-of-emotet-malicious-documents\r\nhttps://www.inde.nz/blog/analysis-of-the-latest-wave-of-emotet-malicious-documents\r\nPage 6 of 6", "extraction_quality": 1, "language": "EN", "sources": [ "Malpedia" ], "origins": [ "web" ], "references": [ "https://www.inde.nz/blog/analysis-of-the-latest-wave-of-emotet-malicious-documents" ], "report_names": [ "analysis-of-the-latest-wave-of-emotet-malicious-documents" ], "threat_actors": [ { "id": "75108fc1-7f6a-450e-b024-10284f3f62bb", "created_at": "2024-11-01T02:00:52.756877Z", "updated_at": "2026-04-10T02:00:05.273746Z", "deleted_at": null, "main_name": "Play", "aliases": null, "source_name": "MITRE:Play", "tools": [ "Nltest", "AdFind", "PsExec", "Wevtutil", "Cobalt Strike", "Playcrypt", "Mimikatz" ], "source_id": "MITRE", "reports": null } ], "ts_created_at": 1775434602, "ts_updated_at": 1775826708, "ts_creation_date": 0, "ts_modification_date": 0, "files": { "pdf": "https://archive.orkl.eu/145cee373c443f20adc6fd052185a5e7a04d95f8.pdf", "text": "https://archive.orkl.eu/145cee373c443f20adc6fd052185a5e7a04d95f8.txt", "img": "https://archive.orkl.eu/145cee373c443f20adc6fd052185a5e7a04d95f8.jpg" } }