AsyncRAT has established itself as a foundational element of modern malware, evolving into a vast network of forks and variants. While its individual capabilities may not be extraordinary, it is the open-source nature of AsyncRAT that has significantly magnified its impact. This article offers a comprehensive overview and analysis of the most relevant forks of AsyncRAT, establishing connections between them and illustrating their evolutionary paths.
Key points covered in this article:
- We provide valuable insights into the landscape of AsyncRAT and its numerous variants to help navigate the complex web of forks.
- By mapping out the extensive hierarchy of AsyncRAT forks, we uncover their unique relationships and document ways to differentiate between them.
- We delve into less common variants that introduce distinctive plugins, ranging from basic screamer plugins to USB malware spreaders.
Origins of AsyncRAT
AsyncRAT, short for asynchronous remote access trojan, made its debut on GitHub in 2019, courtesy of a user known as NYAN CAT. Developed in C#, this open-source RAT offers a wide array of typical RAT functionalities, such as keylogging, screen capturing, credential theft, and more. Its simplicity and open-source nature have made it a popular choice among cybercriminals, leading to its widespread use in various cyberattacks.
But where did AsyncRAT originate? It is believed that the foundation for AsyncRAT was laid earlier by the Quasar RAT, available on GitHub since 2015, which follows a similar approach. While both are coded in C#, their codebases differ significantly, indicating that AsyncRAT was not merely a fork of Quasar but a complete reimagining. The common thread between them lies in the custom cryptography classes used to decrypt the malware configuration settings. Specifically, classes like Aes256 fall under the Client.Algorithm namespace for AsyncRAT and the Quasar.Common.Cryptography namespace for Quasar. Identical code snippets, including the same salt value and decryption settings, in both implementations of Aes256 suggest a possible influence of Quasar RAT on AsyncRAT.
Aside from these similarities, AsyncRAT introduced significant enhancements, particularly in its modular architecture and enhanced stealth features, making it more adaptable and harder to detect in contemporary threat environments. Its plugin-based structure and ease of customization have spurred the proliferation of numerous forks, pushing the boundaries even further.
Fork labyrinth
Since its public release, AsyncRAT has given rise to a plethora of new forks that build upon its foundation. Some of these new versions have expanded the original framework by adding extra features and improvements, while others are essentially the same version dressed in different garb.
Fork hierarchy
Figure 2 depicts how some of the more prevalent forks of AsyncRAT have evolved from one another over time.
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 conducting our analysis, we employed various methods to identify and categorize each sample. It is important to note that the research primarily focused on the client part of the malware, as this binary is what ultimately lands on victims’ machines. It contains valuable information such as malware configuration and the location of C&C information.
The quickest and most straightforward way to identify a fork is to examine the malware’s configuration directly, typically 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 clearly 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 intentionally left this field blank. Figure 5 illustrates the typical configuration initialization process found in DcRat and its derivatives (VenomRAT in this case).
If the Version field is empty, sometimes it’s possible to obtain another clue by inspecting the Salt value used for encrypting the configuration. Attackers often overlook this parameter when adapting their own fork. The Salt value can be located in the Client.Algorithm.Aes256 class, as shown in Figure 6.
Another method to gain more insight is to search for the embedded certificate used to authenticate the C&C server. It is also stored in the configuration as a base64-encoded value. Decoding this value often reveals additional 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 examining the CN field. Figure 7 displays a DER-encoded certificate that unveils the BoratRAT fork after extraction and decoding.
The techniques mentioned above are primarily applicable to straightforward cases where malware authors either neglected 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.
If all else fails, determining the origin of a sample can ultimately be accomplished through manual code inspection. This entails a thorough analysis of the code’s structure, syntax, and functionality, comparing them against the patterns of previously categorized samples.
Extensive fork list
We have spotlighted here some of the more prominent AsyncRAT forks. Due to the sheer number of available forks, it is impractical to cover each one individually. For comprehensive coverage, Figure 8 offers an extended list of AsyncRAT forks known to be utilized for malicious intents, as observed in ESET telemetry up to now.
Exploring lesser-known variants
Thus far, we have discussed some of the major forks that dominate the landscape. In this section, we have handpicked some lesser-known forks that enhance AsyncRAT’s functionality beyond the features included in the default versions. These unique forks are often the brainchild of an individual or group, constituting less than 1% of the volume of AsyncRAT samples.
NonEuclid RAT
This fork stands out primarily for its inclusion of new plugins, in addition to the default ones. While some plugins may seem trivial or geared towards “fun stuff”, others, like WormUsb.dll, serve distinctly malicious purposes. Table 1 lists a selection of NonEuclid RAT plugins that deviate from the standard plugin base seen in regular forks.
