{
	"id": "7c7f168e-4635-4b16-9ecc-27c2a2c69b8a",
	"created_at": "2026-04-06T00:08:02.711592Z",
	"updated_at": "2026-04-10T03:22:07.712692Z",
	"deleted_at": null,
	"sha1_hash": "0a00a7c9d890bce9d92f6e8fdac7ed9d05062515",
	"title": "Emotet Is Not Dead (Yet) – Part 2",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 2265892,
	"plain_text": "Emotet Is Not Dead (Yet) – Part 2\r\nBy Jason Zhang\r\nPublished: 2022-02-07 · Archived: 2026-04-05 16:51:19 UTC\r\nContributor: Jason Zhang\r\nEmotet attacks leveraging malicious macros embedded in Excel files continue, with new variants and novel\r\ntactics, techniques, and procedures (TTPs). Following our recent report, we observed new waves of Emotet\r\ncampaigns abusing legitimate Windows features, such as batch scripts and the mshta utility, combined with\r\nPowerShell, to deliver Emotet payloads.\r\nIn this follow-up blog post, we first provide an overview of the delivery processes of Emotet payloads in typical\r\nattacks. Then, we examine the recent variants and reveal how techniques evolved in these attacks.\r\nEmotet payload delivery chain\r\nThe Emotet infection chain typically starts with a spam email containing a malicious document in the attachment\r\n(see Figure 1). The attachment can be either a Word document or an Excel file with embedded VBA or Excel 4.0\r\n(XL4) macros. To entice the user to enable macro execution in Microsoft Word or Excel, the file displays social\r\nengineering content when opened. Once macro execution has been enabled, the embedded macro is executed,\r\nleading to the delivery process of an Emotet payload.\r\nhttps://blogs.vmware.com/networkvirtualization/2022/02/emotet-is-not-dead-yet-part-2.html/\r\nPage 1 of 13\n\nFigure 1: A typical Emotet payload delivery chain.\r\nAs highlighted in Figure 1, there are typically two ways to deliver an Emotet payload:\r\nExecuting macros to download the payload from a remote server directly: this can be achieved by invoking\r\nthe WinAPI URLDownloadToFile via the CALL function, as we reported earlier.\r\nInvoking PowerShell scripts execution to download the payload: the PowerShell scripts can either be\r\nembedded in macros or downloaded from a remote server. Attackers can leverage various adversary\r\ntechniques, such as multiple layers of obfuscation, to hide the PowerShell scripts. This can increase the\r\ninfection rate by evading anti-virus (AV) scanners, particularly signature-based detection engines. As a\r\nresult, using PowerShell scripts to download Emotet payloads has become a favorite choice in these\r\nattacks. The attacks discussed in this report are examples of this scenario.\r\nDetection timeline\r\nFigure 2 shows the detection timeline of a few recent Emotet waves attacking some of our customers. The first\r\nattack started on January 11, followed by two major waves afterwards.\r\nhttps://blogs.vmware.com/networkvirtualization/2022/02/emotet-is-not-dead-yet-part-2.html/\r\nPage 2 of 13\n\nFigure 2: Detection timeline of Emotet affecting some of VMware customers mainly in EMEA region\r\nBased on our investigation, we can classify these attacks into three clusters (marked as A, B, and C in Figure 2):\r\nCluster A: Emotet payload via XL4 macro directly\r\nCluster B: Emotet payload via XL4 macro with PowerShell\r\nCluster C: Emotet payload via VBA macro with PowerShell\r\nThe Cluster A attack leveraged the XL4 macro to download the Emotet payload directly from one of several\r\npossible remote servers, as has already been discussed in our earlier report. In the following sections, we will\r\nfocus our analysis on clusters B and C. More specifically, we’ll investigate the techniques used in clusters B and C\r\nto understand how the Emotet payload is delivered differently, though the opening pages from the samples of both\r\nclusters appear very similar (see Figure 3).\r\nFigure 3: Similar opening pages from Clusters B and C samples.\r\nCluster B: Emotet payload via XL4 macro with PowerShell\r\nTo investigate Cluster B, we analyzed one of the samples from this campaign (see Table 1).\r\nTable 1: A typical XL4 macro weaponized Excel file from Cluster B attack.\r\nMD5 163206e4cff8d35befbfcdb66d63edd1\r\nSHA1 d8be95d2e1cd544d6b56b83ebad041453893cdb8\r\nSHA256 db2524a38755745b796339f2a7fb4e42dba8341984ce35ea715923742a725315\r\nFile name 0029371874.xls\r\nSize 132214 bytes\r\nhttps://blogs.vmware.com/networkvirtualization/2022/02/emotet-is-not-dead-yet-part-2.html/\r\nPage 3 of 13\n\nType application/msoffice-xls\r\nXL4 macro\r\nFigure 4 shows the extracted XL4 macro from the sample. The macro is stored in a macro worksheet called KEY.\r\nThe macro is relatively simple, with less obfuscation compared to samples in the Cluster A wave (see report).\r\nFigure 4: Simple XL4 macros extracted from the sample.\r\nWhen macro execution is enabled, the macro script runs cmd.exe via the EXEC function to spawn a process to\r\nexecute mshta (the de-obfuscated version of m^sh^t^a from the SET.NAME command line shown in the figure).\r\nOnce mshta is launched, it executes a remote file. The remote file URL is obfuscated with a hexadecimal-encoded\r\nserver name:\r\nh^tt^p^:/^/0xb907d607/c^c.h^tm^l\r\nDe-obfuscating it reveals the actual URL:\r\nhxxp://185.7.214[.]7.cc.html\r\nNext, we discuss mshta and investigate the content stored in the file above.\r\nmshta\r\nmshta.exe is a 20-year-old Windows-native utility that executes Microsoft HTML Application (HTA) files.\r\nWindows-legitimate tools like mshta and PowerShell, dubbed “LOLBINs” (living-off-the-land binaries), have\r\nbecome increasingly popular among threat actors. This is because these utilities and scripts are signed by\r\nMicrosoft and trusted by the Windows OS, allowing attackers to bypass detection by proxying execution of the\r\nmalware. MITRE reports T1218 and T1216 provide more information on signed binary proxy execution and\r\nsigned script proxy execution, respectively.\r\nAttackers typically abuse mshta to execute malicious VBScript and Jscript programs either through inline\r\ncommands (e.g., Kovter Trojan), or through an HTA file. The attack we investigate herein is the latter case. The\r\nnext stage payload is stored in the remote HTA file and delivered via mshta execution. A copy of the HTA file is\r\nalso downloaded to the C:\\Users\\ directory during the execution process, as confirmed by analyzing the Excel\r\nsample with VMware NSX Advanced Threat Analyzer (NSX ATA, see Figure 5).\r\nhttps://blogs.vmware.com/networkvirtualization/2022/02/emotet-is-not-dead-yet-part-2.html/\r\nPage 4 of 13\n\nFigure 5: An HTA file copy downloaded to C:\\Users\\ directory.\r\nAt a first glance, the HTA file (sha1: 2615f7aa2141cc1cb5d0c687bc3396981c2c68dc) doesn’t appear to contain\r\nanything, and it is empty when opening it in a common editor. Using whitespace obfuscation is a typical example\r\nof a steganography technique (see MITRE report T1027.003) to hide code or make analysis harder. One can use\r\ntools such as js-beautify to remove the empty lines and prettify the script inside. Figure 6 shows the first and last\r\nparts of the prettified JScript contained in the HTA file.\r\nhttps://blogs.vmware.com/networkvirtualization/2022/02/emotet-is-not-dead-yet-part-2.html/\r\nPage 5 of 13\n\nFigure 6: Beautified JScript contained in the HTA file.\r\nThe JScript is highly obfuscated. At the end of the script, the unescape() and eval() functions (as highlighted in the\r\nfigure above) are called to decode and execute the obfuscated script. Executing the Jscript sample within VMware\r\nNSX ATA shows that a new process is spawned to invoke PowerShell execution.\r\nOur analysis reveals that the remaining process to deliver the final Emotet payload involves two stages:\r\n1. The PowerShell script contained in the HTA file downloads another PowerShell payload from a remote\r\nURL.\r\n2. The downloaded PowerShell script from the previous step downloads the Emotet DLL payload.\r\nPowerShell: first stage\r\nhttps://blogs.vmware.com/networkvirtualization/2022/02/emotet-is-not-dead-yet-part-2.html/\r\nPage 6 of 13\n\nFigure 7 shows the PowerShell payload contained in the HTA file.\r\nFigure 7: PowerShell script extracted from the HTA file.\r\nAfter removing the obfuscating strings, the purpose of the script becomes more noticeable – when the PowerShell\r\nscript is executed, it attempts to download another payload using the .NET WebClient.DownloadString method, as\r\nhighlighted in Figure 8. The IEX command (shown at the end of the figure) is an alias for the Invoke-Expression\r\ncmdlet that evaluates and runs the string specified by the $JI variable. One can ignore the backticks, as they are\r\nused just to obfuscate the command.\r\nFigure 8: De-obfuscated first stage PowerShell script.\r\nPowerShell: second stage\r\nWhile the payload (sha1: dcc120c943f78a76ada9fc47ebfdcecd683cf3e4) downloaded from the previous stage has\r\nan image file extension .PNG, in fact it is another PowerShell script but without obfuscation (see Figure 9). This\r\ntime it calls the .NET WebClient.DownloadFile method to download the Emotet DLL payload from one of 10\r\nhosts (as compared to 3 hosts seen in samples from Cluster A) and save it to C:\\Users\\Public\\Documents\\ssd.dll\r\n(sha1: e597f6439a01aad82e153e0de647f54ad82b58d3).\r\nhttps://blogs.vmware.com/networkvirtualization/2022/02/emotet-is-not-dead-yet-part-2.html/\r\nPage 7 of 13\n\nFigure 9: Second stage PowerShell script.\r\nAt the end, the process pauses for 4 seconds by running Sleep -s 4 (see Figure 9). This is to make sure the payload\r\nis properly saved before calling cmd.exe to launch rundll.32.exe and execute the Emotet DLL payload.\r\nCluster C: Emotet payload via VBA macro with PowerShell\r\nSimilarly, we analyzed one of the samples from the Cluster C campaign (see Table 2).\r\nTable 2: A typical VBA macro weaponized Excel file from Cluster C attack.\r\nMD5 2c1d8269dfe24bccc7936b304b8dbffe\r\nSHA1 94868da2c75efa650e001e8c5ef53ceb99323cad\r\nSHA256 63d5a4febc0df7e1167b28fd510fad226b060b67b027000010b11413a234084a\r\nFile name 0020645587.xls\r\nSize 147456 bytes\r\nType application/msoffice-xls\r\nVBA macro\r\nLike most Emotet attacks seen in the past, the file contains highly obfuscated VBA macros. If macro execution is\r\nenabled, the embedded VBA scripts are executed. Figure 10 shows a snippet of the macros.\r\nhttps://blogs.vmware.com/networkvirtualization/2022/02/emotet-is-not-dead-yet-part-2.html/\r\nPage 8 of 13\n\nFigure 10: A snippet of obfuscated VBA macros.\r\nTo reveal the actual malicious behavior, one can use open-source emulation tools such as ViperMonkey to analyse\r\nand de-obfuscate the VBA macros. The emulation results show that the macros will drop and execute a Windows\r\nbatch script during execution. The batch file is saved to the hidden folder ProgramData on the system drive. This\r\nis also confirmed by analyzing the Excel sample with VMware NSX ATA (see Figure 11).\r\nFigure 11: A batch file is saved to C:\\programdata folder during macro execution.\r\nBatch script\r\nFigure 12 shows the highly obfuscated content of the dropped batch file (sha1:\r\nbf1171da149442a511a946ded726b94c1ad7cf85).\r\nhttps://blogs.vmware.com/networkvirtualization/2022/02/emotet-is-not-dead-yet-part-2.html/\r\nPage 9 of 13\n\nFigure 12: The batch file dropped during the execution of VBA macros.\r\nIt seems that AV engines are not effective at catching fresh malicious batch scripts. In this example, only 2 of 58\r\nAV engines detected the batch file on VirusTotal (see Figure 13, the results were checked five days after they were\r\nfirst submitted to VirusTotal).\r\nFigure 13: Detection of the batch file on VirusTotal.\r\nAfter de-obfuscating the batch script with batch deobfuscator, it reveals the PowerShell payload (see Figure 14).\r\nFigure 14: PowerShell script contained in the batch file.\r\nPowerShell\r\nAs highlighted in Figure 14, the batch script runs PowerShell in the background with the command start/B. The\r\nPowerShell command accepts a base64-encoded string version of a command by using the -enc (or\r\nEncodedCommand) parameter. After decoding the base64-encoded string, the de-obfuscated PowerShell payload\r\nis shown in Figure 15.\r\nhttps://blogs.vmware.com/networkvirtualization/2022/02/emotet-is-not-dead-yet-part-2.html/\r\nPage 10 of 13\n\nFigure 15: The PowerShell script to download Emotet DLL payload.\r\nThe PowerShell script attempts to download the Emotet DLL payload from one of 12 hosts and save it to the\r\nC:\\ProgramData\\ folder with a randomly generated number as file name, e.g., c:\\ProgramData\\759027055.dll\r\n(sha1: 606e6e0f3b476b2dae26c7f3c95e392a911d04c5). Once the Emotet payload is downloaded successfully, the\r\nscript calls cmd.exe to launch rundll.32.exe and execute the payload, as highlighted in Figure 15.\r\nVMware NSX detection with MITRE ATT\u0026CK mapping\r\nVMware NSX customers are well-protected against Emotet attacks from both clusters. Figure 16 and Figure 17\r\nshow the analysis overview from VMware NSX ATA when executing the initial Excel samples listed in Table 1\r\nand Table 2, respectively. As shown in both figures, NSX ATA successfully detected both samples as Emotet.\r\nWhile NSX ATA identified a few common high-risk characteristics from both clusters, such as the spawning of\r\nshell command and PowerShell, the observation of command \u0026 control traffic, and the execution of a dropped a\r\nfile, there are also some techniques that distinguish both clusters. For example, the sample from Cluster B exhibits\r\nthe behaviors of running XL4 macro with suspicious external commands and spawning an mshta process (see\r\nFigure 16), while the Cluster C sample is capable of dropping and executing a script file (see Figure 17).\r\nhttps://blogs.vmware.com/networkvirtualization/2022/02/emotet-is-not-dead-yet-part-2.html/\r\nPage 11 of 13\n\nFigure 16: Cluster B attack: VMware NSX advanced threat analysis overview with MITRE ATT\u0026CK mapping.\r\nFigure 17: Cluster C attack: VMware NSX advanced threat analysis overview with MITRE ATT\u0026CK mapping.\r\nThe analysis overview also contains MITRE ATT\u0026CK tactic and technique mapping for some of the key\r\nmalicious behaviors observed during the attack execution (as highlighted in both Figure 16 and Figure 17). The\r\ntypical ATT\u0026CK tactics used in this attack include TA0002: Execution, TA0005: Defense Evasion, and TA0011:\r\nCommand and Control. A detailed MITRE ATT\u0026CK tactic and technique mapping for Emotet can be found in the\r\nMITRE report.\r\nConclusions\r\nThe increasing challenges the security community faces today not only come from new threats, but also from old\r\nmalware armed with new TTPs. The recent Emotet attacks discussed in this blog post and our previous report are\r\nnotable examples of these long-term threats that leverage legitimate Windows features (such as XL4 macros and\r\nbatch scripts) and LOLBINs (like mshta and PowerShell utilities). These attacks impose great challenges on\r\ntraditional AV solutions, in particular signature-based detection systems. In contrast, behavior-based detection\r\nsystems such as VMware’s AI-driven NSX ATA are very effective in successfully identifying the techniques\r\nleveraged by attackers.\r\nhttps://blogs.vmware.com/networkvirtualization/2022/02/emotet-is-not-dead-yet-part-2.html/\r\nPage 12 of 13\n\nAppendix: IoCs\r\nIndicators of compromise identified from this report can be found on VMware TAU’s GitHub IoCs repository.\r\nSource: https://blogs.vmware.com/networkvirtualization/2022/02/emotet-is-not-dead-yet-part-2.html/\r\nhttps://blogs.vmware.com/networkvirtualization/2022/02/emotet-is-not-dead-yet-part-2.html/\r\nPage 13 of 13",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"Malpedia"
	],
	"references": [
		"https://blogs.vmware.com/networkvirtualization/2022/02/emotet-is-not-dead-yet-part-2.html/"
	],
	"report_names": [
		"emotet-is-not-dead-yet-part-2.html"
	],
	"threat_actors": [],
	"ts_created_at": 1775434082,
	"ts_updated_at": 1775791327,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/0a00a7c9d890bce9d92f6e8fdac7ed9d05062515.pdf",
		"text": "https://archive.orkl.eu/0a00a7c9d890bce9d92f6e8fdac7ed9d05062515.txt",
		"img": "https://archive.orkl.eu/0a00a7c9d890bce9d92f6e8fdac7ed9d05062515.jpg"
	}
}