{
	"id": "c8cb85fa-2db9-4abe-a971-d2335dc7680e",
	"created_at": "2026-04-06T01:31:36.815291Z",
	"updated_at": "2026-04-10T13:12:58.51436Z",
	"deleted_at": null,
	"sha1_hash": "4e6fe10d76df11b0de7b9535825fe44e5412bacf",
	"title": "Emotet Moves to 64 bit and Updates its Loader",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 184950,
	"plain_text": "Emotet Moves to 64 bit and Updates its Loader\r\nBy Oleg Boyarchuk, Jason Zhang, Stefano Ortolani\r\nPublished: 2022-05-16 · Archived: 2026-04-06 00:16:29 UTC\r\nFor the last three weeks, security researchers have been noticing Emotet migrating to new 64-bit modules\r\nhttps://twitter.com/Cryptolaemus1/status/1516261512372965383. While the change initially affected Epoch 4, by\r\nthe second week of May both Epoch 4 and Epoch 5 had been fully migrated. Figure 1 shows one of the first waves\r\nleveraging 64-bit modules targeting, among others, one of our customers in the Healthcare vertical. At the time of\r\nwriting, we can also confirm that both the DLL loader and stealing modules are now 64-bit binaries. While it is\r\ntrue that 32-bit operating systems have been on their way out for quite a while, it is still not clear why Emotet’s\r\nauthors decided to carry out this transition at this specific moment in time; the benefits are, however, quite clear\r\nfrom a software development perspective: debugging is easier, there is no intermediate emulation layer anymore\r\n(WOW64), and accessing native system directories does not require selectively disabling the emulation layer.   \r\nIn this blog post, we analyze one of the latest samples and investigate whether the changes introduced by\r\nmigrating to pure 64-bit binaries are only cosmetic or they are rather also functionally relevant.  \r\n \r\nFigure 1: Timeline of Emotet DLL 64-bit payloads. \r\nhttps://blogs.vmware.com/security/2022/05/emotet-moves-to-64-bit-and-updates-its-loader.html\r\nPage 1 of 5\n\nWhat Did Not Change \r\nAs we described in a previous blog post, the DLL payload is the key component of any Emotet execution chain: \r\nThe payload is an obfuscated DLL; it is meant to be executed by rundll32.exe or regsvr32.dll, and it holds\r\nan encrypted DLL inside. \r\nThe inner DLL is responsible for persistence and C2 communication.\r\nThe inner DLL relies on functions imported from bcrypt.dll to encrypt and decrypt the network traffic. \r\nNetwork communication is still achieved via functions imported from wininet.dll. \r\nOur initial assessment suggests that the recompilation to target the 64-bit architecture natively did not introduce\r\nany major changes. For instance, the logic handling encryption and network communication have been kept the\r\nsame, including the way in which the malware accesses WinAPI functions. Figure 2 shows the code snippets\r\ntasked with dynamically retrieving the pointers to the WinAPI functions, extracted from both a 32-bit (above) and\r\na 64-bit (below) sample; as one can see, the implemented logic is basically identical. \r\n \r\nFigure 2: Function to retrieve pointers to WinAPI functions in a 32-bit sample\r\ne597f6439a01aad82e153e0de647f54ad82b58d3 (above) vs. the same function in a 64-bit sample\r\nC6fe1cf52c7f3299f07a1e1c05e19e2013330e4c (below). \r\nThis is also substantiated by looking at the API call sequence across 32-bit and 64-bit samples; both logics to\r\nencrypt the traffic and establish network communications use the exact same APIs, in the exact same order: \r\nhttps://blogs.vmware.com/security/2022/05/emotet-moves-to-64-bit-and-updates-its-loader.html\r\nPage 2 of 5\n\nbcrypt!BCryptCreateHash \r\nbcrypt!BCryptHashData \r\nbcrypt!BCryptFinishHash \r\nbcrypt!BCryptDestroyHash \r\nkernel32!GetProcessHeap \r\nkernel32!HeapFree \r\nbcrypt!BCryptCloseAlgorithmProvider \r\nkernel32!GetProcessHeap \r\nntdll!RtlAllocateHeap \r\nntdll!memcpy \r\nntdll!memcpy \r\nbcrypt!BCryptEncrypt \r\nkernel32!GetProcessHeap \r\nntdll!RtlAllocateHeap \r\nbcrypt!BCryptEncrypt \r\n… \r\nwininet!InternetOpenW \r\nkernel32!GetProcessHeap \r\nkernel32!HeapFree \r\nwininet!InternetConnectW \r\nwininet!HttpOpenRequestW \r\nkernel32!GetProcessHeap \r\nkernel32!HeapFree \r\nwininet!InternetSetOptionW \r\nwininet!InternetQueryOptionW \r\nwininet!InternetSetOptionW \r\nhttps://blogs.vmware.com/security/2022/05/emotet-moves-to-64-bit-and-updates-its-loader.html\r\nPage 3 of 5\n\nwininet!HttpSendRequestW \r\nEven the location where the configuration data is stored does not exhibit any update; the data blob at the very\r\nbeginning of the .data section of a 64-bit payload is still the same encrypted C2 configuration (see Figure 3); we\r\nrefer to our previous blog post for more details about how to decrypt the configuration. \r\nFigure 3: By looking at xrefs to the data blob from .data (c6fe1cf52c7f3299f07a1e1c05e19e2013330e4c) it is\r\npossible to locate the config decryption function. \r\nWhat Changed \r\nWhile the main logic did not change, some of the constants used by the DLL loader have been updated. To\r\nunderstand which constants are changed, and how they affect detection and analysis, one needs to look at the\r\nEmotet’s update process. \r\nOne of the main functionalities of the payload DLL is to pull updates from a C2 server; these updates are also\r\nDLLs but featuring a custom entry point: while normal DLLs perform their initialization during the\r\nDLL_PROCESS_ATTACH call and free the resources during the DLL_PROCESS_DETACH call, the 32-bit\r\nDLLs distributed by the botnet as updates execute their initialization routine only when a custom value,\r\nfdwReason=16, is given as input (see Figure 4); furthermore, the loading routine requires custom data structures\r\npassed via the lpReserved pointer. Failure to comply with any of these requirements (by, for example, loading the\r\nDLL using rundll32.exe) will either crash the sample or make it skip the initialization routine. \r\nhttps://blogs.vmware.com/security/2022/05/emotet-moves-to-64-bit-and-updates-its-loader.html\r\nPage 4 of 5\n\nFigure 4: Entry point of a 32-bit update (7d3f067f4b135a4a4d4b717bc7f7f4dd8e3a7ff8). \r\nThe updated 64-bit DLLs retain this specific loading mechanism, but they now correctly initialize only when a\r\ndifferent value, i.e., 100, is given as input (see Figure 5); they also remove the branch called when fdwReason=32,\r\nwhich was originally leading to an empty function. While these little changes can still be considered merely\r\ncosmetic, they are able to break any custom loader built by security analysts to dynamically analyze these update\r\nbinaries; hopefully this is not the start of yet another cat-and-mouse game between security analysts and Emotet\r\ndevelopers. \r\nFigure 5: Entry point of a 64-bit update (3c729151d9d2d326a4a3772ee18a1c0ca5db55ce). \r\nConclusions \r\nAs Emotet is a moving target, security researchers have no choice but to keep investigating how the tactics,\r\ntechniques, and procedures (TTPs) used by Emotet’s authors are evolving over time, and how to effectively detect\r\nthis threat.  \r\nThe move to 64-bit binaries seems to prepare the groundwork for further modifications yet to come, and while the\r\ndifferences are not functionally relevant, they already pose potential challenges to dynamic analysis systems that\r\nanalyze payloads in sandboxing environments. Analyzing a threat by focusing on its full attack chain (as done by\r\nmodern NDR solutions) is the only way to keep up with an ever-evolving threat landscape. \r\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/security/2022/05/emotet-moves-to-64-bit-and-updates-its-loader.html\r\nhttps://blogs.vmware.com/security/2022/05/emotet-moves-to-64-bit-and-updates-its-loader.html\r\nPage 5 of 5",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"Malpedia"
	],
	"origins": [
		"web"
	],
	"references": [
		"https://blogs.vmware.com/security/2022/05/emotet-moves-to-64-bit-and-updates-its-loader.html"
	],
	"report_names": [
		"emotet-moves-to-64-bit-and-updates-its-loader.html"
	],
	"threat_actors": [],
	"ts_created_at": 1775439096,
	"ts_updated_at": 1775826778,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/4e6fe10d76df11b0de7b9535825fe44e5412bacf.pdf",
		"text": "https://archive.orkl.eu/4e6fe10d76df11b0de7b9535825fe44e5412bacf.txt",
		"img": "https://archive.orkl.eu/4e6fe10d76df11b0de7b9535825fe44e5412bacf.jpg"
	}
}