Navigating the labyrinth of forks

AsyncRAT has cemented its place as a cornerstone of modern malware and as a pervasive threat that has evolved into a sprawling network of forks and variants. While its capabilities are not that impressive on their own, it is the open-source nature of AsyncRAT that has truly amplified its impact. This blogpost provides an overview and analysis of the most relevant forks of AsyncRAT, drawing connections between them and showing how they have evolved.

Key points of this blogpost:

• We provide unique insights into the landscape of AsyncRAT and its numerous variants in order to navigate the labyrinth of forks easily.
• In the effort to map the vast hierarchy of AsyncRAT’s forks, we uncover their unique interconnections and document how these variants can be distinguished.
• We explore less common variants that feature unique plugins, ranging from a basic screamer plugin to a USB malware spreader.

Origins of AsyncRAT

You may have heard of AsyncRAT, short for asynchronous remote access trojan. This open-source RAT was released on GitHub in 2019 by a user going by the name of NYAN CAT. Developed in C#, it offers a wide range of typical RAT functionalities, including keylogging, screen capturing, credential theft, and more. Its simplicity and open-source nature has made it a popular choice among cybercriminals, leading to its widespread use in various cyberattacks.

But where does it come from? We believe that the groundwork for AsyncRAT was laid earlier by the Quasar RAT, which has been available on GitHub since 2015 and features a similar approach. Both are written in C#; however, their codebases differ fundamentally, suggesting that AsyncRAT was not just a mere fork of Quasar, but a complete rewrite. A fork, in this context, is a personal copy of someone else’s repository that one can freely modify without affecting the original project. The main link that ties them together lies in the custom cryptography classes used to decrypt the malware configuration settings. Specifically, these are classes Aes256 and Sha256, which fall under the Client.Algorithm namespace for AsyncRAT and the Quasar.Common.Cryptography namespace for Quasar. Figure 1 shows identical code being used in both implementations of Aes256.

The same code is mostly copied and pasted, including the same salt value and decryption settings. This class, together with Sha256, leads us to believe that AsyncRAT was to some degree influenced by the Quasar RAT.

Apart from these similarities, AsyncRAT introduced significant improvements, particularly in its modular architecture and enhanced stealth features, which make it more adaptable and harder to detect in modern threat environments. Its plugin-based architecture and ease of modification have sparked the proliferation of many forks, pushing the boundaries even further.

Fork labyrinth

Ever since it was released to the public, AsyncRAT has spawned a multitude of new forks that have built upon its foundation. Some of these new versions have expanded on the original framework, incorporating additional features and enhancements, while others are essentially the same version in different clothes.

Fork hierarchy

Figure 2 illustrates how some of the more prevalent AsyncRAT forks have evolved from one another over time.

In the middle of the tree are DcRat and VenomRAT. Our analysis has shown that they are the most widely deployed variants, together accounting for a significant number of campaigns. Other lesser-known forks occupy smaller but nonetheless notable portions of the pie. Figure 3 depicts the distribution of the most prevalent forks according to our telemetry.

DcRat offers a notable improvement over AsyncRAT in terms of features and capabilities. One of the more obvious changes is the data structure used for transferring data back and forth. It utilizes MessagePack, a well-known open-source library for more efficient binary data serialization. DcRat also implements evasion techniques like AMSI and ETW patching, which work by disabling security features that detect and log malicious behavior – AMSI patching prevents script scanning, while ETW patching blocks event tracing. Additionally, it features an antiprocess system whereby processes whose names match those in a denylist are terminated. Blocklisted programs include Taskmgr.exe, ProcessHacker.exe, MsMpEng.exe, Taskkill.exe, etc.

It’s also worth noting that DcRat’s plugin base builds upon AsyncRAT and further extends its functionality. Among the added plugins are capabilities such as webcam access, microphone recording, Discord token theft, and “fun stuff”, a collection of plugins used for joke purposes like opening and closing the CD tray, blocking keyboard and mouse input, moving the mouse, turning off the monitor, etc. Notably, DcRat also introduces a simple ransomware plugin that uses the AES-256 cipher to encrypt files, with the decryption key distributed only once the plugin has been requested. Apart from that, there appear to be many small changes like a different choice of salt (a string instead of a binary value), deliberately changed variable names to further evade detection, dynamic API resolution, and many more.

VenomRAT, on the other hand, was likely inspired by DcRat, as evidenced in the Identifying versions section. The malware is packed with so many features that it could be considered a separate threat on its own. We have chosen to group it under AsyncRAT as their client parts are very similar to each other. VenomRAT’s features and plugins have been documented in more detail by other vendors, so we won’t dive deep into them in this blogpost.

Not all RATs are serious in nature though, and this applies equally to AsyncRAT forks. Clones like SantaRAT or BoratRAT (see Figure 4) are meant to be jokes. In the case of the former, its authors have themselves acknowledged that the project was basically “shamelessly ripped off of DcRat”. Yet, despite this, we have found instances of real-world usage of them in the wild.

Identifying versions

While doing the analysis, we used various methods to identify and categorize each sample. It should be noted that the research was primarily on the client part of the malware, as this binary is what ends up on victims’ machines. It contains useful information such as malware configuration and where information about the C&C can be found.

The quickest and most straightforward way to identify a fork is to peek directly into the malware’s configuration, which can usually be found in the InitializeSettings function. The configuration values are encrypted with AES-256 and stored as base64 strings in the Settings class. In most cases, the correct fork name is readily available and conveniently labeled as Version. In about 90% of our analyzed samples, the Version field contains some meaningful description of either the fork’s name or the malware author’s pseudonym. The remaining samples had this field intentionally left blank. Figure 5 illustrates the typical configuration initialization procedure found in DcRat and its derivatives (VenomRAT in this case).

If the Version field is empty, sometimes it’s possible to get another clue by looking at the Salt value used for encrypting the configuration. Attackers often neglect this parameter when copy-pasting their own fork. The Salt value can be found in the Client.Algorithm.Aes256 class, as seen in Figure 6.

Yet another way to get more insight is to look for the embedded certificate used to authenticate the C&C server. It’s also located in the configuration as a base64-encoded value. Unpacking this value often reveals further information about the server, such as common name, organization, and organizational unit. If a particular fork has its own name in the Version field, it is often possible to trace back the previous fork upon which it was likely based by looking at the CN field. Figure 7 shows a DER-encoded certificate that reveals the BoratRAT fork, after extraction and decoding.

The techniques mentioned above primarily apply to trivial cases where malware authors either did not bother to remove traces or used a default certificate. A more sophisticated method for identifying AsyncRAT servers exists, which involves sending a specially crafted packet to the C&C server. This approach is explained in detail in this Axel Mahr blogpost.

Should everything else fail, determining the sample origin can ultimately be done the old-fashioned way, by manually inspecting the code. This involves a detailed analysis of the code’s structure, syntax, and functionality, comparing them against the patterns of previously categorized samples.

Extensive fork list

We have highlighted here some of the more prominent AsyncRAT forks. Due to the sheer number of available forks, it is not feasible to cover every single one. For completeness, Figure 8 provides an extended list of AsyncRAT forks known to be used for malicious purposes, as seen in ESET telemetry to date.

Exploring lesser-known variants

So far, we’ve mentioned some of the major forks that dominate the landscape. In this section, we have cherry-picked some lesser-known forks that enhance AsyncRAT’s functionality beyond the features included in the default versions. These exotic forks are often the work of one person or group and they make up less than 1% of the volume of AsyncRAT samples.

NonEuclid RAT

This fork stands out primarily for its inclusion of new plugins, on top of the default ones. While some plugins might seem trivial or geared towards “fun stuff”, others, like WormUsb.dll, have distinctly malicious purposes. Table 1 lists a selection of NonEuclid RAT plugins that deviate from the standard plugin base seen in regular forks.

Table 1. Selection of NonEuclid RAT plugins we deemed interesting

Screamer.dll

There are five jump scare images built into the plugin. An attacker sends a command that indicates which image they want to use, along with the WAV file to be played, and the delay after which the jump scare is triggered. Figure 9 shows the first three prebundled images an attacker may choose from.

Piano.dll

This plugin plays arbitrary WAV files. All sound files are stored in %appdata%\Piano. piano.dll supports three commands:

• SetSound – adds a new sound file to %appdata%\Piano,
• PlayMisc – plays a requested sound file from %appdata%\Piano, and
• ClientAdd – retrieves multiple sound files from the C&C server.

Service.dll

This plugin facilitates managing Windows services, such as starting, stopping, and pausing services.

Maps.dll

This is a simple plugin to collect geolocation information from the victim. It uses the .NET GeoCoordinateWatcher class to register a callback function to collect data each time the location is available. Among the collected information are latitude, longitude, username, and computer name.

WormUsb.dll

This plugin compromises PE files with an arbitrary payload specified by the attacker.

Despite the term Usb in WormUsb.dll, this plugin targets several locations based on the command provided:

• InfectExe – compromises an individual PE file,
• InfectExeInWindows – targets PE files in personal folders (Desktop, Documents, Downloads, My Music), and
• InfectUsbExe – targets PE files in all drives excluding the C drive.

Under the hood, it works by moving the original file to a temporary location. Then it drops a small stub in place of the original file. This stub’s resource section is then populated to contain both the original file and the specified payload, both of which are compressed and encrypted with a per-file key, generated at the time of construction. Following this, the malware then obfuscates the stub by introducing proxy methods, adding custom control flow obfuscation, and variable renaming. As a final touch, it embeds the original icon and metadata in the modified stub. Figure 10 shows the function, with the original method names, responsible for compromising a single file.

When such a compromised file is executed, it first decrypts, unpacks and runs the payload program, then proceeds to do the same with the original program.

Brute.dll

This plugin supports brute forcing of both SSH and FTP protocols from the client side. The attacker feeds it three parameters: host, login, and password, and the plugin will try to connect using those credentials. If the connection succeeds, the credentials are sent back to the attacker with a flag indicating success. It’s not difficult to imagine a scenario whereby an attacker might use this sort of attack to distribute brute forcing across a large pool of compromised machines, thus circumventing restrictions based solely on the IP address.

Signature Antivirus.dll

The name of the plugin implies it might have something to do with antivirus functionality. While this is technically true, it is also a case of the most primitive, manual antivirus solution ever created. The plugin receives a list of MD5 hashes from the attacker and compares them to the hashes of all EXE files it finds on every disk. If a matching file is found, it triggers the oddly named DetectVirus function, which merely deletes the file without any further analysis. This makes the name of the plugin very dubious at best. In the hands of the malware author, it may have been used to delete competitor malware, or really just any arbitrary file.

cliper.dll

This is a standalone clipper that continuously monitors the victim’s clipboard, and if a cryptocurrency wallet address is detected, it is replaced with one provided by the attacker. Attacker-provided wallets are only sent when the plugin is first requested; they are not hardcoded in the plugin. Additionally, in Figure 11, we can also see some credit card entries. This plugin contains an extensive list of regexes that can detect both cryptocurrency wallets and credit cards, and in the case of the latter they just get sent back to the attacker.

JasonRAT

Identified in 2024, this variant shows continued signs of activity. It is interesting in that it employs obscure variable-naming conventions reminiscent of “satanic” terms from what the malware author refers to as the Book of Jason. In Figure 12, you can see typical AsyncRAT configuration values (in base64), but with renamed variables, while Figure 13 shows the logic of the main entry point of the malware. Besides the usual configuration values, this variant further extends the client by introducing country targeting.

Another strange feature is the choice of string obfuscation. A subset of the strings employs an extra layer of obfuscation by utilizing an extended variant of Morse code. Both uppercase and lowercase letters are included, as well as some special characters. Figure 14 shows the encoded registry key string using an extended mapping.

XieBroRAT

This is a RAT with Chinese localization. It introduces a new plugin, BrowserGhost.dll, which is a browser-credential stealer. Another plugin, Abstain.dll, provides interaction with Cobalt Strike servers by making a reverse connection.

To increase the coverage, the malware provides the delivery chain in several different languages. The standard .NET client binary can be wrapped and distributed via shellcode, VBS, or JavaScript.

Finally, the author further extended the malware by borrowing heavily from open-source projects, integrating tools like mimikatz, SharpWifiGrabber, SharpUnhooker, etc.

Conclusion

AsyncRAT’s rise and its subsequent forks highlight the inherent risks of open-source malware frameworks. Our analysis revealed a diverse and evolving ecosystem of derivatives, ranging from persistent threats like DcRat and VenomRAT to lesser-known novelty forks like JasonRAT and BoratRAT, which seem to serve more as curiosities than credible threats. All of these forks not only extend AsyncRAT’s technical capabilities but also demonstrate how quickly and creatively threat actors can adapt and repurpose open-source code.

The widespread availability of such frameworks significantly lowers the barrier to entry for aspiring cybercriminals, enabling even novices to deploy sophisticated malware with minimal effort. This democratization of malware development – especially considering the rising popularity of LLMs and potential to misuse their capabilities – further accelerates the creation and customization of malicious tools, contributing to a rapidly expanding and increasingly complex threat landscape.

In light of these trends, it is reasonable to anticipate that future forks may incorporate more advanced obfuscation, modularity, and evasion capabilities. This potential evolution underscores the importance of proactive detection strategies and deeper behavioral analysis to effectively address emerging threats.

For any inquiries about our research published on WeLiveSecurity, please contact us at threatintel@eset.com. 

ESET Research offers private APT intelligence reports and data feeds. For any inquiries about this service, visit the ESET Threat Intelligence page.

IoCs

A comprehensive list of indicators of compromise (IoCs) can be found in our GitHub repository.

Files

MITRE ATT&CK techniques

This table was built using version 17 of the MITRE ATT&CK framework.