{
	"id": "1eb40daf-5606-471f-b436-968dc8d7af37",
	"created_at": "2026-04-06T00:10:57.103798Z",
	"updated_at": "2026-04-10T03:20:52.664909Z",
	"deleted_at": null,
	"sha1_hash": "64a6b89700c27c47bc1578815b8ed9bd4ca4e2e0",
	"title": "AsyncRAT: Analysing the Three Stages of Execution",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 2448933,
	"plain_text": "AsyncRAT: Analysing the Three Stages of Execution\r\nBy Hack Sydney\r\nPublished: 2023-02-08 · Archived: 2026-04-05 17:32:36 UTC\r\nMichael Elford\r\nMichael is a cybersecurity professional that is passionate about\r\nmalware analysis and reverse engineering.\r\nIn the second half of 2022, I led an investigation that involved a suspicious registry key, comprising a value that\r\nwould run a potentially malicious executable file.\r\nFurther analysis of the executable file resulted in confirmation of the file being malicious.\r\nIn this blog post, I aim to share the findings from the investigation, with the goal of making the audience aware of\r\nthe techniques that can be used to effectively analyse malware in general and specifically analyse ASyncRAT.\r\nASyncRAT Analysis\r\nNote: All malware analysis should be carried out in a sandboxed environment.\r\nTools used\r\nThis is the list of tools that were used for this analysis:\r\nFlareVM\r\nPEStudio\r\ndnSpy\r\nCyberchef\r\nGarbage Man\r\nStage One\r\nStarting the analysis of Stage One of the malware, the first step was to check the executable in PEStudio, which\r\nconfirmed that we were dealing with a .NET file. Furthermore, we interpreted the fairly high entropy as indicative\r\nof malware packing, where malware adds complexity to stay undetected by security solutions.\r\nPress enter or click to view image in full size\r\nhttps://medium.com/@hcksyd/asyncrat-analysing-the-three-stages-of-execution-378b343216bf\r\nPage 1 of 11\n\nPEstudio file overview\r\nOur next step was to peruse the strings of the malware, and take note of anything strange we may want to look\r\ninto a little bit deeper later on.\r\nPress enter or click to view image in full size\r\nPEstudio file overview\r\nExamining the strings, we immediately identified some strings that appear to be obfuscated. As a note to\r\nourselves, we highlighted that we may need to deploy a ‘find and replace’ later on.\r\nGoing Further\r\nAfter determining that the file was written in .NET and making note of the obfuscated strings, we then turned to\r\ndnSpy, a .NET debugger.\r\nOne of the first things we noticed was a naming discrepancy. The name of the executable on the host and the name\r\nof the executable shown in dnSpy are completely different. The reason as to why the executable having a\r\ncompletely different name is of interest is due to many threat actors that use malware rename them so that they do\r\nhttps://medium.com/@hcksyd/asyncrat-analysing-the-three-stages-of-execution-378b343216bf\r\nPage 2 of 11\n\nnot draw as much attention and can be hidden on the host and quietly run in the background so that even if the\r\nuser does notice the something strange is going on with their system, they will skip over the file thinking that it is\r\nnormal and doesn’t raise any alarms with the user and their AV.\r\nLooking through the code, there is a replace function for a string we had noted earlier. Now that we are certain\r\nabout what is replacing the obfuscation pattern, we can check what those strings are, which could possibly give us\r\na clue as to what is happening.\r\nPress enter or click to view image in full size\r\nExecutable name and replace function\r\nPulling on the Thread\r\nFor analysing the obfuscated strings, we used CyberChef. In CyberChef, we used the `Find/Replace` feature to\r\nperform the replace function found in the code. This enabled us to see the clear text of what was obfuscated which\r\nresulted in getting a clearer understanding of what was going on within the code.\r\nThe end-result of the above exercise gave us the de-obfuscated version of strings which contained “Load” and\r\n“Invoke”. This showed that something was going to be loaded and executed (“invoked”) by the code contained\r\nwithin the executable.\r\nIf at any time you are unsure what actions these methods perform, the best thing to do is Google around and find\r\nsome docs. It may be time consuming at first but it is an important part of analysing malware.\r\nPress enter or click to view image in full size\r\nDe-obfuscated strings\r\nhttps://medium.com/@hcksyd/asyncrat-analysing-the-three-stages-of-execution-378b343216bf\r\nPage 3 of 11\n\nAt this stage of the analysis, we had accumulated enough findings to start sketching out the trajectory of the\r\nmalware’s execution flow. We had identified the malware was loading and executing something, and that the\r\nmalware was packed and contained executable data that we would see in the next stage of analysis.\r\nHunting for the Hidden\r\nThe tool Garbage Man is used for heap analysis — a technique that allows analysts to intervene and observe as\r\nthe .NET malware is unraveling itself.\r\nAnalysing the malware in Garbage Man aided in extraction of hidden data that composed the second executable\r\nwithin the first executable.\r\nGet Hack Sydney’s stories in your inbox\r\nJoin Medium for free to get updates from this writer.\r\nRemember me for faster sign in\r\nIn order to further analyse the malware, we executed the original malware found on the host in Garbage Man. To\r\nget started, we added in a delay of 300ms with 10 snapshots taken at 100ms intervals.\r\nWe added in the delay to allow time for the process to start running and added the extra snapshots and intervals so\r\nthat we can compare the difference between the intervals if we need to.\r\nOnce Garbage Man had executed the file, we had these options:\r\nSift through the heap manually, and look at the strings and values that are contained within the executable\r\nUse the search function to look through all the snapshots. Specifically looking for bytes that start with the\r\nvalue of MZ — which is the PE header for executables and dll files, and then order them by size in\r\ndescending order. The search function gives us a list of results, and we can save the binaries with MZ\r\nheaders and save them for further analysis.\r\nPress enter or click to view image in full size\r\nhttps://medium.com/@hcksyd/asyncrat-analysing-the-three-stages-of-execution-378b343216bf\r\nPage 4 of 11\n\nUsing Garbage Man to search for executables and save the binary for analysis\r\nWhen saving the executable, we chose an executable with the large size value and due to us looking through all\r\nthe snapshots we were getting repeats of the same executable, we could then save it as “stage2.exe”. We then\r\npivoted back to PEstudio to check the file. On examination, our second hidden executable yet again turned out to\r\nbe a .NET file.\r\nPress enter or click to view image in full size\r\nPEstudio of stage2.exe\r\nStage Two\r\nDelving into our stage2.exe, we found that checking its strings highlighted some noteworthy Win32 APIs that\r\nmalware leverages. Some APIs that jumped out were connected with manipulating processes [T1055], specifically\r\nhttps://medium.com/@hcksyd/asyncrat-analysing-the-three-stages-of-execution-378b343216bf\r\nPage 5 of 11\n\nin this case, process hollowing [T1055.012] — an adversarial technique to create a paused, legitimate process then\r\nswap out its memory with malicious contents.\r\nPress enter or click to view image in full size\r\nSome of the APIs and Strings that could indicate Process Hollowing\r\nAs our stage two was in the .NET world again, we used dnSpy to dig a little deeper. When opening up the\r\nexecutable, we were met with a lot of information we had to get through. Like the first stage, the second stage’s\r\nnaming convention was also suspicious.\r\nPress enter or click to view image in full size\r\nStage 2 dnSpy\r\nExamining dnSpy’s output, we discovered a section completely different to the other parts of the code due to it\r\nbeing obfuscated, and seemingly performing a function in memory — both of which are techniques used to evade\r\nhttps://medium.com/@hcksyd/asyncrat-analysing-the-three-stages-of-execution-378b343216bf\r\nPage 6 of 11\n\ndetection [T1140].\r\nPress enter or click to view image in full size\r\nObfuscated section in Stage 2\r\nWe used Garbage Man once again to sneakily observe how the malware unraveled itself. However, if you want an\r\nalternate technique to de-obfuscating this part of the code, you can use de4dot which may also lay it out in an\r\neasier to read format.\r\nNext, in Garbage Man the objective was to retrieve the third hidden stage. Our prior technique could be deployed\r\nhere again, executing the binary and searching for the MZ headers.\r\nWe found an executable and saved it as “stage3.exe”. We then packaged this up and shipped it to PEstudio (There\r\nis also information for procexp.sys contained in this but we are not going to focus on that at this time).\r\nPress enter or click to view image in full size\r\nhttps://medium.com/@hcksyd/asyncrat-analysing-the-three-stages-of-execution-378b343216bf\r\nPage 7 of 11\n\nSearching for MZ header in stage2.exe\r\nStage Three\r\nWhen checking the third stage executable in PEstudio we observed again it to be a .NET file and that it contained\r\nstrings and APIs that suggested it was trying to make a network connection to an external source — like the API\r\nSend. This was a big hint that this was a Remote Access Trojan; I smell a RAT [TA0011]!\r\nPress enter or click to view image in full size\r\nAPIs showing stage3 trying to connect to external sources\r\nAfter we had a quick look at stage three’s strings through PEstudio, we hopped back over to ol’ reliable dnSpy.\r\nTrawling through stage three, we identified that AES encryption was used to encode the port and IP/domain that\r\nmade up the adversary’s command-and-control (C2). We were for sure dealing with a RAT, and we wanted to\r\ngather the IoCs associated with this encryption.\r\nhttps://medium.com/@hcksyd/asyncrat-analysing-the-three-stages-of-execution-378b343216bf\r\nPage 8 of 11\n\nPress enter or click to view image in full size\r\nAES encryption\r\nWe set a breakpoint in dnSpy where the AES decryption was performed, and then run the debugger for this to find\r\nthe decrypted string. Using a ‘stop-start’ technique with breakpoints in a debugger allows a malware analyst to\r\nhalt the malware at opportune moments as it decodes or decrypts itself. This allows us to understand what the\r\nmalware is doing as it is doing it.\r\nPress enter or click to view image in full size\r\ndnSpy breakpoint\r\nWhen we got to our breakpoint it paused the malware’s execution. Now, we gingerly allowed the malware to\r\nprogress one step at a time by using the step over button. We did this until eventually the malware began its\r\ndecryption phase, and we were first gifted the ports used by this RAT.\r\nPress enter or click to view image in full size\r\nhttps://medium.com/@hcksyd/asyncrat-analysing-the-three-stages-of-execution-378b343216bf\r\nPage 9 of 11\n\nPorts decrypted in dnSpy\r\nWhen we stepped over the different sections we were able to see that for this RAT it was using ports “6606, 7707,\r\n8808” and, eventually we unraveled the RAT until it delivered us the adversarial server it reported back to:\r\n“109.206.241[.]84”.\r\nDefending against RATs\r\nOur remediations will vary, but the first step is to recommend blocking this public IPv4 at the organisation\r\nfirewall level so the RAT can no longer beacon out.\r\nThe advice for defending against RATs is really advice for malware overall:\r\nChief advice is to train staff to check what they are downloading. Whether it’s from an email attachment, or\r\na site that promises to make their computer run faster if they run something, security awareness training is\r\nthe best and first layer of defense we’d advise you prioritise.\r\nLeverage network telemetry to try and monitor for unexpected activity. Whether this is VPN, firewall, or\r\nmore security-focused netflow, keeping an eye on in- and outbound traffic will help spot anomalous\r\nbehaviour. Moreover, cultivating a well-maintained deny-list for new and emerging malicious addresses\r\ncan only be a good thing.\r\nGood security tools are the perfect enemy of our adversaries. Deploy what works for your organisation,\r\njust please deploy something. A machine without any security solutions is a machine that presents an\r\nunmanageable, unacceptable risk to your business.\r\nBig thanks to Matthew Brennan and Chad Hudson for help and guidance.\r\nHopefully this writeup has helped show examples of some good tools and\r\ntechniques that can be used to help decrypt and understand what is going on\r\nwith other .NET executables in the future.\r\nhttps://medium.com/@hcksyd/asyncrat-analysing-the-three-stages-of-execution-378b343216bf\r\nPage 10 of 11\n\nSource: https://medium.com/@hcksyd/asyncrat-analysing-the-three-stages-of-execution-378b343216bf\r\nhttps://medium.com/@hcksyd/asyncrat-analysing-the-three-stages-of-execution-378b343216bf\r\nPage 11 of 11",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"Malpedia"
	],
	"references": [
		"https://medium.com/@hcksyd/asyncrat-analysing-the-three-stages-of-execution-378b343216bf"
	],
	"report_names": [
		"asyncrat-analysing-the-three-stages-of-execution-378b343216bf"
	],
	"threat_actors": [],
	"ts_created_at": 1775434257,
	"ts_updated_at": 1775791252,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/64a6b89700c27c47bc1578815b8ed9bd4ca4e2e0.pdf",
		"text": "https://archive.orkl.eu/64a6b89700c27c47bc1578815b8ed9bd4ca4e2e0.txt",
		"img": "https://archive.orkl.eu/64a6b89700c27c47bc1578815b8ed9bd4ca4e2e0.jpg"
	}
}