F5 threat researchers detected attackers actively exploiting the rTorrent client through a previously undisclosed misconfiguration vulnerability and deploying a Monero (XMR) crypto-miner operation.
- The rTorrent client misconfiguration vulnerabilities include:
- No authentication required for XML-RPC communication
- Sensitive XML-RPC method is allowed (direct OS command execution)
- Attackers are actively exploiting this vulnerability in the wild by scanning the Internet for exposed rTorrent clients
- Attackers are using the exploited systems to mine Monero crypto-currency
- The malware is hosted on the hidden TOR network; the Tor2Web “gateway” is used to access it
- Currently only 3 of 59 anti-virus agents detect the malware file
- The campaign employs evasion techniques
- The campaign is possibly connected to the Zealot Monero mining campaign from late 2017
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.
Figure 1: Reconnaissance XML-RPC request to get list of downloaded torrents
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.