We are back again with another C2 framework called, Chaos: https://github.com/tiagorlampert/CHAOS. CHAOS is a PoC written in Go and comes with a healthy number of features for controlling the remote endpoints. It supports agents for Windows, Mac, and Linux, however, the feature availability does differ depending on the platform the agent is deployed on. This C2 only allows control of one agent, and all communication is over TCP sockets. More information surrounding this C2 can be found over at the C2 Matrix: C2Matrix - Google Sheets.
This C2 reminds a lot of one we previously covered called, HARS: https://community.rsa.com/community/products/netwitness/blog/2020/04/01/using-rsa-netwitness-to-detect-http-asynchronous-reverse-shell-hars - so check that post out as well if you haven't already.
The Attack
As always, we're keeping this super simple to place more of a focal point on the C2 traffic itself, rather than the delivery mechanism. So to deploy the agent, we simply copy the binary to the victim endpoint and execute it from the C:\PerfLogs\ directory:
After execution, we see our successful connection back to Chaos as is evident from the [+] Connected! message displayed:
Now we have our connection, we can use one of the available built-in features to set up persistence for Chaos to ensure it starts up again should the system reboot:
From here, we can start to execute commands to get information regarding the endpoint we are controlling:
The Detection Using NetWitness Network
Chaos has no direct support for HTTP and all communication between the C2 and the agent is over TCP sockets. As there is no structure to the traffic being generated, it is not possible to classify it under a specific service, so NetWitness tags this traffic as service = 0 - otherwise known as OTHER. The service OTHER is often overlooked as an area for hunting but should still be analysed by defenders to look for malicious traffic using proprietary protocols, or TCP sockets like Chaos. From the below, we can see that there are some meta values of interest for the Chaos C2 traffic that would stand out during the hunting process:
NOTE: The unknown service over http port meta value is interesting here, as attackers often use typical ports for web browsing to get around firewall policies that block everything but web access for endpoints.
Drilling into the possible base64 windows shell meta value, we can see the structure of the Chaos C2 traffic. The commands are sent as typed to the agent, but the output from the command is Base64 encoded and sent back to the C2, hence why NetWitness generated the possible base64 windows shell meta value:
This gives us the ability to easily observe the commands being executed, and to Base64 decode the output of the commands directly within the UI:
For this type of C2 there is no need to create additional detections for NetWitness Network, the detection is already there and just requires that defenders triage traffic of type OTHER where interesting meta values are generated, such as the ones shown here.
The Detection Using NetWitness Endpoint
As always, when these C2 frameworks are deployed, they have to execute and do things in order to achieve their end goal, and with NetWitness Endpoint it is easy to detect these actions. Below are the meta values generated from the small number of commands that were executed through the C2:
Opening the Events view for the meta values of interest, we can get a better view of all the commands being executed:
The Detection Using NetWitness Logs
In order to better identify suspicious activities taking place on the endpoint, we have chosen to install Sysmon, and to include the detections available through its logging. More information surrounding Sysmon can be found at the following link: https://docs.microsoft.com/en-us/sysinternals/downloads/sysmon. The collection of these logs is performed via the NetWitness Endpoint agent itself and more detail on how that was set up can be found here: https://community.rsa.com/docs/DOC-101743#createWinLog.
There are multiple starting points for using Sysmon to find malicious activities, but for now we are going to start with the following logic which would detect the usage of whoami being executed on a system, this is normaqlly evidence of attacker activity after successful exploitation or privilege escalation and is not overly common for most users to execute regularly:
(event.source = 'microsoft-windows-sysmon') && (service.name ends'whoami.exe') && (reference.id = '1')
NOTE: The reference.id ='1' shown in the above query is for process creations.
Upon executing this query in NetWitness, we can see we get hits for the whoami command being executed from the C:\PerfLogs\ directory:
This is a suspicious directory for processes to be created from, so we can take a look at all processes being created out of this directory by slightly modifying our query to look for all process execution out of the C:\PerfLogs\ directory:
(event.source = 'microsoft-windows-sysmon') && (directory = 'c:\\perflogs\\') && (reference.id = '1')
Here we can see a suspect executable running from the C:\PerfLogs\ directory named chaos.exe, and we can also see that there is a number of other suspicious commands being executed from this directory, as well:
We could also create an application rule that identifies the persistence that was created by looking for edits being made to the \CurrentVersion\Run key using the following logic:
(event.source = 'microsoft-windows-sysmon') && (reference.id = '1') && (param contains 'reg add hkcu\\software\\microsoft\\windows\\currentversion\\run')
NOTE: While we covered Sysmon as a free alternative to EDR, our recommendation would still be to use one, as Sysmon may require a considerable amount of configuration and tweaking, and will not provide as many capabilties or visibility as an EDR solution would. We covered it here just to offer an alternative for those that don’t use EDR.
Conclusion
Chaos C2 is an easy-to-use framework that gives the attacker great control over the victim endpoint, it does not provide much in terms of obfuscation and does not attempt to blend in with normal traffic, so this should make this an easy detection for defenders whether you have NetWitness Network, Endpoint or Logs. Just remember to not shy away from the traffic type OTHER when hunting through those packets!
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.