Skip navigation
All Places > Products > RSA NetWitness Platform > Blog > 2020 > June
2020

Summary:

Several changes have been made to the Threat Detection Content in Live. For added detection you need to deploy/download and subscribe to the content via Live, for retired content you'll need to manually remove those.

Detailed configuration procedures for getting RSA NetWitness Platform setup - Content Quick Start Guide 

 

Additions:

RSA NetWitness Lua Parsers:

  • WireGuard – New Lua parser has been introduced to identify WireGuard VPN sessions. WireGuard open-source is a security-focused virtual private network (VPN) known for its simplicity and ease of use.

Read more about Identifying WireGuard (VPN) Traffic Using RSA NetWitness Network 

 

 

More information about Packet Parsers 

 

RSA NetWitness Application Rules:

More information about NetWitness 11.4 New Features andAlerting: ESA Rule Types 

 

Changes:

RSA NetWitness Lua Parsers:

  • SMB_lua – This parser is updated for significant detection improvements with named pipe parsing capabilities. Detection is expanded to track parent-child relationships to recognize operations performed on child named pipes.

Read more about SMB_lua in action -

Detecting Lateral Movement in RSA NetWitness: Winexe 

Around the Fire With Old Friends (CVE-2019–0604, and CVE-2017-0144)

Keeping an eye on your Hounds...  

 

  • DCERPC – This parser is updated for similar detection improvements with named pipe parsing capabilities.

Read more about Using the RSA NetWitness Platform to Detect Lateral Movement: SCShell (DCE/RPC) 

 

  • TLS_lua - New detections are added in TLS parser to detect suspicious cipher suites for both client and server. This will give analysts added insight into what TLS connections based on suspicious client/server setup which will help detect and analyze malicious activity.

Read more about SSL and NetWitness 

 

  • rtmp_lua – rtmp parser is updated for accuracy and efficiency.
  • HTTP_lua – This parser has been updated with added detection and better accuracy

 

 

Discontinued:

We strive to provide timely and accurate detection of threats as well as traits that can help analysts hunt through network and log data. Occasionally this means retiring content that provides little-to-no value.

Discontinued Content 

 

For additional documentation, downloads, and more, visit the RSA NetWitness Platform page on RSA Link.

 

EOPS Policy:

RSA has a defined End of Primary Support policy associated with all major versions. Please refer to the Product Version Life Cycle for additional details.

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.

This month we did a live demonstration of upgrading the firmware on an iDRAC of version 8 and version 9. Sadly I wasn't able to make videos for this one, but here are Dell's official walkthrough videos: (Please keep in mind RSA only supports certain firmware versions that can be found here RSA NetWitness Availability of BIOS & iDRAC Firmware Updates)

iDRAC9 Firmware Upgrade | iDRAC8 Firmware Upgrade

 

Dell has multiple guides on IPMI-based interfacing with iDRACs, which can all be found on Dell's website depending on your firmware and hardware versions.

 

The recording of the May webinar is available here:

Webinar Recording

Access Password: 8V*6.vT@

 

PowerPoint is attached.

Filter Blog

By date: By tag: