{ "id": "c7b25684-0582-4aa2-8ac6-46bd89bca175", "created_at": "2026-04-06T00:12:26.999005Z", "updated_at": "2026-04-10T13:12:42.516463Z", "deleted_at": null, "sha1_hash": "b23114053ac6c43a73fb850f9bf8c852f4d1714d", "title": "Unpacking an Emotet trojan", "llm_title": "", "authors": "", "file_creation_date": "0001-01-01T00:00:00Z", "file_modification_date": "0001-01-01T00:00:00Z", "file_size": 2286041, "plain_text": "Unpacking an Emotet trojan\r\nBy Otavio M.\r\nPublished: 2023-07-23 · Archived: 2026-04-05 16:51:57 UTC\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 by\r\nmalicous documents with a macro embedded, malicious scripts or malicious links. Then, the pretext comes with\r\nsubjects like: “Your Invoice”, “Payment Details” or an upcoming shipment from well-known companies.\r\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 sleep,\r\nand every sample comes packed or encrypted.\r\nToday we will be covering the unpacking of a sample from emotet family.\r\nhttps://estr3llas.github.io/unpacking-an-emotet-trojan/\r\nPage 1 of 12\n\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\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\nLooking at the entropy, we see that the binary has 89% chance of being packed.\r\nWe can confirm it by looking at the sample on IDA.\r\nhttps://estr3llas.github.io/unpacking-an-emotet-trojan/\r\nPage 2 of 12\n\nIDA shows some indicators of packing, like:\r\nLack of subroutines on a malware this sofisticated.\r\nLack of internet-related APIs\r\nMain (start) function seems small and doesn’t have any WindowsAPI or indirect calls.\r\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\nNtReadVirtualMemor\r\nSearching for VirtualAlloc(), we will soon find the subroutine that probably is the responsible for unpacking the\r\nmalware.\r\nhttps://estr3llas.github.io/unpacking-an-emotet-trojan/\r\nPage 3 of 12\n\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\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\nNormally, after the code finishes the unpack, we will have a indirect call to it.\r\nhttps://estr3llas.github.io/unpacking-an-emotet-trojan/\r\nPage 4 of 12\n\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\nWe can open it on x64dbg, search for those addresses (Ctrl+G), and then set the breakpoints.\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\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\nhttps://estr3llas.github.io/unpacking-an-emotet-trojan/\r\nPage 5 of 12\n\nNow, we will have to stepover that code and analyze all those calls(e. g. call 21CF710).\r\nAfter some analysis, we eventually will find the call to 3AF830, which has some interesting code:\r\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\nhttps://estr3llas.github.io/unpacking-an-emotet-trojan/\r\nPage 6 of 12\n\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) \u0026\u0026 push 3000 as: MEM_COMMIT /\r\nMEM_RESERVE\r\nTo confirm it, we stepover to that call.\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\nAfter stepping over a little bit more, we will notice that memory being populated, more specifically after the call\r\nto 21CFBC0.\r\nhttps://estr3llas.github.io/unpacking-an-emotet-trojan/\r\nPage 7 of 12\n\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\nhttps://estr3llas.github.io/unpacking-an-emotet-trojan/\r\nPage 8 of 12\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\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\nhttps://estr3llas.github.io/unpacking-an-emotet-trojan/\r\nPage 9 of 12\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\nhttps://estr3llas.github.io/unpacking-an-emotet-trojan/\r\nPage 10 of 12\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\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://estr3llas.github.io/unpacking-an-emotet-trojan/\r\nPage 11 of 12\n\nAnd that’s it for today, hope you liked and learned something from this article. Thank you!!!\r\nSource: https://estr3llas.github.io/unpacking-an-emotet-trojan/\r\nhttps://estr3llas.github.io/unpacking-an-emotet-trojan/\r\nPage 12 of 12", "extraction_quality": 1, "language": "EN", "sources": [ "Malpedia" ], "origins": [ "web" ], "references": [ "https://estr3llas.github.io/unpacking-an-emotet-trojan/" ], "report_names": [ "unpacking-an-emotet-trojan" ], "threat_actors": [], "ts_created_at": 1775434346, "ts_updated_at": 1775826762, "ts_creation_date": 0, "ts_modification_date": 0, "files": { "pdf": "https://archive.orkl.eu/b23114053ac6c43a73fb850f9bf8c852f4d1714d.pdf", "text": "https://archive.orkl.eu/b23114053ac6c43a73fb850f9bf8c852f4d1714d.txt", "img": "https://archive.orkl.eu/b23114053ac6c43a73fb850f9bf8c852f4d1714d.jpg" } }