In today’s age of nation state hackers and advanced cyberwarfare, AsyncRat seems like a clown at a funeral. It is developed in the open on Github because it is marketed as an open-source “Remote Administration Tool”.
Not unlike the ps2exe program that was used prolifically by cyber criminals to convert powershell malware scripts to EXE. This time it feels different as when ps2exe had it’s programs marked as malware by popular anti-malware vendors, the community went up in arms about it’s legitimate use but it seems AsyncRat is not bothered by the potential of being marked as malware, almost as if that was the point the whole time 🤔
Table of contents
Open Table of contents
The Code
AsyncRat is built from two angles, the server and the client, just like other RATs but AsyncRat has a few implementation details.
As always it has the client/server but uses MessagePack to facilitate communication within the two and has a Plugin system to activate certain capabilities as part of the process.
It has a somewhat standard server architecture but there are additional functionalities like sending Plugin DLLs.
The client though is where all the ✨MAGIC✨ happens. There are a few interesting things to look at within its source code which will be broken down.
1. Persistence
The AsyncRat client achieves persistence by one of two methods.
-
Creating a scheduled task on logon if the current user is an Admin.
-
Adding the program to the current user’s Software\Microsoft\Windows\CurrentVersion\Run\ registry key.
The keen eyed readers among you would have noticed that the Registry Key path is reversed, I certainly did not notice this until it was pointed out to me in a blog post I was linked to during the research of this specific topic.
The registry key is reversed to avoid static analysis as most AV software are wary of program that try to do anything with the Run key.
2. AV Detection
The Client detects Antivirus programs by enumerating all values in the machine’s SecurityCenter2 registry key.
The client itself does not do anything in particular with this data, instead it sends it to the server where it is listed as part of the identifiers for that specific infected machine.
I personally think this was also done to help the attacker pick and choose what plugins to deploy on the infected machine as some plugins might be too invasive and would get flagged by an AV software.
3. Hardware Identification
The client generates a unique ID that is sent along with the other identifiable information to the server as shown above, but the HWID parameter is itself a unique identifier for the machine. I am not too sure as to why they need both identifiable information and a unique ID but apparently they do, so let’s look at that.
The HardwareID is generated by hashing a concatenation of the Machine’s processor count, the compromised user’s username, the machine’s name, the OS version and the total size of the root disk using the MD5 algorithm.
4. Plugins
AsyncRAT contains multiple plugins that run multiple payloads, the way it is handled is by sending the whole plugin DLL as part of a MessagePack message. There are two ways the client handles plugins.
-
Unsaved Plugin
A plugin is sent from the server with the intention of being executed being in-memory while the client is online. The client checks if the plugin was to be executed is already installed on the system, if it is not, the DLL is requested from the server.
When the server sends back the DLL, the client saves the plugin then executes it in-memory by decoding the assembly.
-
Saved Plugin
If the plugin is saved, the DLL is executed without an intermediate step
The Report
This analysis was done as part of a larger report I worked on with my colleagues at Cyberplural and contains more work from me and other talented personnel at the company.