Darktrace Security Researchers have identified a custom Go-based Linux botnet named PumaBot targeting embedded Linux 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 establishes persistence using system service files.
Darktrace’s advisory provides a breakdown of its key functionalities and explores binaries related to the campaign, including:
Filename: jierui
md5: cab6f908f4dedcdaedcdd07fdc0a8e38
The Go based botnet gains initial access through bruteforcing SSH credentials across a list of harvested IP addresses. Once it identifies a valid credential pair, it logs in, deploys itself, and begins its replication process.
The domain associated with the C2 server did not resolve to an IP address at the time of analysis. The following details are a result of static analysis of the malware.
The malware begins by retrieving a list of IP addresses of likely devices with open SSH ports from the C2 (ssh.ddos-cc[.]org) via the getIPs() function. It then performs brute-force login attempts on port 22 using credential pairs also obtained from the C2 through the readLinesFromURL(), brute(), and trySSHLogin() functions.
Within trySSHLogin(), the malware performs several environment fingerprinting checks. These are used to avoid honeypots and unsuitable execution environments, such as restricted shells. Notably, the malware checks for the presence of the string ‘Pumatronix’, a manufacturer of surveillance and traffic camera systems, suggesting potential IoT targeting or an effort to evade specific devices.
If the environment passes these checks, the malware executes uname -a to collect basic system information, including the OS name, kernel version, and architecture. This data, along with the victim’s IP address, port, username, and password, is then reported back to the C2 in a JSON payload.
Of note, the bot uses X-API-KEY: jieruidashabi, within a custom header when it communicates with the C2 server over HTTP.
The malware writes itself to /lib/redis, attempting to disguise itself as a legitimate Redis system file. It then creates a persistent systemd service in /etc/systemd/system, named either redis.service or mysqI.service (note the spelling of mysql with a capital i) depending on what has been hardcoded into the malware. This allows the malware to persist across reboots while appearing benign.
[Unit]
Description=redis Server Service
