This website uses cookies. By clicking Accept, you consent to the use of cookies. Click Here to learn more about how we use cookies.
Accept
Reject

NetWitness Community

  • Home
  • Products
    • NetWitness Platform
      • Advisories
      • Documentation
        • Platform Documentation
        • Known Issues
        • Security Fixes
        • Hardware Documentation
        • Threat Content
        • Unified Data Model
        • Videos
      • Downloads
      • Integrations
      • Knowledge Base
    • NetWitness Cloud SIEM
      • Advisories
      • Documentation
      • Knowledge Base
    • NetWitness Detect AI
      • Advisories
      • Documentation
      • Knowledge Base
    • NetWitness Investigator
    • NetWitness Orchestrator
      • Advisories
      • Documentation
      • Knowledge Base
      • Legacy NetWitness Orchestrator
        • Advisories
        • Documentation
  • Community
    • Blog
    • Discussions
    • Events
    • Idea Exchange
  • Support
    • Case Portal
      • Create New Case
      • View My Cases
      • View My Team's Cases
    • Community Support
      • Getting Started
      • News & Announcements
      • Community Support Forum
      • Community Support Articles
    • Product Life Cycle
    • Support Information
    • General Security Advisories
  • Training
    • Blog
    • Certification Program
    • Course Catalog
    • New Product Readiness
    • On-Demand Subscriptions
    • Student Resources
    • Upcoming Events
  • Technology Partners
  • Trust Center
Sign InRegister Now
cancel
Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
Showing results for 
Search instead for 
Did you mean: 
NetWitness Community Blog
Subscribe to the official NetWitness Community blog for information about new product features, industry insights, best practices, and more.
cancel
Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
Showing results for 
Search instead for 
Did you mean: 
  • NetWitness Community
  • Blog
  • Detecting Gh0st RAT in the RSA NetWitness Platform

Detecting Gh0st RAT in the RSA NetWitness Platform

JohnSimmons
JohnSimmons Beginner
Beginner
Options
  • Subscribe to RSS Feed
  • Mark as New
  • Mark as Read
  • Bookmark
  • Subscribe
  • Email to a Friend
  • Printer Friendly Page
  • Report Inappropriate Content
‎2020-01-09 01:38 PM

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 below.  Also, 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.

 

                    pastedImage_3.png

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.

 

                    pastedImage_6.png

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.

 

                      pastedImage_8.png

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. 

                                             pastedImage_10.png

Figure 4: Service Installed

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

 

                   pastedImage_12.png

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:

 

                                                pastedImage_14.png

Figure 6: Options Once Connected

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

 

               pastedImage_16.png

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.

 

                     pastedImage_18.png

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.

 

                        pastedImage_20.png

Figure 9: File Manager

pastedImage_22.png

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

 

pastedImage_25.png

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.

 

pastedImage_28.png

Figure 12: Service Created

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

 

pastedImage_32.png

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.

pastedImage_35.png

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.

 

pastedImage_40.png

Figure 16: Autoruns in RSA NetWitness Endpoint

It’s was also listed in the modules.

 

pastedImage_42.png

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.

 

pastedImage_1.png

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.

pastedImage_4.png

pastedImage_5.png

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

 

pastedImage_8.png

Figure 20: Additional Meta after Dropper Execution

pastedImage_10.png

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.

 

pastedImage_13.png

Figure 22: Risk Score Increase

pastedImage_19.png

Figure 23: Autoruns with Four DLLs

pastedImage_17.png

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.

 

pastedImage_21.png

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.

 

pastedImage_24.png

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

 

pastedImage_28.png

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.

 

pastedImage_45.png

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 William 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.

 

pastedImage_48.png

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.

 

pastedImage_52.png

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.

 

pastedImage_54.png

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.

Labels:
  • Use Cases
  • blog post
  • detection
  • dfir
  • EDR
  • Endpoint
  • endpoint detection
  • example
  • gh0st
  • gh0st rat
  • ghost
  • ghost rat
  • NetWitness
  • netwitness network
  • netwitness packets
  • NetWitness Platform
  • network detection
  • NW
  • NWE
  • NWP
  • packets
  • rat
  • remote access trojan
  • RSA NetWitness
  • RSA NetWitness Platform
  • use case
2 Likes
Share

You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.

  • Comment
Latest Articles
  • Agent Tesla: The Information Stealer
  • Threat Analysis: Detecting “Follina” (CVE-2022-30190) RCE Vulnerability with Netwitness Endpoint
  • Introducing NetWitness Vision XDR
  • Introducing NetWitness Platform XDR v12.0
  • Atlassian Confluence Zero-day Vulnerability (0-Zero) CVE-2022-26134: What You Need To Know
  • ‘Follina’ CVE-2022-30190 0-Day: What You Need To Know
  • CVE-2022-1388: BIG-IP iControl REST RCE Vulnerability
  • Ragnar Locker Ransomware: The Rampage Continues…
  • Ransomware Email Attacks: Beware of BazarLoader
  • Detecting Impacket with Netwitness Endpoint
Labels
  • Announcements 54
  • Events 2
  • Features 9
  • Integrations 6
  • Resources 57
  • Tutorials 21
  • Use Cases 21
  • Videos 116
Powered by Khoros
  • Blog
  • Events
  • Discussions
  • Idea Exchange
  • Knowledge Base
  • Case Portal
  • Community Support
  • Product Life Cycle
  • Support Information
  • About the Community
  • Terms & Conditions
  • Privacy Statement
  • Acceptable Use Policy
  • Employee Login
© 2022 RSA Security LLC or its affiliates. All rights reserved.