Delving back into the C2 Matrix to look for some more inspiration for blog posts, we noticed there are a number of Remote Administration Tools (RATs) listed. So we decided to start taking a look at these RATs and see how we can detect their usage in NetWitness. This post will cover QuasarRAT which is an open-source, remote access tool that is developed in C#. It has a large variety of features for controlling the victim endpoint and has been used by a number of APT groups.
The Attack
QuasarRAT can be compiled in two modes, debug and release - for this blog post we compiled QuasarRAT in debug mode as it is the quickest and easiest way to get up and running. Once our agent had been compiled, we dropped it onto our victim endpoint in the C:\PerfLogs\ directory and executed:
Shortly after execution we get a successful connection back to QuasarRAT from our victim endpoint:
QuasarRAT has a large feature set, here we are using the Remote Shell feature to execute some commands:
There is also a file explorer that allows us to easily navigate the file system, as well as upload and download files:
It even has a Remote Desktop feature to view and control the endpoint:
The Detection Using NetWitness Network
QuasarRAT does not have an option for insecure communication and all traffic will be over SSL, it also uses a custom TCP protocol for its communication so if intercepted the protocol would be tagged as OTHER and you would have to look for indicators similar to those outlined in our CHAOS C2 post: https://community.rsa.com/community/products/netwitness/blog/2020/05/14/using-rsa-netwitness-to-detect-chaos-c2.
Under the Service Analysis meta key, we get some interesting meta values generated regarding the certificate. QuasarRAT upon compilation generates a self-signed cert, this means the certificates age is low, as is identified by the certificate issued within last week meta value, and the self-signed meta value is, ssl certificate self-signed - you'll also notice that there is an ssl over non-standard port meta value, this is generated as the default port for QuasarRAT is 4782 (this is easily changed however and would more commonly be over 443 to bypass firewall restrictions). With that being said, these are some great pivot points to start a hunt in SSL traffic to look for suspect SSL communication:
Looking into the parsed data from the certificate, we can see that the SSL CA and SSL Subject identify this as a Quasar Server, which are the default values given to the certificate created by QuasarRAT:
ssl.ca = 'quasar server ca' || ssl.subject = 'quasar server ca'
Another interesting meta value is located under the Versions meta key, where we can see that QuasarRAT uses an outdated version of TLS, tls 1.0 - this could be another starting point to look for this tool, or other applications using outdated protocols for that matter:
The SSL JA3 hash for this comes back as, fc54e0d16d9764783542f0146a98b300, which according to JA3 OSINT maps to, PowerShell 5.1;Invoke-WebRequest. While there is often overlap with JA3 hashes, it would still be a good place to start a hunt from:
On initial execution the RAT will also make an HTTP call to http://ip-api.com to obtain the public IP address of the endpoint. It would be worth hunting through the network traffic for requests to this domain and others that provide the same function:
The Detection Using NetWitness Endpoint
When we were setting up QuasarRAT, we modified the persistence settings to true, the following two meta values were generated based off of this. This is because QuasarRAT will copy itself to the \AppData\Roaming\ directory and use the \CurrentVersion\Run key to start it upon boot:
If you are using the new ATT&CK meta keys, we also see this persistence mechanism described there as well with the following meta values:
As stated in the network detection section, the RAT will make an HTTP connection to http://ip-api.com to get the public IP of the victim, we can also see that in the network endpoint data as shown below:
We can also drill into the meta value, console.remote, which is located under the Context meta key. This will show us commands executed by cmd.exe or powershell.exe as a result of inter-process communication through anonymous pipes, i.e. a reverse shell - here we can see client.exe executing suspect commands:
It is important to triage through all the commands executed in order to identify and follow the attackers intentions. An interesting command seen above is in relation to the esentutl.exe; this binary provides database utilities for the Extensible Storage Engine but can also be used to copy locked files for example. Drilling into this command, we can see it was used to copy the SAM hive (which is a locked file) to the C:\PerfLogs\ directory - it does this by using the volume shadow copy service (as noted by the /vss switch in the command below) to make a backup of the locked file which we are then able to copy:
This is an interesting LOLBin (Living off the Land Binary) as it would allow an attacker to copy any locked file from the system, this is activity that should be monitored and the following application rule logic would detect the usage of this command to copy files using the volume shadow copy service:
(filename.src = 'esentutl.exe' || filename.dst = 'esentutl.exe') && (param.src contains '/vss' || param.dst contains '/vss')
NOTE: Not all usage of esentutl.exe will necessarily be malicious, this could be a legitimate technique used by backup software for example. It is down to the defender to determine the legitimacy of the tool executing the command.
Conclusion
QuasarRAT has been around for some time and has been used in a number of targeted attacks against organizations and it is easy to see why. Remote access tools such as this pose a real risk to organizations and monitoring for their activity is paramount to ensuring the security of your network. It is also important as a defender that when these tools are found, that all command are triaged to gain a better understanding of the attackers intentions and end goal.
