Malware of the Day – AsyncRAT

What is Malware of the Day?

 

Lab Setup

“Malware”: AsyncRAT

MITRE Tactics: TA0011 Command and Control , T1571 Non-Standard Port

Traffic Type: TCP SSL

Connection Type: Reverse TCP

C2 Platform: AsyncRAT

Origin of Sample: Active Countermeasures Lab

Host Payload Delivery Method: EXE binary (C2 implant)

Target Host/Victim: 192.168.100.136 (Windows 10 Enterprise x64)

C2 Server: 172.208.51.75

Beacon Timing: 6.5s

Jitter: +/- 1.5s

 

Malware of the Day Mission

To identify and share examples of post-compromise network activity in order to better detect and respond to potential network threats. Specifically we are looking for command and control (C2) communication channels used by attackers to obtain intelligence, issue commands, and exfiltrate data through a compromised host or hosts.

 

Preface: The Threat Hunting Mindset

As threat hunters, we approach our work with the mindset of a detective, maintaining an open and unbiased perspective to ensure that all potential evidence is considered and interpreted objectively. Our investigation begins when we discover a piece of evidence that suggests something might be amiss. From this point, we employ a variety of supportive tools to either refute or strengthen our case.

The process of threat hunting involves layering evidence, gradually increasing the probability of a compromise as we gather different, independently verified pieces of information. Each new piece of evidence adds to the overall picture, allowing us to build a stronger case. Our ultimate goal is to construct a case that is sufficiently solid to inform the Incident Response team of a probable compromise.

Throughout the investigation, it is crucial to remember the golden rule of threat hunting: never cross the active-passive line. This means that we must use all the tools and techniques at our disposal in a manner that does not alert the intruder to the fact that they are being investigated. By maintaining a passive approach, we can gather the necessary evidence without compromising the investigation.

By adhering to this mindset and methodology, we can effectively investigate potential compromises, providing valuable insights and enabling our organization to respond to threats in an effective manner.

 

Background

In recent years, the cybersecurity landscape has witnessed a significant shift in the tactics employed by threat actors. As modern Endpoint Detection and Response (EDR) solutions become increasingly adept at targeting well-known commercial frameworks like Cobalt Strike, adversaries are adapting their strategies to maintain their effectiveness.

This trend has led to a notable decline in the use of large commercial products, with threat actors instead turning to simpler, open-source command and control (C2) frameworks. These frameworks offer several advantages: they are freely available, eliminating the need for cracking or licensing; their open-source nature and straightforward codebase allow for easy customization to suit specific needs and alter signatures or Indicators of Compromise (IoCs) to bypass detections effectively. Moreover, the abundance of these frameworks, typically hosted on platforms like GitHub, enables threat actors to treat them as disposable commodities—once a framework loses its effectiveness, it can be easily discarded and replaced by another from the pool of available options.

Today’s Malware of the Day investigation focuses on AsyncRAT, a fairly simple, open-source framework written in C# that has been implicated in numerous compromises in the last few months (for example). We hope that by showing how such a compromise might appear in AC-Hunter, along with other support IoC detections, we can help keep your organization safe against it.

 

Scenario

 

In today’s scenario, a threat actor (172.208.51.75) successfully compromised a Windows 10 x64 Enterprise workstation located on the internal 192.168.100.0/24 subnet (Image 1 above). Once the threat actor gained access to the target system (192.168.100.136), they installed an AsyncRAT implant (stub), which initiated a reverse TCP callback (SSL) over port 7707 to a cloud VM running the AsyncRAT server.

 

Network Traffic Analysis Using AC-Hunter

Dashboard

During routine monitoring with AC-Hunter we view something unusual on our dashboard (Image 2 below). On the left-hand side we can see our 4 internal hosts, and we immediately notice that the host appearing at the top (192.168.100.136) has an unusually high Threat Score of 137.33.

 

 

On the right-hand side of the dashboard we notice high scores for both Beacon Score (98.40%), and Beacon Web Score (97.20%). This should immediately pique our interest, and thus the most logical next step would be to investigate these further by clicking on the title, which will take us directly to that module page.

 

Beacon

Upon landing on the Beacons module, we are presented with the top score – an outbound connection to 20.54.24.69 (Image 3 below). However, after conducting some reputation checks, it appears that the domain belongs to a legitimate Microsoft Data Center server. Furthermore, our histogram (mapping connection frequency vs. time interval, highlighted in green) gives us no immediate cause for concern, as the connection timing is inconsistent when normalized on a per-hour basis. This is further confirmed in the connection-timing frequency graph (highlighted in orange), which does not indicate any clear and consistent beaconing behavior typically associated with C2 implants. Accordingly, we decide to move ahead at this point, knowing that we can always circle back and investigate further if needed.

 

 

The second-ranked score, an outbound connection to 172.208.51.75, presents us with more cause for concern (Image 4 below). The histogram (highlighted in green) displays a “flat top” indicating a very consistent hourly connection frequency that is typical of C2 communication.

Furthermore, the connection-timing frequency graph (highlighted in orange) exhibits a parabolic shape, which is indicative of a C2 beacon with jitter. We can observe the axis of symmetry situated around 6.5 seconds, with a spread of approximately 1.5 seconds (i.e., jitter) in either direction.

 

 

Switching over to the packet size frequency graph (Image 5 below) by clicking on view 2, we observe a remarkable consistency in packet sizes – nearly all of the 13,300 connections had the exact same packet size of 1,489 bytes. The bad news is that such remarkable consistency is commonly associated with C2 communication. However, the good news is that this “primary pulse”, also referred to as the C2 heartbeat, is most likely the “check-in” between the server and beacon, and not actual data exfiltration. This suggests that, if this indeed turns out to be a C2 compromise, very little, if any, data was exfiltrated.

 

 

Though the data so far presents a strong case for a potential compromise, we can conduct some simple follow-up investigations to both build our case and provide invaluable evidence to the Incident Response team if and when we determine to notify them. The table related to this connection in the Beacons module (Image 4 above, highlighted in red) can provide us with useful departure points.

First, we can see that the IP resolves to a Microsoft FQDN and ASN. This can be confirmed by clicking on the IP and using any one of the numerous external investigation resources conveniently presented to us. All of these checks indicate that the IP indeed belongs to Microsoft; however, it seems indicative of it being a cloud-based virtual machine (Azure). As we’ve discussed before, threat actors often prefer using cloud-based virtual instances since they have a strong reputation and can essentially be treated like disposable commodities.

Another aspect that stands out as unusual is the SSL communication over port 7707. We typically expect HTTPS communication to happen over port 443, and although using a non-standard port is not an immediate indication of wrongdoing, it is certainly worth investing a minute of our time for further investigation. Let’s perform some basic OSINT and see what we might learn.

 

OSINT

An initial Google search for “port 7707” does not yield any obvious results – we see no mention of malware, or indeed any discrete service using this port. However, by simply adding the word “malware” to our search, that is to search “port 7707 malware”, we see a few hits on the top results page mentioning this port being associated with malware known as AsyncRAT (Image 6 below).

 

 

As AsyncRAT is a free, open-source project hosted on Github and is not inherently malicious, we can download a copy of it and confirm the port numbers ourselves. After downloading and extracting the zip archive, we can immediately run the executable. Moments after doing so, we can see that, by default, AsyncRAT uses one of three ports: 6606, 7707, or 8808 (see Image 7 below).

 

 

After conducting further research using the search term “AsyncRAT malware”, we discover an excellent article by McAfee that details a specific “chain of infection” instance related to AsyncRAT. This article provides valuable Indicators of Compromise (IoCs) associated with AsyncRAT, including two files (a .txt and .jpg file) that were downloaded from another server over port 222 immediately prior to the establishment of the connection to the C2 server (see Image 8 below, highlighted in red). To close our investigation, let’s perform some deep packet inspection to see if we can match the specific indicator of compromise mentioned in the McAfee report.

 

 

Deep Packet Inspection

For deep packet inspection, we’ll use Wireshark. In accordance with David J Bianco’s Pyramid of Pain, it’s essential to keep in mind that some IoCs are much easier for attackers to change than others. For example, when examining the IoCs presented in the McAfee report, we should expect a very low likelihood that specific details such as IPs, ports, and file names will exactly match those mentioned.

Therefore, a better strategy for us would be to search for a similar pattern in Wireshark, rather than an exact, detailed match. Since we know that a .txt file was downloaded, followed by a .jpg file, we can investigate whether such events occurred in close succession. It’s important to remember that although we uncovered the IP associated with a potential C2 server, this might not be the same IP that was used to download the precursor files to establish the connection. Consequently, we cannot rely on that information for this analysis.

To determine whether these files were downloaded, we can use Wireshark’s built-in feature to view all downloaded files. Once Wireshark is open, click on File -> Export Objects > HTTP. This will display all files downloaded over HTTP in the given dataset. In this case, we can indeed observe a .txt file followed by a .jpg file in sequential order (see Image 9 below).

 

 

Further, although the actual file names and IP addresses differ from those presented in the McAfee report, we can see that the unusual port 222 was also used in this case, further reinforcing the likelihood that we are indeed dealing with an AsyncRAT compromise.

Please note that this “quick and dirty” method of viewing downloaded files in the dataset can become quite cumbersome when dealing with a large number of files. In such cases, we suggest using a filter instead. For our specific scenario, we would simply search for all GET requests involving a txt or jpg file using the following filter: http.request.method == “GET” && (http.request.uri contains “.txt” || http.request.uri contains “.jpg”).

 

Conclusion

As this point in our investigation, we feel confident about the case we’ve built:

1. We found a connection with a high Threat Score in AC-Hunter.
2. The beacon associated with this connection has a histogram, connection-timing frequency graph, and packet size frequency graph typical of what we associate with a C2 beacon with jitter.
3. The outbound port used for the connection (7707) is associated with AsyncRAT malware.
4. Precursor files found in other AsyncRAT chain of infection reports were matched in Wireshark.

 

Although we could conceivably continue our investigation and perhaps look into the process responsible for mediating the connection, at this point, our case is solid enough to present to the Incident Response team. It is crucial to remember that the longer we wait, the more potential damage the threat actor could inflict. There is always a fine line between building a sufficiently solid case to avoid potentially leading to a false alert and recognizing that the longer we wait, the higher the potential costs to our organization.

Below are capture files of this network traffic. Would you be able to easily identify this C2 channel within your network?

 

Capture Files

PCAPs

Because… PCAPs, or it didn’t happen. 😊

The following PCAP files are packet captures taken from the same lab environment over a 1-hour time frame and a 24-hour time frame. The files were generated using Wireshark from the target host and include normal Windows OS traffic and normal network broadcast traffic. They have not been edited. The PCAPs are safe, standard PCAP files and do not include any actual malware.

AsyncRAT 1 Hour Capture
asyncrat_1hr.pcapng
Size: 4.62 MB
SHA256 Checksum: D844FC691A40C7EEDBCC4775E4760E12A6A25A1C93602ACACFC0B9A84C55068D

AsyncRAT 24 Hour Capture
asyncrat_24hr.pcapng
Size: 122.52 MB
SHA256 Checksum: 179908CDF5848725084D0AE696BC7196953CA8E12E0837E764067F88420B5E08

 

Zeek Logs

If you are an AC-Hunter user, we are providing the 24-hour Zeek logs for you to import directly into AC-Hunter. The following Zeek Logs have been taken from the same lab environment over a 24-hour time frame and include normal Windows OS traffic and normal network broadcast traffic. They have not been edited. The Zeek logs are safe, standard log files and do not include any actual malware.

The following is an example of how to import Zeek logs into AC-Hunter:

ssh into your AC-Hunter server and upload all the Zeek logs contained in the zip file below (all files that have the ‘.log’ extension) into a temporary directory on the server. In this example, we are uploading the Zeek logs into /tmp/asyncrat-zeek-logs/

Then run the following command:

rita import /tmp/asyncrat-zeek-logs/*.log asyncrat

You will now have a new database in the AC-Hunter UI/web interface titled “asyncrat” you can select and view.

24 Hour Zeek Logs
asyncrat_zeek_logs.zip
Size: 1.89 MB
SHA256 Checksum: 40DD6DFDCC31B81A66B7D54402F039D2E16092354C14AA350DFDFAACEACFFDCC

 

Discussion

Want to talk about this or anything else concerning threat hunting? Want to share how good (or not so good) other detection tools were able to detect this sample?

You are welcome to join our Discord server titled “Threat Hunter Community” to discuss topics surrounding threat hunting. We invite you to join our server here.

 

Additional Resources

Unmasking AsyncRAT New Infection Chain

Analyzing The Prolific Open-Source AsyncRAT Malware

What is the Pyramid of Pain?

 

A huge thanks to Keith Chew and Chris Brenton for allowing me the opportunity to contribute to this awesome initiative, as well as their guidance, helpful feedback, and for being a couple of stand-up gents.

Live long and prosper!