Over the last month, we have observed over 7000 NodeZero RAT installation attempts across various customer environments. We would like to show a little bit of what happens behind the scenes in the development of the NodeZero RAT.
Introduction
Part of a manual penetration test normally done by a human is post-exploitation. Post-exploitation is what an attacker does after they compromise an endpoint. This typically involves a Remote Access Tool (RAT) like Cobalt Strike or Sliver. Back when we were designing our autonomous post-exploitation framework for NodeZero, we had to confront what an autonomous RAT would look like. We started down the path designing tooling around a third-party RAT, but quickly realized that we wanted more finely tailored solution and decided to write our own.
We followed a somewhat traditional approach and broke our RAT into various components:
- The RAT binary itself for Windows and Linux.
- A Command and Control (C2) server responsible for storing task information and handling callbacks from the RAT.
- A “Payload Service” responsible for stamping the RAT binary with required information for communicating with the C2.
- A command line interface (CLI) that we use to issue tasks and receive results from our RATs.
This traditional separation worked well, but we also need to address how to control the RATs autonomously. This lead to us design a RAT control system within NodeZero. This autonomous control system is best understood in the context of a RATs lifecycle which consists of the following steps:
- NodeZero identifies remote code execution (RCE) opportunities through either vulnerabilities or credentials.
- NodeZero uses those RCEs to copy or download the RAT binary to the compromised endpoint.
- NodeZero uses that same RCE to start the RAT.
- The RAT begins calling back the its C2 server.
- NodeZero uses the RAT for a variety of post-exploitation operations.
Now that we have a basic idea of how the RAT works, let’s dig into the lifecycle of a NodeZero RAT in a bit more depth.
Step1: Identify opportunities for RCE
At this stage of the RAT lifecycle, NodeZero identifies opportunities for RCE. These opportunities can be broken down as follows:
Credential Based Opportunities
For Windows, if we find a credential with local administrator permissions on an endpoint, we will attempt to load and execute the RAT with various techniques including abusing protocols like SMB, WMI or WinRM. If these credentials have access to a database like Postgres, NodeZero may also try to abuse features of the database to load and execute the RAT. Lastly, there are some vulnerabilities like Print Nightmare that NodeZero can abuse along with a credential to load the RAT.
On Linux, if we find plaintext SSH credentials or private keys. We can use those credentials to load and execute the RAT. Often, NodeZero will do some reconnaissance to determine attributes of the target, like its CPU architecture. This reconnaissance allows NodeZero to chose techniques that give it the highest probability of landing the RAT.
Vulnerability Based Opportunities
NodeZero can also use any vulnerability that allows for RCE to load and execute the RAT. This even includes blind RCEs where we aren’t necessarily able to do target reconnaissance before hand. NodeZero has a library of different techniques for downloading and executing the RAT that it will try until it receives a successful callback.
What Does the Data Say on Credentials vs Vulnerabilities
We gathered some data from our customer’s environments over the last month and did some analysis. Out of over 7000 RAT installation attempts, the vast majority of attempts use credentials, not vulnerabilities.
To add insult to injury, credential based methods for deploying the NodeZero RAT often face less scrutiny from security systems.
Imagine you are a security system trying to distinguish legitimate activity from malicious activity. If I give an attacker a legitimate credential, how can you tell if it’s an attacker installing a program or a legitimate user?
Security systems face this same conundrum. We observe that when we install the RAT with a vulnerability, it is much more likely to get caught by an EDR compared with when we install the RAT with a credential. It’s like giving a burglar your house key, no alarm will trigger because they’re using the “right” way to get in.
If we break the data down by module we see that SMB and SSH based credential attacks lead the pack in RAT installation attempts by a landslide.
smb_execuses Windows credentials with local admin permissions to install RATs over SMBssh_execuses SSH and SFTP to install and run RATspostgresql_rceuses Postgres credentials to download and install RATs
Now that we have the RAT running on the endpoint we move into the next stage in its lifecycle.
Stage 2: Autonomous Post-Exploitation
At this stage, NodeZero is free to use the RAT as it sees fit. Depending on what NodeZero learns about the target environment, it can choose to do different things with the RAT.
NodeZero typically runs a core set of telemetry modules to do things like enumerate processes, users, and installed programs. After the initial enumeration, what NodeZero decides to do can be highly variable. Let’s dig into two specific examples.
Okta User Compromise
In this example, let’s see how NodeZero can use the RAT to access Okta as a particular user.
If NodeZero discovers that a user on a compromised endpoint uses Google Chrome, NodeZero will use the RAT to pull the Chrome cookie file and the Chrome application-bound key. It will store these two files in its knowledge graph. In order to decrypt the Cookies, NodeZero needs a few pieces of cryptographic information including the System DPAPI key and particular user DPAPI keys.
Depending on the circumstances, NodeZero may find these keys through the RAT’s credential dumping modules, or it may find these keys through other non-RAT methods. Once, NodeZero has all of the appropriate decryption keys, NodeZero will decrypt the Chrome cookies offline.
Next, NodeZero will then analyze the decrypted cookies and store them in its knowledge graph. If NodeZero finds a valid Okta Cookie, it will use a RAT module to make HTTP requests to Okta. By making the request through the RAT, NodeZero avoid impossible travel protections because the requests come from the same endpoint where NodeZero found the cookie.
This is just one example of many where NodeZero demonstrates emergent behavior and uses the RAT to make a big impact. There are many more interesting technical details on this attack that we will elaborate on in a future post.
Slack User Compromise
In another example, we will see how NodeZero is able to use the RAT to steal Slack information.
NodeZero uses a string of vulnerabilities and credentials to load more RATs to more endpoints. This cycle continues until we eventually land an endpoint running the Slack messaging application. NodeZero the uses the RAT on that endpoint to steal Slack tokens and impersonate that user. In a similar manner to the Okta user compromise attack, NodeZero uses the RAT to make requests to slack.com to avoid impossible travel protections.
These examples are just a small sample of interesting attack paths enabled by the RAT. Both of these examples are done with 0 human intervention, which allows NodeZero to make decisions very quickly. This leads us to our next data driven insight.
AI Enabled Attacker: Can you SOC match the Speed of the NodeZero RAT?
Once the RAT lands, our data shows that on average the RAT takes only a few minutes to complete its core mission. Our analysis showed that the median time for a RAT to complete its core set of modules was just 3 minutes!
This core set of modules includes, user and process enumeration, credential stealing, file pilfering, cloud provider specific attacks and more.
If we break down the difference between Linux and Windows RATs we find that:
- Linux RATs take only 20-60 seconds to complete their entire battery of tasks.
- Windows RATs are much more variable. Our fastest RATs take less than a minute. Our slower RATs can run for much longer if they start pilfering the filesystem for interesting files.
The speed an agility of the NodeZero RAT is enabled through tight integration between NodeZero, NodeZero’s knowledge graph, and the NodeZero RAT itself. Most other third party RATs are designed with a human user interface in mind, the NodeZero RAT has no such interface since it is entirely controlled by NodeZero.
Engineering Considerations
An interesting point brought up by a co-worker recently was along the lines of “You know, we have a command line interface for the RAT, but no human has ever used it”. The CLI for the RAT is indeed not an interface designed for humans. There interface primarily consists of strongly typed JSON blobs that are serializable to with Rust (for the RAT) or Python (for NodeZero). In some ways its more like an MCP server. Although it was created before the popularity of MCP servers.
This strong integration allows us to iterate quickly and add new features to the RAT in response to what we see in customer environments.
The RAT’s tight integration into NodeZero also allows us to derive great insights from the telemetry we gather. For example, many other RAT frameworks might focus on dynamic compilation, special binary packing techniques, or sophisticated in-memory loaders. These features, while cool, take a lot of time to build, test, and maintain. The telemetry gathered by the NodeZero RAT shows us that those things don’t matter so much in many real-world environments.
For example, on Windows, EDRs catch the RAT with varying levels of success. Behavioral triggers for things like dumping LSASS are more consistent in catching the RAT than static signatures. We’ve noticed that for some EDRs, a simple recompilation of the RAT bypasses an EDR that previously blocked the RAT due to a static signature.
Another example of a simple change with an outsized impact is an instance where we noticed that our Linux RAT was not landing with as high a frequency as we expected. We added a simple update to enumerate mount points, and note whether or not they were marked with noexec. This allowed us to greatly increase our chances of landing the RAT in certain environments.
We are constantly examining the success rates of the RAT and making minor adjustments to increase those rates. Most of those adjustments are simple changes and not things like building custom binary packers and the like.
The RAT does have some cool features like custom in-memory loaders, custom .NET execution environments and much more. Maybe we’ll write a blog on some of those features in the future. But, those things don’t matter nearly as much as simple things like putting some care into our download and execution techniques.
Conclusion
We hope you’ve enjoyed this quick tour of the NodeZero RAT and gained some understanding that:
- Attackers can easily make small modifications to existing malware strains to avoid some signatures.
- Credentials are king when it comes to landing a foothold for post-exploitation.
- AI-enabled and autonomous attacks happen in the blink of an eye. Your security systems need to be ready for these high speed attacks.
Get a NodeZero Demo:
See how NodeZero autonomously detects and exploits real-world weaknesses in minutes. Schedule a demo to experience precision post-exploitation in action.