{
	"id": "fca6eb03-d175-4ac1-9067-14e3570d579a",
	"created_at": "2026-04-06T00:17:28.517606Z",
	"updated_at": "2026-04-10T03:20:56.254033Z",
	"deleted_at": null,
	"sha1_hash": "a3a3935bf91d7d474941d4d7204d933f3c03e300",
	"title": "How to Use Process Hacker and DnSpy to Unpack .NET Malware",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 2608150,
	"plain_text": "How to Use Process Hacker and DnSpy to Unpack .NET Malware\r\nBy Matthew\r\nPublished: 2023-10-30 · Archived: 2026-04-05 22:27:31 UTC\r\nUnpacking malware can be a tedious task. Often involving intensive static analysis and in-depth knowledge of\r\ndebugging.\r\nIn this post, I'll demonstrate an easy method that can be used to unpack files that ultimately load a .NET based\r\nmalware.\r\nThis method primarily involves running the file and monitoring for process executions using Process Hacker.\r\nUpon execution, Process Hacker can be used to observe any .NET files loaded into memory. If a file is identified,\r\nit can then be obtained using Dnspy.\r\nLink to the File\r\nSha256: 05c2195aa671d62b3b47ff42630db25f39453375de9cffa92fc4a67fa5b6493b\r\nMalware Bazaar\r\nAnalysis\r\nWe will begin analysis by saving the file into our virtual machine and unzipping it with the password infected .\r\nAfter unzipping, we will also create a copy of the file with a shorter filename.\r\nWe will also perform a basic initial assessment using Detect-it-easy.\r\nInitial Assessment with Detect-it-easy\r\nOur primary goal here is to review the entropy graph. Here we can determine if there are any high-entropy areas\r\nlarge enough to store a file.\r\nIn this case, there is such an area (as seen in below screenshot). This area suggests that the file could be a loader\r\n(as it contains a possible encrypted payload).\r\nhttps://embee-research.ghost.io/unpacking-net-malware-with-process-hacker/\r\nPage 1 of 15\n\nInitial Assessment With DnSpy\r\nBefore attempting to unpack the file, we will also open it within DnSpy.\r\nThis is to make sure that the file is not already unpacked. In our initial assessment, we didn't see any functionality\r\nthat suggested the file was already unpacked.\r\nhttps://embee-research.ghost.io/unpacking-net-malware-with-process-hacker/\r\nPage 2 of 15\n\nObserving Unpacked Content With Process Hacker\r\nAt this point, we want to run the file and attempt to let it unpack itself.\r\nThis can be achieved by running the file for a few seconds, and observing the process as well as any new\r\nprocesses that are spawned.\r\nAfter a few seconds have passed, we can go ahead and view the process to see if any new .NET modules have\r\nbeen loaded.\r\nRunning the file for a few seconds, we can see that it spawns aspnet_compiler.exe . This is suspicious and\r\nsomething we can hone in on.\r\nhttps://embee-research.ghost.io/unpacking-net-malware-with-process-hacker/\r\nPage 3 of 15\n\nWe can also observe that after the new process is spawned, the original process 05c.exe exits a few seconds\r\nlater.\r\nThis is an indicator that any suspicious or unpacked content is likely contained within aspnet_compiler.exe .\r\nIdentifying Unpacked .NET Files Using Process Hacker\r\nWith the suspicious aspnet_compiler.exe identified, we can go ahead and inspect it using Process Hacker.\r\nWe can do this by double clicking on the process name, or right-clicking and selecting \"Properties\".\r\nThis will open a window like the following. There are two main points here.\r\n.NET Assemblies tab - This shows us that some kind of .NET module is loaded into the process.\r\nImage Type - 32bit - The process is 32-bit, this tells us that any future debugging will require a 32-bit\r\ndebugger (eg Dnspy x86)\r\n(Verified) Microsoft Corporation - This is likely a legitimate process that has been hijacked.\r\nInspecting Loaded .NET Modules With Process Hacker\r\nWe can go ahead an inspect any loaded modules with the .NET assemblies tab.\r\nThis will list any loaded .NET modules within the current process. As well as information for each module. We\r\nwant to look for loaded modules that look out of place, or different to the others.\r\nhttps://embee-research.ghost.io/unpacking-net-malware-with-process-hacker/\r\nPage 4 of 15\n\nIn this case, there is a loaded module named vik that doesn't look right. It has a completely different style of\r\nname to the other modules, and doesn't have a corresponding native image path (like all the other modules)\r\nIf we look closer, we can also see that the \"regular\" path is that of aspnet_compiler.exe . This is suspicious, why\r\nwould aspnet_compiler be named vik ?\r\nVerifying Suspicious .NET Modules Using DnSpy\r\nNow that we have identified a suspicious module, we can go ahead and obtain it using DnSpy.\r\nTo obtain the file, we can open up Dnspy (32-bit) and attach to the aspnet_compiler.exe process.\r\nThis will allow us to inspect the loaded modules and view their corresponding source code.\r\nAttaching Dnspy To a .NET Process\r\nWe can attach to aspnet_compiler.exe using Debug -\u003e Attach To Process -\u003e Aspnet_compiler.exe\r\nhttps://embee-research.ghost.io/unpacking-net-malware-with-process-hacker/\r\nPage 5 of 15\n\nWith the process attached, we now want to inspect any loaded modules.\r\nWe can do this by opening a Modules tab, using Debug -\u003e Windows -\u003e Modules\r\nhttps://embee-research.ghost.io/unpacking-net-malware-with-process-hacker/\r\nPage 6 of 15\n\nWith the new Modules tab, we can list the same loaded modules that were observed with Process Hacker.\r\nInterestingly, there is no vik module, but there is an aspnet_compiler.exe module that we know was\r\nassociated with vik .\r\nBy clicking on aspnet_compiler.exe , and selecting Go To Module , we can view the module contents and\r\ncorresponding decompiled code.\r\nhttps://embee-research.ghost.io/unpacking-net-malware-with-process-hacker/\r\nPage 7 of 15\n\nHowever, this will open the original aspnet_compiler.exe file from disk and not from within memory.\r\nHence, the \"real\" file will be loaded and we won't see anything suspicious.\r\nhttps://embee-research.ghost.io/unpacking-net-malware-with-process-hacker/\r\nPage 8 of 15\n\nInstead, we can go back and re-open the file from memory.\r\nhttps://embee-research.ghost.io/unpacking-net-malware-with-process-hacker/\r\nPage 9 of 15\n\nWith the file opened \"from memory\", we can obtain the real suspicious content. Which has likely been used to\r\noverwrite the original file in memory.\r\nWe can see the vik module loaded into DnSpy.\r\nJumping to the Entry Point of .NET Malware\r\nTo inspect the vik file more closely, we can right-click on vik and select Go To Entry Point\r\nThis will take us to the beginning of the code. Which very closely resembles that of Asyncrat.\r\nhttps://embee-research.ghost.io/unpacking-net-malware-with-process-hacker/\r\nPage 10 of 15\n\nClicking on the Settings.InitializeSettings() method, we can see where the configuration values are\r\ndecrypted and loaded into the file.\r\nIdentifying the Malware With Google\r\nIf you haven't seen Asyncrat before, you could instead take some of the values in the \"unpacked\" sample and\r\ngoogle them.\r\nIf the malware is known and there are existing reports, you will likely encounter reports that will suggest which\r\nfamily the malware belongs to.\r\nYou may have to experiment with which values to Google, some return better results than others. Below we can\r\nsee Asyncrat comes up straight away when googling Settings.InitializeSettings Malware\r\nhttps://embee-research.ghost.io/unpacking-net-malware-with-process-hacker/\r\nPage 11 of 15\n\nVerifying With a Sandbox\r\nWith an unpacked module now obtained, you can use DnSpy to save the file for additional analysis.\r\nFrom here, you can submit the unpacked file to a sandbox or scan it against a set of Yara rules. This is useful if the\r\nstrings/functions within the file are obfuscated or you aren't able to obtain a good result from google.\r\nThis will save the file from memory, so you don't have to worry about saving the \"wrong\" file\r\nhttps://embee-research.ghost.io/unpacking-net-malware-with-process-hacker/\r\nPage 12 of 15\n\nSubmitting the File To Hatching Triage\r\nAfter saving, you can submit the file to an online sandbox like Hatching Triage.\r\nHatching Triage is correctly able to identify the file as Asyncrat and extract the associated configuration values.\r\nhttps://embee-research.ghost.io/unpacking-net-malware-with-process-hacker/\r\nPage 13 of 15\n\nSubmitting the File to Unpacme\r\nAnother option which is effective and significantly cheaper for researchers, is Unpacme.\r\nUnpacme is correctly able to identify the file as Asyncrat and extract all configuration values.\r\nhttps://embee-research.ghost.io/unpacking-net-malware-with-process-hacker/\r\nPage 14 of 15\n\nConclusion\r\nIn this post, we performed some basic analysis of an Asyncrat loader, and utilised Process Hacker to identify an\r\nunpacked payload. We then used Dnspy to obtain the unpacked malware and identify it as Asyncrat.\r\nSign up for Embee Research\r\nMalware Analysis Insights\r\nNo spam. Unsubscribe anytime.\r\nSource: https://embee-research.ghost.io/unpacking-net-malware-with-process-hacker/\r\nhttps://embee-research.ghost.io/unpacking-net-malware-with-process-hacker/\r\nPage 15 of 15\n\n  https://embee-research.ghost.io/unpacking-net-malware-with-process-hacker/  \nWith the process attached, we now want to inspect any loaded modules.\nWe can do this by opening a Modules tab, using Debug -\u003e Windows-\u003e Modules\n   Page 6 of 15",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"Malpedia"
	],
	"references": [
		"https://embee-research.ghost.io/unpacking-net-malware-with-process-hacker/"
	],
	"report_names": [
		"unpacking-net-malware-with-process-hacker"
	],
	"threat_actors": [],
	"ts_created_at": 1775434648,
	"ts_updated_at": 1775791256,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/a3a3935bf91d7d474941d4d7204d933f3c03e300.pdf",
		"text": "https://archive.orkl.eu/a3a3935bf91d7d474941d4d7204d933f3c03e300.txt",
		"img": "https://archive.orkl.eu/a3a3935bf91d7d474941d4d7204d933f3c03e300.jpg"
	}
}