The Miner Botnet: Bitcoin Mining Goes Peer-To-Peer

Identifying a botnet is not an easy task sometimes, especially when one gets lost in different components like droppers, infectors and other bad stuff. Some two weeks ago, Jose Nazario from Arbor Networks pointed me to a new varmint that appears to be another peer-to-peer bot. When executed, the program installs tons of stuff that holds a number of goodies, for example

• an executable hidden in an Alternate Data Stream,
• three Bitcoin miners: the Ufasoft miner, the RCP miner and the Phoenix miner,
• a file with geo-location information for IP address ranges.

However, we leave these aside for now and focus on the botnet’s architecture instead, which is really just a channel for pushing software to infected machines. Scrabbling about in the installed programs finally brought up the actual bot, which we detect as Trojan.Win32.Miner.h. The binary has some layers of obfuscation to make analysis harder but eventually writes a UPX packed executable into a memory section from where to original binary can be restored.

One of the first things that come to attention is a list of 1953 hard-coded IP address strings that are contained in the binary. These addresses are contacted by the bot during its bootstrapping phase in order to join the peer-to-peer network.

IP address list in the deobfuscated binary

To verify if a remote host is really part of the botnet, it is first probed on port 62999/tcp. Afer that, all subsequent communication with that host takes place over HTTP connections on port 8080/tcp. If a bot wants to receive a piece of information from the botnet, it sends a GET request for the URL /search=[resource] to another peer (see red part below). The response (shown in blue) contains the requested data. In the example below the bot asks if a file named ip_list_2 exists.

GET /search=ip_list_2.txt HTTP/1.1
Connection: close
Host: 67.230.63.171

0|8E2105CC235624452CF4CA5ED5880636

The remote peer confirms the existence of the file by sending back an MD5 hash of its content. A non-existing file or otherwise invalid request would have been indicated by the string null. To actually download the searched file, the .txt suffix is left out in the request:

GET /search=ip_list_2 HTTP/1.1
Connection: close
Host: 67.230.63.171

86.121.101.197
194.44.169.112
77.123.56.166
65.75.122.227
79.115.121.40
89.208.252.138
213.135.179.130
31.43.66.129
67.230.65.87
94.76.96.80
...

The response contains a list of IP addresses belonging to other peers in the botnet. This information is sufficient to recursively enumerate the peer-to-peer network, or at least the part of it that lives on public IP addresses. We crawled a part of the network and recorded the IP addresses we got back. A graph plot of the resulting data shows a highly interconnected network. The graph will soon get too big to render in reasonable time, thus we terminated our crawler after a few seconds. As a result, some nodes link to ‘dead ends’, peers that have not been followed further.

There are three separate host lists: ip_list, ip_list_2 and ip_list_3, however, during our tests the latter has always been empty. A run where we crawled the networks corresponding to the first two lists for seven hours resulted in 9.141 hosts for ip_list and 28.675 hosts for ip_list_2 with only 57 hosts being present in both lists — a total of almost 38.000 different public IP addresses. Taking into account that most machines are behind network address translation or some gateway nowadays, the real number of infected machines can easily be magnitudes bigger.

A bot may retrieve its Internet-facing IP address via /search=get_my_ip and check if it can be reached from the outside with /search=listen_test. Another interesting thing is the request for /search=soft_list, a list of executables:

GET /search=soft_list HTTP/1.1
Connection: close
Host: 91.124.141.114

1881|37055143655159895100072920[...]056290908384488867|iecheck12.exe|8|1
1864|74659789337208584676889842[...]363065321014216383|client_8.exe|24|0
1861|50130190106950587675951378[...]854716588011099242|w_distrib.exe|6|0
1859|17628191893358990544434624[...]934535221101899258|btc_server.exe|22|0
1855|70418953044346961647340893[...]411084368838550531|loader2.exe|2|0
1816|63902848972275419049312273[...]804891227296793639|loader_rezerv.exe|3|0
1714|71450190375046068004318922[...]621691365929209616|gbot_loader.exe|27|0
873|450976523626203858415918223[...]004413953350864628|resetsr.exe|14|0

This list contains a number of files that the bot will download from the peer-to-peer network and run. Again, it requests them by sending the file name as a parameter for a /search= request. Each file has a unique ID, the number before the first dash. The number string in the next field has been shortened in the above example for better readability. Its purpose is not known yet. Newer files seem to have higher ID numbers. For example, the files client_3.exe, client_4.exe, client_6.exe and client_7.exe which are not present in the software list but still available for download have ascending ID numbers:

• client_3.exe: 1555
• client_4.exe: 1596
• client_6.exe: 1607
• client_7.exe: 1611
• client_8.exe: 1864

Checking if new software is being distributed in the botnet is easy: all we have to do is download the software list and look for new IDs. We will continue to do so and add signatures for new bad things to our detection as they show up.