{
	"id": "c538bfa8-553c-47d5-8aa8-a0659f77b284",
	"created_at": "2026-04-06T00:06:06.596257Z",
	"updated_at": "2026-04-10T13:12:44.356026Z",
	"deleted_at": null,
	"sha1_hash": "3d93ac448b14cae40f1618032b985a74b6b179c0",
	"title": "Hunting AsyncRAT \u0026 QuasarRAT",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 9322655,
	"plain_text": "Hunting AsyncRAT \u0026 QuasarRAT\r\nPublished: 2024-01-15 · Archived: 2026-04-05 20:21:13 UTC\r\nIntroduction\r\nRecorded Future writes in their Adversary Infrastructure Report 2023:\r\nThe top 5 malware families we detected this year are AsyncRAT, Quasar RAT, PlugX, ShadowPad, and\r\nDarkComet. Interestingly, the top 2 detections are open-source, and the last 3 are well-established tools, showing\r\nthat our statement from last year’s report remains true:\r\n[The] high level of commodity tool use indicates that threat actors are more concerned with blending in and being\r\nnon-attributable rather than being undetectable, or have simply determined that their targets are not likely to\r\ndetect even these well-known tools.\r\nFigure 1: Top 20 Remote Access Trojans (RATs) and backdoors, ranked according to the number of unique\r\nCommand and Control (C2) servers observed. (Source: Recorded Future)\r\nThe final statement in the aforementioned quote is particularly interesting: […] have simply determined that their\r\ntargets are not likely to detect even these well-known tools. This post combines and extends two longer threads\r\npreviously shared on X (formerly Twitter) by me, discussing AsyncRAT and QuasarRAT. It highlights techniques\r\nand indicators of compromise (IOCs) that we, as defenders, can leverage to identify and hunt infections in our\r\nenvironment caused by these two types of remote access trojans.\r\nhttps://dfir.ch/posts/asyncrat_quasarrat/\r\nPage 1 of 17\n\nAsyncRAT is a prevalent Trojan executed at the end of a (potentially longer) infection chain on target computers.\r\nHP Security and Trellix have recently reported that attackers have been deploying AsyncRAT. Since the source\r\ncode of AsyncRAT is publicly available, we obtained a copy of the builder to scrutinize its features and build\r\ndetection capabilities for this Remote Access Trojan (RAT).\r\nSeveral methods can be employed to identify endpoints infected with AsyncRAT:\r\nDetection of standard Command and Control (C2) ports usage.\r\nSearch for persistence mechanisms.\r\nExamination of Mutexes.\r\nLast but not least, hunting for dropped DLL files.\r\nStandard Command and Control (C2) Ports\r\nThe builder shows three default ports (6606, 7707, 8808) when assembling a new AsyncRAT client. Within the\r\nsame interface, users can input the C2 address, to which the AsyncRAT client will establish a connection upon\r\nsuccessful infection. Additionally, there is an option to store the C2 address on Pastebin.\r\nFigure 2: AsyncRat's default ports\r\nhttps://dfir.ch/posts/asyncrat_quasarrat/\r\nPage 2 of 17\n\nAnalysis of 1000 AsyncRAT samples from ThreatFox revealed that, as of January 2024, the top three ports for the\r\nCommand and Control (C2) address were consistently 6606, 7707, and 8808. This indicates that many attackers\r\ndid not take the effort to modify the default port within the builder. Additionally, it was observed that all samples\r\naccessible on Bazaar utilized a C2 port higher than 1024. This information might be helpful for hunts within the\r\nFirewall logs (search especially for connections to IP-only domains connecting to a high-port - but beware: this\r\nsearch might return many hits and, without the context of the process that created the network connection, a\r\ndaunting task).\r\nTo retrieve Indicators of Compromise (IOCs) from AsyncRAT samples on ThreatFox, we used the following curl\r\ncommand:\r\ncurl -X POST https://threatfox-api.abuse.ch/api/v1/ -d '{ \"query\": \"taginfo\", \"tag\": \"AsyncRAT\", \"limit\": 1000\r\nPersistence\r\nIn the builder, you can specify whether a persistence should be set up or not. When this option is selected, you can\r\ndefine a filename and choose the directory where the payload will be stored (per default, only two directories are\r\navailable). However, as the source code is available, expanding the selection to include additional paths should be\r\na straightforward task.\r\nFigure 3: Installation directories\r\nMutex\r\nAsyncRAT uses a mutex to detect an already infected system. The prefix of the mutex “AsyncMutex_” was also\r\nmentioned in HP Security’s tweet, indicating that attackers use the default settings in some cases (which is good\r\nhttps://dfir.ch/posts/asyncrat_quasarrat/\r\nPage 3 of 17\n\nfor us defenders; read the section about Mutex hunting below).\r\nFigure 4: Default Mutex\r\nAssembly Information\r\nInterestingly, we can “clone” the information about the binary from another binary for blending in. In this\r\nexample, I took the data from the legitimate PingCastleCloud binary - the builder then used the same information\r\nfor the malicious binary.\r\nhttps://dfir.ch/posts/asyncrat_quasarrat/\r\nPage 4 of 17\n\nFigure 5: Tamper the assembly information\r\nWe can also force an obfuscation of the .NET code to slow down Reverse Engineering (I haven’t looked into this\r\nfeature).\r\nhttps://dfir.ch/posts/asyncrat_quasarrat/\r\nPage 5 of 17\n\nFigure 6: Simple obfuscation mechanism\r\nThe sample generated through the outlined steps above comes straight to a VT score of 48 (as of the time when I\r\ninitially posted the original tweets) - anything but unknown, also detected by various YARA signatures.\r\nFigure 7: VirusTotal results\r\nClient information\r\nhttps://dfir.ch/posts/asyncrat_quasarrat/\r\nPage 6 of 17\n\nAfter executing the AsyncRAT sample we built with the settings outlined above (in the various reports and tweets\r\nreferenced so far, AsyncRAT is run at the end of a longer infection chain) on our lab machine, we see that our\r\ninfected machine has reported back to the controller.\r\nFigure 8: Infected machines\r\nPlugins\r\nAsyncRAT now has various built-in functions that can further extend the initial access, such as “Password\r\nRecovery”. If the function “Password Recovery” is selected, we see in the logs that a DLL (Recovery.dll) was sent\r\nto the client.\r\nFigure 9: Plugin recovery.dll sent to the client\r\nAlso, using other plugins, AsyncRAT sends specific files (dlls) to the client. I have yet to look into how these\r\nplugins work under the hood, but that might be a topic for another blog post.\r\nhttps://dfir.ch/posts/asyncrat_quasarrat/\r\nPage 7 of 17\n\nFigure 10: Sending other plugins to the client\r\nTime for Velociraptor 😍 Utilisting the MTF-Hunt, we searched for the names of the plugins transfered from the\r\nserver to the infected machine and found the plugins placed directly under the path C:\\.\r\nFigure 11: Velociraptors MFT Hunt\r\nTo get a list of all plugins available within AsyncRAT, browse to the public GitHub repo.\r\nhttps://dfir.ch/posts/asyncrat_quasarrat/\r\nPage 8 of 17\n\nFigure 12: AsyncRAT's plugins\r\nThe LimeLogger plugin for recording keyboard strokes works fine, recording all keystrokes on our test machine.\r\nhttps://dfir.ch/posts/asyncrat_quasarrat/\r\nPage 9 of 17\n\nFigure 13: Logfile of the keylogger\r\nMutex Hunting\r\nUsing Velociraptor’s Mutants-Hunt and the string “AsyncMutex_” (the prefix of the Mutex), we can also find\r\ninfected machines.\r\nFigure 14: Velociraptors Mutants Hunt\r\nPersistence techniques\r\nAsyncRAT distinguishes between two types of persistence. Either the installer is run with administrative\r\nprivileges, in which case a Scheduled Task is created. Or a new entry in the Run Key is created when the installer\r\nrun as an unprivileged user. Below is the relevant code (highlighted with the red square is the code that creates the\r\nScheduled Task).\r\nhttps://dfir.ch/posts/asyncrat_quasarrat/\r\nPage 10 of 17\n\nFigure 15: The code that creates the Scheduled Task\r\nIn Figure 16, the sample was installed as an unprivileged user, resulting in a new run key.\r\nFigure 16: Run-Key\r\nThe THOR APT scanner from from Nextron findes AsyncRAT samples based on the Rule Reversed_String - see\r\nFigure 17 for the relevant code. Probably noisier than stealthier 🤔\r\nFigure 17: Reversed Registry Key Path\r\nhttps://dfir.ch/posts/asyncrat_quasarrat/\r\nPage 11 of 17\n\nFigure 18: Rule Reversed_String from THOR Scanner\r\nBelow is the newly created Scheduled Task (installation with admin rights) - the executable is again placed in\r\nAppData\\Roaming (one of the two options in the builder).\r\nFigure 19: The newly created Scheduled Task\r\nQuasarRAT\r\nQuasarRAT is another RAT we see periodically in our IR cases. It was also used against NATO facilities in March\r\n2023, as reported by Proofpoint.\r\nWe can hunt for\r\nhttps://dfir.ch/posts/asyncrat_quasarrat/\r\nPage 12 of 17\n\nDetect the usage of standard C2 ports\r\nHunting for the persistence mechanisms\r\nMutexes\r\nLast but not least, hunting for User-Agents\r\nQualys has published an excellent paper, Stealthy Quasar Evolving to Lead the RAT Race, where the builder and\r\nmuch more details about Quasar are described in detail.\r\nStandard C2 ports\r\nIn the client builder (which creates an executable used for the infection), the default port is pre-configured to\r\n4782.\r\nFigure 20: Default port\r\nOn ThreatFox, we see that a quarter of the samples kept this default port. The other samples use a different high\r\nport.\r\nhttps://dfir.ch/posts/asyncrat_quasarrat/\r\nPage 13 of 17\n\nFigure 21: Default ports in the wild (Threatfox)\r\nMutex Hunting\r\nWe can create a “random” Mutex per client build, though random is not quite right, as the structure of the mutex\r\nremains the same. 🤔\r\nFigure 22: Default Mutex\r\nWith the following regex, we can find these generated mutexes and thus efficiently find infected clients on the\r\nnetwork:\r\nhttps://dfir.ch/posts/asyncrat_quasarrat/\r\nPage 14 of 17\n\n[0-9a-f]{8}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{12}$\r\nUsing the example of a recent sample on Bazaar, we look at the Mutexes logged by Joe Security. So besides the\r\ndefault port also, the default mutex values are used in the wild.\r\nFigure 23: Default Mutex in the wild\r\nUtilising Velociraptor and the Mutants-Hunt with the following regex:\r\n(?-i)\\\\[0-9a-f]{8}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{12}$\r\nWhich finds the infected machine in the lab 😎\r\nhttps://dfir.ch/posts/asyncrat_quasarrat/\r\nPage 15 of 17\n\nFigure 24: Velociraptor's Mutants Hunt\r\nUser Agent\r\nThe hard-coded user agent string could be used for hunting or monitoring purposes. This User Agent ist also part\r\nof the the Sigma rule Malware User Agent, mainted by the Nextron Systems stuff.\r\nFigure 25: Hardcoded User-Agent\r\nhttps://dfir.ch/posts/asyncrat_quasarrat/\r\nPage 16 of 17\n\nPersistence techniques\r\nQuasar uses the exact same persistence mechanisms as AsyncRAT, which we analyzed above in depth. A run-key\r\nentry is created when the installation is performed under an unprivileged user, or a new scheduled task is created\r\nwith administrative credentials.\r\nFigure 27: Quasar Persistence\r\nSource: https://dfir.ch/posts/asyncrat_quasarrat/\r\nhttps://dfir.ch/posts/asyncrat_quasarrat/\r\nPage 17 of 17",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"Malpedia"
	],
	"origins": [
		"web"
	],
	"references": [
		"https://dfir.ch/posts/asyncrat_quasarrat/"
	],
	"report_names": [
		"asyncrat_quasarrat"
	],
	"threat_actors": [],
	"ts_created_at": 1775433966,
	"ts_updated_at": 1775826764,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/3d93ac448b14cae40f1618032b985a74b6b179c0.pdf",
		"text": "https://archive.orkl.eu/3d93ac448b14cae40f1618032b985a74b6b179c0.txt",
		"img": "https://archive.orkl.eu/3d93ac448b14cae40f1618032b985a74b6b179c0.jpg"
	}
}