Async RAT - Analysis

Overview

AsyncRAT is a remote access trojan (RAT) built to remotely monitor and control other computers through a secure, encrypted connection. The name “AsyncRAT” comes from its core functionality—’async’ means it performs its operations asynchronously, which means it is capable of executing several tasks simultaneously. AsyncRAT has been observed as being bought, sold, and deployed for years, going through many versions and renditions. Functionality associated with AsyncRAT includes keylogging, remote desktop control, and the ability to enumerate a victim machine and exfiltraing stolen data - among other fucntionality.

In this post, we’ll look at the newest version or AsyncRAT, and go over what to expect in terms of output, that being the tangible things we get from analysing trojans - such as the configuration.

So, with that introduction out of the way, let’s dissect this rat! (The fun kind, not the kind they make you do in science class)

Initialisation

In January 2019 AsyncRAT was released as an open source remote administration tool project on GitHub. Since then, threat actors and adversaries have used several interesting script loaders and spear phishing attachments to deliver AsyncRAT to targeted hosts or networks in different campaigns over the years. Though, this blog will focus specifically on AsyncRAT rather than the delivery mechanisms used throughout the many campaigns that use this trojan.

AsyncRAT begins it’s execution process by sleeping for one second before going through the rest of its initialisation, the sleep time is set by the attacker when they compile their sample in the builder (more on that later). In addition, AsyncRAT initialises itself using its settings, and if this errors in any way, AsyncRAT terminates it’s execution.

The InitializeSettings method shows that the malware’s configuration is Base64 decoded and AES encrypted. This configuration is decoded and decrypted before use, as shown in the picture below:

The configurations used by the malware, such as the C2 host and ports are indeed encrypted and encoded.

One of the main goals when analysing trojans is to identify and extract this configuration information, as it’s quite telling as to how the malware is built. This will become more apparent later when I dicuss the server side operations, the builder, and how the config structure for AsyncRAT is exactly the same sample to sample, even if the values are different (as many of them are set by the attacker).

One other things to mention is the flag = Settings.VerifyHash(); check in the code block above. AsyncRAT needs to verify the integrity of it’s configurations and return a true result. If false, AsyncRAT will terminate. The malware also checks if any of the configurations have been changed post compilation, by using Serversignature and ServerCertificate with the VerifyHash function - returning the result. This works like a watermark for wants of a better example. Without this check, we could reverse engineer the malware allot faster since I could manually put in whatever values I wanted by editing the methods, and I’d be able to see the malware’s functionality that way.

Decryption Routine

Insofar as the encrpytion and decryption routine goes, it is reasonbly straightforward and doesn’t differ too much from other RATs. The decryption routine for the latest version of ASyncRAT is shown below:

I am not 100% on this, but I analysed a few samples for this blog and found the encryption key to be exactly the same, and nothing in the builder suggests you can change it, some food for thought around signituring. The AES Key can be found in the Client.Settings. An example of the key is below, in both Base64 (as it originally is in the binary), and UTF-8.

Key (Base64) = ejFjc0p0QWtudENHVTdsakhjTExYbm1KM1RqbTVUMlA=
Key (UTF8) = z1csJtAkntCGU7ljHcLLXnmJ3Tjm5T2P

In relation to the decryption routine in which the key is used, This is how it works:

• The method Decrypt takes an encrypted byte array as input.
• If the input is null, it throws an exception.
• The AesCryptoServiceProvider is set with specific variables for decryption.
• An HMAC hash is computed and compared with the one from the input to validate the data.
• Initialization Vector (IV) for the AES operation is read from the input. The IV is generated from the first 16 bytes of the encrypted data
• The encrypted byte array is decrypted using CryptoStream.
• The decrypted data is stored in byte arrays, completing with array6.
• The function finally returns array6 which contains the decrypted data.

In the Detection and Mitigation section of this blog, I have a python script for doing the full decryption and decoding, as long as you identify and add the values to the script.

Anti-analysis and defence evasion

There are a few anti-analysis techniques employed by ASyncRAT, which I will discuss presently. Though, anti-analysis is an optional feature provided to users of the ASyncRAT builder that they’ll need to toggle to get in their malware.

ASyncRAT does a number of anti-analysis checks, such as checking to see if it’s inside a debugger or sandbox, and checking the disk size (most secure labs tend to be quite small, especially cloud-based sandboxes). If there is a debugger or sandbox detected, or the disk is too small, the malware will terminate execution.

AsyncRAT also has a check to ensure that it doesn’t have more than one version of itself running at the same time, it does this by creating a unique Mutex key, which is stored in the Client.Settings, inside the binary. Presumably this is for operational security (OPSEC) reasons. As with the other checks mentioned, all running versions will be temrinated if identified.

Persistence

ASyncRAT has a number of methods for persisting on the victim machine. As with the Anti-Analysis, the attacker can choose whether to set this in the builder. Here I will go through the method that does all of the persistence for ASyncRAT.

Firstly, a file path is setup so that RAT knows where to instal itself, in this case it’s %APPDATA%, as shown with the InstallFolder variable in Client.Settings.

FileInfo fileInfo = new FileInfo(Path.Combine(Environment.ExpandEnvironmentVariables(Settings.InstallFolder), Settings.InstallFile));

The path of the currently running malicious process is, and if the malware is not running at that install location, the malware will initiate the copy process.

string fileName = Process.GetCurrentProcess().MainModule.FileName;
if (fileName != fileInfo.FullName)

This is where things branch off a little bit. If the malware is running in the context of an Administrator, a scheduled task is created as the method of persistence.

schtasks /create /f /sc onlogon /rl highest /tn "AsyncRAT.exe" /tr "C:\Path\To\AsyncRAT.exe"

Everytime the machine boots and the Administrator account is logged on, the malware will run.

If not running as the Administrator level context, a registry key is created instead, as below.

else
{
    using (RegistryKey registryKey = Registry.CurrentUser.OpenSubKey(Strings.StrReverse("\\nuR\\noisreVtnerruC\\swodniW\\tfosorciM\\erawtfoS"), RegistryKeyPermissionCheck.ReadWriteSubTree))
    {
        registryKey.SetValue(Path.GetFileNameWithoutExtension(fileInfo.Name), "\"" + fileInfo.FullName + "\"");
    }
}

You’ll also notice that string reversing is used here as yet another layer of obfuscation, this is so if you ran strings against the malware, the registry key path wouldn’t flag immediately inside a tool like PEStudio.

Command and Control (C2)

ASyncRAT creates an infinite loop to connect to the C2 (defined through the builder), alongside routinely checking in with the C2 server. Between these checks, the ASyncRAT will sleep

Following this is the Reconnect() method.

This method is forcefully disconnecting the client from a remote server by disposing of its SSL stream, TCP socket, and any timers related to communication (likely a keep-alive or ping mechanism as mentioned earlier).

It then marks the client as disconnected but does not attempt to reconnect. It seems to be used to clean up a C2 connection - especially in the event of launching a new sample.

Server Side Ops

This is the section where I breifly explain the builder, and what options the attacker has. When the victim runs the malware created from the builder, it functions in a very similar way to C2 frameworks like Havoc, Sliver, or Cobalt Strike. Once the malware makes contact with the server, the attacker has some of the following options:

• RDP into the victim machine
• Activate the Keylogger function inside the malware
• Activate the webcam configured on the victim machine
• View the process manager, this is helpful for looking for EDR’s or interesting process to inject

Detection

Below is a Yara rule I’ve created to detect AsyncRAT samples from the version 3 builder. This rule is also available in my GitHb repository.

rule ASync_RAT {
    meta:
        author      = "Echo01409 (Ben Hopkins)"
        description = "detects AsyncRAT using host based indicators of compromise"
        date = "08/03/2025"
        hash = "DA8814D41003A320BB8BC59E7E899CC80553D91BB87F30EA4E32BE8FDAA2E020"
    strings:

        $async_header_1 = { 04 00 00 00 ?? ?? ?? ?? 00 00 00 00 }
        $async_header_2 = { 02 00 00 00 ?? ?? ?? ?? 00 00 00 00 }

        $str_anti_1 = "VIRTUAL" wide
        $str_anti_2 = "vmware" wide
        $str_anti_3 = "VirtualBox" wide
        $str_anti_4 = "SbieDll.dll" wide

        $str_key = "ejFjc0p0QWtudENHVTdsakhjTExYbm1KM1RqbTVUMlA="

        $str_reg_key_run    = "\\nuR\\noisreVtnerruC\\swodniW\\tfosorciM\\erawtfoS" wide
    
        $str_schtask = "schtasks /create /f /sc onlogon /rl highest /tn"

        $str_config_1 = "Ports" wide
        $str_config_2 = "Hosts" wide
        $str_config_3 = "Version" wide
        $str_config_4 = "Install" wide
        $str_config_5 = "MTX" wide
        $str_config_6 = "Anti" wide
        $str_config_7 = "Pastebin" wide
        $str_config_8 = "BDOS" wide
        $str_config_9 = "Group" wide

    condition:
        all of ($str_anti_*)  and 
        4 of ($str_config_*) and (
            ($str_schtask) or
            ($str_reg_key_run) or 
            ($async_header_1) or 
            ($async_header_2) or
            ($str_key)
        )
}

In addition, I have provided a config decoder script on my Github. All you need do is identify the configuration information from the AsyncRAT sample and paste the values into the script, then run it, and it’ll decode, decrypt, and print the final values. I do have a secondary script as a work in progress, that reaches into the binary and pulls the values for you. Later down the line, as I get more experience with other RATS, the goal is to provide an all in one script that can grab the configuration from almost any RAT and decode/decrypt the values and print them out for fast and efficient triaging.

Conclusion

To conclude, AsyncRAT is still used in the wild by e-crime threat actors and opportunistic actors alike, due to it’s simple setup spanning multiple capabilities. With it’s C2 capability aswell, threat actors can send commands to the client, where it’ll execute those commands in the context of the user logged into the machine. The ASyncRAT client is pretty simple in it’s design, but it doesn’t really need to be complicated as it seems to get the job done, even in 2024/2025.