While various covert botnets were proposed in the past, they still lack complete anonymization for their servers/botmasters or suffer from slow communication between the botmaster and the bots. In this paper, we first propose a new generation hybrid botnet that covertly and efficiently communicates over Bitcoin Lightning Network (LN), called LNBot. Exploiting various anonymity features of LN, we show the feasibility of a scalable two-layer botnet which completely anonymizes the identity of the botmaster. In the first layer, the botmaster anonymously sends the commands to the command and control (C&C) servers through regular LN payments. Specifically, LNBot allows botmaster’s commands to be sent in the form of surreptitious multi-hop LN payments, where the commands are either encoded with the payments or attached to the payments to provide covert communications. In the second layer, C&C servers further relay those commands to the bots in their mini-botnets to launch any type of attacks to victim machines. We further improve on this design by introducing D-LNBot; a distributed version of LNBot that generates its C&C servers by infecting users on the Internet and forms the C&C connections by opening channels to the existing nodes on LN. In contrary to the LNBot, the whole botnet formation phase is distributed and the botmaster is never involved in the process. By utilizing Bitcoin’s Testnet and the new message attachment feature of LN, we show that D-LNBot can be run for free and commands are propagated faster to all the C&C servers compared to LNBot. We presented proof-of-concept implementations for both LNBot and D-LNBot on the actual LN and extensively analyzed their delay and cost performance. Finally, we also provide and discuss a list of potential countermeasures to detect LNBot and D-LNBot activities and minimize their impacts.

Index Terms—Bitcoin, lightning network, botnets, covert channel

1 INTRODUCTION

Botnets are networks of computing devices infected with malicious software that is under the control of an attacker, known as bot herder or botmaster [2]. The owner of the botnet controls the bots (i.e., devices that become part of the botnet) through command and control (C&C) server(s) which can communicate with the bots using a C&C channel and can launch various attacks through these bots, including, but not limited to, denial of service (DoS) attacks, information and identity theft, sending spam messages, and other activities. Naturally, a botmaster’s goal is to make it difficult for law enforcement to detect and prevent malicious operations. Therefore, establishing a secure C&C infrastructure and hiding the identities of the C&C servers play a key role in the long-lasting operation of botnets.

Numerous botnets have been proposed and deployed in the past [3], [4]. Regardless of their communication infrastructure being centralized or peer-to-peer, existing botnet C&C channels and servers have the challenge of remaining hidden and being resistant against legal authorities’ actions. Such problems motivate hackers to always explore more promising venues for finding new C&C channels with the ever-increasing number of communication options on the Internet. One such platform is the environment where cryptocurrencies, such as Bitcoin [5], is exchanged. As Bitcoin offers some degree of anonymity, exploiting it as a C&C communication channel has already been tried for creating new botnets [6], [7]. While some of these Bitcoin-based botnets addressed the long transaction validation times, they still announce the commands publicly, where the botnet activity can be traced by any observer with the help of the Bitcoin addresses or nonce values of the transactions. By using Bitcoin for botnet C&C communication, the history of malicious activities are recorded on the blockchain forever.

Nonetheless, the issues regarding the public announcement of commands and leaving traces in the blockchain are already addressed with a Bitcoin payment channel network called Lightning Network (LN) [8]. LN enables off-chain transactions (i.e., transactions which are not announced and thus not recorded on the blockchain) in order to speed up the transaction by eliminating the confirmation time and decreasing fees associated with that transaction. Additionally, users’ identities are more anonymous since the transactions are not announced publicly. In this paper, we show that LN can be exploited as an ideal C&C infrastructure for botnets with all the aforementioned features (i.e., faster transactions, decreased costs, more anonymity). Specifically, LN offers botmasters numerous advantages over existing techniques: First, LN provides very high anonymity since the transactions on the off-chain channels are not recorded on the blockchain. Thus, a botmaster can covertly communicate with the C&C server(s). Second, the revelation of a server does not reveal other servers, and an observer cannot enumerate the size of the botnet. Most importantly, C&C communication over the LN cannot be censored.

• A. Kurt, K. Akkaya, and A. S. Uluagac are with the Department of Electrical and Computer Engineering, Florida International University, Miami, FL, 33174. E-mail: {akurt005, kakkaya, suluagac}@fiu.edu * E. Erdin is with the Department of Computer Science, University of Central Arkansas. E-mail: eerdin@uca.edu * M. Cebe is with the Department of Computer Science, Marquette University. E-mail: mumin.cebe@marquette.edu * *A preliminary version [1] of this work was published in the proceedings of the 25th European Symposium on Research in Computer Security (ESORICS 2020).

Although LN is a fast-growing emerging payment network, it only has around 16,000 nodes which may not be ideal for large-scale botnets. Therefore, we propose a two-layer hybrid botnet to use LN as an infrastructure to maintain a network of C&C servers each of which can run its own botnet. The use of multiple C&C servers has been around for a while [3]. However, the communication with these servers was still assumed to be through the existing communication infrastructures which impairs the servers’ anonymity. Therefore, LN can be utilized to further strengthen the anonymity.

Hence, this paper first presents LNBot, which is the first botnet that utilizes LN infrastructure for its communications between the botmaster and C&C servers with a two-layer hybrid architecture. Specifically, at the first layer, a botmaster maintains multiple C&C servers, which are nodes on the LN that have specialized software to control the bots under them. Essentially, each C&C server controls an independent isolated mini-botnet at the second layer. These mini-botnets are controlled using a specific C&C infrastructure that can rely on traditional means such as stenography, IRC channel, DNS, social media, etc. Botmaster sends the commands to the C&C servers covertly through LN. This two-layer command and control mechanism not only enables scalability, but also minimizes the burden on each C&C server, which increases their anonymity. Second, we present iLNBot which stands for improved version of LNBot that has significantly reduced cost and latency overheads. To achieve this, we employ a new functionality in LN that enables sending messages to other LN nodes by attaching them to the regular LN payments.

However, the proposed LNBot and iLNBot still assume a centralized communication model between the botmaster and C&C servers. To further strengthen the anonymity, we show that a distributed version, namely D-LNBot can be created which forms itself over existing LN nodes. Specifically, we propose to utilize a C&C discovery mechanism where the new C&C servers that join the network can discover some of the previously joined C&C servers and vice versa. This is achieved by using LN channels that are opened to public LN nodes following a specific rule which is only recognizable by other C&C servers. In this way, the management burden on the botmaster is almost completely removed. Additionally, proposed LNBot utilizes LN on Bitcoin Mainnet which incurs non-negligible costs to the botmaster for sending the commands. In D-LNBot, we show that in fact, Bitcoin’s Testnet can also be used instead of the Mainnet to remove any costs that were present in LNBot. Since Testnet Bitcoins can be obtained for free, botmaster will not have to spend any money to send commands nor fund C&C servers’ channels. All these versions follow the same hybrid architecture where the C&C servers control their own mini-botnet through various C&C infrastructures.

To demonstrate the feasibility of the concept, we implemented the all three versions (i.e., LNBot, iLNBot, D-LNBot) using real LN nodes on Bitcoin’s Testnet. For LNBot, we utilize a one-to-many architecture (i.e., botmaster sends the commands to all C&C servers separately) for sending the commands. We show that by encoding the commands into payments sent over LN, one can successfully send commands to the C&C servers that are part of the LN. The C&C servers further relay those commands to the bots they control to launch any type of attack to victim machines. For iLNBot, we use the same one-to-many architecture but the commands are embedded into payments rather than getting encoded. This change let us achieve a 98% reduction on the command sending cost and 99% reduction on the command sending delay. Finally for D-LNBot, we show that the commands can be sent to all the C&C servers with a single payment without spending any money. On top of sending the commands for free, D-LNBot propagates the commands to the C&C servers faster than LNBot and iLNBot.

Our contributions in this work are as follows:

• We first propose LNBot which is a covert and hybrid botnet that uses Bitcoin’s LN for its C&C communications. LN’s strong anonymity features makes it very challenging to stop the botnet.

• Next, we propose iLNBot which is a significantly improved version of LNBot in terms of cost and time spent on sending the commands to the bots.

• We then propose D-LNBot which is a distributed version of LNBot that is superior in cost, delay and resiliency aspects. Specifically, D-LNBot forms itself over LN with minimum botmaster intervention, sends the commands to the bots for free, spends significantly less time to propagate the commands to all the bots.

• We present proof of concept implementations for all three versions and extensively analyze their performance metrics. Some implementation details can be found in our GitHub repository at: https://github.com/startimeahmet/D-LNBot.

• Finally, all these features of LNBot and D-LNBot make them botnets that need to be taken seriously therefore we provide a list of countermeasures that may help detect LNBot and D-LNBot activities and minimize damages from them.

The rest of the paper is organized as follows: Related work is given in Section 2. In Section 3, we give some background information about LN. Section 4 describes the threat model. In Section 5, we describe the architecture and construction of our proposed LNBot. Similarly, in Section 6, we describe the details of our proposed D-LNBot. Section 7 is dedicated to the proof-of-concept implementations of LNBot and D-LNBot in real world settings while Section 8 presents their evaluation results. In Section 9, possible countermeasures for LNBot and D-LNBot are discussed. Finally, we conclude the paper in Section 10.

2 Related Work

Botnets have been around for a long time and there have been even surveys classifying them [2], [10]. While early botnets used IRC, later botnets focused on P2P C&C channels for resiliency [11]. Our proposed LNBot and D-LNBot fall under covert botnets which became popular much later. As an example, Nagaraja et al. proposed Stegobot, a covert botnet using social media networks as a command and control channel [12]. Pantic et al. proposed a covert botnet command and control using Twitter [13]. Tsatsikas et al. proposed SDP-based covert channel for botnet communication [14]. Calhoun et al. presented a MAC layer covert channel based on WiFi [15]. A recent work by Wu et al. [16]

presents a mobile covert botnet network. Another covert botnet design based on social networks was recently proposed by Wang et al. [17]. Tian et al. proposed DLchain [18], a covert channel utilizing the Bitcoin network.

Recently, there have been proposals on using the Bitcoin blockchain for botnet C&C communication [19]. For instance, Roffel et al. [20] came up with the idea of controlling a computer worm using the Bitcoin blockchain. Another work [21] discusses how botnet resiliency can be enhanced using private blockchains. Pirozzi et al. [22] presented the use of blockchain as a command and control center for a new generation botnet. Kamenski et al. [23] also show a proof of concept to build a Bitcoin-based botnet. Similarly, ChainChannels [7] utilizes Bitcoin to disseminate C&C messages to the bots. These works are different from our architecture as they suffer from the issues of high latency and public announcement of commands. ZombieCoin [6] proposes to use Bitcoin’s transaction spreading mechanism as the C&C communication infrastructure. The authors later proposed ZombieCoin 2.0 [24] that employs subliminal channels to increase the anonymity of the botmaster. However, subliminal channels require a lot of resources to calculate required signatures which is computationally expensive and not practical to use on a large scale. A more recent work by Yin et al. [25] proposes CoinBot, a botnet that runs on cryptocurrency networks based on Bitcoin protocol such as Litecoin and Dash. Similar to other Bitcoin based botnets, CoinBot utilizes the \texttt{OP_RETURN} field in the transactions. However, this approach is still costly and command propagation is slow.

There are also Unblockable Chains [26], and Botract [27], which are Ethereum [28] based botnet command and control infrastructures that suffer from anonymity issues since the commands are publicly recorded on the blockchain. Baden et al. [29] proposed a botnet C&C scheme utilizing Ethereum’s Whisper messaging protocol. However, it is still possible to blacklist the topics used by the botmaster. Additionally, there is not a proof of concept implementation of the proposed approach yet, therefore it is unknown if the botnet can be successfully deployed or not.

The closest works to ours are the Franzoni et al. [30] and DUSTBot [31]. Franzoni et al. propose to utilize the Bitcoin Testnet for controlling a botnet. Even though their C&C communication is encrypted, non-standard Bitcoin transactions used for the communication exposes the botnet activity. Once the botnet is detected, the messages coming from the botmaster can be prevented from spreading, consequently stopping the botnet activity. DUSTBot also partially uses the Bitcoin Testnet in its design. Authors propose to utilize the Testnet as the upstream channel for sending the bot data back to the botmaster. However, botmaster’s Bitcoin address is subject to blacklisting which blocks the communication of the botnet.

Finally, there are also botnets that utilize anonymity networks such as Tor [32]. It is tempting for botmasters to use Tor and other anonymity networks due to their privacy and anonymity guarantees. However, there are numerous works in the literature showing ways to detect and stop botnets utilizing Tor. For example, Casenove et al. [33] showed that a botnet over Tor can be exposed due to the recognizable patterns in the C&C communication. Sanatinia et al. [34] proposed a Sybil mitigation technique to neutralize the bots in their proposed OnionBots which is a botnet utilizing Tor. Thus, as can be seen, anonymity networks are susceptible to other unique attacks associated with their inherent characteristics when used for botnet communication.

In contrast, our work is based on legitimate LN payments and does not require any additional computation to hide the commands. Also, these commands are not announced publicly. Moreover, LNBot offers a very unique advantage for its botmaster: C&C servers do not have any direct relation with the botmaster thanks to LN’s anonymous multi-hop structure. Even more, D-LNBot removes the costs that were present in LNBot and enables running a free botnet on LN. As a result, LNBot and D-LNBot do not carry any mentioned disadvantages through their two-layer hybrid architecture and provide superior scalability and anonymity compared to others. We would like to note that, a preliminary version of this paper that proposed LNBot was published in [1]. This paper extends it with D-LNBot and iLNBot along with their design, implementation and analysis.

3 Background

3.1 Lightning Network

The LN concept is introduced in [8]. It is a payment protocol operating on top of Bitcoin. Through this concept, an overlay payment channel network (i.e., LN) is started among the customers and vendors in 2017. The aim in creating the LN was to decrease the load on the Bitcoin network, facilitating transactions with affordable fees and reduced transaction validation times, and thus increasing the scalability of Bitcoin [35], [36]. Despite the big fluctuations in the price of Bitcoin recently, the LN grew exponentially reaching 16,359 nodes and 73,580 channels in five years by the time of writing this paper.

In the following subsections, we briefly explain the components of LN.

3.2 Off-chain Concept

The main idea behind LN is to utilize the off-chain concept which enables near-instant Bitcoin transactions with negligible fees. This is accomplished through bidirectional payment channels which are created among two parties to exchange funds without committing the transactions to Bitcoin blockchain. The channel is opened by making a single on-chain transaction called the funding transaction. The funding transaction places the funds into a 2-of-2 multisignature address which also determines the capacity of the channel. Whenever the parties want to send a payment, they basically shift corresponding portion of their channel balance to the other side of the channel. So, after a transaction takes place, the total capacity in the channel does not change but the directional capacities do. Therefore, the peers can make as many transactions as they want in any amount as long as the amount they want to send does not exceed the directional capacity. The example shown in Fig. 1 illustrates the concept in more detail.

Per figure, 1 Alice opens a channel to Bob by funding 5 Bitcoins into a 2-of-2 multi-signature address which

1. https://1ml.com

is signed by both Alice and Bob. Using this channel, Alice can send payments to Bob simply by transferring the ownership of her share in the multi-signature address until her funds in the address are exhausted. Note that these transactions are off-chain meaning they are not written to the Bitcoin blockchain which is a unique feature of LN that is exploited in our botnet. Alice performs 3 transactions at different times with amounts of 1, 2 and 1 Bitcoin respectively. Eventually, when the channel is closed, the remaining 1 Bitcoin in the multi-signature address is returned to Alice while the total transferred 4 Bitcoins are settled at Bob. Channel closing is another on-chain transaction that reports the final balances of Alice and Bob in the multi-signature address to the blockchain.

3.3 Multi-hop Payments

In LN, a node can send payments to another node even if it does not have a direct payment channel to that node. This is achieved by utilizing already established payment channels between other nodes and such a payment is called multi-hop payment since the payment is forwarded through a number of intermediary nodes (i.e., hops) until reaching the destination. This process is trustless meaning the sender does not need to trust the intermediary nodes along the route. Fig. 2 depicts a multi-hop payment. Alice wants to send a payment to Bob but does not have a direct channel with him. Instead, she has a channel with Charlie which has a channel with Bob, thus Alice can initiate a payment to Bob via Charlie. For this to work, Bob first sends an invoice to Alice which includes the hash ( H ) of a secret ( R ) (known as pre-image). Then, Alice prepares the payment through a contract called Hash Time Locked Contract (HTLC) and includes ( H ) inside the payment. HTLCs are used to ensure that the payments can be securely routed over a number of hops. Now, Alice sends this HTLC to Charlie and waits for Charlie to disclose the ( R ). That is the condition for Alice to release the money to Charlie. In the same way, Charlie expects Bob to disclose ( R ) so that he can send it to Alice the claim the money. Finally, when Bob releases the ( R ) to Charlie, the payment will have successfully sent and HTLC will have fulfilled. Through this mechanism of LN, as long as there is a path from the source to the destination with enough liquidity, payments can be routed just like the Internet.

3.4 Key Send Payments

Key send in LN enables sending payments to a destination without needing to have an invoice first \cite{37}. It utilizes Sphinx \cite{38} which is a compact and secure cryptographic packet format to anonymously route a message from a sender to a receiver. This is a very useful feature to have in LN because it introduces new use cases where payers can send spontaneous payments without contacting the payee first. In this mode, the sender generates the pre-image for the payment instead of the receiver and embeds the pre-image into the Sphinx packet within the outgoing HTLC. If an LN node accepts key send payments, then it only needs to advertise its public key to receive key send payments from other nodes. We utilize this feature to send payments from botmaster to C&C servers in LNBot, iLNBot and D-LNBot.

3.5 Source Routing, Onion Routed Payments and Private Channels

With the availability of multi-hop payments, a routing mechanism is needed to select the best route for sending a payment to its destination. LN utilizes source routing which gives the sender full control over the route for the payment to follow within the network. Senders are able to specify: 1) the total number of hops on the path; 2) total cumulative fee they are willing to pay to send the payment; and 3) total time-lock period for the HTLC \cite{39}. Moreover, all payments in LN are onion-routed payments meaning that HTLCs are securely and privately routed within the network. Additionally, by encoding payment routes within a Sphinx packet, the following security and privacy features are achieved: the nodes on a routing path do not know: 1) the source and the destination of the payment; 2) their exact position within the route; and 3) the total number of hops in the route. Consequently, these features prevent any node from easily censoring or analyzing the payments.

In LN, it is optional to announce the opened channels publicly. The channels that are not publicly announced to the network are called private channels. They are only known by the two peers of the channel. Other users cannot use the private channels to route payments over them. However, it is still possible to utilize these channels for routing payments with the help of routing hints. Routing hints are used to let the sender know how to reach an LN node behind a private channel.

3.6 Attaching Messages to the Payments

Recent developments in LN made it easier to attach arbitrary data to the payments. A protocol to enable this functionality was developed at 2019(^4). Later, the protocol was incorporated to the Core Lightning through the noise plugin [^4]. We utilize the plugin for sending botmaster’s commands to the C&C servers in iLNBot and D-LNBot. Messages are included in the payload inside the onion packets that are routed over the hops until reaching the recipient. Onion size is 1300 bytes, thus theoretically, messages of size up to 1300 bytes can be sent in a single payment. This is much higher than the size allowed by the OP_RETURN field in Bitcoin transactions which allows carrying only 80 bytes of data. The protocol carries the following information inside the onion payload: 1) key send pre-image, 2) message of variable size, 3) compressed signature and recovery id, and 4) timestamp. Intermediary nodes cannot see the payload inside the onion packet thus the messages can be anonymously sent to the recipients. Note that, different LN implementations might have a different version of this protocol or may not have it at all.

4 Threat Model

The potential adversaries to the proposed botnets and to any botnet system in general include the governments, law enforcement, and security researchers who actively discover new botnets and develop methods to stop them. We assume that these parties can work with Internet Service Providers (ISPs) to track down IP addresses and physically locate devices. They possess access to advanced security and debugging software, including packet analyzers and tracing tools. Moreover, they are capable of reverse engineering the botnet malware, monitoring on-chain Bitcoin transactions, and deploying their own Bitcoin and LN nodes.

With these capabilities, attackers can perform various attacks, including compromising the bots and ultimately a C&C server. They can also identify the hardcoded parameters within the botnet malware, conduct timing analysis on certain LN payments to detect the botmaster, send payments to C&C servers to corrupt the commands, analyze on-chain payments generated by the botnet to expose the botmaster, analyze the network packets of certain LN payments, and attempt to blacklist specific nodes in the Bitcoin and LN networks by reaching out to Bitcoin and LN developers. Lastly, they might even attempt to reset Bitcoin’s Testnet or completely shut down LN.

---

2. https://write.as/arshbot/everything-you-need-to-know-about-hints-in-the-lightning-network
3. https://github.com/lightning/bolts/pull/619
4. https://github.com/joostjager/whatsat

---

5 LNBot Architecture

In this section, we describe the overall architecture of LNBot with its elements.

5.1 Overview

The overall architecture is shown in Fig. 3. As shown, the LN is used to maintain the C&C servers and their communication with the botmaster. Each C&C server runs a separate mini-botnet. Receiving the commands from the botmaster, the C&C servers relay the commands to the bots in their possession to launch attacks. The details of setting up the C&C servers are explained next.

5.2 Setting up the C&C Servers

The botmaster sets up the necessary number of C&C servers s/he would like to deploy. Depending on the objectives, the number of these servers and the number of bots they will control can be adjusted without any scalability concern. In Section 7, we explain how we set up real C&C servers running on LN on the real Bitcoin network.

Each C&C server is deployed as a private LN node which means that they do not advertise their channels within the LN. This helps C&C servers to stay anonymous in the network. Each C&C server opens private channels to at least ( k ) different random public LN nodes. The number ( k ) may be tuned depending on the size and topology of LN when LNBot will have deployed in the future. To open the channels, C&C servers need some Bitcoin in their Bitcoin wallets. This Bitcoin is provided to the C&C servers by the botmaster before deploying them. Since C&C servers’ channels are unannounced (i.e., private) in the network, botmaster uses routing hints to be able to route his/her payments to the C&C servers. In this case, since the C&C servers are set up by the botmaster, s/he knows the necessary information to create the routing hints.

5.3 Formation of Mini-botnets

After the C&C servers are set up, we need bots to establish connections to the C&C servers. An infected machine (bot) connects to one of the C&C servers available. The details of bot recruitment and any malware implementation issues are beyond the objectives of this paper. It is up to the botmaster to decide which type of infrastructure the C&C servers will use to control the bots in their possession. This flexibility is enabled by our proposed two-layer hybrid architecture of the LNBot. The reason for giving this flexibility is to enable scalability of LNBot through any type of mini-botnets without bothering for the compromise of any C&C servers. As it will be shown in Section 9, even if some of the C&C servers are compromised, this neither reveals the other C&C servers nor the botmaster.

5.4 Forming LNBot

Now that the C&C servers are set up and mini-botnets are formed, the next step is to form the infrastructure to control these C&C servers covertly with minimal chances of getting detected. This is where LN comes into play. Botmaster has the LN public keys of all the C&C servers. Using an LN…

node called LNBot master server, the botmaster initiates the commands to all the C&C servers through LN payments. Similar to the C&C servers, LNBot master server is also a private LN node and the botmaster has flexibility on the setup of this node and may change it regularly. Without using any other custom infrastructure, the botmaster is able to control the C&C servers through LN, consequently controlling all the bots in the botnet.

5.5 Command Propagation in LNBot

Once the LNBot is formed, the next step is to ensure communication from the botmaster to the C&C servers. We utilize a one-to-many architecture where the botmaster sends the commands to each C&C server separately. Commands can be sent in two different ways: 1) Encoding the characters in the command to individual LN payments; 2) Attaching the whole command to a single LN payment. The first method is utilized in LNBot and the second one is utilized in iLNBot. These two methods are explained separately at the sections below.

5.5.1 Encoding/Decoding Schemes

An important feature of LNBot is its ability to encode botmaster’s commands into a series of LN payments that can be decoded by the C&C servers. We used ASCII encoding and Huffman coding [41] for the purpose of determining the most efficient way of sending commands to the C&C servers in terms of Bitcoin cost and time spent. American Standard Code for Information Interchange (ASCII) is a character encoding standard that represents English characters as numbers, assigned from 0 to 127. Huffman coding on the other hand is one of the optimal options when the data needs to be losslessly compressed. We used Quaternary numeral system to generate the codebook as will be shown in Section 8.

For both methods, botmaster uses the Algorithm 1 to send the commands. S/he first checks if the respective C&C server is online or not (LN nodes have to be online in order to send and receive payments) before sending any payment. If the C&C server is not online, command sending is scheduled for a later time. If online, the botmaster sends 5 satoshi as the special starting payment of a command, then the actual characters of the command one by one. Lastly, the botmaster sends 6 satoshi as the special ending payment to finish sending the command. Note that the selection of 5 satoshi and 6 satoshi in this algorithm depends on the chosen encoding and could be changed based on the needs. If any of these separate payments fail, it is retried. If any of the payments fail for more than $k$ times in a row, command sending to the respective C&C server is canceled and scheduled for a later time.

5.5.2 Noise Plugin Method

When LNBot was introduced, attaching custom data to LN payments was a work in progress by the LN developers.

Algorithm 1: Send Command

1 define k;
2 initialize command;
3 int counter = 0; /* retry count */
4 bool isOnline = checkIfC&CServerIsOnline();
5 if isOnline then
6   bool result = send(5 satoshi);
7   if result==success then
8     counter = 0;
9     for character in command do
10        bool result = send(character);
11        if result==success then continue;
12        else if result==fail and counter < k then
13           retry sending character;
14           counter++;
15        else reschedule(command, date, time);
16     end
17     counter = 0;
18     bool result = send(6 satoshi);
19     if result==success then
20        Command has been successfully sent!
21        else if result==fail and counter < k then
22           retry sending 6 satoshi;
23           counter++;
24        else reschedule(command, date, time);
25     end
26     else if result==fail and counter < k then
27        retry sending 5 satoshi;
28        counter++;
29    else reschedule(command, date, time);
30  end
31```

As explained in Section 3.6, noise plugin [40] gives one the opportunity to embed messages in LN payments. If we utilize this plugin in LNBot for sending botmaster’s commands, the command sending will be much faster and cheaper. Specifically, the delay of sending a command to a C&C server will be reduced to a delay of sending a single payment. In the same way, the cost of sending a command will now be the cost of sending a single payment. Thus, we propose iLNBot which utilizes the noise plugin as its command sending mechanism instead of the encoding method presented earlier.

5.6 Reimbursing the Botmaster

Another important feature of LNBot is the ability of its botmaster to get the funds back from the C&C servers. Depending on botmaster’s command propagation activity, C&C servers’ channels will fill up with the funds received from the botmaster. Therefore, in our design, C&C servers are programmed to send the funds in their channels to an LN node called collector when their channels fill up completely. Collector is a private LN node set up by the botmaster. Its LN public key is stored in the C&C servers and thus they can send the funds to collector through LN. In addition to collector’s LN public key, C&C servers are also supplied with routing hints to be able to successfully route their payments to the collector. In this way, the funds accumulate at the collector. The botmaster can collect these funds by closing collector’s respective LN channels and sending the settled Bitcoins to his/her own Bitcoin wallet through on-chain transfers.

6 D-LNBOT ARCHITECTURE

The LNBot we presented in the previous section relies on a centralized model where the botmaster communicates with each C&C server separately. Additionally, in LNBot, C&C servers are manually set up by the botmaster which incurs several operating costs on the botmaster that grows with each installed C&C server. Specifically, botmaster needs to create machines to run the C&C servers and the LN nodes on them as well as fund each of these LN nodes which costs time and money. On top of that, LNBot’s centralized design might tamper the anonymity of the botmaster and the C&C servers. Therefore, in this section, we present a distributed version of LNBot, namely D-LNBot, where the payments sent by the botmaster are reduced to a single transaction (i.e., to a specific C&C server) regardless of the size of the botnet. On top of the distributed design, we propose to utilize the Bitcoin Testnet instead of the Mainnet which removes the associated costs of running the botnet.

6.1 Overview

In this section, we describe the overall architecture of D-LNBot with its elements. LN is used for the communication between the botmaster and the C&C servers also among the C&C servers themselves. Different than LNBot, in D-LNBot, botmaster does not send the commands to each C&C server individually. Rather, the commands are just sent to one of the C&C servers which relays them to all other C&Cs distributively as will be explained in the subsequent sections. We illustrated this difference in command sending between the LNBot and D-LNBot in Fig. 4. We propose to utilize the noise plugin for sending the commands. Similar to the LNBot, each C&C server controls a mini-botnet which can utilize any existing known C&C infrastructure in the literature.

![Fig. 4. Comparison of the command propagation between LNBot and D-LNBot.](image)

6.2 Creation of the C&C Servers

The way that the C&C servers are created differs from the LNBot. Botmaster infects existing machines on the Internet to turn them into C&C servers. Thus, s/he deploys a malware into the wild for this purpose. Deployment details of...

this malware is out of the scope of this paper. However for later reference, we will call it the malware$_1$. Once a machine is infected with malware$_1$, there are two possibilities: 1) With probability $p$, the machine becomes a C&C server or 2) with probability $1-p$, nothing happens and the malware deletes itself. Ultimately, the probability $p$ should be less than 0.5 to ensure that C&C servers are generated occasionally. The reason for not turning every infected machine into a C&C server is to limit the number of C&C servers that will be ever created. If botmaster lets every infected machine to turn into a C&C server, that will increase the number of public LN nodes in LN on Bitcoin’s Testnet dramatically. As of May 2023, LN on Bitcoin’s Testnet have around 2,400 public nodes.$^5$ Considering how fast a malware can infect new machines, we propose that it is best to limit the number of C&C servers that can be generated with the malware. There might be several ways to do this and we leave its design to the botmaster. After this process, if the machine turns into a C&C server, it will download an LN software first. We propose to go for an LN light client instead of a full LN node since downloading a full LN node may alert the user of the infected machine as the download size is around 480 GB at the time of writing this paper. Light LN clients such as Neutrino $^6$ occupy a very small space (around 1 MB) on the file system and have higher chances of going unnoticed by the users. After the LN node is created and initiated, it needs to be funded with some Testnet Bitcoins. For this, we suggest to use a pre-funded Testnet Bitcoin wallet where the C&C server can fetch the Bitcoins from. Generally, Testnet Bitcoins are obtained from Testnet faucets.$^6$ The procedure of pre-funding a wallet can be tailored by the botmaster to leave as little on-chain trace as possible. After the C&C server obtains some Testnet Bitcoins, the next step is the recruitment of the bots to work under the C&C server (i.e., formation of the mini-botnet).

6.3 Formation of the Mini-botnets

Similar to the LNBot, the botmaster uses a specific malware for this purpose. Let us call it malware$_2$. The machines that are infected with malware$_2$ become bots and connect to the available C&C servers. When enough number of machines are infected with malware$_2$, they form a mini-botnet which are controlled by their respective C&C server. Here, the command and control infrastructure to control the bots can be different for each mini-botnet. There are many available C&C types such as DNS, social media, IRC, blockchain etc.$^{43}$. Botmaster should include as many of these C&C channel options as possible into the malware$_2$ so that the C&C servers can randomly utilize one of them. These randomization is required since in D-LNBot, the C&C servers are not set up by the botmaster. Otherwise, botmaster would have to create variations of malware$_2$ which utilize different C&C channels. However, this creates additional management overhead for the botmaster therefore we opt to create only one malware for this purpose that includes different C&C channel options where C&C servers can randomly choose from. This flexibility is a design choice which enables creating a hybrid botnet. So, ultimately botmaster deploys two malware into the wild, namely malware$_1$ and malware$_2$, to create the C&C servers then to create bots to work under them. Next step is to create the connections between the C&C servers to form the D-LNBot.

6.4 Forming D-LNBot using Innocent Nodes

An important challenge in D-LNBot is to piece together the D-LNBot from individual C&C servers without the botmaster intervening in the process. We propose forming the communication among the C&C servers by exploiting the connections that can be created with existing nodes in LN. We will call them innocent nodes and basically these are LN nodes that are publicly reachable by other nodes. Current LN implementation lets users explore the network topology. For example, typing lncli describegraph (lncli is ln’s $^{44}$ command line interface) returns the network topology information in JSON format that can be analyzed to get information about the nodes reachable from our node. The information that can be collected include their public keys, IP addresses, channels, and channels’ capacities.

The steps of forming the D-LNBot is shown in Algorithm 2 as well as illustrated in Fig. 5. First step is to identify some innocent nodes. When a new C&C server, say C&C$_n$, is created, it will establish channels with some of these innocent nodes following a specific policy. To do that, first, C&C$_n$ queries the LN and finds the $h$ most connected nodes in the network. Next, among these $h$ nodes, C&C$_n$ randomly selects one of them and opens a channel to it with a capacity $K_1$ (line 7 in Algorithm 2). As for choosing the value of $K_1$, it should satisfy the following condition: $f(K_1) = \xi$, where $f()$ is a general function and $\xi$ is an unique value (line 3-6). Then, C&C$_n$ scans the LN to discover the existing C&C servers (line 8). This is easy to do by querying the LN and checking the capacity of each channel to see if it is satisfying the rule given earlier. As soon as C&C$_n$ finds a channel satisfying the rule, it will register the node that opened this channel as a C&C server to its local database (line 16). Here, even though discovering the existing C&C servers is the goal, it is not desirable to reveal the presence of all existing C&C servers at once. Therefore, older C&C servers should hide their existence and the newly joined C&C servers should be able to discover only a small number of C&C servers at any given time. This is possible by older C&C servers closing their open channels with the innocent nodes after getting discovered by $m$ new C&C servers (line 31). For example, if $m$ is set to 2, C&C$_1$ will close its open channel with the innocent node after getting discovered by the C&C$_3$. C&C$_2$ will do the same after C&C$_4$ joins the network. In this way, there will always be $m$ C&C servers only that are discoverable by a newcomer at any time. This number can be adjusted based on the needs and we will refer to it as the number of active C&C servers. But, how can the existing C&C servers know that a new C&C server joined the network? This is possible by existing C&C servers monitoring each new channel creation on LN and checking if the channel capacity satisfies the given rule. New channels are already announced to the network automatically so one would only need to implement a helper function to detect the channels that were created by the newly joined C&C servers (line 10). Following this mechanism, each C&C server obtains some Testnet Bitcoins, the next step is the recruitment of the bots to work under the C&C server (i.e., formation of the mini-botnet).

server will be aware of ( m ) older C&Cs and ( m ) newly joined C&Cs (except for the first ( m ) C&C servers).

Next, assume that a new C&C server, C&C(_{n+1}), joins the network. Similarly, it will establish a channel with an innocent node with a capacity ( K_2 ) where ( f(K_2) = \xi ) and query the LN to find the older C&Cs. It will find out that, C&C(n) has a channel with an innocent node that satisfies the condition ( f(K_1) = \xi ). Thus, C&C({n+1}) will add C&C(n) as a C&C server to its local database (line 16). In the meantime, C&C(n) will observe that C&C({n+1}) has joined LN since it opened a channel satisfying the rule ( f(K_2) = \xi ) and will add C&C({n+1}) to its local database (line 28). This procedure goes on as new C&C servers join the network. Here, the function ( f() ) and value ( \xi ) can be hard-coded in the malware(_I). An example function for ( f() ) could be ( \sin() ). One possible issue that might arise is that when new C&C servers join the network, the ( h ) most connected nodes in LN might change. This might cause the newly joined C&C servers to not be able to discover the existing C&C servers and vice versa. To remedy this issue, the C&C servers that could not discover at least two other C&C servers repeat the process of opening a channel to an innocent node (line 20). This will make sure that all C&C servers are aware of at least two other C&C servers. Essentially, this process forms an overlay network on top of LN to control a botnet.

6.5 Command Propagation in D-LNBot

Unlike LNBot, D-LNBot utilizes a logical topology created during the setup for command propagation. To initiate the command propagation, the botmaster sends the command from a node called D-LNBot master server to a particular C&C server which sends it to the C&C servers it recorded in its local database. We will call these recorded C&Cs, neighboring C&C servers. Every C&C server does the same so the command is propagated among the C&C servers in a P2P fashion. We illustrate two logical D-LNBot topologies in Fig. 6 when the number of active C&C servers is two and three. The bidirectional links show the command propagation between the respective C&C servers. Note that, the C&C servers are not connected to each other with direct channels.

For the ( m = 2 ) case in Fig. 6, the propagation starts when C&C(_1) receives a command from the botmaster. C&C(_1) immediately relays the command to its neighbors C&C(_2) and C&C(_3) by sending them a single payment which includes the command. Then, when C&C(_2) receives the command, it also immediately forwards the command to its neighbors C&C(_1), C&C(_3), and C&C(_4). C&C(_3) does the same when it receives the command from C&C(_1) or C&C(_2). Here, each C&C server sends and receives the command multiple times but this do not result in multiple executions of the same command. Because, each C&C server knows its neighbors and upon receiving a command from one of its neighbors, the C&C server can ignore the command if it was received from another neighbor before. This requires being able to authenticate the sender of the commands which the C&C servers can do. As mentioned in Section 5.6, the noise plugin messages include a signature. Using the signature, the LN public key of the sender can be recovered. This means that, a C&C server can compare this public key with the ones it has in its local database to make sure the command is coming from a legitimate C&C server. Additionally, the redundancy on sending and receiving the commands helps C&C servers keep their channels balanced. For the command propagation of ( m = 3 ) case, please refer to Fig. 6.

The redundancy on command propagation also helps detecting any false positives during the D-LNBot formation phase. Let us imagine a scenario where an honest LN node opens a channel with a capacity satisfying the policy used

1 define h, m, f(), \xi;  
2 global K = []; /* an empty list */  
3 for i ← 1 to n do  
4     /* calculate n valid channel capacities 
5         for the policy based on f() and \xi */  
6         solve f(K_i) = \xi for K_i;  
7         K.append(K_i);  
8 end  
9 global node = open_channel_to_innocent();  
10 check_for_existing_C&Cs();  
11 global counter = 0; /* newcomer C&C count */  
12 monitor_new_channels();  
13 Function check_for_existing_C&Cs(void):  
14     LN_topology = query_LN();  
15     count = 0; /* existing C&C count */  
16     for channel in LN_topology do  
17         if f(channel.capacity) == \xi then  
18             register channel.getNode();  
19             count++;  
20         end  
21     end  
22     if count < 2 then  
23         open_channel_to_innocent();  
24     end  
25 Function is_C&C(channel):  
26     if f(channel.capacity) == \xi then  
27         if counter < m then  
28             register channel.getNode();  
29             counter++;  
30         else  
31             close_channel(node);  
32         end  
33     end  
34 end  
35 Function open_channel_to_innocent(void):  
36     innocent_nodes = []; /* an empty list */  
37     LN_topology = query_LN();  
38     innocent_nodes = get_h_most_connected(LN_topology, h);  
39     node = randomly_select_one(innocent_nodes);  
40     K_i = randomly_select_one(K);  
41     open_channel(node, K_i);  
42     return node;  
43 end

Fig. 5. An illustration of how D-LNBot is formed when number of active C&C servers is 2 (i.e., ( m = 2 )). a) C&C(n) joins the network and opens a channel to an innocent node with a capacity ( K_1 ). b) C&C({n+1}) joins the network and opens a channel to an innocent node with a capacity ( K_2 ) which results in C&C(_n) closing its channel with the innocent node. The process of C&C servers registering each other as neighboring servers into their local databases are also illustrated.

by the C&C servers. This will be automatically detected by the active C&C servers (there are only ( m ) of them) who were actively querying the LN to detect the newly joined C&C servers. The active C&C servers will register this honest LN node to their local database. Now, let us imagine that the botmaster issues a command which starts getting propagated among the C&C servers which will eventually reach the C&Cs that registered the honest node as a neighbor C&C. At that point, the honest node will receive a number of noise messages from these C&Cs but will not propagate anything back. In fact, it might not even receive the messages successfully because of the custom TLV (type-length-value) used by the noise messages. Regardless, when the C&Cs do not get the command back from the honest node, they can understand it was not actually a C&C server thus, mark it as a false positive and delete it from their local database.

One advantage of D-LNBot is that, the botmaster can initiate the command propagation from any one of the C&C servers because the initial C&C server will replicate the command to its neighboring C&C servers. In other words, the botmaster does not need to initiate the command propagation from C&C(_1) necessarily, and can use the C&C(_5) instead for example. Botmaster is able to do this because s/he is aware of all the C&C servers as s/he is constantly watching the network and knows the policy the C&C servers use to open channels to the innocent nodes. Being able to freely choose the first C&C server to initialize the command propagation also provides better anonymity for the botmaster.

7 P\text{ROOF-OF-CONCEPT IMPLEMENTATION}

In this section, we demonstrate that implementations of the proposed LNBot and D-LNBot are feasible by presenting a proof-of-concept for each. Full LN nodes interact with the Bitcoin network in order to run the layer-2 protocols. There are two Bitcoin networks: Bitcoin Mainnet and Bitcoin Testnet. As the names suggest, Bitcoin Mainnet hosts Bitcoin transfers with a real monetary value. On the contrary, in Bitcoin Testnet, Bitcoins do not have a monetary value. They are only used for testing and development purposes. Nonetheless, they both provide the same infrastructure and LNBot and D-LNBot can run on both networks. The only difference between the Testnet and Mainnet networks for LN is the number of nodes and the channels they have. LN on Bitcoin Testnet have about 60% less nodes, and 80% less channels compared to LN on Bitcoin Mainnet.

LNBot: We used \textit{lnd} (version 0.9.0-beta) from Lightning Labs [44] for the full LN nodes. We used Bitcoin Testnet for our proof-of-concept development. We created 100 C&C servers and assessed certain performance characteristics for command propagation. We created a GitHub page explaining the steps to set up the C&C servers [7]. The steps include installation of \textit{lnd} & \textit{bitcoind}, configuring \textit{lnd} and \textit{bitcoind}, and extra configurations to hide the servers in the network by utilizing private channels. Nevertheless, to confirm that the channel opening costs and routing fees are exactly the same in both Bitcoin Mainnet and Testnet, we also created 2 nodes on Bitcoin Mainnet. We funded one of the nodes.

https://github.com/LightningNetworkBot/LNBot

---

Useful information for enthusiasts:

• [1]YouTube Channel CryptoDeepTech
• [2]Telegram Channel CryptoDeepTech
• [3]GitHub Repositories CryptoDeepTools
• [4]Telegram: ExploitDarlenePRO
• [5]YouTube Channel ExploitDarlenePRO
• [6]GitHub Repositories Keyhunters
• [7]Telegram: Bitcoin ChatGPT
• [8]YouTube Channel BitcoinChatGPT
• [9] Bitcoin Core Wallet Vulnerability
• [10] BTC PAYS DOCKEYHUNT
• [11] DOCKEYHUNT
• [12]Telegram: DocKeyHunt
• [13]ExploitDarlenePRO.com
• [14]DUST ATTACK
• [15]Vulnerable Bitcoin Wallets
• [16] ATTACKSAFE SOFTWARE
• [17] LATTICE ATTACK
• [18] RangeNonce
• [19] BitcoinWhosWho
• [20] Bitcoin Wallet by Coinbin
• [21] POLYNONCE ATTACK
• [22] Cold Wallet Vulnerability
• [23] Trezor Hardware Wallet Vulnerability
• [24] Exodus Wallet Vulnerability
• [25] BITCOIN DOCKEYHUNT

Contact me via Telegram: @ExploitDarlenePRO