Behavioral Detection Out-Performs Signature-Based Detection
During a recent proof-of-concept, RAD Security’s behavioral-based detection uncovered a reverse shell attack, while a leading signature-based CNAPP tool failed. This blog will show examples as to why this happened. We use examples of a reverse shell, sensitive data access, and a privilege escalation exploit in Sudo, illustrating how attackers can gain root privileges and avoid detection in a target environment.
The examples suggest that the difference is signature versus behavioral-based detection, and that, in general, RAD Security’s behavioral approach, plus AI-powered, automated investigation, catches exploits that would not be picked up by signature-based methods.
Download the Top 8 Reasons to Go Signatureless
Comparing Behavioral Detection with Signature-Based Detection Using Falco
Falco is arguably the most popular open-source runtime security tool in cloud-native security, frequently used for command execution and detection and response, with 7.1 thousand stars and 191 contributors. Falco is a signature-based tool, and has one of the broadest libraries of rules (aka signatures) available. Even though it is open source, and it is usually used via a CLI versus in the UI of an enterprise product, at its core, it demonstrates the same disadvantages as any other signature-based tool because its rules are signatures, and are meant to detect known malicious activity. But, as we’ll see, even known malicious activity is difficult for a signature-based detection method.
Detecting Symlink Attacks: Falco vs. RAD Security
Accessing sensitive files can be a serious indication of an attack in progress, particularly in a Linux system where attackers often attempt to modify files to elevate privileges and gain root access. In this first example, we will see the difference between detecting access to sensitive files using the popular open source, signature-based tool Falco, versus behavioral detection and response with RAD Security.
Where Falco Detects Sensitive Data Access
Falco has rules that warn you when sensitive files are opened, or when symlinks are created over sensitive files. The example is based on etc, which is usually the place in a Linux system where system configuration files are kept, and often a target for attackers looking to modify files and gain root privileges.
Below, we can see that Falco has two rules that are triggered when somebody tries to create a symlink over an etc file, or tries to cat (concatenate) or shorten the path to etc. The first rule warns that a sensitive file is being opened, and the second one warns that symlinks are being created over those sensitive files.
Falco rule examples for sensitive data access:
Limitations of Falco in Detecting Sensitive File Access
In the example below, we can see that a simple redirection allows us to bypass the above rules in Falco, highlighting a common method of defense evasion used by attackers.
First, we create a symlink for an unmonitored subdirectory we have created called security-link, which is not in the list of tracked files by Falco.
Creation of symlink for unmonitored subdirectory
We then use a relative path `../` to get back the parent directory and cat the etc file content.
Using the relative path and cat to get to etc
So by creating a symlink to a file that we have created, located in a non-monitored subdirectory within the target etc, we can bypass the Falco rules around sensitive data access.
Symlink Detection with RAD Security’s Behavioral Approach
Behavior-based detection with RAD Security takes a different approach that leads to better detection accuracy, reducing the likelihood of false positives and enhancing the ability to detect command execution and file modification attempts. Instead of applying a specific, stateless rule around sensitive data access, RAD Security starts by profiling the runtime behavior of the container (in this case, an nginx container). Below, you see the nginx fingerprint that will later exhibit drift, in terms of its hierarchy of processes, programs and files at runtime.
RAD Security baseline fingerprint for nginx image
Now that we have the fingerprint, we observe any drift that occurs and classify the drift, either in one container or across multiple containers. The classification of the threat is done by AI analysis of various drift events.
In this case, the first redirect in the Falco example above is shown as drift, and we can see the attempt to create a symlink for an unmonitored directory we have created called security-link.
RAD Security fingerprint exhibiting drift from malicious bypass attempts
Meanwhile, the AI-powered investigation engine has put together all the pieces to tell the story of what happened:
“Unauthorized access to shadow file
The container is attempting to access the shadow file, which contains encrypted user passwords. This could be part of a credential harvesting attack or an attempt to escalate privileges within the container or on the host system.”
Screenshot of AI-powered Automated Investigation
The results are very different in the RAD detection compared to Falco, using the exact same script; namely, RAD detects it and Falco doesn’t.
Identifying Sudo Potential Privilege Escalation Exploit
A Sudo potential privilege escalation happens when the Super User DO command, which is nearly ubiquitous across Linux, allows a user to run commands as a super user, with all the privileges that come with it.
This can be a significant threat in any target system. In an attack, a malicious actor might use this command to enable a lateral move, access sensitive data or even create its own users. In 2021, there was a serious vulnerability that was published for Sudo, CVE-2021-3156, that affected anyone running an unpatched Sudo version up to 1.9.5p1. In this example, we show that, even with its own purpose-based rule for this vulnerability, Falco did not pick it up, while RAD’s behavioral method did.
Where Falco Detects Sudo Potential Privilege Escalation
Falco has a rule for detecting Sudo Potential Privilege Escalation created by CVE-2021-3156.
For the rule to work, the process name needs to be ‘sudoedit.’ Below is the Falco rule that requires this process name.
Falco rule for Sudo CVE-2021-3156
Where Falco Doesn’t Detect Sudo Potential Privilege Escalation
At the time, Falco did not always detect CVE-2021-3156, even with its own rule intended for this purpose. According to our tests, this is still the case. Why? It again goes back to redirection and symlinks.
We saw above that the rule is meant to work when the process is named as ‘sudoedit’. When the rule got the actual binary instead of the symlink to the binary, it failed to detect anything. Why?
Falco rule fails to detect Sudo CVE-2021-3156
Per Falco’s documentation, process names are parsed from the execve pathname. Below you can see that the process name is in there, sudoedit, but the rule has censored the sudoedit process name, because on ubuntu base images sudoedit is a symlink to sudo. Put another way, the rule isn’t considering the process name because it’s a symlink.
Falco rule missing the sudoedit process name
Sudo Potential Privilege Detection with RAD Security
As before, instead of relying on very specific rule parameters that could easily be bypassed, RAD Security begins with a baseline profile of the image’s behavior, and detects anomalous activity from that baseline, categorizing the actual attack using AI.
The entire detection and AI interpretation is below, showing the exploit and also the AI-powered description of the entire issue:
Potential privilege escalation attempt using CVE-2021-3156 (Sudo Baron Samedit)
The container is running a Python script named 'exploit_nss.py' which then executes sudo with unusual parameters. This behavior is consistent with an attempt to exploit CVE-2021-3156, a heap-based buffer overflow in Sudo that could lead to privilege escalation.
RAD Security behavioral detection of CVE-2021-3156
Again, RAD Security picks up the threat and Falco doesn’t.
Reverse Shell Attack Detection: Falco vs RAD Security
In a reverse shell, the attacker obtains remote access to the target’s network, which can lead to further command execution, IP address manipulation, and evasion of traditional signature-based detection methods. Reverse shells are a common part of most attacks, and with this kind of access, an attacker can move laterally, upload malware, or exfiltrate data, depending on where they have access.
Falco’s Detection of Reverse Shell Attacks
Falco, like other signature-based detection tools, has multiple rules that can help against reverse shells. In order to work, Falco has to be able to see the binary directly as well as the network connection. Three triggers of those rules, and the associated request, are indicated below:
Example of Falco reverse shell detection
Challenges Faced by Falco in Reverse Shell Detection
It has been shown many times that it is possible to use symlinks or process name evasion to create redirects and aliases that fool the super-specific Falco signatures for detecting a reverse shell. Whereas in the first example, the way the rule was set up, Falco was actually looking for a symlink and when the binary is supplied instead, the rule doesn’t work. In this example, one could use a symlink to bypass Falco, because Falco would be looking for the binary or the network address.
Yet another way to bypass a reverse shell in Falco is to run an executable file format, versus direct code, for the reverse shell activity. In the below example, the msfvenom tool is used to create a custom remote code execution payload for linux, it is run under an executable file format, and Falco does not pick it up because the signature has no way of detecting the behavior under this file. In the end, Falco isn’t an anti-virus either, even if the payload did come with an assigned hash.
Example of reverse shell payload executing without Falco detection
Reverse Shell Detection with RAD Security’s Behavioral Analysis
In the exact same scenario as above, RAD Security will both detect the threat, as well as provide a detailed explanation of the malicious processes. This image was an ubuntu image, so the activity is detected as drift from the ubuntu container’s runtime behavior.
The entire detection and AI interpretation is below, showing the exploit and also the AI-powered description of the entire issue:
Potential malware execution and C2 communication detected in container
A suspicious sequence of commands was observed, including base64 decoding, file permission changes, and execution of an unknown binary 'gshell.elf'. This binary then established a network connection to 172.17.0.1:443, potentially indicating command and control (C2) communication. This behavior is consistent with malware deployment and remote access.
RAD Security reverse shell detection
Once again, behavioral detection picks up where the signature-based approach fails; in this case, while the signature-based methodology is looking at an individual runtime event, we can see that when the script is executed, an outbound connection has been established and a new interactive shell has been opened. On their own, maybe these things aren’t bad, but with the combination of drift events and AI-powered analysis we can look beyond individual events to see how they are all related and might constitute an attack.
The Need for Behavior-Based Detection in Modern Security
The examples above demonstrate the difficulties in using a method that relies on signature-based detection, which requires explicit instructions for what to look for and often fails to detect more sophisticated attack methods such as defense evasion, command execution, and privilege escalation. Whether detecting a reverse shell or a Sudo privilege escalation exploit, RAD Security's behavioral approach proves to be more effective.
There are clearly many different ways to set up a reverse shell, there are many times when symlinks are used, and base images each have different defaults for how they refer to processes. These downsides to signature-based detection are not new; in fact, they are well-known, and throughout the history of cyber security, these limitations have led to the replacement of signature-based methods with behavioral approaches. The attacks happening in cloud security are far more advanced than a reverse shell or a CVE; take the XZ Backdoor for example, which would have been installed via a simple software update, allowing remote code execution.
It’s clearly time to pivot to a behavioral approach to detection in cloud security, to stop relying on rules that require high levels of maintenance, with very little efficacy.
If you agree, sign the ‘Signatures are History’ petition and get the Top 8 Reasons to Go Signatureless whitepaper, or reach out to the RAD team to start fingerprinting the behavior of your cloud workloads today. By transitioning to behavior-based detection, you can significantly reduce the risk of false positives and improve your defense against threats targeting your system’s web server, command line interfaces, and overall target environment.
