{
	"id": "ad9b8293-402d-41c6-afff-9b6f93a1127e",
	"created_at": "2026-04-06T00:18:29.616343Z",
	"updated_at": "2026-04-10T13:12:13.732006Z",
	"deleted_at": null,
	"sha1_hash": "9b5e890508b8dadb7b8023c8ad17a0d1377d0512",
	"title": "Unpacking Emotet Trojan",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 4590048,
	"plain_text": "Unpacking Emotet Trojan\r\nBy mov eax, 27\r\nPublished: 2023-08-13 · Archived: 2026-04-05 21:27:12 UTC\r\n7 min read\r\nJul 23, 2023\r\nPress enter or click to view image in full size\r\nEmotet, in general, is a banking trojan. Identified in-the-wild for the first time in 2014 as a stealth info stealer\r\n(mainly targeting banking informations), emotet has evolved to a sofisticated trojan over the years; Now having\r\nfuncionalities that goes from simply keylogging to self-spreading (as worms do).\r\nThe main campaign of the malware is through malspam. Using the “urgency” pretext, emotet make his victims\r\nby malicous documents with a macro embedded, malicious scripts or malicious links. Then, the pretext comes\r\nwith subjects like: “Your Invoice”, “Payment Details” or an upcoming shipment from well-known companies.\r\nhttps://infosecwriteups.com/unpacking-emotet-trojan-dac7e6119a0a\r\nPage 1 of 14\n\nEmotet uses some tricks to evade and prevent his detection and analysis. The malware will check for common\r\nmalware analysis tools (like IDA or Wireshark), check if it is running on a virtual environment and remain\r\nsleep, and every sample comes packed or encrypted.\r\nToday we will be covering the unpacking of a sample from emotet family.\r\nReconnaissance\r\nsha256: 3a9494f66babc7deb43f65f9f28c44bd9bd4b3237031d80314ae7eb3526a4d8f\r\nmd5: ca06acd3e1cab1691a7670a5f23baef4\r\nFirst, we need to know if the sample is definitely packed. Lets open it on DiE.\r\nPress enter or click to view image in full size\r\nWe can see that it is a 32-bit binary, made in C/C++ and having a certificate stored in the overlay section\r\n(WinAuth(2.0))\r\nBy looking at the entropy, we see that the binary has 89% chance of being packed.\r\nPress enter or click to view image in full size\r\nhttps://infosecwriteups.com/unpacking-emotet-trojan-dac7e6119a0a\r\nPage 2 of 14\n\nWe can confirm it by looking at the sample on IDA.\r\nPress enter or click to view image in full size\r\nIDA shows some indicators of packing, like:\r\nLack of functions on a malware this sofisticated.\r\nMain (start) function seems small and doesn’t have any WindowsAPI call.\r\nhttps://infosecwriteups.com/unpacking-emotet-trojan-dac7e6119a0a\r\nPage 3 of 14\n\nBut, we can have the proof of it by looking into common packing APIs:\r\nCreateProcessInternalW()\r\nVirtualAlloc()\r\nVirtualAllocEx()\r\nVirtualProtect() | ZwProtectVirtualMemory()\r\nWriteProcessMemory() | NtWriteProcessMemory()\r\nResumeThread() | NtResumeThread()\r\nCryptDecrypt() | RtlDecompressBuffer()\r\nNtCreateSection() + MapViewOfSection() | ZwMapViewOfSection()\r\nUnmapViewOfSection() | ZwUnmapViewOfSection()\r\nNtWriteVirtualMemory()\r\nNtReadVirtualMemory()\r\nSearching for VirtualAlloc(), we will soon find the subroutine that probably is the responsible for unpacking the\r\nmalware.\r\nNow it gets a little bit more complicated. The red box marks an “abnormal epilogue”. An “abnormal epilogue”\r\noccurs when we have some pushes into the stack and not a single pop before it returns.\r\nhttps://infosecwriteups.com/unpacking-emotet-trojan-dac7e6119a0a\r\nPage 4 of 14\n\nYou can notice that ds:VirtualAlloc is being moved into ecx, then ecx is pushed onto the stack and the\r\nreturn is called, meaning the call of VirtualAlloc().\r\nAfter calling ecx (VirtualAlloc), the return will execute the second push from the stack (osffset loc_417d9a),\r\nexecuting whatever is present on the second block, and then the real return will come.\r\nSo, the return of the subroutine will be on 0x00417E3F.\r\nNormally, after the code finishes the unpack, we will have a jmp to it.\r\nWe can confirm it by looking at the end of the main function, which has an “jmp ecx”.\r\nAgain, take notes of the address. 0x00417F1F.\r\nUnpacking\r\nSo we got two addresses to set breakpoints in:\r\n0x00417E3F\r\n0x00417F1F\r\nWe can open it on x64dbg, search for those addresses (Ctrl+G), and then set the breakpoints.\r\nPress enter or click to view image in full size\r\nBy going to the “jmp” breakpoint and scrolling down, we will encounter another abnormal set of instructions. This\r\ntime, a subroutine is being pushed into the stack and not popped, the the ret makes the call to that subroutine.\r\nFollowing it on the dump, we can see that it is the newly allocated memory.\r\nPress enter or click to view image in full size\r\nhttps://infosecwriteups.com/unpacking-emotet-trojan-dac7e6119a0a\r\nPage 5 of 14\n\nHaving the knowledge of the abnormal epilogue, we will stepover until the ret is called and take us to another\r\nstage of the unpack.\r\nPress enter or click to view image in full size\r\nNow, we will have to stepover that code and analyze all those calls(e. g. call 21CF710).\r\nGet mov eax, 27’s stories in your inbox\r\nJoin Medium for free to get updates from this writer.\r\nRemember me for faster sign in\r\nAfter some analysis, we eventually will find the call to 3AF830, which has some interesting code:\r\nPress enter or click to view image in full size\r\nhttps://infosecwriteups.com/unpacking-emotet-trojan-dac7e6119a0a\r\nPage 6 of 14\n\nWe can see that this subroutine is using “stack strings” as a form of evasion/obfuscation. This piece of code tries\r\nto obfuscate the passing of arguments “LoadLibraryExA” and “kernel32.dll” to the call 21CFE10. And many\r\nothers.\r\nAs we know what is happening here, lets go straight to the return of that subroutine.\r\nAfter returning to the main unpacking subroutine, we notice that the upcoming calls has the same mechanism as\r\n3AF830.\r\nBut, the last one is important. Since the code inside of it is different, is worth a analysis.\r\nPress enter or click to view image in full size\r\nWe can assume that edx is a call to VirtualAlloc, because some of the parameters passed to it are common\r\nparameters passed to VirtualAlloc itself.\r\npush 40 as: PAGE_EXECUTE_READWRITE (flProtect)\r\npush 3000 as: MEM_COMMIT | MEM_RESERVE\r\nTo confirm it, we stepover to that call.\r\nPress enter or click to view image in full size\r\n:)\r\nKnowing the return of that API is the base address of the recent allocated memory, we can follow the address in\r\nEAX (return).\r\nPress enter or click to view image in full size\r\nhttps://infosecwriteups.com/unpacking-emotet-trojan-dac7e6119a0a\r\nPage 7 of 14\n\nAfter stepping over a little bit more, we will notice that memory being populated, more specifically after the call\r\nto 21CFBC0.\r\nPress enter or click to view image in full size\r\nThen, we have to continue to stepover until the subroutine finishes populating that memory.\r\nWe will know it finished when we encounter a return.\r\nPress enter or click to view image in full size\r\nhttps://infosecwriteups.com/unpacking-emotet-trojan-dac7e6119a0a\r\nPage 8 of 14\n\nAfter all of this, we can finally dump that memory.\r\nThe dump is made by:\r\nright-clicking the first byte -\u003e following it on memory map -\u003e right-click \u003e dump memory to file\r\nAnother way of doing it is: Opening the process in process hacker (administrator), searching for the\r\naddress marked in dump, then dumping to a file.\r\nhttps://infosecwriteups.com/unpacking-emotet-trojan-dac7e6119a0a\r\nPage 9 of 14\n\nUnmapping\r\nIf we open the recently dumped file on IDA for example, it will be completely scrambled. The reason for this is\r\nbecause the binary may be unaligned or mapped, so we need to align and unmap it.\r\nTo align and unmap it, we will open the dumped binary on PE Bear.\r\nPress enter or click to view image in full size\r\nhttps://infosecwriteups.com/unpacking-emotet-trojan-dac7e6119a0a\r\nPage 10 of 14\n\nAs you can see, we don’t have the import tab, meaning we need to unmap the binary.\r\nThe unmap process is simples. It will take 4 steps:\r\n1. Change the Raw Address to the same as Virtual Address.\r\n2. Ajust the Raw Size by subtracting the first sectin by the second, and so on.\r\n3. Copy the adjusted Raw Size to the Virtual Size\r\n4. Fix the Base Address in the Optional Header (The same as the dump address).\r\nYou can subtract those values with the windows calculator and the “programmer” option.\r\nAfter that, we have the Unmapped Binary:\r\nPress enter or click to view image in full size\r\nPress enter or click to view image in full size\r\nhttps://infosecwriteups.com/unpacking-emotet-trojan-dac7e6119a0a\r\nPage 11 of 14\n\nNow, all we have to do is save the new binary.\r\nBinary name -\u003e right-click -\u003e Save the executable as...\r\nConfirming\r\nTo confirm all we’ve done , let’s open it on IDA.\r\nPress enter or click to view image in full size\r\nAs you notice, now we have plenty of functions to analyze, and assuming by it’s strings and imports, the malware\r\nis unpacked but has a severe method of encryption and dynamic linking.\r\nhttps://infosecwriteups.com/unpacking-emotet-trojan-dac7e6119a0a\r\nPage 12 of 14\n\nPress enter or click to view image in full size\r\nAnd that’s it for today, hope you liked and learned something from this article. Thank you!!\r\nhttps://infosecwriteups.com/unpacking-emotet-trojan-dac7e6119a0a\r\nPage 13 of 14\n\nSource: https://infosecwriteups.com/unpacking-emotet-trojan-dac7e6119a0a\r\nhttps://infosecwriteups.com/unpacking-emotet-trojan-dac7e6119a0a\r\nPage 14 of 14",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"Malpedia"
	],
	"origins": [
		"web"
	],
	"references": [
		"https://infosecwriteups.com/unpacking-emotet-trojan-dac7e6119a0a"
	],
	"report_names": [
		"unpacking-emotet-trojan-dac7e6119a0a"
	],
	"threat_actors": [],
	"ts_created_at": 1775434709,
	"ts_updated_at": 1775826733,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/9b5e890508b8dadb7b8023c8ad17a0d1377d0512.pdf",
		"text": "https://archive.orkl.eu/9b5e890508b8dadb7b8023c8ad17a0d1377d0512.txt",
		"img": "https://archive.orkl.eu/9b5e890508b8dadb7b8023c8ad17a0d1377d0512.jpg"
	}
}