Carrying on with the theme of Remote Access Tools (RATs), in this blog post will be covering Void-RAT. This tool is still in development and currently at alpha release so doesn't come with as many features as other RATs we've looked at, with that being said it still works quite nicely for controlling a remote endpoint. As always, check out the C2 Matrix for more details on its functionality.
The Attack
On our victim endpoint, we drop our compiled binary, client.exe, into the C:\PerfLogs\ directory and execute it:
After execution, it attempts to connect back to the C2 server, if successful it creates a slightly modified version of itself and stores it here: C:\Windows\Firewall\Firewall.exe - it then executes this binary which is the one that communicates back to the C2 server along with some information about the endpoint it is running on:
There are a number of options available to control the endpoint, but the most useful is the Remote CMD option. This allows us to execute commands remotely on the victim:
The Detection Using RSA Network
Void-RATs communication is in cleartext but uses a custom TCP protocol which is not directly understood by NetWitness. This means that the traffic gets tagged as OTHER, even though NetWitness does not understand the protocol, it will still analyse it. From the below screenshot, we can see that NetWitness has detected windows cli commands over some sessions using a suspect port:
Drilling into these sessions and reconstructing them, we can see the structure of the protocol used by Void-RAT, and the information that was sent to and from the victim:
Some more of the payload can be seen below. These commands are what NetWitness detected:
Void-RAT also reports back the public IP of the victim upon its initial check-in. It does this by making an HTTPS request to wtfismyip[.]com - this could also be used as a potential starting point for a hunt to find potentially compromised endpoints:
service = 443 && sld = 'wtfismyip'
These types of tools also require interaction from a remote operator, so at some point the attacker will perform actions that may supply additional indicators leading you to their presence. Here under the Indicators of Compromise meta key, we can see the meta value, hex encoded executable:
Drilling into this meta value and opening the events view to reconstruct the session, we can see that a hex encoded executable is being sent across the wire which uses the same proprietary protocol as Void-RAT, so even if we had not detected the RAT initially, we detected suspect behaviour, which led us to the RAT:
The Detection Using NetWitness Endpoint
Upon execution of Void-RAT, it sets up persistence for itself. It achieves this by creating a slightly modified version of itself here: C:\Windows\Firewall\Firewall.exe and modifies the \Current\Version\Run key to execute it upon boot. This behaviour was detected by NetWitness Endpoint and is shown as the two meta values in the following screenshot:
Drilling into these two meta values we can see these two events in more detail:
Changing our pivot in the Navigate view to focus on the new binary, filename.src = 'Firewall.exe', we can see that it is executing suspect commands (as shown under the Source Parameter meta key) and making network connections (as shown under the Context meta key):
Drilling into the network connections made by Firewall.exe, we can see the lookup performed to get the public IP of the victim using wtfismyip[.]com:
A simple application rule that could be created to look for this behaviour is shown below:
domain.dst = 'wtfismyip.com'
We can also see the connection back to the C2, which would have given us a nice indicator to search and see if other endpoints are infected:
Similarly, as stated in the network detection, the tool is operated remotely and will at some point have to perform actions to achieve its end goal. The attacker transferred a hex encoded binary across the wire, but this cannot be executed by the system, so they used certutil (a LOLBin) to hex decode the file into an executable, which was detected under the Behaviours of Compromise meta key as shown below:
Conclusion
While many RATs seem to use custom TCP protocols to communicate, their behaviour is easily identifiable
with NetWitness. When hunting in network traffic make sure to spend some time on service = 0 - and
remember that a RAT has to do something in order to achieve its end goal, and those actions will be picked
up by NetWitness, so make sure to look for executables performing suspicious actions and
making network connections that you typically wouldn't expect for that endpoint. While this RAT does use a custom protocol, in a lot of cases, attackers exploit security controls in organizations that allow direct internet access on well-known common ports, like port 80/HTTP, 443/HTTPS, 22/SSH, etc. In these cases, NetWitness will also flag the unknown service on these ports. For more mature organizations, using NGFWs that do a certain level of protocol inspection before allowing traffic for well known services to flow through them, RATs like this would have some difficulty surviving, and therefore attackers are more prone to use tools that rely on standard protocols, which we have covered on some of the other posts.
