BlockchainBot: A Novel Botnet Infrastructure Enhanced by Blockchain Technology and IoT

Abstract

Although the traditional P2P botnet has significant resilience against termination, its dependence on neighbor lists (NL) has left it vulnerable to infiltration and destruction. In addition, it is not sufficient in protecting the botmaster’s identity. To overcome these weaknesses, we proposed BlockchainBot, a botnet model that leveraged IoT devices as maintainers, and integrated blockchain, also known as distributed ledger technology (DLT). The BlockchainBot was able to fully deploy bots on public blockchains. It was versatile for multiple botnet applications and eliminated the dependence on NL. In addition, we further introduced a novel method, the forking of a channel, to kick out spy nodes that infiltrate a botnet. To further enforce the resistance against a single point of failure (SPoF), we introduced bot-cluster dispersing to prevent clustering around full nodes and more evenly scatter bots to prevent hostile takeovers. The analysis of the security of BlockchainBot indicated that it had strong resilience against DDoS attacks, Sybil attacks, and forensic investigations. Furthermore, the security of the forking of the channel and bot-cluster dispersing were also shown to be effective. The robustness of the BlockchainBot against the Sybil attack was also briefly discussed. Experimental results authenticated the effectiveness and performance of the BlockchainBot, as compared to previous models.

1. Introduction

A bot network, or “botnet”, has been a long-standing threat to the digital world and is evolving rapidly. Recently, another potential tool for criminal activity was brought to the attention of the research community: the establishment of a botnet via blockchain. A botnet consists of a network of compromised computers (“bots”) connected to the Internet that are controlled by a remote attacker (“botmaster”) [1,2], a person or a group of people often known as “hackers”. A bot is a program installed on a computer that allows an attacker to control its use and activities remotely [3]. Botnets pose a severe threat to users of the Internet: botnets are employed for distributed denial-of-service (DDoS) attacks, sending spam, or other nefarious purposes [4,5,6]. Command and control software (C&C) allows the botmaster to synchronize and direct the botnet for their purposes. From a botmaster’s perspective, C&C servers are a fundamental weakness in the current botnet architecture for several reasons. First, a botmaster will lose control of their botnet when the limited number of C&C servers have been shut down by defenders [7]. Second, defenders could then obtain the identities (e.g., Internet protocol (IP) addresses) of all the C&C servers based on their service traffic to a large number of bots [8], or simply from a single captured bot that contains a list of the C&C servers. Third, an entire botnet may be exposed once a C&C server in the botnet has been taken over or captured by defenders [9]. Therefore, how to better secure and disguise C&C channels has become a focus for bad actors.

Using Internet relay chat (IRC) channels for C&C communication was the original foundation of botnet design. Later, a hypertext transfer protocol (HTTP)-based variant, with the aid of a C&C server with a fixed domain name server (DNS) or IP address, became the standard for botnet frameworks. However, each has a single point of failure (SPoF) that results in the entire network being decimated when the C&C server has been identified and overtaken.

To further improve the resilience and stealth of a botnet’s C&C channel, Mónica et al. [6] presented a novel strategy that extended the C&C channel to two layers by leveraging benign users as a “broker” layer of C&C to relay the commands of the botmaster to the bots, whereas a website, whether deployed or only infected by the botmaster, would be needed to dispatch messages to these benign users, thus making the broker website a potential SPoF.

Furthermore, botnets soon adopted a new tactic using peer-to-peer (P2P) protocols to, in part, decentralize their C&C servers. As a result of their resistance to law enforcement’s tactics of capturing a central C&C server, most of the current botnets use P2P for their C&C infrastructure. However, this has not eliminated their vulnerabilities or SPoFs, as in order to pierce through the network address translators (NAT), they have to employ either a STUN server or a TURN server.

The number of connected Internet-of-things (IoT) devices has been growing exponentially since their introduction were predicted to surpass 20.4 billion by the year 2020 [10]. Unfortunately, due to botnets leveraging benign users as brokers to relay their commands, IoT devices provide yet another opportunity for these malicious networks to disguise their actions. IoT devices have been identified as “easy prey” for cybercriminals [11]. However, due to their proliferation and anonymity, they have significant potential for use in botnets to further mask their malicious activities and covertly relay communication, which would impede forensic investigations and law enforcement.

In addition, another ideal mechanism for C&C dissemination in botnet construction is the emerging distributed ledger technology (DLT), also known as “blockchain”, as it is not censored or centralized, and it is not hampered by a SPoF or permissions.

For example, IOTA’s Tangle [12] is a bridge linking IoT devices to DLT with secure data and value exchange and is designed for an IoT machine-to-machine (M2M) economy, so publishing data on Tangle costs nothing.

In this study, we proposed a novel botnet C&C resolution, namely “BlockchainBot”, established on blockchain and in view of a “red team” (the attacker in a drill). To the best of our knowledge, this is the first theoretically and empirically sound mechanism formulated entirely on a directed acyclic graph (DAG)-based blockchain and has no associated fees. Moreover, BlockchainBot is fundamentally different from contemporary botnets. (For clarity, though “blockchain” and “DLT” are often used synonymously, they are not entirely equivalent. For instance, Tangle is a DLT, but it is implemented in a DAG structure rather than a chain.)

The contributions of our work were as follows:

• We provide a novel botnet infrastructure synchronized with DLT and able to use all the advantages of blockchain while circumventing the associated bottlenecks.
• We leveraged benign IoT devices as our botnets’ maintainers, which provided better resistance to tear-down, and we developed an algorithm to discover and collect as many DLT full nodes as possible, which would improve the resilience of our botnet.
• We eliminated the neighbor list (NL) that current P2P botnets require from the outset and thus reducing the network’s vulnerability to Sybil attacks or “spy” nodes.
• We designed a novel scheme that can remove spying nodes upon discovery.
• We implement a versatile botnet infrastructure, as compared to other proof of concept (POCs) botnets using blockchain; however, they were unable to handle multiple C&C botnet scenarios, such as those including data upstream and bidirectional communication.

The rest of the paper is organized as follows: Section 2 analyzes the main drawbacks of historical and blockchain-based botnets, and Section 3 introduces the background knowledge and the underlying mechanisms of IOTA’s Tangle. Section 4 describes the mechanism of our C&C channel of botnet communication and the algorithms used to boost the robustness of our BlockchainBot. Section 5 presents the efficacy and performance of the BlockchainBot, and Section 6 provides an analysis of five aspects of our model when presented with an opposing “threat” model as well as the underlying security assumptions. Section 7 details potential countermeasures against a novel blockchain- and IoT-based botnet. Finally, Section 8 outlines our conclusions.

2. Literature Review

The C&C server is the central rallying point for the botnet [13]. Therefore, the ownership of the C&C channel authorizes the virtual possession of a botnet, making the C&C channel the lifeline of a botnet. The C&C structure evolved from IRC [14] to HTTP and DNS until P2P protocols were found to have the most robust structures.

Table 1. Overview of historical botnets and their topology and other features.

Botnet	Year	Topology	Purpose	Related/Family
Trinoo	1999	Central	DDoS	Stacheldraht, Trin00
TFN	1999	Central	DDoS	Stacheldraht
Slapper	2002	P2P	DDoS, software loading	Scalper, Cinik, Unlock
Sinit	2003	P2P	Malware distribution	Calyps.a, Calypso
Sality	2003	Central; later P2P	Data theft	Multiple variants
Phabot	2004	P2P	Data theft, DDoS	Agobot, Gaobot, Forbot, many variants
Conficker	2008	Central; later P2P	Malware distribution	Downadup, multiple versions
Adwind	2012	Central	Remote Access	AlienSpy, Frutas, Unrecom, Sockrat, JSocket
Zeroaccess	2011	P2P	Click-fraud, software loading	Smiscer, Max++, Sirefef
Duqu2.0	2014	Central	Remote access	Flame, Gauss, Stuxnet, miniFlame
Mirai	2016	Central	DDoS	Multiple Variants

presents the most notorious botnets in digital history, along with their C&C topologies, purposes, and variants [14].

In addition to these famous botnets, researchers have proposed their botnet designs, centralized or otherwise, such as those in [7] and [15]. However, with the exception of those based on P2P protocols, SPoF is an issue for all other C&C frameworks, as when the C&C is destroyed, the entire botnet will be disabled. Comparatively, as P2P-based C&C does not rely on a central server, each bot in the network has the potential of being used as part of the C&C framework, and they are all interconnected with each other. Therefore, if even a significant number of bots are disabled, the communication among the rest will not be disrupted.

Despite their significant advantages, P2P-based botnets have certain drawbacks. For example, transferring commands and other egress messages mutually among all the neighboring nodes increases redundancy and thus incurs a high communication overhead. The botmaster has to balance the resilience of the network against the cost of redundancy.

Furthermore, during the initiation of a P2P-based botnet, a bootstrap, or seed server with a hardcoded IP address is required for recruited bots to be added to the botnet via a neighbor list (NL) and thus making it a weakness of the fledgling botnet. Once the seed has been identified and disabled, new bots will not be able to join the network. As law enforcement has significant influence with Internet service providers (ISPs) and other integral digital entities in the cyberworld, they are able to request and scrutinize network traffic and subsequently ascertain the identity of the botmaster.

Blockchain may provide a solution to the vulnerabilities inherent in a P2P-based botnet, as they are well-known for maintaining the anonymity of their participants as well as many unique advantages [16], as follows:

• Anonymity: The design of blockchain provides a degree of anonymity (most often, pseudonymity) to its users.
• Robustness: Public blockchains are censorship-resistant (i.e., anyone can interact on the network as long as they abide by the network protocol rules).
• Enumeration-resistance: Bots retrieving commands from the blockchain are hidden among other legitimate users.
• Stealth: Due to the growing popularity of blockchain users, botnet traffic data can blend in among benign blockchain transactions.
• Simplicity: Due to the large community and open-source tools, developing a blockchain P2P network is simpler than setting up a custom P2P protocol.

While these advantages mitigate many of the challenges involved in securing botnets against discovery, other challenges have emerged as researchers have developed and tested POCs for blockchain-based P2P botnets.

Table 2. Comparison of existing POCs for a blockchain-based botnet.

Botnet	Blockchain Downstream	Blockchain Upstream	Blockchain as Backup	Alternate Channel	Versatile for Multiple Botnet Scenario	Public Blockchain
ZombieCoin2.0 [14]	√	×	×	√	×	√
Frkat [17]	√	×	×	√	×	√
NeuroMesh [18]	√	×	×	√	×	√
Botract [19]	√	Not Specified	×	Not Specified	×	√
Zohar [20]	√	√	×	×	×	√
Sweeny [21]	√	√	×	×	×	×
Curran [22]	×	×	√	√	×	√
Cerber [23]	×	×	√	√	×	√
Redaman [24]	×	×	√	√	×	√
Fbot [25]	×	×	√	√	×	√
BlockchainBot	√	√	×	×	√	√

presents a comparison of baseline functionalities between the innovative proposals for blockchain-based botnets and our BlockchainBot.

As shown in Table 2, previous attempts to develop blockchain-based P2P botnets have all contended with various challenges such as the upstream channel, which functions for file transfer and data feedback to the botmaster, and overhead costs including the transaction fees on public blockchains, which can vary based on the sizes of the messages exchanged. In addition, Zohar et al. [20] acknowledged that their scheme is not for individuals. Other similar works are [26,27].

Furthermore, nearly all of the botnets in Table 2 grappled with the same issue: communication using blockchain is unidirectional. The botmaster can dispatch commands, but the bots cannot respond, or “phone home” due to the increasing fees associated with messaging. Therefore, uploading data feedback using only blockchain is not feasible.

In addition, botnets rely on instant communication relays, whereas the rates of transactions-per-second (TPS) on public blockchains are 7 on Bitcoin and 8–15 on Ethereum, which would interfere with a core component of botnet C&C.

Last but not least, most public blockchains are vulnerable under forensic investigations. Typically, forensic investigators aim to identify individuals who are involved, or potentially involved, in criminal activity [28]. Digital forensics analyzes communication records to infer relationships among entities [29]. The data for most public blockchains are permanently recorded. These historical data are necessary for DLT, but they could allow the botmaster to be identified.

The main flaws when integrating botnets with blockchain are as follows:

(1)

Excessive costs

This disadvantage originates from the transaction fees that are proportional to the number and data size of transactions on Bitcoin and Ethereum, which can be formulated as (1) and (2). On Ethereum, the transaction fee is measured by a unit called “gas”. Every 1 gas is worth 0.00000001 ether on Testnet (which is cheaper than on Ethereum Mainnet), and each transaction’s basic fee is 21,000 gas. Each byte is worth 8 gas, and the operation of storing data as a log on Ethereum costs 375 gas. The product of x and n is the total size of the data needed to upload per day by a bot, and the daily cost C (in gas) can be quantified as:

$$C=n\cdot 375+n\cdot x\cdot 8+n\cdot \mathrm{21,000}$$

(1)

For a practical example, if n were 500 and x were 60 kilobytes, the daily cost would be 250,687,500 gas or ETH 2.506875 (USD 8269.50376875) per day.

The Bitcoin average transaction fee [30] was USD 3.465 at the time of this study, according to Formula (2), which measures the average fee when a Bitcoin transaction is processed by a miner and confirmed. The average Bitcoin transaction fees can spike during periods of congestion on the network, as they did during the 2017 crypto-boom when they reached nearly USD 60.00. A single Bitcoin transaction is able to contain, at most, 40 bytes of data. The daily cost in USD can be measured as:

$$C=n\cdot \lceil x/40\rceil \cdot 3.465$$

(2)

Assuming a bot needed to upload 60Kilo bytes a day and there were 500 bots in the botnet, according to Formula (2) and assuming that x = 60 k and n = 500, the daily cost on Bitcoin would be USD 2,661,120 per day.

(2)

Lack of Uploading Channels

Currently, public blockchain uploads information for the purpose of maintaining a digital ledger of transactions, not for communicating and storing significant amounts of data.

(3)

High Latency of Communication

The low TPS rate worldwide is due, in large part, to the verification of proof-of-work (POW) on Bitcoin and Ethereum. Therefore, the instant communication required for a large-scale botnet cannot be achieved.

Therefore, we developed three rules for building a suitable blockchain-based P2P botnet that would enable us to utilize the advantages of DLT while mitigating the risks.

(a)

Low or no transaction/message fees. Free of charge would be ideal.

(b)

A secure, fast communication channel for data exchange would be crucial.

(c)

No POW requirements.

(4)

Susceptible to forensics

When using a public blockchain for a botnet, the traffic data generated by the botmaster and their bots are permanently recorded and can be analyzed by law enforcement and other entities to identify the botmaster.

IOTA’s Tangle has overcome these drawbacks, at least to some extent, which made it the logical cornerstone for our botnet model design. With the ongoing evolution of IoT technology and the soaring number of IoT users, the “Internet of Everything” has become a goal for the future, where smart cities and smart devices connect people, processes, data, and “things” worldwide. IOTA developed the first DLT built for the “Internet of Everything” concept: a network for exchanging value and data between human users and machines [12]. It is an open, free, and scalable DLT, a trust layer for an M2M economy, and designed to support frictionless data and value transfer [31]. In addition, IOTA has a unique function called a “snapshot” that has differentiated it from other public blockchains [32]. These snapshots reduce the size of the Tangle database by removing all transactional details and leaving behind only a record of addresses with corresponding balances [33]. Therefore, when using IOTA as the infrastructure of a botnet, the traffic data of the botmaster and the bots would not be permanently stored in IOTA’s Tangle database, making it ideal for use in a botnet.

3. Preliminaries

In this section, IOTA’s background mechanisms (Through DAG structure has less resilience against double-spending than chain structure inherently, the consensus algorithm of IOTA’s Tangle, namely the FPC-BI [34], mitigates the risk of double-spending) necessary for implementing our BlockchainBot are briefly reviewed, and the advantages of leveraging IOTA’s Tangle as our botnet’s underlying infrastructure are discussed. Abandoning the traditional chain structure that many public DLTs adopt, IOTA has introduced DAG to organize its ledger as DAG supports concurrent ledgering. Figure 1 provides an overview of Tangle, which utilizes the DAG framework.

• Low Latency

As shown in Figure 1, each vertex in the DAG structure is a “bundle”, which consists of many transactions that have been packaged together. The green bundle is then sent to Tangle to be validated, and it has a new tip. The brown folders represent validated bundles whose legitimacy has been confirmed by Tangle.

Figure 2 shows a normal IOTA transaction and its entries. These include transactional hash; the address which sends the value or receives them; a signature message fragment (SMF) for recording the signature generated by the private key; a timestamp for the transaction; an index showing the order of this transaction among the others in the bundle; a tag determined by the user for the transaction; a branch and trunk notation in reference to other bundles on Tangle; a bundle hash to identify the transaction’s bundle; and a nonce parameter against potential spam and DDoS attacks.

Since multiple vertices can exist and be processed simultaneously, as opposed to waiting for a single available chain, the validation process is accelerated and significantly reduces the typical latency found in public blockchains.

• Anonymity

Whereas Bitcoin and Ethereum depend on public addresses to identify participants in the blockchain, IOTA’s Tangle uses a “seed” to identify users and protect their anonymity [35]. Figure 3 shows the relationship between the user, the seed, and public addresses.

As shown in Figure 3, a user receives a seed from an entropy pool, which aggregates digital environmental noise such as time, network packets, and other sources and provides these random data to a cryptographically secure pseudo-random number generator (CSPRNG) to obtain a correctly formatted random number as IOTA’s seed. Generally speaking, in other DLT implementations, if a private key is compromised, the key owner can be exposed, and their account can be lost. However, in IOTA, a seed can generate 3²⁴³ keys [35], and the seed cannot be determined by acquiring the private keys as the Keccak-384 is a hash function abstracting the seed to acquire private keys. Furthermore, the private keys are neither stored on the Tangle nor saved in IOTA’s digital wallet as it is “computed and played” dynamically when needed. For the purpose of finding a balance between security and speed, a user can determine a private key’s length by choosing the security level (level 1, level 2, and level 3) in advance. The private key of level 1 has the fastest generation speed as well as the shortest transaction signing time and public address generation time (see Figure 4). Conversely, level 3 has the most security enhancement, but the longest signing and public address generation time. In addition, its signature is three times larger than a level 1. The detail of public address generation on IOTA’s Tangle with respect to the three security levels is shown in Figure 4.

In Figure 4, the generation of a public address from a private key depends on the security level of the private key. Initially, assuming that the private key has a security level 3, it is divided into 27 fragments and hashed 26 times to obtain segments. The segments are hashed again to produce the digest. Finally, the public address is obtained via hashing the digest(s). There is no method to attain private keys from public addresses as the hash process is irreversible. Given that the seed is safely guarded, whether the private keys are stolen or lost has no impact on the security of the seed’s owner. These features enhance the anonymity of IOTA’s Tangle.

• Feeless and Less Computing Resource Demanding

While Bitcoin and Ethereum adopt POW as their consensus protocol, IOTA’s Tangle leverages FPC-BI [34] for achieving agreement on the full nodes (a full node is a DLT participant running software modules to keep and maintain ledger data). In other words, there are no mining processes or miners in IOTA’s Tangle; therefore, IOTA’s Tangle is feeless and conserves the computing power and resources of the full node, which allows devices with low computing power (i.e., IoT devices) to join Tangle.

• Encrypted Message Queuing Telemetry Transport (MQTT) Channel

Masked authenticated messaging (MAM) enhances the security of MQTT in IOTA’s Tangle. Similar to its literal meaning, MAM is:

(1)

Encrypted (Masked);

(2)

Confirmed as from the device (Authenticated); and

(3)

Created on Tangle and will continue until the device stops publishing data (Messaging)

Although MAM can be used as a channel, it behaves similarly to a message chain, and its transaction will still be added to a bundle (see Figure 5). A transaction for MAM is different from a normal value transfer, as the SMF stores the MAM payload (a component of the MAM object), and its address is not the public address of the private key but specifically calculated for MAM to attach messages. In addition, the value transfer is always zero in MAM. The MAM channel id is determined by a Merkle tree. Assuming that the message being sent is 10,240 bytes (≈10 k), it will be divided into eight transactions (as a transaction can only have one SMF, and the maximum SMF size is 1300 bytes). These transactions form a Merkel tree, and the root of the Merkle Tree is the id of the MAM channel. The relative MAM Merkle Tree is calculated, as shown in Figure 6.

As shown in Figure 6, eight of the transactions have eight private keys. To obtain the root, the public addresses are first derived from the private keys, and they are hashed to obtain the leaves of the Merkle Tree. Then the leaves are hashed in pairs to obtain the branches, and finally, the branches are hashed in pairs again to produce the final root. This root serves as both the channel id and the address to which all the transactions are attached. If the MAM publisher needs to send new messages in the future, then they will repeat the Merkle tree’s root calculation.

IOTA’s MAM allows sensors and other devices to encrypt entire message streams and securely store them in Tangle, each on a separate address. Only authorized entities are able to read and reconstruct the entire message stream. In essence, it is similar to how radio broadcasting operates, where only those with the right frequency can hear the broadcast. In MAM, only those with the right channel IDs can obtain access to the message. In a MAM stream, the message is encrypted (i.e., masked), and it contains a signature proving the authentication of the publisher and preventing spam messages forged by others. The entire message bulk is divided into blobs chained together by referencing many different addresses.

As shown in Figure 7, MAM posts every message to different addresses with verbose information connecting them as a message chain. On this message chain, older messages are connected to newer ones, but with different addresses, eliminating the vulnerability of reusing the same address. For example, if a botmaster wants to send information within a fixed period of time, without MAM, the message will be posted with the same address, which would aid an investigator in searching for similarities and inferences to a bad actor’s identity.

There are three modes in a MAM channel:

(1)

The public mode uses the Merkle tree root as the address of the transaction publishing the message. The root is the encryption and decryption key of the message. Therefore, any user can decode the message if they possess the root.

(2)

The private mode can be used for encrypted streams not meant for public consumption. In private mode, the hash of the Merkle root is used as the address. Therefore, a user who stumbles across the hash cannot decode the messages without knowing the root.

(3)

The restricted mode adds an authorization key to the private mode, which is called the “sidekey”. The address used to attach messages is the hash of the authorization key and the Merkle root. A message publisher can generate a new key and revoke access to subscribers at any time. Only those in possession of the new sidekey would be able to access the messages.

Regardless of the mode used, only the owner of the seed that generated the MAM Merkle tree can write data to the MAM channel. Message recipients cannot interfere with the messages.

IOTA’s Tangle provides a unique foundation for botnet deployment, namely our own model BlockchainBot:

• Botmaster identity security

Typically, transactions on DLT are publicly announced and broadcasted, which risks the anonymity of the botmaster and bots. Our use of IOTA’s Tangle eliminated that risk.

• Removal of SPoF

We constructed our botnet model to provide a bulletproof defense against the DNS botnet domain “sinkholing”.

• “Killing with a Borrowed Sword”

With the aid of DLT, benign IoT devices linked on Tangle were used to transfer our commands and receive inbound information for bots, and thus the state of the whole botnet was updated by these benign devices.

• Anti-Sinkholing

The overlay of the C&C channel we implemented and the secure connection of the bots to Tangle mitigated any sinkholing techniques.

• Low-to-No Associated Costs

Our novel method eliminated this concern by using a quorum of bots, the size of which can be arbitrary and adjusted as needed, due to the negligible costs associated with message publishing on Tangle.

• Remove of NAT-Relay Servers

Decentralized botnets, typically existing P2P botnets, need a broker server such as STUN or TURN to relay their messages to bots inside NAT. (In this scenario, NAT gateways are typically firewalls.) In a blockchain, only full nodes communicate through NAT. As for the botmaster and bots, if they can connect to the Internet, the NAT will be pierced (see Figure 8). Therefore, in our BlockchainBot model, relay servers were unnecessary.

As Figure 8 shows, the botmaster and their bots can communicate freely as long as they connect to the Internet. Their traffic is disseminated by the gossip protocol between the full nodes (i.e., IoT devices).

4. Model Design

In this section, we first describe the ability of an entity working against the botnet, namely our BlockchainBot, and then outline the design of our model BlockchainBot.

4.1. Threat Model

The first step in dismantling a botnet is to collect information about the botmaster and the network, including topology, scale, commands, targets, etc. Therefore, we had to assume that all the entities attempting to infiltrate the botnet by deploying their nodes inside the botnet were the adversary, regardless of their actual motivations. In addition, any nodes not controlled by the botmaster were considered spies. We also assumed that the adversary would interrupt communication signals and employ DDoS attacks to interfere with the communication between the botmaster and the bots.

4.2. Overview of the BlockchainBot

In this section, the essential design of the C&C channel on IOTA’s Tangle is introduced, and the bots connected to the full nodes are defined by Algorithm 1. The overall architecture is depicted in Figure 9.

As shown in Figure 10, there were two encrypted private MAM channels established for C&C and data reporting. The first was the commands dispatch channel (CDC), which would be used by the botmaster to command the bots. The second was the data upstream channel (DUC), which would be used by the bots to send data back to the botmaster, including files, credentials, and the results of the botmaster’s commands. To scatter the bots, the botmaster could create a restricted MAM channel in which to publish the full nodes and hardcode the channel ID (the root) in the binary execution program. After the binary program had been executed on the target computer, which could be delivered in various ways, such as click-fraud, e-mail, social engineering, remote execution vulnerabilities, worms, etc.), the target would become a bot. The channel ID of DUC and CDC was created by the bot and botmaster after the bot’s initiation. Thereby, the bot could make a transaction on Tangle and send it to the botmaster to provide the channel ID if a rendezvous point had been defined in advance. After the two channels were constructed, a bot would be ready to receive and execute commands. For the purpose of clarity, the two channels were directly connected to the botmaster and the bot, but in reality, these channels would be relayed through many full nodes in IOTA’s Tangle. Therefore, by outsourcing the communication to the full nodes in IOTA’s Tangle, the potential risk of the exposure of the botmaster’s identity would be mitigated. The sequence of the construction of the three channels is shown in Figure 11.

As Figure 11 indicates, when a bot was recruited, it first received a list of full nodes enumerated by the botmaster and randomly selected one from the list to change its connection of the original full node, which was considered as a resident portal operated by IOTA’s community. We referred to this process as “bot-cluster dispersing” since connecting to one node alone could lead to a risk of a SPoF. For example, if a node were offline due to being disabled, all the connected bots would then be out of order. We designed Algorithm 1 to enumerate as many full nodes as possible to prove more alternatives. Secondly, the bot created the DUC channel using its seed, which was be derived from the online entropy pools such as Random.org [36] and Cloudflare’s Lava Lamps [37]. The IOTA’s foundation recommends using their seed generation services provided by Trinity Wallet [38] or Python’s SystemRandom [26]. The random seeds generated by Trinity Wallet and SystemRandom are shown in Figure 12 and Figure 13.

After creating the DUC channel, the bot would send the channel’s root, also known as the channel ID, to the botmaster by issuing a transaction. To protect anonymity, a bot could use the tag parameter of IOTA’s transaction as a secondary option to avoid sending the transaction directly to the botmaster and expose the public address of the botmaster. Then, after the botmaster subscribed to the DUC, they would receive the bot’s uploaded data. Afterward, the botmaster would create a CDC to issue commands to the bot and send the CDC’s root to the bot via a transaction. To avoid (To avoid the risk of eavesdropping, the content of the transaction could be ciphered by the seed of the bot). Upon receiving the CDC’s root, the bot would be ready to execute the instructions assigned by the botmaster and upload data.

4.3. Bot-Cluster Dispersing

The bots needed to be scattered evenly so they could interact with different full nodes and avoid any clustering, namely around the IoT gateways and other smart devices with significant computational power (e.g., edge computing devices).

The portal bootstrap server of IOTA’s Tangle was public and would likely be the first node new bots would encounter. Therefore, we needed to enumerate as many full Tangle nodes as possible and publish their addresses in the aforementioned C&C MAM to prevent any risk of SPoF issues, even though there were unlikely.

We examined the implementation of the gossip protocol used by Tangle as a fundamental infrastructure to propagate transactions among all full nodes and invented a method to discover public portals, as follows:

Algorithm 1: Full Node Enumeration and Publishing
Input:	p: The bootstrap node of IOTA’s Foundation; N: A new set of nodes obtained; c: The channel on which to publish full node address;
Output:	SN: the set of full nodes obtained;
Procedure:	begin
1:	Initialize p with the node of IOTA’s Foundation
2:	Populate N with the neighboring nodes of p
3:	Merge SN with N: SN ∪ N
4:	For all a in N
5:	Populate N with the neighboring nodes of a
6:	Merge SN with N: SN ∪ N
7:	Remove all the duplicate nodes in SN
8:	Broadcast SN to c
9:	end for
10:	end procedure

As Algorithm 1 illustrates, the bootstrap node provided a gateway to discover other full nodes as it maintained a list of them. Therefore, we could add as many nodes as necessary to the neighbor list or to the neighbor’s neighbor list and then periodically publish the information regarding these emerging nodes to the channel using an interchange protocol that would prevent a feedback loop and remove duplicate nodes.

In BlockchainBot, if a bot were unplugged by an adversary or appear offline, other bots would not be affected as each bot’s state was not dependent on the other bots. Traditional P2P botnets have not been capable of this.

As Algorithm 2 shows, after receiving the list of full nodes in the channel, a bot would be able to randomly connect to a full node. This ensured that most of the bots could connect to different full nodes, as opposed to clustering around only a few. The purpose of bot-cluster dispersing was to prevent a large portion of bots from being disabled if a full node were disabled.

Algorithm 2: Random Full Node Connection
Input:	c: The channel used for publishing full nodes addresses; SN: a set of neighboring full nodes enumerated by Algorithm 1;
Output:	a: the full node to which the bot has selected randomly to connect to.
Procedure:	begin
1:	Listen to c;
3:	Get information of full nodes published by Algorithm 1 from c and store them in SN.
4:	Randomly pick a node a from SN.
5:	Connect to a
6:	end procedure

4.4. The Forking of the Channel

When attempting to disable a botnet, the adversary often deploys spy bots disguised as normal bots to probe the variance of intelligence of the botnet. Although these spies behave similarly to normal bots, they do not respond to commands issued by the botmaster or send valuable digital trophies back. Therefore, if a botmaster suspects tampering, he would be able to simply turn off the CDC. Furthermore, only the full node enumeration and dispersing channel would need to be reinforced due to its open access to all the bots with its channel ID hardcoded in the binary executions. We provided an anti-intelligence probing scheme, “Forking”, to ban suspect bots from collecting information within the botnet. Figure 14 provides an overview.

As Figure 14 demonstrates, at time T + 3 and after published message 3 (which has information of the full nodes enumerated, in part, by Algorithm 1), the botmaster discovered suspect bots. Therefore, he could fork the channel at message 3 via two steps:

(1)

Changing the sidekey of the channel and making message 4 not available to all the bots, or

(2)

Informing the loyal bots about the new sidekey through the CDC.

If a similar situation occurred at T + 5, the botmaster could repeat the steps. The technique for forking is to change the mamState object of MAM, which is a temporary structure for generating MAM, and it is invisible to anyone other than the MAM owner. Its components are depicted in Figure 15.

As shown in Figure 15, the MAM object was actually a JSON object and its main components were a seed that generated the MAM Merkel tree, a channel state object recording the status of the current channel that would change when new messages were input (along with its sub-components), and an argument that stored the subscribers of the current channel. For forking, the botmaster would need to change the sidekey, which would consequently change the channel’s state, leaving other parameters in the MAM object untouched (especially the seed, which must not change during our forking plan as the MAM Merkle tree was derived from it). Subsequently, he would dispatch the new sidekey to the loyal bots via the CDC, and the suspected bots would no longer have access to the full node enumeration and dispersing channel.

5. Efficacy and Performance Analysis

In this section, we first demonstrate the necessity of Algorithm 1 and then show its effectiveness in

Table 3. Full nodes enumerated by Algorithm 1.

Full Node Address	Port	IOTA Version	SSL	Neighbors
Node3.itrocks-latus.de	14267	0.5.6	Yes	4
Node2.itrocks-latus.de	14267	0.5.6	Yes	4
Node1.itrocks-latus.de	14267	0.5.6	Yes	5
iota.fan.ch	14267	0.5.6	Yes	5
tr.cbus.io	443	0.5.6	Yes	1
node.cbus.io	443	0.5.6	Yes	4
v2202101139835141056.ultrasrv.de	14267	0.5.6	Yes	3
node1.rosipay.net	443	0.5.6	Yes	5
stirrlink.dyndns.org	14267	0.5.6	Yes	5
wallet1.iota.town	443	0.5.6	Yes	4
wallet2.iota.town	443	0.5.6	Yes	5
pow.iota.community	443	0.5.6	Yes	6
nodes.iota.cafe	443	0.5.6	No	3
207.180.218.59	14265	0.5.6	No	6
207.180.202.219	14265	0.5.6	No	3
207.180.225.229	14265	0.5.6	No	4
turbor.ddns.net	14265	0.5.6	No	3
195.201.114.197	14265	0.5.6	No	5
node.iotadev.org	14265	0.5.6	No	6
81.169.167.13	14265	0.5.6	No	4
node2.iota.town	14265	0.5.6	No	5
173.249.16.120	14265	0.5.6	Yes	5
nodes.thetangle.org	443	0.5.6	No	24
185.53.131.77	14265	0.5.6	Yes	4
papa.iota.family	14267	0.5.6	Yes	4
mama.iota.family	14267	0.5.6	Yes	5
hornet.eiter.tirol	443	0.5.6	Yes	4
xeevee.net	14267	0.5.6	Yes	2
65.21.34.166	14265	0.5.6	Yes	3
3.122.198.108	14265	0.5.6	Yes	2
95.217.89.99	14265	0.5.6	Yes	3
gewirr.com	14267	0.5.6	Yes	4

. Secondly, the performance of the BlockchainBot was examined with two main metrics of the botnet via experiments.

The IOTA full nodes, especially those supported by the IOTA community, are residents with high availability and undertake a high number of transactions on Tangle, so the risk of being shut down was low. However, to further promote the resilience and robustness of the BlockchainBot, Algorithm 1 discovered as many full nodes as possible. Table 3 provides the nodes enumerated by Algorithm 1 up to the date of publication, and the rows within Table 3 were aggregated until the algorithm was halted.

As denoted in Table 3, while collecting IOTA nodes, we also obtained additional information about each node such as the port number used, SSL support, and the neighboring number of nodes. To guarantee that the full-node-record channel could not be attacked or forged, one simple but effective measure was to require a signature generated by the botmaster’s private key to authenticate the messages.

As discussed in Section 2, communication between the botmaster and the bots must be instantaneous for a botnet to be successful. We used the speed of communication and the cost of message dissemination as metrics by which to compare our model to previously developed POCs. We used Ethereum (Kovan test chain) and IOTA Testnet as benchmarks for an accurate comparison. Experimental conditions are listed in

Table A1. Transaction details for performance comparison.

Data Size	Sender Address	Receipt Address	Transaction Hash
40KB	0xf93f66753f61df77218cf1154fb804bd2d170616	0x744ec433f89dbc65b79e091085d28a0bdeac84f5	0x1d2c0fc356435cc9bae7cfdf8eb0ddfdc9257ace932977d8c10271a36d07443f
60KB	0xf93f66753f61df77218cf1154fb804bd2d170616	0x744ec433f89dbc65b79e091085d28a0bdeac84f5	0xc3d6ef955f5281dbac6a85af19d76f1757768c7844b76e75a3d22cdd3d2cf52f
80KB	0xf93f66753f61df77218cf1154fb804bd2d170616	0x744ec433f89dbc65b79e091085d28a0bdeac84f5	0x1c61441342cfddb865eb52579ec317d1bb5a2af35eb5ce3086d7ca5ddce126b5

(Appendix A).

On Testnet and Mainnet, sending excessive transactions within a short period of time is considered malicious spamming and can result in a user being banned. During our experiments, we were banned several times. Furthermore, on IOTA’s Tangle, only those transactions with value transfers are stored; messages with no value transfer are eventually erased. The results of our analysis are shown in Figure 16 and

Table 4. The cost of message transmission comparison between the BlockchainBot and Bitcoin and Ethereum public blockchains.

Data Size	Cost of Bitcoin	Cost of Ethereum	Cost of Our Scheme
40KB data	$3548	$35.102	$0
60KB data	$5322	$52.979	$0
80KB data	$7096	$70.224	$0

.

As shown in Table 4, the cost of transferring data of different sizes was zero for our model; however, the costs are prohibitive using the Bitcoin blockchain. Although the cost of transferring data on Ethereum was much cheaper, as compared to Bitcoin blockchain, when the number of bots increased, the cost would rise rapidly and become prohibitive as well. Between the high costs and high latency of public blockchains, we concluded once again that they were not feasible frameworks on which to implement a large-scale botnet.

In addition, we tested the efficacy of the channel forking method we designed in Section 4.2. In the experiment, we assumed that the botmaster had identified the adversary’s spying nodes and that he would publish new information regarding the full nodes enumerated on the root where the previous list, now accessible to the adversary, was located. The parameters of the experiments of forking are shown in

Table 5. Original parameters before forking.

The Seed	Channel Mode	Sidekey	Message	IOTA Portal Provider
9SVFMVXNRZYXLEPGLDICYBXNNC9PMWHGLSSTAN99B9ESWYDVIRGOWTDWHIZSBSDZT9NNROWUWPNBBEQBJ	Restricted	“VERYSECRETKEY”	wallet1.iota.town	https://nodes.devnet.iota.org:443
			wallet2.iota.town
			node.iotadev.org

.

As shown in Table 5, the botmaster published three full node addresses in the channel, and he set the sidekey of the channel to “VERYSECRETKEY”. On the IOTA Foundation’s MAM explorer, the messages were confirmed on IOTA’s Tangle, as shown in Figure 17.

After publishing the three full node addresses on Tangle, the botmaster would then discover the adversary’s nodes and launch the forking method we proposed. The new parameters for forking are listed in

Table 6. New parameters for forking.

The Seed	Channel Mode	Sidekey	Message	IOTA Portal Provider
9SVFMVXNRZYXLEPGLDICYBXNNC9PMWHGLSSTAN99B9ESWYDVIRGOWTDWHIZSBSDZT9NNROWUWPNBBEQBJ	Restricted	“ANOTHER”	xeeve.net	https://nodes.devnet.iota.org:443

. The results are presented in Figure 18.

As shown in Figure 18, the botmaster changed their sidekey to “ANOTHER” while leaving the other arguments untouched, and the channel ID, which is the root, also remained the same (see Figure 17 for comparison). However, by changing the sidekey from “VERYSECRETKEY” to “ANOTHER” and informing the other loyal bots via the CDC, the botmaster revoked access by the spy nodes without the adversary’s awareness of the change. Therefore, the effectiveness of the forking method for this scenario was confirmed.

In addition, we evaluated the bot’s response time against our baseline testing (ZombieCoin2.0, see Figure 19). We defined a bot’s response time as the time period between when the botmaster issued an instruction and it was successfully received by the bot over IOTA’s Tangle network. (This definition was the same for ZombieCoin2.0). All bots successfully received the botmaster’s instructions. Figure 11 plots the cumulative probability distribution of the bot response time. As Figure 11 shows, the BlockchainBot had faster response times. Furthermore, as compared to ZombieCoin2.0 which had outliers with extremely long response times (100–260 s), the BlockchainBot’s longest response time was less than 10 s.

Our model performed even challenging tasks such as file transfers and instant messaging with low latency and negligible overhead expenses. By eliminating the vulnerabilities and addressing the unique challenges of using DLT as a framework for a P2P botnet, we created a versatile model that achieved low-latency bidirectional communication between botmaster and bot.

6. Security Analysis

6.1. Threat Model

The adversary had the following abilities:

(1)

The adversary could capture a maximum of one-third of the full nodes of IOTA and could inspect all the data they possessed.

(2)

The adversary could interfere with or jam the traffic of the botnet by overwhelming them with trash data (DDoS).

(3)

The adversary could analyze the data they obtained from the full nodes and gather information about the botnet; this would take time, however.

6.2. Security Assumptions

We made four assumptions about our model and the constraints of the adversary:

(a)

The cryptographic primitives used in IOTA and our model were safe (such as encryption and hash functions). Current research has suggested that the total computational power of the adversary would be confined to standard cryptographic assumptions of probabilistic polynomial-time.

(b)

The IOTA Foundation was trustworthy as were Random.org and Cloudflare. Python’s RandomSystem pack was trustworthy. They would not be corrupted by the adversary to generate random numbers as the adversary commands. In our model, the seed of the botmaster was generated using a pseudo-random number generator (PRNG). The adversary was not able to predict future PRNG outputs as he could not influence the entropy source used in our scheme to initialize or refresh the internal state of the PRNG. The adversary was not able to predict future results as he could not compromise the internal state of the PRNG used in our scheme.

(c)

No more than one-third of the total number of full nodes on Tangle’s network could be silenced by the adversary. This was required by the fast probabilistic consensus [39] (FPC, a variant of the byzantine consensus) that IOTA’s Tangle adopts.

(d)

Due to the global distribution of the full nodes, any forensic investigations would be required to cross international borders to gain information, and we assumed this would take a reasonable amount of time to accomplish and would not necessarily be an easy task.

6.3. The Security of DDoS Protection

The adversary may try to overwhelm the normal botnet’s traffic via spamming while the possibility of flooding the whole network with junk on many famous public DLTs was asymptotically zero due to the transaction fees and the computation difficulty of POW. However, due to the fact that there were no transaction fees or miners on IOTA’s Tangle, the harm to our botnet caused by spamming was theoretically possible. Empirically, our botnet was sheltered by the rate control mechanism of IOTA’s Tangle. If a node i wants to issue a transaction at time t, it must first solve a hash problem. While this may be similar to POW, it is several orders of magnitude easier than Bitcoin’s. The difficulty of the problem was determined by Equation (3):

$$d_i(t)=d_0+\lfloor {\gamma }_i\cdot a_i(t)\rfloor$$

(3)

In Equation (3), d_i(t) is the final difficulty of the hash problem. The parameter d₀ is the base difficulty, and γ_i represents the adaption rate, which ranges from 0 to 1, providing flexible control of the rate of the difficulty. The a_i(t) denotes the number of transactions already issued by node i at time period [t-w, t] (w represents a time interval elapsed, during which node i has sent a_i(t) transactions). Assuming γ_i equals 1, the adversarial node i can attempt the hash computation for μ times (which can represent the computational capacity of node (i) in a second (and solving a hash problem can take many attempts). The variable b denotes the mean number of hash computation attempts needed to solve the hash problem at a base difficulty of d₀. Hence, the number of attempts μ that can be computed by node i during w produces an upper bound on the node’s throughput:

$$b\cdot 3^{d_0}+b\cdot 3^{d_0+1}+b\cdot 3^{d_0+2}+b\cdot 3^{d_0+3}+\cdot \cdot \cdot +b\cdot 3^{d_0+a_i(t)}\le \mu w,$$

(4)

In the design of IOTA’s Tangle, the number of attempts triples for each increment of the difficulty; thus, an attempt at difficulty d₀ should be $b\cdot 3^{d_0}$. An attempt at difficulty d₁ should be $b\cdot 3^{d_0}\cdot 3$, which is $b\cdot 3^{d_0+1}$, and so on. After some computation, we found

$$b\cdot {\displaystyle \sum _{j=0}^{a_i(t)}{3}^{d_0+j}}\le \mu w,$$

(5)

Which is

$$b\cdot \frac{3^{d_0+a_i(t)}-1}{3^{d_0}-1}\le \mu w,$$

(6)

The variable a_i(t) should be lower than:

$${\log }_3(\frac{w\cdot (3^{d_0}-1)}{b}\cdot \mu +1)-d_0,$$

(7)

Therefore, the throughput θ of a node i can be derived from the quotient of a_i(t) and w:

$${\theta }_i=\frac{a_i(t)}{w},$$

(8)

We found:

$${\theta }_i\le \frac{{\log }_3(\frac{w\cdot (3^{d_0}-1)}{b}\cdot \mu +1)-d_0}{w},$$

(9)

For example, assuming that the base difficulty d₀ = 1, b = 1, and μ = 10,000,000, the pattern of θ_i would be acquired according to Figure 20:

As Figure 20 demonstrates, the throughput θ_i of the adversarial node would decrease rapidly with an increase of time, meaning that the difficulty of the hash problem would soar if the adversary attempted to overwhelm the botnet with spamming transactions. They would require an increasing amount of time to solve the hash problem before they could issue additional transactions. Therefore, the DDoS threat was neutralized.

6.4. The Security of Bot Cluster Dispersing

As assumption (b) illustrated, one-third of the full nodes could be overtaken by the adversary. We considered an extreme example, where all the bots were connected to one single full node before it was corrupted and controlled by the adversary. By shutting down the full node, the adversary would be able to disable the bots for a period of time. Once the bots realized they had lost contact with the full node, they would connect to another one. Until this point, though, it would cause significant disruption on the botnet. Therefore, to avoid such a scenario, each bot should choose its full node randomly, distributing them uniformly among full nodes once again. Once they had done so, the adversary could not cause great disruption.

6.5. The Security of Anti-Forensics

As mentioned previously, IOTA’s Tangle does not permanently store messages with identifiable information; instead, it uses a “snapshot” to strip the unnecessary data from the records and condense their size. This can impede forensic investigations into the data, which would be advantageous for a botnet.

In order to find and capture the botmaster, an adversary must take over the full nodes that the botmaster had connected to using proxies or VPNs and investigate them thoroughly. We assumed this process would take at least a full day to accomplish. Let n be the number of all the full nodes participating in Tangle’s network and k (far less than n/3) represents the time interval (in days) of the snapshot. Let l be the lower bound of consecutive times that the adversary finds the full node successfully to which the botmaster connects. Let A represent the likelihood of accurately tracking the botmaster. Thereby, the possibility P(A) of successively continuing the forensic investigation into the botmaster for l times is:

$$P\left(A\right)\le {\left(\frac{k}{n}\right)}^l,$$

(10)

Our prior work found that IOTA’s Foundation takes a snapshot of all full nodes less than once every 30 days. This number should be less in the operation of full nodes by other non-official individual operators, so we assumed that k = 30 was reasonable. To avoid a false positive when identifying and tracking the botmaster, the success of the forensic investigation should be as large as possible; thus, we assumed l = 10. The number of participating nodes in DLT is massive, so we let n = 1000 (conservatively). Therefore, we obtained a P(A) less than 5.904899999999998·10⁻¹⁶. We found that capturing the botmaster via breaching the BlockchainBot would be difficult, especially under real-world conditions.

Figure 21 shows the possibility of successfully collecting sufficient information to track the botmaster; we found that the number would be asymptotically closer to zero as long as the number of the full nodes was large enough.

6.6. The Security of Channel Forking

Our channel was built upon MAM and used signatures to secure the authorship of itself. Only the owner of the seed could publish messages. In the early stages of IOTA’s Tangle, a hash algorithm, Curl, was used to generate signatures. After MIT researchers found that their implementation of Curl had collision risks [40,41], Curl was substituted by Kerl [42], a secure implementation of hash function Keccack-384, for signature generation and verification. As assumption (a) indicated, the adversary could not forge the signature in polynomial time, so the security of our channel forking method was guaranteed.

6.7. The Resilience against Sybil Attacks

A Sybil attack [43] is an effective method to terminate P2P botnets by creating many fake identities and inserting them into the bot’s routing table to re-route the command queries and eventually disrupt the botmaster’s C&C communication. Although P2P botnets are vulnerable to this kind of attack, our model was not as the bots did not connect with each other. Therefore, our model was inherently resilient against this type of attack.

7. Discussion

As DLT is extremely proficient in protecting the identities of its participants and its decentralization makes it nearly indestructible, interrupting and disabling botnets using DLT as a foundation will be challenging. Law enforcement may analyze the activity of the botmaster’s (public) address on DLT and their interaction with other addresses and, with some hefty data analysis, eventually, deduce the identity of the botmaster.

Another method could be by deploying a full node owned by the adversary and waiting for it to be enumerated by Algorithm 1. The adversary could lure the botmaster to connect and obtain their basic network information, such as IP addresses and port numbers. The botmaster’s network traffic could reveal their identity. However, since the botmaster can choose the full nodes for their networked connections, choosing only full nodes with high credibility such as those operated by IOTA’s Tangle Foundation and the community would neatly sidestep this method.

The channel forking method, as a countermeasure against the adversary’s information gathering, was able to prevent a suspect from permanently infiltrating the botnet, though it was powerless to detect and identify the suspicious nodes. As long as the spying scout is discreet, they can theoretically lurk without being noticed. Therefore, an effective mechanism for accurately discerning spies is required.

In addition, in the process of a bot sending a channel ID back, the adversary may try to confuse the botmaster by sending trash data into the channels, which would not only overwhelm the channel but could also possibly deplete the computational and network resources of the botmaster.

8. Conclusions and Future Works

The blockchain is naturally adaptable for botnet C&C due to its anonymity, lack of censorship, and resilience against SPoF; however, its high latency and costs required an innovative solution. A large-scale, fully functional botnet built upon DLT with the aid of benign IoT devices as the C&C backbone was created in this study. Our model was versatile in many application contexts such as credentials and data theft, file transfer, information feedback, and instant communication. We overcame the requirements of NL and the risks of SPoF. BlockchainBot is not just a POC; our results indicated that it has the potential to be implemented successfully under real-world conditions.

However, BlockchainBot still requires further research to shore up certain vulnerabilities. Our future research will concern the detection of camouflaged sensor nodes controlled by an adversary as well as interfering with their ability to receive the botmaster’s commands. In addition, most DLTs cannot support larger file storage due to their focus on ledgering. Additional research might consider how to promote the capability of storing large files using DLT.

Given the rapid growth and expansion of blockchain and DLT, botnets will likely become even more destructive and more difficult to suppress. Therefore, efficient mitigations against this emerging threat are gravely needed.