University of Amsterdam

MSc System and Network Engineering

Offensive Technologies

Using the BitcoinBlockchain as a BotnetResilience Mechanism

Authors:

Tom Currantom.curran@os3.nl

Dana GeistDana.Geist@os3.nl

May 27, 2016

Abstract

In this report we describe a communication channel that uses the Bitcoin blockchainto migrate botnet infrastructure. This is achieved by exploiting a feature that permitsthe storage of arbitrary data within Bitcoin transactions. Our research is divided intotwo phases. We begin with a review of common resilience mechanisms deployed in typicalbotnet architectures, identifying their advantages and disadvantages. We then outlinethe design and implementation of blockchain-based mechanism that could complementexisting techniques. A proof-of-concept is used to show such a scheme is practical and canprovide a botnet with an additional layer of resilience and covertness in comparison toother architectures. Finally, we analyse our solution and propose mitigation techniqueswhich could be used to deactivate such a botnet. Though our research targets theBitcoin blockchain, its principles should extend to other blockchain implementations,provided they permit the storage of arbitrary data.

Contents

1 Introduction 21.1 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . 21.2 Research Questions . . . . . . . . . . . . . . . . . . . . . . . 21.3 Related Work . . . . . . . . . . . . . . . . . . . . . . . . . . 31.4 Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31.5 Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

2 Methodology 5

3 Background 63.1 Botnets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

3.1.1 Architectures . . . . . . . . . . . . . . . . . . . . . . 63.1.2 Attacks against botnets . . . . . . . . . . . . . . . . 63.1.3 Resilience mechanisms . . . . . . . . . . . . . . . . . 8

3.2 Blockchains . . . . . . . . . . . . . . . . . . . . . . . . . . . 93.2.1 Transactions . . . . . . . . . . . . . . . . . . . . . . 93.2.2 Transaction Structure . . . . . . . . . . . . . . . . . 103.2.3 Scripts . . . . . . . . . . . . . . . . . . . . . . . . . . 113.2.4 OP RETURN . . . . . . . . . . . . . . . . . . . . . . 113.2.5 Resiliency of the Bitcoin Blockchain . . . . . . . . . 11

4 Architecture 12

5 Implementation 145.1 Botnet implementation . . . . . . . . . . . . . . . . . . . . . 175.2 Blockchain implementation . . . . . . . . . . . . . . . . . . 17

5.2.1 Storing Data via OP RETURN . . . . . . . . . . . . 185.2.2 Sending the transactions . . . . . . . . . . . . . . . . 195.2.3 Retrieving the data . . . . . . . . . . . . . . . . . . . 19

5.3 Design Considerations . . . . . . . . . . . . . . . . . . . . . 19

6 Discussion 21

7 Conclusion 22

8 Ethics 23

9 Limitations 24

10 Future Work 25

1

1. Introduction

Botnets continue to grow in both size and sophistication, representing an ever-increasing threat on the Internet. A botnet is a network of compromised machinesthat are remotely controlled by a botmaster. Once infected, a machine will connect to anetwork of other compromised machines where it awaits instructions from the botmas-ter. The number of victim machines often reaching tens of thousands, grants botmastersaccess to large pools of resources; often used for malicious activities such as distributingspam, launching distributed denial-of-service attacks, and harvesting sensitive informa-tion.

Naturally, the crucial component of a botnet is its communication infrastructure,where commands are distributed and sensitive data exfiltrated. Attempts to disman-tle botnets usually aim to disrupt or hijack communication channels between bots andthe command & control servers (C&Cs). As there have been several successful take-downs, botnet architectures continue to evolve and develop features to make them moreresistant.

At the same time, there has been a significant growth in interest in Bitcoin andthe “Blockchain” technology that underpins it since its inception in 2008 [Nak08]. Ablockchain is a distributed computing architecture where network nodes execute andrecord the same transactions, grouped into blocks. The blockchain is secured by meansof strong cryptography and consensus across the network. Though Bitcoin was the firstimplementation of such technology, offering a distributed ledger system, there have sincebeen many more blockchain implementations [But14] [Lit16].

Designed to be tamper-proof, uncensored, and always available, the ability to storearbitrary information on a blockchain presents interesting use-cases within a resilientbotnet architecture. In this paper we explore a use-case for the blockchains to covertlymigrate botnet infrastructures.

1.1 Motivation

Botnets are becoming more resilient and accessible, whilst new technologies suchas Bitcoin present new opportunities for cybercriminals to conduct malicious activities.Underground marketplaces offering botnet-related services on the dark web lower thebarriers to entry for less sophisitcated cybercriminals.

It is clear that cybercriminals like Bitcoin. It’s rising price, ease of movement, andperceived anonymity features make it an attractive currency. In the recent past wehave seen hacked cryptocurrency exchanges, ransomware authors demanding paymentin Bitcoin, as well as botnets that use their victims machines to mine Bitcoins [Gre14].

As we continue to roll-out and depend upon Internet-connected devices in our dailylives, it is important to better understand the potential misuse of new technologies inorder to help prevent their abuse in the future.

1.2 Research Questions

Given the arguments described in 1.1, we propose the use-case for the blockchain asa fall-back mechanism in a command and control infrastructure.

Our main research question is: Can the Bitcoin blockchain be used as a resiliencemechanism in botnets?

2

In order to answer this question, we will address the following subquestions:

1. What techniques are currently employed to create resilient botnet infrastructuresand what are their pitfalls?

2. Could the Bitcoin blockchain be used to complement those techniques?

3. What are the implications of building such an infrastructure? Are there anymitigations that defenders can put into practice?

1.3 Related Work

The structure and operation of botnets has been extensively researched. Existingliterature covers almost all aspects ranging from their detection on networks, counter-measures to disrupt them, and network topologies that could make them more robust.

In [And+13] [SNK09], researchers reverse-engineered the protocols of the Waledacand Gameover Zeus botnets. It is clear from their work that the designers of thesebotnets considered how resilient their structures would be to external attacks; usingmethods such as Domain Generation Algorithm and Domain Fast fluxing to ensure thatbots can always contact a host.

There is currently one paper that focuses on the intersection between blockchainsand botnets. In [Ali+15], researchers implemented a command & control infrastructurethat utilised the main Bitcoin network. Each bot is hardcoded with the public keyof the botmaster and equipped with a light-weight Bitcoin client wallet. Bots receivetransactions from the botmaster and verify their authenticity before they are finallydecoded and executed. Though a working implementation was created, we identifiedsome limitations with this implementation.

Firstly, as bots are hard-coded with the public key of the botmaster, the same publickey is used to generate each of the botmaster’s bitcoin addresses used in transactions.When making a payment using Bitcoin wallet software, the outputs of smaller trans-actions that the botmaster owns will be aggregated until they are either equal to orgreater than the total amount to be sent. With all addresses originating from the samepublic key, linkability between bitcoin addresses used by the botmaster is inevitable.

All communication between the bots and the botmaster take place over the blockchain,thus everything is stored permanently and is openly visible to users of the network. Eventhough data is first encoded, it would be only a matter of time before a researcher dis-covers the relevant bot binary and uses it to develop a decoder. From this point on,past and current communication can be deciphered.

1.4 Scope

The aim of this paper is to research the viability of using the blockchain as a meansof providing botnet resiliency. The focus is on the advantages the blockchain provideswhen migrating a botnet infrastructure. It is not our objective to build a functioningbotnet beyond what is necessary to perform our research and implementation as a proofof concept.

1.5 Structure

The remainder of this paper is structured as follows. In the next chapter we discussour methodology. In Chapter 3, we provide an overview of the main pillars of our

3

project: botnets and blockchains. In Chapter 4 we present our design and architecture,followed by a description of our implementation in Chapter 5. The results are discussedin Chapter 6, and our conclusions are reviewed in Chapter 7. Ethical aspects are takeninto consideration in Chapter 8. Finally, we discuss the limitations of our research inChapter 9 and elaborate on future work in Chapter 10.

4

2. Methodology

This project researches whether it is possible to provide botnet resilience using theblockchain. We focus on centralised botnet architectures as these are simpler to analyseand implement. However, as we will see in Section 6, the concepts presented could beextended to work for P2P botnets as well.

As mentioned in Section 1.3, one way of using the botnet by means of the blockchain,is to implement a model in which the C&C sends commands through Bitcoin transac-tions. This would make the botnet difficult to take down as the blockchain is known tobe a resilient network. However, this approach presents disadvantages as discussed inSection 1.3. For this reason, we designed a new model in which there is one active C&Cat a time, but several passive ones that can take over in the event that the active C&Cis compromised. This way, instead of using Bitcoin transactions to send commands tothe bots, they are only used to inform the bots to connect to a new C&C. With thisapproach we aim to reduce the botnet’s exposure to a public blockchain.

In order to implement this model we went through two phases. We first focused ondesigning the architecture of the system. In this phase we designed the general structureand defined the different components and their interactions. We then focused on theimplementation of the model. This phase consisted of selecting the proper tooling andcreating a proof of concept that could show the inner workings of the system. Finally,we analysed the solution proposed and discussed its advantages and disadvantages, aswell as identifying possible mitigation techniques.

5

3. Background

3.1 Botnets

A botnet is a network that consists of infected hosts usually called bots. These areprograms with specific behavioural characteristics, which are hosted on victim machines.There are many variations of bots and these provide different functionality, usuallytailored for some specific purpose. However, common modules they implement are theuploading/downloading of files, port scanning and taking screenshots.

Bots are generally distributed via infection mechanisms such as a drive-by download,which installs them on the victim machine, without the owner’s consent or knowledge.Botnets generally use well-known protocols and implement encryption so as to avoidbeing detected. The network is controlled by a human, called botmaster, who uses theC&C as an intermediary to contact bots, and accomplish different attacks such as DDoS,fraud or espionage.

3.1.1 Architectures

Throughout the history of botnets, different models have been created to accommo-date botmasters’ demands, as well as to withstand takedown attempts. These modelscan be categorized based on their architecture, which is highly dependent on the waythe commands are spread to the bots.

The first and simplest architecture is a centralized one. In this case there is one C&Cserver which is used by the botmaster to distribute commands to the bots. Figure 3.1shows a diagram of such an architecture. These type of C&Cs are usually implementedby means of widely used protocols such as HTTP, IRC and POP3 [MNM15]. The mainweakness of this architecture is that the C&C constitutes a single point of failure. If theC&C is taken down, the botnet is deactivated.

In response to this problem, attackers designed peer-to-peer (P2P) botnets in whichcommands are not directly sent to all bots by the C&C, but spread by means of a P2Pprotocol. The idea is that each bot in a P2P botnet is able to receive commands aswell as send them to other bots in the network. This way, the single point of failure isremoved, as there is no need for a central point to coordinate the command spreading.However, there have been measures developed to detect and take P2P botnets down.Such methods are generally based on detecting the bots bootstrapping mechanisms aswell as enumerating the network’s topology once a connected bot is captured.

Weaknesses in traditional P2P botnets, such as poorly designed bootstrapping mech-anisms, have encouraged attackers to consider more complicated and resilient architec-tures. Examples of such architectures are hybrid P2P botnets, which aim to address theidentified limitations in traditional P2P botnets [WSZ10].

3.1.2 Attacks against botnets

The first step in taking a botnet down is detecting it. Detection can be implementedusing signature-based systems or anomaly-based systems. Though signature-based sys-tems are generally considered to be simple, effective, and efficient, they can not detectunknown threats. For this reason it may be more convenient to use anomaly-basedmechanisms, which focus on analysing the system’s behaviour. The analysis could beperformed on different layers such as network, host and even on a global scale in which

6

Figure 3.1: Centralized C&C architecture [MNM15]

the component interactions are observed rather than analysing parts of the system in-dividually [MNM15].

The second step, once a botnet has been detected, is to understand its inner work-ings. It is important to determine key features of the botnet such as its architecture,communication protocol and the encryption algorithms being used (if any). A commonstrategy is to set up a honeypot and let a test machine get infected. The next step isto study the bot’s behaviour through extensive monitoring of its activities. In addition,it is also important to reverse engineer the bot binary, which could drastically improvethe knowledge about the botnet, yielding insights on encryption algorithms, protocolsand concealing mechanisms being used.

The final step is to take the botnet down. The techniques used for this purposeare highly dependent on the architecture and specific characteristics of the botnet. Ingeneral, we can identify two approaches. The first is focused on disabling the bots thatconstitute the botnet. However, this approach could be cumbersome if not impossible torealize, especially when dealing with large botnets. Nevertheless, targeting the bots is ameasure that needs to be addressed in an organization so as to eliminate the infection.

The second approach focuses on disrupting the command distribution channels. Thiswould mean targeting the C&C server in centralized architectures, whilst targeting thecommunication channels in a P2P botnet. Both approaches are similar in the sensethat both of them attempt to disrupt the communication between bots and botmaster[Wan+15].

In centralized architectures, one option is to block the C&C channel completely.However, this is not always an option as common protocols such as HTTP are used andthey cannot simply be shut down without disrupting the victim machine’s normal usage.A different approach would be trying to change the C&C’s command in an attempt tobreak the protocol and deactivate the command being sent to the bot. Even though

7

this solution could work, it fails to eliminate the root cause and will most likely lead toperformance loss. One could also block the C&C’s IP address, which is a simple andeffective solution as long as the C&C has not moved to another IP. Finally, one can tryto take control over the C&C so as to completely deactivate the entire botnet. Althoughthis solution is effective, it is not easily achievable, even when ignoring the legal andethical concerns that must be taken into account before doing so.

In decentralized P2P botnets, the bootstrap mechanism is usually used to enumeratethe different bots within the botnet, exposing the entire network. As each of thesebots are used to propagate commands, deactivating each of them would lead to thedeactivation of the botnet as a whole. In addition, defenders can try to poison thebotnet using aforementioned honeypot techniques. With this approach, the honeypotmachines will be part of the peer lists of many bots, thus reducing the number of real botsin the network, or even issuing commands to netutralise malicious activities [WSZ10].

3.1.3 Resilience mechanisms

In reaction to several known attacks designed to take botnets down, botmastersengineered different resilience mechanisms to withstand them. As mentioned beforeattacks are architecture-dependent, as are their resilience mechanisms. The focus ofthis research is in centralized architectures. However, we think it is relevant to includesome known resilience mechanisms used by P2P botnets.

In centralized architectures the key component that the botmaster needs to protectis the C&C. As mentioned before, the control server constitutes a single point of failureso all the efforts are placed in protecting it as much as possible. In this paper we willmention some of the defensive techniques that have been created for this purpose.

One of methods consists of using the Tor network to anonymize the C&C’s identity.The idea is to include all C&C communication inside Tor, so the C&C is harder to trackand thus more difficult to take down. Although this technique sounds appealing, it hassome drawbacks worth considering. Firstly, Tor platform has some vulnerabilities thatcan result in the deanonymisation of a certain service, perhaps resulting in the C&C’sdiscovery. In addition, the use of this technique adds overhead to the Tor network,which could result in bots being less responsive [CM14].

A common mechanism that centralized botnets implement is a Domain GenerationAlgorithm (DGA). The basic idea is to generate many random domain names, that willbe used as rendezvous points in which the bots will be able to communicate with theirC&C to receive commands. In practice, the C&C generates these domains and registersthem, so then the bots, using the same generation algorithm, can connect to each ofthe domains in a pre-defined sequence. Although this is a widely used method, thesealgorithms can be defeated in several ways. One example is proposed by [Sch+14]. Itinvolves looking into DNS NXDomain traffic so as to filter domains that are generatedalgorithmically by botnets.

P2P botnets have developed several mechanisms to address the identified weaknesses.One of these mechanisms is intended to thwart enumeration. A key aspect of bots thatenable the use of enumeration techniques is the ability for the bot to uniquely identifypeers. However, as shown in [Ros+13], not all protocols use unique identifiers, whichmakes enumeration more difficult, decreasing their effectiveness. An example of thissituation could happen when multiple bots share the same IP address as they are behindthe same NAT. In this case the enumeration could be underestimated. Conversely, botscan constantly change their IP addresses while crawling, in which case enumerationcould be overestimated.

Decentralised botnets can also defend against peer-poisoning by properly authen-ticating the commands sent to the P2P network. However, this is not a trivial task.

8

Finally, common techniques such random padding are used to avoid signature baseddetection systems [Ros+13].

Resilience techniques are very important to keep botnets alive. This is the reasonwhy they have been engineered and implemented over time. Even though they arenot infallible, they considerably increase the time and difficultly defenders face whenattempting to take them down. In these context, it becomes relevant for researchers toenumerate and understand resilience techniques so as to be able to thwart them.

3.2 Blockchains

There is a distinction between a blockchain and the Bitcoin blockchain, thoughthey are sometimes perceived as the same thing. Bitcoin is a distributed ledger forstoring economic transactions between users. To do this, it makes use of a blockchain,which is the distributed database responsible for maintaining the growing list of records.Records are stored within blocks by miners, who take cryptographic hashes of eachblock. As every miner records all transactions propagated to the network, consensuscan be reached across nodes through the comparison of block hashes, hardening thedata against tampering and revision.

Numerous blockchains exist, however the Bitcoin blockchain holds the largest marketcapitalisation as of today at around $7 billion [coi16b]. The number of daily transactionsrecently peaked at 276,000 in February 2016 [Blo16]. In addition, a plethora documen-tation of documentation is available online to learn how to interact with the Bitcoinblockchain using clients or APIs.

A full exposition of the protocol is beyond the scope of this paper, to learn moreabout Bitcoin there are plenty of online resources [Wik16] [Ant14]. What follows is adescription of the aspects relevant to our research.

3.2.1 Transactions

Ownership of bitcoin is proven by possession of the cryptographic key capable of“unlocking” the unspent output from a previous transaction. Transactions representingthe transfer of bitcoin ownership from one address to another.

In order to make a successful transaction, the sender must include the bitcoin addressand public key of the recipient, as well as the addresses with which he intends to fundthe payment. Ownership over these addresses is proven by cryptographically signingthe transaction with the private key that matches the public key from the fundingtransaction. A simplified example of a transaction is presented in Figure 3.2.

Owner 1 will create a transaction that includes the address and public key of Owner2, as well as the source transaction from which he wishes to make the payment. Thisinformation is then hashed and signed by the private key associated with the sourcetransaction. A transaction is validated by the first node it connects to on the network.This node will retrieve the public key associated with the transaction and use this toverify the signature. If the transaction is validated successfully, it is then broadcastacross the network and recorded in the blockchain. Owner 2 can now spend the receivedfunds by including the a reference to this transaction, along with the destination address,and cryptographically signing this new transaction with his private key.

Transaction messages are created client-side and then sent to any of the nodes con-nected to the Bitcoin network. Transactions will then be validated and, if successful,propagated to other nodes connected to the network to be stored in their copies of theblockchain.

9

Figure 3.2: An example bitcoin transfer [Nak08]

3.2.2 Transaction Structure

A transaction is a data structure that encodes information about the transfer. Thesource(s) of the funds to be sent is stored as inputs whilst the destination(s) are storedas outputs.

Spendable funds held from previous transactions are known as unspent transactionoutputs (UXTO). These are indivisible units of bitcoin that can be used as inputs to newtransactions. If a UXTO is used to pay for a transaction of lesser value, the sender willinclude one or more change addresses as additional outputs. These are simply addressesunder the sender’s control and are used to receive the funds in excess of the desiredpayment.

Figure 3.3: Unspent transaction outputs

In Figure 3.3, Bob and Charlie pay Alice 1 and 0.5 BTC, respectively. The sources of

10

these funds are added as inputs to each of the transactions and Alice’s wallet is includedas an output. Later, Alice wishes to send Dan 1.2 BTC. To reach this amount she willinclude the UXTOs from the previous transactions as inputs, amounting to 1.5 BTC.As outputs, she will include Dan’s address and one of her own addresses to receive the0.3 BTC “change”.

For a user to track his total balance, bitcoin wallet software will aggregate all of theUXTOs associated with a list of addresses within that user’s wallet.

3.2.3 Scripts

Bitcoin uses a scripting system for transactions. They are a list of instructionsrecorded with each transaction that describe what conditions must be met for the nextperson wishing to spend the bitcoins (e.g. bitcoin address and a corresponding signa-ture).

Scripts make use of a number of opcodes to provide the flexibility to change the pa-rameters required to spend transferred bitcoins. For example enabling multisig wallets,where any n of m private keys can be used to spend a certain UXTO.

3.2.4 OP RETURN

The OP RETURN opcode is one such script and has been included in the Bitcoinprotocol since version 0.9 [bit16]. It is used to mark a transaction output as invalid.The data included after the OP RETURN is irrelevant to making payments and allowsthe storage of arbitrary data. Currently, default Bitcoin clients will relay transactionscontaining OP RETURN transaction outputs that are up to 40 bytes in total.

The ability to store arbitrary data in the blockchain has been used by a number ofprojects for means beyond recording transactions. For example, Factom [Fac16] enablesusers to embed a permanent, time-stamped record of data in the blockchain offeringproof of existence.

3.2.5 Resiliency of the Bitcoin Blockchain

The bitcoin network consists of thousands of nodes. Each node stores a copy ofthe blockchain, providing resilience against the failure of one or more nodes. Incentivesprovided through mining bitcoin ensures (to an extent) that there will always be multipleminers storing a copy of the blockchain and able to process new transactions. The morenodes that join the network, the more resilient the network becomes. Today, there areapproximately 5,700 geographically distributed nodes supporting the network [21c16].

Links between the cryptocurrency space and traditional banking infrastructure in-crease the number stakeholders and provide a greater incentive for network stability.Services such as Cryptopay [Cry16] that enables users to load debit cards with Bit-coin and convert them into fiat on-the-fly, and the growing number of cryptocurrencyexchanges, lower the barriers to entry for accessing the market.

Of course, the Bitcoin project is still an experiment and its future has yet to bedetermined. Unforeseen events could disrupt the network or bring it down indefinitely.Nevertheless, the use-cases for distributed consensus architectures will grow with thenumber of devices being connected to the Internet. In this respect, blockchains willlikely stay. The principles from using the Bitcoin blockchain (i.e. the ability to storearbitrary data) could apply to other blockchains, making them also a suitable means ofcommunication.

11

4. Architecture

The first phase of the research consisted of designing the architecture of the system.In order to do so, we considered a layered approach, in which the bottom layers are thetraditional components of a centralised botnet such as the C&C and the bots. Besidethe active C&C, we included other passive C&Cs which are prepared to take over incase the active C&C is compromised or blocked.

On top of this traditional botnet infrastructure, we introduced a new layer calledorchestrator. The orchestrator is a key component of the system, as it is in charge ofmonitoring the health of the active C&C server, and acting upon any disruptions. Thegeneral idea is this: if the orchestrator discovers that the active C&C server is down, itwill issue a bitcoin transaction to the blockchain, with the IP information of the C&Cthat is going to take over. This transaction is going to be read by the bots, which willthen redirect their command requests to this newly appointed C&C. This architectureis depicted in Figure 4.1.

Figure 4.1: System Architecture

12

The next step in the design process was to decide on the botnet architecture. Asmentioned before the choice was to work with centralised botnets. This design is easier todeploy and manage in comparison to P2P botnets, in which bootstrapping mechanismsand P2P protocols need to be dealt with.

There are several ways of implementing a centralised botnet based on C&C-botcommunication. Botnets tend to implement widely used protocols in order to maketheir traffic less obvious and more difficult to detect. The most common options whenit comes to picking protocols are HTTP and IRC.

IRC implementations are highly suitable for creating botnets. The procotol is sim-ple, flexible and scales well. It also provides availability capabilities, which makes itattractive for botmasters. In addition, because of the nature of the protocol, bots canrespond to commands the C&C sends, as well as request commands. In spite of theseadvantages, the IRC protocol presents some disadvantages. First of all traffic is gen-erally not encrypted, which could give insight into the inner workings of the botnetonce it is discovered. Secondly, IRC traffic may be blocked in corporate environments,which reduces the effectiveness and reach of the botnet. For this reason, we decidedto chose an HTTP-based implementation. Even though it does not give the possibilityfor the botmaster to initiate the communication with the bots, HTTP is a widely usedprotocol, which scales well. In addition, it is commonly used in combination with certifi-cates, which provides a means of implementing encryption through TLS/SSL protocols[MNM15].

13

5. Implementation

This chapter discusses details about the proof of concept (PoC) that was created toshow how the proposed method could be carried out in practice. In addition, implemen-tation gave interesting insights on different aspects of the architecture such as feasibility,weaknesses and limitations.

For the implementation of this PoC, we decided to work on Linux platforms, morespecifically Ubuntu 15.10 operating system [Ubu16]. In addition, we chose to programusing Python 2.7 [pyt16], in order to ease the rapid development to adhere to theinherent time constraints of this project. As per the architecture explained in Chapter4, the implementation consists of three main components (python scripts):

• C&C: HTTP-based command and control server.

• Bot: agent deployed on a victim host, which is going to connect periodically tothe C&C so as to get commands.

• Orchestrator: top layer component of the architecture, in charge of monitoringC&C’s health and triggering the infrastructure migration.

The orchestrator and the bots interact indirectly and asynchronously through theblockchain to achieve the rollover of the botnet in case the active C&C is find to bedown. Whenever the orchestrator detects that failure, it contacts another passive C&Cand checks whether it is alive. If it is not alive it selects another from a pre-defined listuntil one alive is reached. At this point the orchestrator already knows which one isgoing to become the new C&C, so it publishes a transaction in the blockchain with theIP address of it. After sending the transaction, the orchestrator gathers a new bitcoin

address, public key pair, and communicates it to the new C&C, so the bots havetheir next address to follow. This process viewed from the orchestrator’s perspective isshown in Figure 5.1. Details about the transaction and the information encoding withinit are discussed in depth in Section 5.2.

If we look at it from the Bot’s perspective, we will see that the bot tries to commu-nicate with its active C&C in order to retrieve a command. If the bot realises the C&Cis down, it knows a rollover needs to happen, so it will try to parse the new bitcointransaction sent by the orchestrator. This way it can redirect its requests to the newC&C. It is important to note that the first command the bot receives from the C&C isgoing to tell it to update its bitcoin information. After that first contact has been made,the bot can start retrieving normal commands. Figure 5.2 displays the interactions fromthe bot’s point of view.

14

Figure 5.1: Orchestrator interaction diagram

15

Figure 5.2: Bot interaction diagram

16

5.1 Botnet implementation

There are several publicly available implementations of HTTP-based botnets, whichprovide both C&C and bot code. Nonetheless, most of them are targeted for Windowssystems. In addition, only a subset of those implementations are available in python.Ares, is a python remote access tool [KL16], which basically implements two programs:

• A C&C server based on CherryPy [che16], which provides a web interface for thebotmaster to administrate the bots.

• A bot program, which runs on a compromised host and communicates with theC&C.

The C&C server provides a web interface for the botmaster to communicate withthe bots. When it is first initiated, the server requires an administrative password tobe set to ensure no other third party is able to access the C&C. This password needsto be long and complex enough so as to reduce the likelihood of a successful brute forceattack.

Once the password is set, the server presents the botmaster with a status page,displaying information about the bots connected to it. Information is kept in a SQLitedatabase and includes bot information such as ID, last seen, IP and operating system.It is important to have this data, as it enables the botmaster to determine which typesof attacks are feasible. For example, by knowing the size of the botnet the botmastercould easily determine if an effective DDoS attack is possible.

The web interface provides means of broadcasting commands to all bots in the net-work, as well as bot-specific commands. This feature gives the botmaster the flexibilityof determining the granularity of the attack.

The implementation provided by Ares, does not support the HTTPS protocol. Inour perspective it is an important feature for a C&C, as the botnet is most likely moredifficult to detect if traffic is encrypted. For this reason we added SSL support to theserver. In order to make SSL work, certificates are needed. We decided to use self-signedcertificates for this purpose, in which the common name used was the IP of the serverinstead of the domain name. This way there is no need of registering a DNS domain.

Another important feature we implemented is a facade for the main web page, soas to cover the real purpose of the service. Whenever someone goes to the index pagebeing served, an innocent looking page will be displayed. Attempts to reach other webpages will be answered with a 404 HTTP error, saying the page was not found, unlessthe right parameters are given in the form of token=<secret value>. It is importantto take care of information leakage that could occur through different error messagesbeing displayed. If the messages vary depending on which url is queried, a third partymay be able to deduce information about the pages that are actually present, and pagesthat are non-existent.

The bot program is able to execute three main operations: path traversal (cd),file downloading and execution of simple linux commands such as pwd, ls and whoami.These modules are used to demonstrate that the bots are functional. However, in realitya bot would be comprised of several more complex modules such DDoS or file uploadingfor example. The bot program was originally designed for Windows systems, so wemodified it in order to run in a Linux environment.

5.2 Blockchain implementation

As mentioned in Chapter 4, if the current C&C server is down, the botmaster willuse the blockchain to inform the bots which IP address to now connect to. He will

17

encode the IP address as an OP RETURN output in each transaction. Bots receive abitcoin address and public key when first connecting to a new C&C. Should the bot beunable to connect to the C&C, it will query the bitcoin address for a transaction fromthe orchestrator and extract the new IP address. Our implementation consists of thefollowing:

• Orchestrator-side:

– A full bitcoin node to send transactions.

– A script to generate new bitcoin addresses for future messages.

– A script to monitor C&C availability and craft raw transactions to be sentusing Coinspark’s OP RETURN library.

– Python cryptography library.

• Bot-side:

– Blockcypher/Blockr.io library to interact with block explorer APIs.

– Pycoin library to decode stored information.

– Python cryptography library.

5.2.1 Storing Data via OP RETURN

As mentioned in Section 3.2, the OP RETURN script allows developers to add 40bytes of non-payment data to a transaction output. We can retrieve raw transactionbytes using the bitcoin core client. Listing 5.1 shows an example of a transaction withembedded OP RETURN data.

010000000175 a9fa84cb2bc43899cc380c05e7f27d730cf088b7ba2572ac9e fb0d6915a97f000000006b483045022100ecfaa56046bbc38d866acb19a42d48a7af f390b815d72a5a750f868096e8e1f40220510256169125f4769e fc77440a6784359 e0e69eada59368d6926b85b5015d10401210211623182c5264c08753aa1acb6b5e6 f 9 f 25dd7 f10ab7d4 f0 c4d0a3ec962 f 8268 f f f f f f f f 0 3a0860100000000001976 a91496902270b548a8c0bcc982e95f916483cb59836f88ac70f30500000000001976 a9147c2db59dd3ac00ce138bb578f12bc77147df8f6488ac000000000000000011 6a 0f 48656c6c6f2c20746573746e65742100000000

Listing 5.1: Raw Bitcoin Transaction

The byte string consists of the standard transaction parameters such as specifyingthe number of inputs and outputs, as well as the addresses included in the transaction.The OP RETURN script is indicated by 6a (highlighted). Following this, the numberof bytes that are to be processed as data is specified. In this case, we have 0f, whichis 15 in decimal. What follows from this is the actual data. In Listings 5.1, we have asimple ASCII string, “Hello, testnet!”, encoded in hexadecimal.

The python-OP RETURN library from Coinspark [Gre16] automates the processof encoding specific data into the OP RETURN script and preparing the raw bitcointransaction to be sent via the bitcoin API [Wik16]. A similar method was used in thebot to decode the information from a sent transaction [Guy16].

Obfuscating the Data

Many of the blockchain explorers available online will automatically detect ASCIIstrings encoded as hexadecimal and display them when viewing the transaction. Ad-ditionally, websites have been set up to specifically display the decoded contents ofOP RETURN scripts [Sec16].

18

To avoid drawing attention to transactions sent with embedded data, we encrypt itbefore encoding it. Given the 40 byte data limit, we opted for the RC4 symmetric cipher.Bots are configured with a symmetric key shared between the bot and the orchestrator,enabling them to decrypt the information obtained from the blockchain.

5.2.2 Sending the transactions

As mentioned in Chapter 3, bitcoin ownership is determined by holding the privatekey able to unlock immutable “UTXOs”. A user’s “wallet” contains a set of key pairsfor each of the UTXOs they own. For ease of use when making a transaction, bitcoinsoftware will often enumerate through the user’s UTXOs to create a set whose totalamount is greater than or equal to the amount to be sent. For an orchestrator sendingmultiple transactions from the same wallet, this creates a risk of combining used andunused addresses together (i.e. crosslinking).

To mitigate this, we use a new bitcoin addresses for each message sent by the orches-trator. This way the source, destination and change addresses cannot be linked withother addresses. This process requires generating new bitcoin addresses, and using on-line faucets to fund each of them with free bitcoins valid for the testnet [Ser16] [coi16a].In order to implement this we modified the Coinspark’s OP RETURN library to onlyuse the specified address when sending a transaction.

When the orchestrator initially sets up the C&C, he will store the next bitcoinaddress and public key to be used. This information will be passed on by the C&Cto each bot that successfully connects to it. Addresses are used only once, so the nextC&C will be configured with a different one.

5.2.3 Retrieving the data

If a bot is unable to contact the C&C, it will query a public block explorer API fornew transactions sent from the address specified earlier. As the API could return mul-tiple transactions, including some not initiated by the orchestrator, the bot parses eachtransaction and checks its input scripts for the public key of the orchestrator. If present,the bot will parse the OP RETURN data, decrypt it, and update it’s configuration.

5.3 Design Considerations

Resilience mechanisms are used to strengthen botnets and make them more difficultto take down. However, if not carefully implemented, these mechanisms could evenweaken these networks.

We already mentioned that for a centralised botnet architecture the C&C is the cru-cial component that needs to be well protected. Our design, introduces the orchestratorcomponent. As the orchestrator is used to protect the C&C and handle the rollover, itbecomes an interesting target for a defender. For this reason we assume the orchestratoris well protected and running in a machine which is in full control of the botmaster. Itis important to note that if the orchestrator is compromised, the botnet could be easilytaken down.

Another interesting attack vector for potential defenders is the communication be-tween the orchestrator and the C&C. When a new healthy C&C is selected, the orches-trator sends the new bitcoin information (bitcoin address, public key pair). TheC&C will in turn distribute that information to the bots so they can follow the correcttransaction and rollover to a new C&C if he is taken down. If that link were to becompromised, an attacker could alter the message being sent from the orchestrator to

19

the C&C, and inject their own bitcoin information. This way, when the active C&C istaken down, bots will be redirected to a C&C under the attacker’s control.

In order to avoid this, we implemented a simple mutual authentication scheme be-tween the orchestrator and the C&C. The orchestrator implements certificate pinning.This way when the orchestrator communicates with the C&C, it validates whether thecertificate being presented is the correct one. If the certificate is incorrect it stops thecommunication, whereas if it is correct it continues. Once the certificate is validated,a TLS/SSL session is established, so the traffic is encrypted. Using this secure chan-nel the orchestrator can authenticate to the C&C by sending a pre-defined password.The C&C can verify now the orchestrator’s identity, and therefore distribute the bitcoininformation received to the bots.

The communication between the orchestrator and the bots through the blockchainneeds to be secured as well. If any third party other than the orchestrator could senda transaction to the destination bitcoin address and embed the IP of a fake C&C,the botnet could be taken down. In order to avoid this, the bot stores not only thebitcoin address it has to monitor, but also the public key corresponding to that address.Whenever the bot parses a transaction for that address, it checks whether the correctpublic key is placed in the signature script. Therefore, any other transactions that arenot from the orchestrator are ignored.

Next to the implementation of the mechanism itself, the blockchain services need tobe available. As the blockchain is a resilient distributed network, we assume that is useis not going to downgrade the availability of our system. However, as we mentioned inSection 3.2, the bots rely on API functions to query for transactions and subsequentlyparse them. If the API being used is not responsive, the bots are not able to rolloverto a different C&C when needed. One possible solution for this is to make use of morethan one API to improve redundancy.

20

6. Discussion

Though our implementation follows a centralised command and control structure,the results from this paper are can also apply within a decentralised peer-to-peer commu-nication model. For example an operator could use the blockchain to distribute pointersto new peer lists so as to recover from peer poisoning attacks. This is similar to theapproach discussed in [And+13], in which a DGA backup channel is used for peer listdistribution.

We have demonstrated that bitcoin messages can be used for communication, how-ever this was made possible due to the presence of the OP RETURN script in transac-tions. The ability to use this channel of communication depends on the support for thisscript in future Bitcoin implementations. Regardless, the principle remains the samewith other blockchains: any possibility to embed arbitrary data, whichever blockchain,can be used to achieve communication.

Our design relies on the orchestrator’s machine being up, its ability to detect whetherthe C&C is up and, most importantly, send transactions to publish the new IP addressfor bots to switch to. In the event that the C&C is down and the orchestrator’s machineis compromised, then the network will collapse. There is however nothing stopping thebotmaster from creating an additional layer of orchestrators on top of the network andthen managing from above.

In contrast to the approach [Ali+15], which equips bots with Bitcoin SPV wallets toquery full nodes running by developers or volunteers, our approach does so via reputablepublic APIs. When viewing the traffic of queries made using Bitcoin SPV, DNS requestsare made to the URLS of nodes list in the code. These URLs can often contain strangestrings, or otherwise look suspicious. Using public APIs will still generate DNS requests,however these will be to services offered by companies who have a strong incentive tobe trustworthy in order maintain their reputation. This measure could not only makesthe bot client software used in this paper lighter, as a Bitcoin wallet doesn’t need to beincluded, but perhaps also subjectively less suspicious.

For ethical reasons we chose to use Bitcoin’s test network (“testnet”) so as to avoidinterfering with legitimate users making payments. However, using the testnet is justas effective and infinitely 1 cheaper than using the main network. The botmaster’sonly concern is communicating the message reliably. Though costless, there is a trade-off. The testnet was set up in order to facilitate experiments with the Bitcoin protocolwithout impacting the main network. As such, it could be subject to intermittent downtime.

In the described architecture, the bot is able to decrypt communication with theC&C and migrate when a new C&C comes online. Such a setup could be obtainedby means of a honeypot machine enabling the possibility of passively monitoring themovement of C&C server IPs. Nevertheless, enumeration is not possible as bots donot interact with each other. In addition, should a bot be unable to connect to a newerC&C before the network migrates to the next, it won’t receive the next bitcoin address toquery. As all transactions are completely independent, missing an update will preventthe bot from following the network. This situation opens a small window of time inwhich the botnet could be taken down. This window takes place between the time thenew C&C is published and the bots join it. If the active C&C were to be compromisedby a defender during that period of time, the botnet could be completely deactivated.However, this is not easy to achieve, specially if the C&C server is well secured.

1Bitcoin for use on the testnet can be easily obtained for free.

21

7. Conclusion

In this paper we researched the viability of using the blockchain as a means of pro-viding botnet resilience. The first research question aimed to explore different resiliencemechanisms used by botnets and their pitfalls. Common techniques in centralised archi-tectures include the use of the Tor service and the implementation of domain generationalgorithms. In P2P botnets common techniques often comprise of authenticating mem-bers of the botnet to avoid poisoning, and using multiple ID’s for the same peer so asto complicate enumeration attempts. We found that even though these mechanismscontribute to improving botnet resilience, they are not infallible.

In this context, the use of a different resilience mechanism through the blockchaincould be appealing for attackers. Based on this idea, we designed and implemented aproof of concept to enable the migration of a botnet from a compromised C&C to ahealthy one. The PoC illustrates that such a mechanism is plausible and it also can beused in combination with other resilience methods. For example, in P2P botnets theblockchain could be used to distribute new peer lists to bots that have been poisoned.

Finally, we wanted to look into the implications of building such an infrastructureand the enumeration of possible mitigation techniques. Any blockchain that allowsthe storage arbitrary data could be potentially exploited by botnets as a means ofachieving resilience. If we consider the bitcoin testnet, this is possible without the needto purchase bitcoins. In addition, our proposed approach minimises the interaction withthe blockchain, as this channel is only used if the current C&C is down. The rest ofthe traffic is HTTPS, which is used to carry out common tasks commanded by thebotmaster. This way, the botnet is able to conceal its tracks better than a botnet whichuses blockchain transactions for all its purposes.

In terms of mitigation, honeypot techniques could be used to get a machine infectedin order to monitor the bot’s behaviour. Moreover, if the bot is reverse engineered,it may be possible to track new C&C’s being deployed. In addition, there is a smallwindow of time in which the botnet could be taken down. This window takes placebetween the time the new C&C is published in the blockchain and the bots join it. Ifthe defenders act fast and take the current C&C under their control, the botnet couldbe completely deactivated.

22

8. Ethics

The goal of this research is to shed some light on the use of the blockchain infuture botnet implementations. We consider it is important to raise awareness aboutthis specific method botmasters might use to withstand attacks against their botnets.However, the information provided must not be used for malicious purposes. This is oneof the reasons why the source code of the proof of concept will not be disclosed unlessrequested for academic purposes. It is also important to note that using the bitcoinblockchain for ulterior purposes is highly discouraged and should be avoided.

23

9. Limitations

This project presents certain limitations. First of all, the resilience mechanism de-signed and implemented is heavily dependent on the bitcoin blockchain. If this networkis down, the system is not able to rollover as intended. However, the botnet structurecan survive as long as the active C&C is not taken down during the disruption period.This way the system could possibly withstand temporarily unavailable bitcoin services.

Secondly, bots rely on API functions to be able to query for transaction information.If the APIs used are down, bots will not be able to retrieve transactions, and there-fore will fail to redirect their requests to the newly appointed C&C. In addition, APIsrestrict the usage of its functions so as to avoid possible abuses. This means that inthe hypothetical case that bots need to constantly query the blockchain, they could beblocked. As mentioned before, using several APIs mitigate this issue but it does noteliminate the inherent dependency on these external services.

Finally, it is possible for a potential defender to capture the bitcoin address the botsare monitoring (e.g. by reverse engineering the code of the bot), and start flooding itwith spurious transactions. This will result in the bot being slowed down, as it hasmore transactions to parse. However, it is not possible to disrupt the botnet with theseactions as bots check for the public key of the orchestrator as a means of validating theinformation received is legitimate. Moreover, this type of behaviour, such as flooding acertain address, are discouraged among the bitcoin community members as it underminesnetwork performance.

24

10. Future Work

Future work from our perspective could be to conduct further tests and analysison our implementation, perhaps measuring the performance of the rollover mechanismis and the responsiveness on the botnet in general. Other research could look intothe possibility of a similar scheme implemented in other blockchains such as Ethereum[But14]. This blockchain introduces smart contracts, which are essentially scripts storedon the blockchain that can hold a balance and make decisions based on certain events.Such contracts open the possibility for completely autonomous logic that interacts withother smart contracts, providing some form of service.

25

Bibliography

[21c16] 21.co. Bitnodes. May 23, 2016. url: https://bitnodes.21.co/.

[Ali+15] Syed Taha Ali et al. “ZombieCoin: powering next-generation botnets withbitcoin”. In: Financial Cryptography and Data Security. Springer, 2015,pp. 34–48.

[And+13] Dennis Andriesse et al. “Highly resilient peer-to-peer botnets are here:An analysis of Gameover Zeus”. In: Malicious and Unwanted Software:”The Americas”(MALWARE), 2013 8th International Conference on. IEEE.2013, pp. 116–123.

[Ant14] Andreas M Antonopoulos. Mastering Bitcoin: unlocking digital cryptocur-rencies. ” O’Reilly Media, Inc.”, 2014.

[bit16] bitcoin.org. Bitcoin Core version 0.9.0 released. May 24, 2016. url: https://bitcoin.org/en/release/v0.9.0.

[Blo16] Blockchain.info. Blockchain.info. May 19, 2016. url: https://blockchain.info/.

[But14] Vitalik Buterin. “Ethereum: A next-generation smart contract and decen-tralized application platform”. In: URL https://github. com/ethereum/wik-i/wiki/% 5BEnglish% 5D-White-Paper (2014).

[che16] cherrypy.org. CherryPy. A Minimalist Python Web Framework. May 19,2016. url: http://www.cherrypy.org/.

[CM14] Matteo Casenove and Armando Miraglia. “Botnet over Tor: The illusion ofhiding”. In: Cyber Conflict (CyCon 2014), 2014 6th International Confer-ence On. IEEE. 2014, pp. 273–282.

[coi16a] coinfaucet. Bitcoin testnet3 faucet. May 20, 2016. url: https://testnet.coinfaucet.eu/en/.

[coi16b] coinmarketcap.com. Crypto-Currency Market Capitalizations. May 19, 2016.url: http://coinmarketcap.com/.

[Cry16] Cryptopay. Cryptopay: A better way to manage bitcoins. May 20, 2016. url:https://cryptopay.me/.

[Fac16] Factom. A Scalable Data Layer for the Blockchain. May 19, 2016. url:https://www.factom.org.

[Gre14] Andy Greenberg. “How Hackers Hid a Money-Mining Botnet in the Cloudsof Amazon and Others”. In: (July 24, 2014). Ed. by Wired. url: https://www.wired.com/2014/07/how- hackers- hid- a- money- mining-

botnet-in-amazons-cloud.

[Gre16] Gideon Greenspan. Simple Python commands and library for using bitcoinOP RETURNs. May 20, 2016. url: https://github.com/coinspark/python-OP%5C_RETURN.

26

[Guy16] Justin Guy. Embedding data in the blockchain with OP RETURN. May 20,2016. url: https://21.co/learn/embedding-data-blockchain-op-return/#creating-and-sending-the-transaction.

[KL16] Wayne Kenney and Kevin LOCATI. Ares. May 19, 2016. url: https://github.com/sweetsoftware/Ares.

[Lit16] Litecoin. Litecoin. May 20, 2016. url: https://litecoin.org/.

[MNM15] Muhammad Mahmoud et al. “A Survey on Botnet Architectures, Detectionand Defences.” In: IJ Network Security 17.3 (2015), pp. 264–281.

[Nak08] Satoshi Nakamoto. Bitcoin: A peer-to-peer electronic cash system. 2008.

[pyt16] python.org. Python 2.7.0 Release. May 19, 2016. url: https : / / www .

python.org/download/releases/2.7/.

[Ros+13] Christian Rossow et al. “Sok: P2pwned-modeling and evaluating the re-silience of peer-to-peer botnets”. In: Security and Privacy (SP), 2013 IEEESymposium on. IEEE. 2013, pp. 97–111.

[Sch+14] Stefano Schiavoni et al. “Phoenix: DGA-based botnet tracking and intelli-gence”. In: Detection of intrusions and malware, and vulnerability assess-ment. Springer, 2014, pp. 192–211.

[Sec16] Coin Secrets. Recent Metadata in the Bitcoin Blockchain. May 20, 2016.url: http://coinsecrets.org/.

[Ser16] BlockCypher Web Services. Free Bitcoin Testnet Faucet. May 20, 2016. url:https://accounts.blockcypher.com/testnet-faucet.

[SNK09] Greg Sinclair et al. “The waledac protocol: The how and why”. In: Maliciousand Unwanted Software (MALWARE), 2009 4th International Conferenceon. IEEE. 2009, pp. 69–77.

[Ubu16] Ubuntu. Ubuntu 15.10 (Wily Werewolf). May 19, 2016. url: http : / /

releases.ubuntu.com/15.10/.

[Wan+15] Ping Wang et al. “Analysis of Peer-to-Peer Botnet Attacks and Defenses”.In: Propagation Phenomena in Real World Networks. Springer, 2015, pp. 183–214.

[Wik16] Bitcoin Wiki. Bitcoin Wiki. May 19, 2016. url: https://en.bitcoin.it/.

[WSZ10] Ping Wang et al. “An Advanced Hybrid Peer-to-Peer Botnet.” In: IEEETransactions on Dependable and Secure Computing 7.2 (2010), p. 113.

27