Attacking with Bitcoin: Using Bitcoin to Build Resilient Botnet Armies

Botnet armies act as a dispersed network of computers that are subject to the command of a single bot master [5]. The bot master manages the botnet via a command and control center which receives data from the botnet and issues further instruction sets from a command and control server. The command and control server usually is a single machine whose location is predefined within the botnet. Botnet armies typically require communication to be available between botnet machines and a command and control server (C&C) in order to receive instructions from a bot master. If this command and control server’s address is hard coded we can examine the malware and either find some way to shutdown communication, take down the C&C server, or alternatively takeover the server. An example of a defensive takeover was studied by Stone-Gross et. al. their research discusses the implications of a takeover on the Torpig botnet [8]. Torpig uses a domain name sequence to validate if a new C&C server was available. If the next domain name in the sequence resolved, the botnet connected to the new C&C server address. Torpig uses a relatively outdated methodology, however, the same issues and concept applies to today’s botnets.

In order to improve the resilience of the botnet, botmasters deploy more sophisticated and ‘dynamic’ communication with ‘floating [C&C] servers’ [5]. These use a range of different tactics, from DNS Resolution, or the more novel approach of custom code left behind social media pages [7], to IRC messages and P2P architectures. The immutability of blockchain is a critical feature that none of the current methods capture.

Implementation guidelines for blockchain based botnets have been scarce and typically have not been aimed at truly disseminating whether it is the right tool for the job. Notably, Omer Zohar’s ‘Unstoppable chains’ explains in detail, with smart contract examples, on how Ethereum (a similar protocol to Bitcoin) can be used to manipulate the behaviour of botnets [10]. The attacker is able to manipulate the actions of a botnet army by sending updates to the smart contract. These updates detail to the botnet where the next floating C&C is located [10]. Despite the title of the work suggesting that these chains are unstoppable, Zohar makes note of the complexities with coding Solidity smart contracts and how take downs and takeovers can easily be a side effect of poor coding practices in Solidity. Even simple contracts have been ruined through misuse or neglect of Solidity principles [10]. Our decision to focus on Bitcoin was determined by the sheer complexity of managing a production quality deployment of an Ethereum smart contract, the costs involved and the recently reported attacks such as [9].

Bitcoin had aimed at being the world’s first successful decentralised peer to peer cash systems. Bitcoin removed trusted third parties from the global financial system through the effective use of cryptography. By trusting cryptographic protocols instead of Banks, Bitcoin provided a viable alternative by leveraging code in order create new ’Bitcoins’ and reaching consensus on who owns what Bitcoin. The consensus algorithms effectively decide what transactions are valid and when valid they are then posted to the blockchain stored by full nodes. These full nodes are machines that hold a record of all transactions and verify new transactions that are broadcast. Bitcoin is compromised of Bitcoin core, JSON-RPC API and a P2P API. These both of these building blocks are essential to how communication occurs over the Bitcoin network.

Bitcoin core establishes the rules for setting up full nodes which are responsible for indexing all transactions to local databases and then verifying that transaction inputs originated from unspent transaction outputs¹¹1https://github.com/bitcoin/bitcoin. It is responsible for the rules that govern how full nodes communicate with one another. The collection of transactions held by other full nodes, and ability to create new addresses and transaction hashes is governed by the JSON-RPC API, whereas the communication between nodes is handled by the P2P API²²2https://bitcoin.org/en/p2p-network-guide. The distinction between using JSON-RPC and using P2P is of significant importance. In the case of JSON-RPC we need authentication credentials in order to use this API and we would be connecting directly to an individual full node, instead of leveraging the entire network of Bitcoin full nodes. If we focus on JSON-RPC our communication is centralised to a single full node and will therefore not be harnessing the full decentralised capabilities of the Bitcoin blockchain. Instead, Bitcoin P2P allows our botnet to ’pretend to be a full node’ allowing it to sync with specific blocks on the blockchain and retrieve near-arbitrary data with no credentials.

Bitcoin makes use of OP codes in transactions in order to decide whether certain transactions are more than ’simple transactions’. Some of these OP codes stored on the Bitcoin blockchain allow for certain non-Turing complete actions to be handled when a transaction is processed. More specifically, OP_Return allows us to add up to 80 bytes of arbitrary data. This is more than enough data for us, given that most IP addresses consist of 32 bits and 4-5 bits for a port number [2]. With the ability to store IP addresses, we have the ability to create a communication protocol for our floating Command & Control servers.

A bind or reverse shell establishes connection with a remote listener from the infected device. Dynamic shells have the capability to interpret commands from the listener and alter their behaviour based on those commands. An attacker can use any available, or hand crafted tool in order to create a dynamic shell. However, using tools like Meterpreter the management of shells becomes incredibly easy, even for the unskilled attacker. In the case of Meterpreter, shells can either be staged or ’stageless’ with their distinction being the approach that the main payload is loaded into the device. Staged payloads refer to a payload which only has instructions for an initial connection, the rest of the malicious payload is returned after the victim connects to the Meterpreter listener. Stageless payloads refer to a payload presented upfront in full. We have opted for using the stageless (or single) ‘reverse TCP’ payload available in the Metasploit framework. The details of the payload and its matching listener used for our implementation are included in Appendix 0.A.

Furthermore, Meterpreter supports the ability to load a live Python interpreter onto the victim. This can then be used to load Python code after the attacker gains access to the machine. This does not require Python to be installed on the device. Using Meterpreter bindings in our Python code we are able to dynamically adjust the transport configuration of the shell session. Importing the script in Appendix 0.C within our meterpreter session results in a passive C&C server which we can then aim to manipulate in the subsequent sections through blockchain transactions.

With the prepared malware payload we can now focus on ’discovering new C&C servers’. To manage this using the Bitcoin blockchain we are required to leverage the ’ScriptPubKey’ options available within the Bitcoin Core transaction outputs [2]. These options provide ’OP codes’ to the transaction that signify certain transaction ’contexts’. We used the ’OP_Return’, an OP code that allows us to signify a transaction output as invalid or void and simultaneously write up to 80 bytes of data into the blockchain, which allows us to write an IP address and a port for which our bot can connect to.

In order to manipulate transaction data with granularity there is a requirement to host a full node with capable JSON RPC access. This required installing a Bitcoin Core full node, connecting to the Testnet and crafting a raw transaction.

Crafting the raw transaction involves listing the unspent Bitcoin for the required wallet address (listunspent), creating the raw transaction data locally on the full node (createrawtransaction), signing the transaction with the wallet private keys (signrawtransactionwithwallet) and then broadcasting this to all other full nodes (sendrawtransaction). The command-line arguments used for crafting the raw transactions are listed in Table 1.

At this point, we need to communicate with the Bitcoin blockchain in order to read the transaction hash outlined in Table 1. This may be achieved either through Blockchain explorers or directly from a full node.

These strategies both have quite peculiar positives and negatives when considering the implications on our decentralised botnet. This decision has a strong impact on the botnets ability to be genuinely ’decentralised’. A decentralised botnet requires a truly decentralised way of processing transactions in order to be truly censorship resistant. Block explorers should not considered as decentralised as they are often hosted on centralised servers with potentially mutable copies of our immutable blockchain. The transactions that are validated by Bitcoin full nodes are stored in a database and can be indexed when blockchain explorers are queried. An example of this can be seen in Appendixs 0.D. Full code available at https://github.com/dummytree/blockchain-botnet-poc.

This approach avoids the complexities of dealing directly with the blockchain, however if these centralised servers are compromised, so too is our botnet. Appendix 0.E shows the basic structure of the required for communication in order to create a truly decentralised data fetching process. This code outlines how a connection should be created to a full node, how data is formulated for each message type and how the parsing of the data is managed. The fundamental idea behind Bitcoin is that full nodes can potentially lie about what transactions have been verified, however in order to gain consensus one would have to ’convince’ over 51% of the Bitcoin network in order to publish false data to the blockchain. Much in the same way, our decentralised botnet can establish trust with multiple full nodes in order to obtain a trusted source of information rather than relying on a single node.

Our Bitcoin based botnet emulates other full nodes in order to simulate parts of the Bitcoin node blockchain sync process. By creating the handshake, exchanging version support messages it is then able to request for blocks. After receiving the required block we are then able to parse through the block and extract ’inventory items’, which in the case of a block is actually the transactions posted permanently to the blockchain. Each transaction may or may not contain an OP_Return value which we are analyzing.

We can therefore examine the blockchain and determine whether there is an OP_Return involved that has any data aimed for our botnet. If this was the case, we parsed this input and added this to our Meterpreter dynamic shell’s transport as explained in Appendix 0.C. As discussed in the following section, while our proof of concept clearly proves feasibility of this attack, it can be improved further to make the blockchain-based botnet more resilient and censorship-resistant.