{
	"id": "658c2767-d91a-412e-a8c7-a4d0d210f7c0",
	"created_at": "2026-04-06T00:19:13.54118Z",
	"updated_at": "2026-04-10T03:20:20.289058Z",
	"deleted_at": null,
	"sha1_hash": "083df5bf97c2e3c3130c76a8acc8d8fbb64f7f2a",
	"title": "PumaBot: Novel Botnet Targeting IoT Surveillance Devices",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 3141031,
	"plain_text": "PumaBot: Novel Botnet Targeting IoT Surveillance Devices\r\nBy Tara Gould\r\nPublished: 2025-05-28 · Archived: 2026-04-05 19:39:44 UTC\r\nIntroduction: PumaBot attacking IoT devices\r\nDarktrace researchers have identified a custom Go-based Linux botnet named “PumaBot” targeting embedded Linux\r\nInternet of Things (IoT) devices. Rather than scanning the Internet, the malware retrieves a list of targets from a command-and-control (C2) server and attempts to brute-force SSH credentials. Upon gaining access, it receives remote commands and\r\nestablishes persistence using system service files. This blog post provides a breakdown of its key functionalities, and\r\nexplores binaries related to the campaign.\r\nTechnical Analysis\r\nFilename: jierui\r\nmd5: cab6f908f4dedcdaedcdd07fdc0a8e38\r\nThe Go-based botnet gains initial access through brute-forcing SSH credentials across a list of harvested IP addresses. Once\r\nit identifies a valid credential pair, it logs in, deploys itself, and begins its replication process.\r\nhttps://www.darktrace.com/blog/pumabot-novel-botnet-targeting-iot-surveillance-devices\r\nPage 1 of 8\n\nFigure 1: Overview of Jierui functions.\r\nThe domain associated with the C2 server did not resolve to an IP address at the time of analysis. The following details are a\r\nresult of static analysis of the malware.\r\nThe malware begins by retrieving a list of IP addresses of likely devices with open SSH ports from the C2 server (ssh.ddos-cc[.]org) via the getIPs() function. It then performs brute-force login attempts on port 22 using credential pairs also obtained\r\nfrom the C2 through the readLinesFromURL(), brute(), and trySSHLogin() functions.\r\nWithin trySSHLogin(), the malware performs several environment fingerprinting checks. These are used to avoid honeypots\r\nand unsuitable execution environments, such as restricted shells. Notably, the malware checks for the presence of the string\r\n“Pumatronix”, a manufacturer of surveillance and traffic camera systems, suggesting potential IoT targeting or an effort to\r\nevade specific devices [1].\r\nhttps://www.darktrace.com/blog/pumabot-novel-botnet-targeting-iot-surveillance-devices\r\nPage 2 of 8\n\nFigure 2: Fingerprinting of “Pumatronix”.\r\nIf the environment passes these checks, the malware executes uname -a to collect basic system information, including the\r\nOS name, kernel version, and architecture. This data, along with the victim's IP address, port, username, and password, is\r\nthen reported back to the C2 in a JSON payload.\r\nOf note, the bot uses X-API-KEY: jieruidashabi , within a custom header when it communicates with the C2 server over\r\nHTTP.\r\nThe malware writes itself to /lib/redis , attempting to disguise itself as a legitimate Redis system file. It then creates a\r\npersistent systemd service in /etc/systemd/system , named either redis.service or mysqI.service (note the spelling\r\nof mysql with a capital I) depending on what has been hardcoded into the malware. This allows the malware to persist across\r\nreboots while appearing benign.\r\n[Unit]\r\nDescription=redis Server Service\r\n[Service]\r\nType=simple\r\nRestart=always\r\nRestartSec=1\r\nUser=root\r\nExecStart=/lib/redis e\r\n[Install]\r\nWantedBy=multi-user.target\r\nIn addition to gaining persistence with a systemd service, the malware also adds its own SSH keys into the users’\r\nauthorized_keys file. This ensures that access can be maintained, even if the service is removed.\r\nA function named cleankill() contains an infinite loop that repeatedly attempts to execute the commands “xmrig” and\r\n“networkxm”. These are launched without full paths, relying on the system's PATH variable suggesting that the binaries may\r\nbe downloaded or unpacked elsewhere on the system. The use of “time.Sleep” between attempts indicates this loop is\r\ndesigned to ensure persistence and possibly restart mining components if they are killed or missing.\r\nDuring analysis of the botnet, Darktrace discovered related binaries that appear to be part of a wider campaign targeting\r\nLinux systems.\r\nFilename: ddaemon\r\nMd5: 48ee40c40fa320d5d5f8fc0359aa96f3\r\nDdaemon is a Go-based backdoor. The malware begins by parsing command line arguments and if conditions are met, enters\r\na loop where it periodically verifies the MD5 hash of the binary. If the check fails or an update is available, it downloads a\r\nnew version from a C2 server (db.17kp[.]xyz/getDdaemonMd5) , verifies it and replaces the existing binary with a file of\r\nthe same name and similar functionality (8b37d3a479d1921580981f325f13780c) .\r\nThe malware uses main_downloadNetwork() to retrieve the binary “networkxm ” into /usr/src/bao/networkxm .\r\nAdditionally, the bash script “installx.sh” is also retrieved from the C2 and executed. The binary ensures persistence by\r\nwriting a custom systemd service unit that auto starts on boot and executes ddaemon.\r\nFilename: networkxm\r\nMd5: be83729e943d8d0a35665f55358bdf88\r\nThe networkxm binary functions as an SSH brute-force tool, similar to the botnet. First it checks its own integrity using\r\nMD5 hashes and contacts the C2 server (db.17kp[.]xyz) to compare its hash with the latest version. If an update is found,\r\nit downloads and replaces itself.\r\nhttps://www.darktrace.com/blog/pumabot-novel-botnet-targeting-iot-surveillance-devices\r\nPage 3 of 8\n\nFigure 3: Part of networkxm checking MD5 hash.\r\nFigure 4: MD5 hash\r\nAfter verifying its validity, it enters an infinite loop where it fetches a password list from the C2 (/getPassword), then\r\nattempts SSH connections across a list of target IPs from the /getIP endpoint. As with the other observed binaries, a systemd\r\nservice is created if it doesn’t already exist for persistence in /etc/systemd/system/networkxm.service.\r\nFigure 5: Bash script installx.sh.\r\nInstallx.sh is a simple bash script used to retrieve the script “jc.sh” from 1.lusyn[.]xyz, set permissions, execute and clear\r\nbash history.\r\nhttps://www.darktrace.com/blog/pumabot-novel-botnet-targeting-iot-surveillance-devices\r\nPage 4 of 8\n\nFigure 6: Snippet of bash script jc.sh.\r\nThe script jc.sh starts by detecting the operating system type Debian-based or Red Hat-based and determines the location of\r\nthe pam_unix.so file. Linux Pluggable Authentication Modules (PAM) is a framework that allows for flexible and\r\ncentralized user authentication on Linux systems. PAM allows system administrators to configure how users are\r\nauthenticated for services like login, SSH, or sudo by plugging in various authentication modules.\r\nJc.sh then attempts to fetch the current version of PAM installed on the system and formats that version to construct a URL.\r\nUsing either curl or wget, the script downloads a replacement pam_unix.so file from a remote server and replaces the\r\nexisting one, after disabling file immutability and backing up the original.\r\nThe script also downloads and executes an additional binary named “1” from the same remote server. Security settings are\r\nmodified including enabling PAM in the SSH configuration and disabling SELinux enforcement, before restarting the SSH\r\nservice. Finally, the script removes itself from the system.\r\nFilename: Pam_unix.so_v131\r\nmd5: 1bd6bcd480463b6137179bc703f49545\r\nBased on the PAM version that is retrieved from the bash query, the new malicious PAM replaces the existing PAM file. In\r\nthis instance, pam_unix.so_v131 was retrieved from the server based on version 1.3.1. The purpose of this binary is to act as\r\na rootkit that steals credentials by intercepting successful logins. Login data can include all accounts authenticated by PAM,\r\nlocal and remote (SSH). The malware retrieves the logged in user, the password and verifies that the password is valid. The\r\ndetails are stored in a file “con.txt” in /usr/bin/.\r\nFigure 7: Function storing logins to con.txt\r\nFilename: 1\r\nmd5: cb4011921894195bcffcdf4edce97135\r\nIn addition to the malicious PAM file, a binary named “1” is also retrieved from the server\r\nhttp://dasfsdfsdfsdfasfgbczxxc[.]lusyn[.]xyz/jc/1. The binary “1” is used as a watcher for the malicious PAM file\r\nusing inotify to monitor for “con.txt” being written or moved to /usr/bin/.\r\nhttps://www.darktrace.com/blog/pumabot-novel-botnet-targeting-iot-surveillance-devices\r\nPage 5 of 8\n\nFollowing the daemonize() function, the binary is run daemonized ensuring it runs silently in the background. The function\r\nread_and_send_files() is called which reads the contents of “/usr/bin/con.txt”, queries the system IP with\r\nifconfig.me , queries SSH ports and sends the data to the remote C2\r\n(http://dasfsdfsdfsdfasfgbczxxc[.]lusyn[.]xyz/api/).\r\nFigure 8: Command querying SSH ports.\r\nFor persistence, a systemd service (my_daemon.service) is created to autostart the binary and ensure it restarts if the\r\nservice has been terminated. Finally, con.txt is deleted, presumably to remove traces of the malware.\r\nConclusion\r\nThe botnet represents a persistent Go-based SSH threat that leverages automation, credential brute-forcing, and native Linux\r\ntools to gain and maintain control over compromised systems. By mimicking legitimate binaries (e.g., Redis), abusing\r\nsystemd for persistence, and embedding fingerprinting logic to avoid detection in honeypots or restricted environments, it\r\ndemonstrates an intent to evade defenses.\r\nWhile it does not appear to propagate automatically like a traditional worm, it does maintain worm-like behavior by brute-forcing targets, suggesting a semi-automated botnet campaign focused on device compromise and long-term access.\r\nThis report explores the latest trends shaping the cybersecurity landscape and what defenders need to know in 2025\r\nRecommendations\r\n1. Monitor for anomalous SSH login activity, especially failed login attempts across a wide IP range, which may\r\nindicate brute-force attempts.\r\n2. Audit systemd services regularly. Look for suspicious entries in /etc/systemd/system/ (e.g., misspelled or duplicate\r\nservices like mysqI.service) and binaries placed in non-standard locations such as /lib/redis.\r\n3. Inspect authorized_keys files across user accounts for unknown SSH keys that may enable unauthorized access.\r\n4. Filter or alert on outbound HTTP requests with non-standard headers, such as X-API-KEY: jieruidashabi, which may\r\nindicate botnet C2 communication.\r\n5. Apply strict firewall rules to limit SSH exposure rather than exposing port 22 to the internet.\r\nAppendices\r\nhttps://www.darktrace.com/blog/pumabot-novel-botnet-targeting-iot-surveillance-devices\r\nPage 6 of 8\n\nReferences\r\n1.     https://pumatronix.com/\r\nIndicators of Compromise (IoCs)\r\nHashes\r\ncab6f908f4dedcdaedcdd07fdc0a8e38 - jierui\r\na9412371dc9247aa50ab3a9425b3e8ba - bao\r\n0e455e06315b9184d2e64dd220491f7e - networkxm\r\ncb4011921894195bcffcdf4edce97135 - 1\r\n48ee40c40fa320d5d5f8fc0359aa96f3 - ddaemon\r\n1bd6bcd480463b6137179bc703f49545 - pam_unix.so_v131\r\nRSA Key\r\nssh-rsa\r\nAAAAB3NzaC1yc2EAAAADAQABAAABAQC0tH30Li6Gduh0Jq5A5dO5rkWTsQlFttoWzPFnGnuGmuF+fwIfYvQN1z+WymKQmX0ogZdy/CEkki3swrkq29K/xsyQQclNm8+xgI8BJdEgT\r\n@root\r\nNetwork\r\nhttp://ssh[.]ddos-cc.org:55554\r\nhttp://ssh[.]ddos-cc.org:55554/log_success\r\nhttp://ssh[.]ddos-cc.org:55554/get_cmd\r\nhttp://ssh[.]ddos-cc.org:55554/pwd.txt\r\nhttps://dow[.]17kp.xyz/\r\nhttps://input[.]17kp.xyz/\r\nhttps://db[.]17kp[.]xyz/\r\nhttp://1[.]lusyn[.]xyz\r\nhttp://1[.]lusyn[.]xyz/jc/1\r\nhttp://1[.]lusyn[.]xyz/jc/jc.sh\r\nhttp://1[.]lusyn[.]xyz/jc/aa\r\nhttp://1[.]lusyn[.]xyz/jc/cs\r\nhttp://dasfsdfsdfsdfasfgbczxxc[.]lusyn[.]xyz/api\r\nhttp://dasfsdfsdfsdfasfgbczxxc[.]lusyn[.]xyz/jc\r\nDetection Rule\r\nrule Linux_PumaBot\r\n{\r\n meta:\r\n   description = \"Rule to match on PumaBot samples\"\r\n   author = \"tgould@cadosecurity.com\"\r\n strings:\r\n   $xapikey = \"X-API-KEY\" ascii\r\n   $get_ips = \"?count=5000\" ascii\r\n   $exec_start = \"ExecStart=/lib/redis\" ascii\r\nhttps://www.darktrace.com/blog/pumabot-novel-botnet-targeting-iot-surveillance-devices\r\nPage 7 of 8\n\n$svc_name1 = \"redis.service\" ascii\r\n$svc_name2 = \"mysqI.service\" ascii\r\n   $uname = \"uname -a\" ascii\r\n   $pumatronix = \"Pumatronix\" ascii\r\n condition:\r\n   uint32(0) == 0x464c457f and\r\n   all of (\r\n     $xapikey,\r\n     $uname,\r\n     $get_ips,\r\n     $exec_start\r\n   ) and any of (\r\n     $svc_name1,\r\n     $svc_name2\r\n   ) and $pumatronix\r\n}\r\nSource: https://www.darktrace.com/blog/pumabot-novel-botnet-targeting-iot-surveillance-devices\r\nhttps://www.darktrace.com/blog/pumabot-novel-botnet-targeting-iot-surveillance-devices\r\nPage 8 of 8",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"Malpedia"
	],
	"references": [
		"https://www.darktrace.com/blog/pumabot-novel-botnet-targeting-iot-surveillance-devices"
	],
	"report_names": [
		"pumabot-novel-botnet-targeting-iot-surveillance-devices"
	],
	"threat_actors": [],
	"ts_created_at": 1775434753,
	"ts_updated_at": 1775791220,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/083df5bf97c2e3c3130c76a8acc8d8fbb64f7f2a.pdf",
		"text": "https://archive.orkl.eu/083df5bf97c2e3c3130c76a8acc8d8fbb64f7f2a.txt",
		"img": "https://archive.orkl.eu/083df5bf97c2e3c3130c76a8acc8d8fbb64f7f2a.jpg"
	}
}