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