{ "id": "c3517a1f-bf8c-4d00-a14f-6538c61bfdc6", "created_at": "2026-04-06T00:18:31.480278Z", "updated_at": "2026-04-10T03:24:29.793104Z", "deleted_at": null, "sha1_hash": "f20a392f376f95c0a1e4f4ee9a09f09fb26a437c", "title": "Malware Unpacking With Memory Dumps - Intermediate Methods (Pe-Sieve, Process Hacker, Hxd and Pe-bear)", "llm_title": "", "authors": "", "file_creation_date": "0001-01-01T00:00:00Z", "file_modification_date": "0001-01-01T00:00:00Z", "file_size": 3991485, "plain_text": "Malware Unpacking With Memory Dumps - Intermediate Methods\r\n(Pe-Sieve, Process Hacker, Hxd and Pe-bear)\r\nBy Matthew\r\nPublished: 2023-11-01 ยท Archived: 2026-04-05 16:41:46 UTC\r\nIn a previous post, we demonstrated a method for unpacking an Asyncrat malware sample by utilising Process\r\nHacker and Dnspy.\r\nWe leveraged Process Hacker to identify a suspicious process, then utilised Dnspy to attach to the process and\r\nenumerate loaded modules. From there we were able to open a suspicious module from memory, which ultimately\r\nobtained the unpacked Asyncrat malware sample.\r\nIn this post, we'll go over some additional methods for obtaining the same unpacked payload.\r\n1. Pe-sieve - Directly obtaining the unpacked payload\r\n2. Process Hacker - Monitoring modules and directly dumping memory\r\n3. Process Hacker + X32dbg - Monitoring threads and obtaining the payload using a debugger (x32dbg)\r\nAnalysis\r\nWe will assume that you have downloaded and unzipped the file from the previous post. You can also obtain the\r\nfile here.\r\nSHA256: 05c2195aa671d62b3b47ff42630db25f39453375de9cffa92fc4a67fa5b6493b\r\nWe will also assume that you have executed the file inside of a safe virtual machine, which will result in a running\r\nprocess of aspnet_compiler.exe . (This is the file which the malware has injected itself into)\r\nRecap of Initial Post\r\nIn the initial post, we monitored for the creation of aspnet_compiler.exe using process hacker.\r\nWe then used Process Hacker to view loaded .NET assemblies, which resulted in the identification of a suspicious\r\nvik module, which appeared to have overwritten the original aspnet_compiler.exe\r\nhttps://embeeresearch.io/unpacking-malware-using-process-hacker-and-memory-inspection/\r\nPage 1 of 16\n\nWe then used Dnspy to attach to the suspicious aspnet_compiler.exe process.\r\nThis enabled us to view all loaded modules and open the aspnet_compiler.exe file from memory.\r\nBy opening the file from memory, we were able to obtain the Asyncrat sample that had overwritten the \"real copy\"\r\nof aspnet_compiler.exe\r\nWith the recap covered, we will now go over some additional methods that could have been used to obtain the\r\nunpacked sample.\r\nThese methods work equally as effectively on this particular sample, and also work on samples that are not based\r\non .NET (and hence where Dnspy would not be able to work).\r\nObtaining the Unpacked Sample Using Pe-sieve\r\nPe-sieve is one of the quickest and most effective ways to obtain an unpacked sample.\r\nhttps://embeeresearch.io/unpacking-malware-using-process-hacker-and-memory-inspection/\r\nPage 2 of 16\n\nPe-sieve works by scanning a running process for any suspicious modules that may have been injected or\r\noverwritten into memory. If a suspicious module has been identified, pe-sieve will obtain it and save it for you.\r\nPe-sieve is an extremely effective and easy-to-use tool.\r\nIn the previous screenshot, we identified the suspicious process aspnet_compiler.exe , and we can see that it's\r\nprocess id (pid) is 5876 .\r\nTo scan the process and obtain the unpacked payload, we can run pe-sieve and pass the pid parameter of 5876\r\n(or whichever the pid is in your situation).\r\nTo pass the parameter, we can run the command pe-sieve /pid 5876\r\nAfter running the command, you may see a bunch of text come up on the screen. You can largely ignore the text\r\nand skip straight to the end.\r\nHere we can see the scan summary, indicating that 52 modules were scanned and 1 \"implanted PE\" was identified.\r\nhttps://embeeresearch.io/unpacking-malware-using-process-hacker-and-memory-inspection/\r\nPage 3 of 16\n\nA new folder process_5876 will be created from where you ran the command.\r\nInside this folder contains a series of files that pe-sieve obtained from memory.\r\nOne of these files corresponds to aspnet_compiler.exe . Which we previously identified as potentially being\r\noverwritten by malware.\r\nBy opening the 40000.aspnet_compiler.exe inside of Dnspy, we can see the unpacked payload.\r\nhttps://embeeresearch.io/unpacking-malware-using-process-hacker-and-memory-inspection/\r\nPage 4 of 16\n\nThis is the same vik file as identified in the initial post. In this case, we have obtained the same file by using pe-sieve.\r\nAdditional Methods for Analysis - Members Section\r\nIf you enjoyed this section, you may enjoy the next two sections which are available for paid members of the site.\r\nBecoming a paid member grants you access to all future bonus content. And helps support the creation of more\r\nblogs. You will also get access to a discord server where you can ask questions and receive guidance and help.\r\nIn the next two sections, you can learn how to\r\nPerform a memory dump with Process Hacker\r\nIdentify a broken memory dump using a hex editor\r\nIdentify and Correct a broken memory dump using pe-bear\r\nIdentify a suspicious thread with Process Hacker\r\nMap a thread to a memory region and obtain it using X32dbg.\r\nObtaining the Malware From Memory Using Process Hacker\r\nIt is also possible to obtain the unpacked file directly using only Process Hacker.\r\nRecall that we previously used Process Hacker and the .NET Assemblies tab to identify the suspicious vik\r\nmodule. Which had a corresponding \"Path\" of aspnet_compiler.exe\r\nhttps://embeeresearch.io/unpacking-malware-using-process-hacker-and-memory-inspection/\r\nPage 5 of 16\n\nWe can use this knowledge to assume that the malware has overwritten the original aspnet_compiler.exe file in\r\nmemory.\r\nBy browsing to the Modules tab of Process Hacker, we can obtain the base address of which\r\naspnet_compiler.exe has been loaded into memory.\r\nWe can then go hunting at this base address, again running with the assumption that the original content has been\r\noverwritten with Malware.\r\nDumping Memory With Process Hacker\r\nBrowsing to the Memory tab, we can locate this base address and inspect it more closely.\r\nIt's interesting to note that 0x400000 has RWX permissions. Which is a useful indicator that something\r\nis odd here.\r\nhttps://embeeresearch.io/unpacking-malware-using-process-hacker-and-memory-inspection/\r\nPage 6 of 16\n\nBy right-clicking on the memory region 0x40000 , we can save it to disk for further inspection.\r\nI will go ahead and save the file as phacker_0x40000.bin .\r\nWith the memory region now saved as phacker_0x40000.bin , we can go ahead and open it inside of DnSpy .\r\nhttps://embeeresearch.io/unpacking-malware-using-process-hacker-and-memory-inspection/\r\nPage 7 of 16\n\nBut something is wrong, the file loads as a PE but there is no decompiled code or identified .NET modules.\r\nThis is because we have saved the module \"directly\" from memory, which means that the content is already\r\nloaded and remapped to virtual addresses. The memory sections are aligned to their \"virtual\" addresses rather than\r\nthe \"raw\" addresses.\r\nThe TLDR on this is that the contents of the memory dump are not aligned to their expected places, and some\r\nslight fixing needs to be done. This is common when saving a pe file directly from memory.\r\nLuckily it's simple to fix this with another tool called pe-bear. (From the same developer of pe-sieve\r\n@hasherazade)\r\nTo correctly load the file within Dnspy, we first need to correct the section headers using Pe-bear.\r\nFirst, we can open our file by dragging it to the pe-bear icon.\r\nOnce the file is loaded, we can browse directly to the \"Section Headers\" tab. Here we can see the \"raw\" addresses\r\nwhere most tooling will expect to find the associated section.\r\nWe can see above that the .text section should be at a location of 0x200 .\r\nIf we open the file inside of a hex editor, we can see that it starts at 0x2000 . Which is the virtual address seen in\r\npe-bear. This is an indicator that the section headers will need to be re-aligned.\r\nhttps://embeeresearch.io/unpacking-malware-using-process-hacker-and-memory-inspection/\r\nPage 8 of 16\n\nWith confirmation that the sections are contained at their \"virtual\" addresses. We can go ahead and redirect the\r\nraw addresses to their virtual address.\r\nWhen we load the file in Dnspy, Dnspy starts looking for .text data at the Raw Address. For pe files\r\nsaved from memory, this may not always be where the data actually is. This requires occasional fixing\r\nas we're doing here.\r\nWe can go ahead and click on each of the raw addresses and edit them to match that of the corresponding Virtual\r\nAddress.\r\nhttps://embeeresearch.io/unpacking-malware-using-process-hacker-and-memory-inspection/\r\nPage 9 of 16\n\nWith the Raw and Virtual Addresses now aligned. We can right-click inside of the left window and save a new\r\ncopy of the file.\r\nWe should create a new filename indicating that the file has been \"fixed\". I will go ahead and name the file\r\nphacker_fixed.bin\r\nWith the section headers now fixed, we can go ahead and re-open the file inside of Dnspy.\r\nThe file now loads successfully, with all relevant modules and decompiled code displayed correctly.\r\nhttps://embeeresearch.io/unpacking-malware-using-process-hacker-and-memory-inspection/\r\nPage 10 of 16\n\nObtaining the Malware With Thread Inspection and x32dbg\r\nAnother means for obtaining the unpacked payload, is to inspect running threads and dump memory using a\r\ntraditional debugger such as x32dbg.\r\nBy inspecting threads and looking for anomalies, we can also see where threads are executing from. Using this\r\ninformation we can dump relevant memory.\r\nFor example, we can use the threads tab to view running threads inside of the aspnet_compiler.exe process.\r\nOne of these threads stands out as different to the others. It's also running from aspnet_compiler.exe memory\r\nspace which we already suspect may be overwritten with malicious content.\r\nWe can go ahead and copy the start address of this particular suspicious thread.\r\nhttps://embeeresearch.io/unpacking-malware-using-process-hacker-and-memory-inspection/\r\nPage 11 of 16\n\nAttaching to The Process with X32dbg\r\nWith a suspicious address now identified, we can go ahead and attach to aspnet_compiler.exe using x32dbg.\r\nhttps://embeeresearch.io/unpacking-malware-using-process-hacker-and-memory-inspection/\r\nPage 12 of 16\n\nWith the process selected and the debugger attached, we can go ahead and jump the starting location of the\r\nsuspicious thread.\r\nAfter jumping to the address, we can right click on the first address and find it's corresponding memory region.\r\nhttps://embeeresearch.io/unpacking-malware-using-process-hacker-and-memory-inspection/\r\nPage 13 of 16\n\nDumping Memory Regions With X32dbg\r\nThis will reveal a memory region of 0x40000 , the same as identified by previous methods.\r\nWe can go ahead and save this region using \"Dump Memory To File\".\r\nSaving this region to a file x32dbg_dump.bin , we will run into the same issue as the previous method when\r\nopening in DnSpy.\r\nhttps://embeeresearch.io/unpacking-malware-using-process-hacker-and-memory-inspection/\r\nPage 14 of 16\n\nWe can go ahead and re-align the sections as in the previous method.\r\nAfter correcting the section headers, the file loads successfully inside of DnSpy.\r\nWe have now obtained the unpacked payload by using Process Hacker and x32dbg.\r\nConclusion\r\nWe have now successfully obtained the unpacked payload using 3 different methods of varying complexity. No\r\nsingle method will work all of the time, so it's good to have multiple methods available.\r\nHopefully, you were able to recreate these methods and have learnt something new in this post.\r\nhttps://embeeresearch.io/unpacking-malware-using-process-hacker-and-memory-inspection/\r\nPage 15 of 16\n\nSource: https://embeeresearch.io/unpacking-malware-using-process-hacker-and-memory-inspection/\r\nhttps://embeeresearch.io/unpacking-malware-using-process-hacker-and-memory-inspection/\r\nPage 16 of 16\n\n https://embeeresearch.io/unpacking-malware-using-process-hacker-and-memory-inspection/ \nWith the process selected and the debugger attached, we can go ahead and jump the starting location of the\nsuspicious thread. \nAfter jumping to the address, we can right click on the first address and find it's corresponding memory region.\n Page 13 of 16", "extraction_quality": 1, "language": "EN", "sources": [ "Malpedia" ], "references": [ "https://embeeresearch.io/unpacking-malware-using-process-hacker-and-memory-inspection/" ], "report_names": [ "unpacking-malware-using-process-hacker-and-memory-inspection" ], "threat_actors": [ { "id": "aa73cd6a-868c-4ae4-a5b2-7cb2c5ad1e9d", "created_at": "2022-10-25T16:07:24.139848Z", "updated_at": "2026-04-10T02:00:04.878798Z", "deleted_at": null, "main_name": "Safe", "aliases": [], "source_name": "ETDA:Safe", "tools": [ "DebugView", "LZ77", "OpenDoc", "SafeDisk", "TypeConfig", "UPXShell", "UsbDoc", "UsbExe" ], "source_id": "ETDA", "reports": null } ], "ts_created_at": 1775434711, "ts_updated_at": 1775791469, "ts_creation_date": 0, "ts_modification_date": 0, "files": { "pdf": "https://archive.orkl.eu/f20a392f376f95c0a1e4f4ee9a09f09fb26a437c.pdf", "text": "https://archive.orkl.eu/f20a392f376f95c0a1e4f4ee9a09f09fb26a437c.txt", "img": "https://archive.orkl.eu/f20a392f376f95c0a1e4f4ee9a09f09fb26a437c.jpg" } }