I recently reviewed HTTP Asynchronous Reverse Shell (HARS) for The C2 Matrix, which should be posted soon! They also have a Google Docs spreadsheet here: C2Matrix - Google Sheets. I’ve been following them for awhile and have tried to map as may of the frameworks as possible from a defensive perspective. This blog post will therefore cover just that, how to use RSA NetWitness to detect HARS.
The Attack
After editing the configuration files, we can compile the executable to run on the victim endpoint. After executing the binary we get the default error message, which is configurable, but we left it with default settings:
The error message is a ruse and the connection is still made back to the C2 server where we see the successful connection from our victim endpoint:
It drops us by default into a prompt where we can begin to execute our commands, such as whoami, quser, etc:
Detection Using NetWitness Network
By default HARS uses SSL, so to see the underlying HTTP traffic, we used a MITM proxy to intercept the communication; it is highly advisable to introduce SSL interception into your own envrionment. Within this post, we will also cover the anomalies with the communication over SSL.
HTTP
An interesting meta value generated for the HARS traffic is, http invalid cookie - this meta value looks for HTTP cookies that do not follow RFC 6265:
Drilling into the Events view for these sessions before reconstructing them, we can observe that there is a beacon type pattern to the connections with some jitter, and also a low variance in the payload for each request - this indicates that this is a more mechanical type check-in behaviour:
Reconstructing the events and looking at the cookie for the requests, we can see what looks like Base64 data:
Using the built-in Base64 decoding, we can see that this decodes to HELLO. While this is not indicative of malicious activity, this is still a malformed cookie and a rather strange value:
From here, we can continue to go through the traffic and decode the values supplied within the cookie header. The next few cookies contain the text QVNL, which returns ASK when Base64 decoded:
Eventually we come across a cookie with a Base64 encoded version of what looks like the ouput from a whoami command:
As well as one that contains the output from a quser command. Both these look rather suspicious and this is information that normally shouldn't be sent to a remote host, especially in this manner as a cookie value:
Looking through the request prior to the one that returns the output of quser, and sifting though the payload, there is a Base64 encoded quser command within it:
This C2 framework disguises its commands within legitimate looking pages in an attempt to evade detection by analysts, but is easily detected with NetWitness using a single meta value, http invalid cookie.
NOTE: It is important to remember that many applications abuse the HTTP protocol and do not follow RFC's, it is therefore possible for legitimate traffic to have inavlid cookies, it is down to the defender to determine whether the activity is malicious or not, but NetWitness points you to these anomalies and makes it easier to focus on traffic of interest.
This C2 is highly malleable and therefore the following application rule would only pick up on its default configuration, however, attackers tend to be lazy and leave many of the default settings for these tools. This would allow us to easily create an application rule to detect this behaviour:
cookie = 'QVNL','SEVMTE8='
In order for the application rule to work, you would need to register the cookie HTTP header. This involves using the customHeaders() function within the HTTP_lua_options file as described on the community:
One of our previous posts also covered registering the cookie HTTP header into a meta key and can be found on the community:
SSL
As previously stated, HARS uses SSL to communicate by default. When HARS initially connects back to the C2 from the victim endpoint, it attempts to blend in with typical traffic to www[.]bing[.]com. The below screenshot shows the malicious traffic (on the left), and the legitimate traffic to Bing (on the right). Playing spot the difference, we can see a few anomalies as highlighted below:
This allows us to create logic to detect possible HARS usage with the following application rule:
service = 443 && alias.host='www.bing.com' && ssl.ca='microsoft corporation' && ssl.subject='microsoft corporation'
And we can also create an application rule to look for anomalous Bing certificates, this would, however, be lower fidelity in order to detect a broader range of suspicious cases to aid in threat hunting:
service = 443 && alias.host = 'www.bing.com' && not(alias.host='www.bing.com' && ssl.ca='microsoft corporation','baltimore' && ssl.subject='www.bing.com')
Detection Using NetWitness Endpoint
HARS uses PowerShell to execute the commands on the victim endpoint, but does not use any form of obfuscation. Therefore in NetWitness Endpoint, we can see multiple hits under the Behaviours of Compromise meta key for the reconaissance commands executed, quser, whoami, and tasklist:
Drilling into those meta values, we can see an executable named, hars.exe, running out of a suspect directory and executing reconaissance type commands:
Pivoting on the filename, hars.exe, (filename.src = 'hars.exe'), which really could be any other name, but would still be launching your commands, we can see all the events from this suspect executable, such as the commands it executed under the Source Parameter meta key:
After every command executed, HARS adds the following, echo flag_end. We can use this to our advantage to create an application rule to detect its behaviour:
category = 'console event' && param.src ends 'echo flag_end'
Another neat indicator comes under the Context meta key, here we can see four interesting meta values associated with, hars.exe - console.remote, network.ipv4, network.nonroutable, and network.outgoing - these meta values tell us that this executable is making an outbound network connection and running console commands:
Drilling into the Events view for the network meta values, we can see where the executable is connecting to:
And drilling into the console.remote meta value, we can see the commands that were executed:
So from a defenders perspective, it could be a good idea to use the filter, context = 'console.remote' - and look for suspicious executables:
Conclusion
Not all C2 frameworks use advanced methods of obfuscation or encryption, some rely on confusing analysts by trying to blend in with normal traffic by mimicking legitimate web sites. It is important as a defender to spot these anomalies and fully analyse the traffic, even if it at first glance appears to be normal, and remember, the attacker would probably think none of this really matters as the attack is over SSL and this data would not be visible to analysts, which is where having SSL interception is a great advantage for analysts, it really catches attackers out.
1 Comment
