Skip navigation
All Places > Products > RSA NetWitness Platform > Blog > Author: John Simmons

RSA NetWitness Platform

4 Posts authored by: John Simmons Employee

In order to defend their network effectively, analysts need to understand the threat landscape, and more specifically how individual threats present themselves in their tools. With that in mind, I started researching common Remote Access Trojans/Tools (RAT) that are publicly available for anyone to use. This will walk you through Gh0st RAT (https://attack.mitre.org/software/S0032/), its footprint, and how the RSA tools help you detect its presence from both the endpoint and packet perspective. 

 

Just like any malware, a Gh0st infection will consist of some sort of delivery mechanism. Most mature SOCs with mature tools should get an alert on either its delivery (using common methods such as phishing, drive-by download, etc) or subsequent presence on an endpoint. However, let’s assume that it does not get detected, and as an analyst you are proactively hunting in your environment.  How would you go about detecting the presence of such a Trojan?

 

Gh0st Overview and Infection

Gh0st is a very well-documented RAT but you’ll find a quick overview of some of the functionality and way it was configured for testing purposes belowAlso, I will show you how our tools can help identify Gh0st.  The Gh0st server component is a standalone portable executable (PE) file, which gives you a simple interface when executed.  Once executed, the server component is used not only to control infected systems, but also used to configure the client component that is delivered to victims.

 

                    

Figure 1: Gh0st Interface

 

The build tab that is used to configure the client executable had some default HTTP settings, which I changed to use “gh0st[.]com” for simplicity.  I also created an entry in DNS for this domain to point to our command and control (C2) server.

 

                    

Figure 2: Gh0st HTTP and Service Options

 

You can also see that the Build tab contains options for the service display name and description.  After I created the malicious client component sample, I crafted an email using Outlook Web Access on Exchange and sent it to the victim.

 

                      

Figure 3: Phishing Email

 

The victim setup had Windows 10 installed using all default settings.  Once the user received the email, I was surprised to learn that this wasn’t flagged by local Antivirus or any other tools.    Even after I executed the PE file, it was not flagged as malicious.  It installed the service as seen here but there was no initial identification and no “alarms” were raised. 

                                             

Figure 4: Service Installed

 

 The malware executed fine, and I could see the connection through the Gh0st Dashboard on the server component.

 

                   

Figure 5: Successful Client Connection

 

From here, I used some of the built-in features of Gh0st to control and interact with the endpoint.  Here are some of those features:

 

                                                

Figure 6: Options Once Connected

 

I first opened a “Remote Shell” which basically just gives you a command prompt with System level permissions.

 

               

Figure 7: Remote Shell

 

From there, I executed net user commands through the remote shell.  The net user commands are for reconnaissance and used to identify what users are on the machine.  They can be used in conjunction with a username to identify what groups the user belongs to.

 

                     

Figure 8: Running Commands Using Remote Shell

 

Next, I modified the registry to allow for cleartext credential storage in memory. I then copied procdump over to the machine using the “File Manager” feature, and then I used procdump to dump the lsass.exe memory into a .dmp file.  I finally copied that .dmp file back over to my C2 server.  This a common technique for getting credentials out of memory in cleartext.  The attacker can use these credentials to access other parts of the network.

 

                        

Figure 9: File Manager

 

Figure 10: Procdump on LSASS

 

RSA NetWitness Endpoint 4.4 Detection

Prior to performing any of the aforementioned steps, I installed RSA NetWitness Endpoint on the victim and created a baseline of the IIOCs.  This was also prior to performing any additional interaction with the hosts.  These IIOCs were coming from multiple machines since I had Windows 10 and Windows 7 victims with agents installed.  There was only one level 1 IIOC and not much else going on.

Once the email was opened and the file was clicked, there were some additional IIOCs that fired including:

  • Unsigned writes executable
  • Unsigned writes executable to appdata local directory
  • Unsigned writes executable to Windows directory
  • Renames files to executable

 

Figure 11: IIOCs Fired in RSA NetWitness Endpoint

 

 

These are all great indicators for hunting and that should be checked daily, the results triaged, and appropriate measures taken for each hit.

Then I pivoted from those IIOCs and looked for the “invoice.exe” module in the tracking data.  This showed me the “FastUserSwitchingCapability” service being created.

 

Figure 12: Service Created

 

Also, this is where the net user commands were found. 

 

Figure 13: Net User Commands Found in RSA NetWitness Endpoint

 

Once the registry change for cleartext credential storage was executed, the IIOC for that fired as seen here.

 

Figure 15: More IIOCs

 

So, going back to the service we can see that it created an Autorun entry and gave it a high IIOC score.

 

Figure 16: Autoruns in RSA NetWitness Endpoint

 

It’s was also listed in the modules.

 

Figure 17: Modules Listed

 

RSA NetWitness Endpoint 11.3 Detection

Here’s how things look in RSA NetWitness Endpoint 11.3.  First here is the baseline IOC, BOC, EOC, and File Analysis meta fields after the agent has been installed.

 

Figure 18: RSA NetWitness Endpoint 11.3 Baseline

 

This is the risk score for the host which is based on the windows firewall being disabled.

 

Figure 19: Initial RSA NetWitness Endpoint 11.3 Risk Score

 

After I executed the dropper there was some additional meta generated including:

  • Unsighted writes executable to appdatalocal directory
  • Runs service control tools
  • Starts local service
  • Auto unsigned hidden
  • Auto unsigned servicedll

 

Figure 20: Additional Meta after Dropper Execution

Figure 21: Invoice.exe Creating Files in AppData Folder

 

We can also see this alert for “Autorun Unsigned Servicedlls” which is related to the “autorun unsigned servicedll” meta in the Navigate view.

 

Figure 22: Risk Score Increase

Figure 23: Autoruns with Four DLLs

Figure 24: Autorun Unsigned Servicedll Meta

 

Next, I opened up a remote shell using the Gh0st dashboard and executed some basic reconnaissance commands (whoami, net user /domain, etc) just like in RSA NetWitness Endpoint 4.4.

 

Figure 25: Reconnaissance Commands

 

Again, I executed the registry command to enabled cleartext credential storage and procdump on the lsass.exe process.  That triggered a critical alert in RSA NetWitness Endpoint 11.3 which gave a risk score of 100 just like in RSA NetWitness Endpoint 4.4.

 

Figure 26: Registry Command to Enable Cleartext Credential Storage

 

Also, going back to look at the navigate view, there was some additional meta generated for these commands.

  • Enumerates domain users
  • Modifies registry using command-line registry tool
  • Runs registry tool
  • Enables cleartext credential storage
  • Gets current user as system
  • Gets current user

 

Figure 27: Additional Meta

 

RSA NetWitness Network Detection

While there are obviously various detection capabilities for identification of delivery of the gh0st executable, the purpose of this post is to discuss presence of the gh0st RAT once a system is infected.  As such, the RSA NetWitness Packets (NWP) Gh0st parser detected the presence of the Gh0st trojan, based on the communications between the gh0st server and client. Just by looking in the “Indicators of Compromise” the Gh0st traffic is listed there.  With just one click I was able to find the C2 activity using RSA NetWitness Platform packet data.

 

Figure 18: IOC Meta in the RSA NetWitness Platform

 

As mentioned earlier, one of the benefits of doing this is that when we identify gaps, we work with people like Bill Motley in our content team to create appropriate content.  Initially the parser wasn’t detecting this specific gh0st activity but that has been fixed. An updated parser is now available in RSA NetWitness Live.

 

Here we can see some of the Gh0st C2 traffic that generates the IOC meta mentioned before.

 

Figure 19: Gh0st C2 Seen in the RSA NetWitness Platform

 

Also here is the HTTP traffic which is  heart beat callout to check and make sure it’s still connected.  It does this HTTP get request about every two minutes and only the string “Gh0st” is returned.

 

Figure 20: Heartbeat Traffic

 

Even without this parser, Gh0st C2 traffic can be found with as little as three pieces of metadata.  First, looking at service metadata labeled as ‘OTHER’ which can be a good place to start hunting because it’s network traffic that doesn’t have a known parser and/or doesn’t follow the RFCs for known protocols.  Then, in the IOC meta there was ‘binary indicator’ which can help limit the dataset.  Finally, in the analysis.service metadata the ‘unknown service over http port’ value stuck out.  Performing these three pivots from the full dataset found all of the gh0st traffic, including some additional traffic not seen previously.  That can be seen in the screenshot below under the Indicators of Compromise column.  There are IOCs showing gh0st but there are also some that only show the traffic as binary.

 

Figure 21: Additional Traffic Not Seen Previously

 

Summary

Gh0st is one of the simplest and easiest RATs to use.  The RSA NetWitness Platform had no trouble finding this activity.  Though this is a publicly available and commonly used RAT, it frequently goes unidentified by AV and other technologies, as referenced in my example.  This is where the power of regular threat hunting comes in, since it helps you detect unknown threats that your regular tools don’t necessarily pick up on. Some of these can be automated, as we did with the parser changes.

 

This means that, in the future, you no longer need to look for this specific threat but rather follow this process, which will hopefully lead you to newer unknown threats. Using the right tools coupled with the right methodology will help you better protect your network/organization, unfortunately not all of this can be fully automated and some of the automation will still require appropriate human triage.

On a recent engagement, I took a different approach to finding possible malicious files entering the customer's network.  Rather than focusing on the e-mail, I looked for any RAR, macro-enabled office documents, and portable executable files (PE) entering the network where no service was specified.  Of course, this was done using RSA NetWitness and immediately I found a RAR file which contained a malicious executable.  Although, this was a different vector by which it entered the network.  It didn't appear to be a link that someone clicked from an e-mail and it wasn't an attachment from an email either.  It was from a customer configured, cloud based support site.  You can find many customers who use these types of sites.

 

So here's how I believe this was attempted.  A malicious actor goes to the <customer name>.<customer support site>.com site where they open a support ticket for an order they placed. (Of course they probably didn't place an actual order)  Then using the support interface, they upload what appears to be an order list.  In this instance I found the file name was "OrderList_Xlsx.arj" which is a RAR file and inside was a file called "OrderList.exe" all of which was downloaded by the customer support representative using their admin console to the site.

 

It's a simple approach.  It involves the actor opening a support ticket on the customer's site but whether they are actually doing this or using a script/automation is another question.  In this instance, I didn't see it as being targeted towards this customer but maybe they're testing the waters.  Without having access to this customers admin console to this service it's hard to determine whether this is happening more frequently because from our perspective, we only see where the employee downloads the file and enters into the customer's network. 

 

I created a quick and easy search to find this type of activity.

 

alias.host = '<customer name>.<customer support site>.com' && (filetype = 'rar' || filetype = 'windows executable' || ((filetype = 'zip' || filetype contains 'office') && filename contains 'vbaproject.bin') || extension contains 'docm','xlsm','pptm' || content contains 'macro')

A question was posed to our team by one of the engineers; had we seen the new Chrome and Microsoft zero-day exploits using RSA NetWitness Endpoint?  I honestly didn't even know about these exploits and so I had to do some research.  I found the initial Google Blog post here: Google Online Security Blog: Disclosing vulnerabilities to protect users across platforms.  The first vulnerability (NVD - CVE-2019-5786) is the Google Chrome vulnerability and the second was disclosed to Microsoft by Google but as of the time I am writing this, no patch had been released by Microsoft.

 

Other articles and blogs that talk about these zero-days say they are being used in conjunction with each other. There was no proof of concept code nor any exploits I could use from the research I did. I did see some articles talking about these being exploited in the wild but I couldn’t find any other details. The second zero day is a Windows 7 32 bit privilege escalation vulnerability which does a null pointer dereference in win32k.sys. I found a similar privilege escalation exploit for CVE-2014-4113 and successfully exploited a box in my sandbox environment while it had an NetWitness Endpoint agent on it. The two IIOCs that fired that would help detect this attack were:

 

IIOC 1 - “Creates process and creates remote thread on same file”
IIOC 2 - “Unsigned creates remote thread”

 

The remote thread in this case was on notepad.exe which is common of Meterpreter.

 

The exploit I used can be found here: https://www.exploit-db.com/exploits/35101. It also does a null pointer dereference in win32k.sys similar to the Microsoft zero-day.  Below are some screenshots of what I saw from the attacker side and the NetWitness Endpoint side.

 

Here you can see the the exploit being injected in process ID 444.

 

 

Here is the entry in RSA NetWitness Endpoint.

 

 

Another entry is lsass.exe opening notepad.exe after the remote thread creation.  I believe this is the actual privilege escalation taking place.  It also makes sense because the timestamp matches exactly to the timestamp in Kali.

 

 

Here are the IIOCs which I believe are the initial meterpreter session based on timestamps.   It's still an indication of suspicious activity and when combined with lsass.exe opening the same remote thread process, it raises even more alarms.

 

 

I gave this to the engineer in hopes that the new Microsoft zero-day could be detected in the same way and even though we don't know the details of the Google Chrome vulnerability, we do know they are being exploited together.  This could help possibly identify this attack that has been seen in the wild.  Also, on another note, the fact that two zero-days are being exploited in the wild together just screams of a well-funded advanced adversary and it's a relief to know that our tool out-of-the-box should be able to help find this type of activity.

During a recent customer engagement, I found the "customtcp shell" meta with some very interesting sessions.  All of the traffic was using what appeared to be custom encryption and the destination IP was based in Korea.  Of course, I knew this couldn't be the first time someone had come across traffic like this so I looked at previous reporting for similar traffic.  Multiple analysts, like myself, had seen traffic exactly like this and their analysis led them in different directions.  Some even believed that this was NanoCore RAT traffic as it had similar attributes but I was still skeptical.  After hours of researching this traffic and trying to dissect this traffic I came across someone's master's thesis talking about end-to-end encrypted mobile messaging apps.  The link to the thesis is below.

 

https://www.diva-portal.org/smash/get/diva2:1046438/FULLTEXT01.pdf 

 

The traffic I was seeing matched perfectly with the handshake packet used with the propriety protocol called LOCO, which is used by the mobile messaging app KakaoTalk.  The article broke it down very well and without it I think I would still be scratching my head at this traffic.  So lets go back to what this traffic looks like and how I was able to determine it was KakaoTalk.

 

Here is an example of the customtcp shell meta being populated in a customer's environment.  This over a 5 day time period so it's not very common in most customer's environments.

 

 

As of today, I have seen this type of traffic in four customer environments within the RSA NetWitness Platform. Further, fellow colleagues and team members have also inquired about this type of traffic.  To recreate this traffic and avoid showing customer data, I downloaded the KakaoTalk mobile app on my personal iPhone.  Here is an example of the what the handshake packet looks like.

 

 

With the help of Stephen Brzozowski during the first engagement, we were able to dissect this packet to some extent.  The first 12 bytes of the sessions are the custom headers and always repeat during the first session.

 

 

The response and any follow-on packets would begin with the size in little-endian format.

 

 

With the help of the article mentioned above, I was able to match this traffic to the LOCO protocol's initial handshake packet.

 

 

As well as the follow-on packets that matched the LOCO encrypted packet.

 

Considering that every instance of the handshake packet I have seen in multiple environments always begin with the same first 12 bytes, I wrote a quick parser to find this traffic.  It's attached below.  I have deployed it on two customer environments and left it running for almost 24 hours with no false positives and approximately 20 sessions discovered in each environment.  Currently, it only detects the initial handshake, but I intend to modify it later to detect all sessions with the same high fidelity.  In addition, I have seen one other instance where the first 12 bytes didn't match because of one bit being off but I still believe it was KakaoTalk.

 

While deploying this parser and testing in these environments, I also discovered similar traffic that used other custom headers which I believe is another type of mobile messaging app that uses end-to-end encryption.  I believe we will continue to see additional mobile apps that populate this meta key in the future.  While documentation for these apps and custom protocols are scarce, I believe that it will present a challenge for analysts to distinguish between malicious custom TCP shells and benign traffic such as discussed in this blog.

Filter Blog

By date: By tag: