LNBot: A Covert Hybrid Botnet on Bitcoin Lightning Network for Fun and Profit

BY KEYHUNTER 06.03.2025
LNBot: A Covert Hybrid Botnet on Bitcoin Lightning Network for Fun and Profit

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 propose a new generation hybrid botnet that covertly and efficiently communicates over Bitcoin Lightning Network (LN), called LNBot. LN is a payment channel network operating on top of Bitcoin network for faster Bitcoin transactions with negligible fees. Exploiting various anonymity features of LN, we designed a scalable two-layer botnet which completely anonymize the identity of the botmaster. In the first layer, the botmaster sends commands anonymously to the C&C servers through LN transactions. Specifically, LNBot allows botmaster’s commands to be sent in the form of surreptitious multihop LN payments, where the commands are encoded with ASCII or Huffman encoding to provide covert communications. In the second layer, C&C servers further relay those commands to the bots they control in their mini-botnets to launch any type of attacks to victim machines. We implemented a proof-of-concept on the actual LN and extensively analyzed the delay and cost performance of LNBot. Our analysis show that LNBot achieves better scalability compared to the other similar blockchain botnets with negligible costs. Finally, we also provide and discuss a list of potential countermeasures to detect LNBot activities and minimize its impacts.

Keywords: Lightning Network · Botnet · 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 [28]. 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 C&C server identity play a key role in the long-lasting operation of botnets.

Numerous botnets have been proposed and deployed in the past [12,31]. 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, 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 [3,2]. While 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 communications, C&C leaves the history of malicious activities on the blockchain forever.

Nonetheless, the issues regarding the public announcement of commands and leaving traces in the blockchain are already being addressed in a newly developed Bitcoin payment channel network called Lightning Network (LN). LN enables off-line 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 still kept anonymous since the transactions are not announced publicly. In this paper, we advocate using LN as an ideal C&C infrastructure for botnets with all the aforementioned features (i.e., faster transactions, decreased costs). Specifically, LN offers botmasters numerous advantages over existing techniques: First, LN provides very high anonymity since 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.

Although LN is a fast-growing emerging payment network, it only has around 12K 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 [21]. However, the communication with these servers was still assumed to be through the existing communication infrastructures which impairs the servers’ anonymity. Therefore, further strengthening of anonymity is still needed.

Hence, this paper 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 will maintain 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 is controlling 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, Tor, etc. Botmaster sends the commands to the C&C servers covertly through LN. This two-layer command and control topology not only enables scalability, but also minimizes the burden on each C&C server, which increases their anonymity.

To demonstrate the feasibility of the concept, we implemented the LNBot using real LN nodes in Bitcoin’s Testnet which is the actual network for Bitcoin. Utilizing one-to-many architecture (i.e., botmaster sends commands to all C&C servers separately), we show that by encoding the commands in terms of payments sent over LN, one can successfully send commands to the C&C servers that are part of the LN. These C&C servers further relay those commands to the bots they control to launch any type of attack to victim machines.

Nevertheless, as sending the commands to every C&C server in the form of payment requires the botmaster to maintain high capacity LN channels (i.e., increased monetary cost) and pay forwarding fees to LN, we also propose mechanisms to further decrease these costs to the levels where they can be neglected. Specifically, when the attacks are executed, we circulate the received payments at C&C servers back to botmaster. Essentially, this means the botmaster will receive all of his/her money back except the fees charged by LN. To also minimize those fees, in addition to ASCII-based encoding, we propose a Huffman-based encoding mechanism which considers the frequency of characters that could potentially be used in constructing the attack commands. We demonstrate that for a network comprising 100 C&C servers, the total fixed fees for forming LNBot would be lower than $5.

Contrary to the traditional blockchain based communication schemes, LNBot covertly communicates with the C&C servers by utilizing the strong relationship anonymity of LN. This covert communication comes with a very little cost and latency overhead. Additionally, since LNBot does not require a custom C&C infrastructure, it is very practical to deploy it. All these features of LNBot makes it a botnet that needs to be taken seriously therefore we provide a list of countermeasures that may help detect LNBot activity and minimize damages from it.

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

2 Background

2.1 Lightning Network

The LN concept is introduced in [26]. It is a payment protocol operating on top of Bitcoin. Through this concept, an overlay payment 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 increasing the scalability of Bitcoin by establishing peer-to-peer connections. Despite the big fluctuations in the price of Bitcoin recently, the LN grew exponentially reaching 12,384 nodes and 36,378 channels in less than two years by the time of writing this paper [1]. In the following subsections, we briefly explain the components of LN.

2.2 Off-chain Concept

The main idea behind LN is to utilize the off-chain concept [24] which en- ables 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 funding transaction. The funding transaction determines the capacity of the channel. Whenever one of the parties wants to make a transaction, she basically conveys ownership of that amount of her money to her peer. So, after a transaction takes place the total capacity in the channel does not change but the directional ca- pacities do. Therefore, the peers can make as many as transactions they want in any amount unless the amount they want to send does not exceed the directional capacity. The example shown in Fig. 1 illustrates the concept in more detail.

![Diagram of off-chain transactions]

Fig. 1: Off-chain mechanism of LN.

Per figure, 1⃝ Alice opens a channel to Bob by funding 5 Bitcoins to a multi- signature address and the multi-signature address is signed by both Alice and Bob. 2⃝ Using this channel, Alice can send payments to Bob simply by trans- ferring the ownership of her share in the multi-signature address until her fund in the address is exhausted. Note that these transactions are off-chain meaning they are not written to the Bitcoin blockchain which is a unique feature of LN and that feature is exploited in our botnet. Alice performs 3 transactions at different times with amounts of 1, 2 and 1 Bitcoin respectively. 3⃝ Eventually, when the channel is closed, the remaining 1 Bitcoin in the multi-signature wallet 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.

2.3 Multihop Payments

In LN, a node can make 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 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. As there is a direct payment channel between Alice and Charlie and between Charlie and Bob, Alice can initiate a transaction to Bob via Charlie.

1⃝ First, Bob sends an invoice to Alice which includes the hash (H) of a secret R (known as pre-image).

2⃝ Then, Alice prepares a payment locked with H, the answer of which is known by Bob. Hash-Locking is required for Alice to ensure that the payment is received by Bob. So, locked with H, Alice gives ownership of some of her money destined to Bob if and only if Charlie knows and discloses the answer to H. Likewise, 3⃝ Charlie promises to give the ownership of some of his money which is locked by H to Bob if Bob knows the answer. As Bob receives a payment he naturally discloses the answer to Charlie and in return he gets the money from Charlie as promised. Now, as Charlie learned the answer, he discloses the answer to Alice and gets his money from Alice as promised. This mechanism is realized with the “Hash Time Lock Contracts” (HTLC). Through this mechanism of LN, as long as there is a path from source to destination requiring that the channels on the path have enough capacities, payments can be routed just like the Internet.

Fig. 2: Illustration of a multihop payment. R is the secret (i.e. pre-hash) generated by Bob, H is the hash of the secret. When the transaction is locked by H, yielding the secret R opens the lock. Namely, when asked, yielding R changes the ownership of the money in the channel.

2.4 Key Send Payments

Key send in LN enables sending payments to a destination without needing to have an invoice first [22]. It utilizes Sphinx [9] 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. In LNBot, we utilize this feature to send payments from botmaster to C&C servers.

2.5 Source Routing & Onion Routed Payments

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 transaction to follow within the network. Senders are able to specify: 1) the total number of hops on the path; 2) total cumulative fee they will pay to send the payment; and 3) total time-lock period for the HTLC [14]. Moreover, all payments in LN are onion-routed payments meaning that HTLCs are securely and privately routed within the network. Onion routing LN also prevents any nodes from easily censoring payments since they are not aware of the final destination of the payment. Additionally, by encoding payment routes within a Sphinx packet, 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.

2.6 Motivation to Use LN for a Botnet

In this section, we justify why LN is suitable for a perfect botnet design.

– No publicly advertised activity: The drawback of using a cryptocurrency based communication infrastructure is that all of the activities are publicly stored in a persistent, transparent, append-only ledger. However, using the off-chain transaction mechanism, only the intermediary nodes in a multi-hop payment path know the transactions. Because, they are responsible to keep the state of their own channels just to prove the ownership of their share in case of a dispute. Namely, the activities taking place in a payment channel is locally stored by the nodes responsible for forwarding that transaction.

– Covert messaging: LN was proposed to ease the problems occurring in the Bitcoin network. Hence, all of the actions taking place in the network is regarded as financial transactions. In that sense, twisting this idea into using the channels for covertly forwarding commands will be indistinguishable from innocent, legitimate, and real financial transactions.

– Relationship anonymity: LN utilizes source-routing for payment forwarding. This feature enables the peers to enjoy a higher anonymity. Assume that, during a transaction let the next node successfully guess that the preceding node was the origin of the transaction. Ideally, there is no possibility for it to successfully guess the final destination for that transaction. This applies to any “curious” node in the network. Namely, without collusion it is impossible to know who communicates to whom, which is known as relationship anonymity feature.

– Instantaneous communication: Apart from being public, another drawback of using Bitcoin network is that a transaction is approved in 10 minutes the earliest. Moreover, for a transaction to be approved in the ledger for good, the peers have to wait for at least 60 minutes. By moving to the off-chain, a transaction simply becomes a network package traversing in the network through the intermediary nodes. In that sense, the communication latency in LN is nothing but the time for a packet to traverse on the Internet.

– Minimal cost: Bitcoin network charges fees for every transaction regardless of its amount. LN was also designed to transform these fees into negligible amounts. The fees charged by LN is comprised of the combination of a “base fee” and a “proportional fee” which are close to zero. In the ln implementation of LN, default setting for the base fee is 1 millisatoshi(^1). The proportional fee is, as name suggests it is proportional with the amount being forwarded, 0.0001% of the payment.

3 LNBot Architecture

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

3.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. Note that it is up to the botmaster how to populate these mini-botnets. Each C&C server can utilize a different botnet model (i.e., based on IRC, DNS, steganography, cryptocurrencies, etc).

1 A satoshi is defined to be 0.00000001 Bitcoin. In other words, 1 Bitcoin is 100 million satoshi.

The botmaster could set up the C&C servers by creating LN nodes at remote locations that are accessible to him/her. The botmaster knows the LN public keys of all C&C servers since s/he sets them up. These public keys are needed to communicate with them in the LN. Then s/he installs a special software on the C&C servers which are used to control the bots. In this way, it is enough for botmaster to release a malware into the wild for infecting user machines and upon infection, these machines connect to existing available C&C servers (i.e., they become bots). One possible way to achieve this would be to spread the malware via embedded advertisements on web pages frequently visited by intended victims. When a viewer clicks on the link, s/he is redirected to a website hosting malicious code that executes in the background and infects the victim’s machine without his/her knowledge.

Upon infection, the bot establishes a communication with an available C&C server. The type of connection used depends on the communication method chosen by the C&C server the bot connects to. This can be picked among existing botnet C&C infrastructures such as IRC, DNS, steganography, cryptocurrencies or even the LN itself.

The botmaster’s commands have to propagate to every C&C server, and then, ultimately to every single bot through the C&C servers. For this task, we propose one-to-many propagation where the botmaster sends commands to each C&C server separately. This approach is described in Section 3.5. The botmaster periodically issues commands to C&C servers by sending payments over LN. Thus, the commands have to be encoded into a series of LN payments. We implemented two encoding schemes to represent the commands as LN payments. These methods are detailed in Section 3.6.

With the availability of command propagation, the C&C servers could now listen to the incoming instructions from the botmaster. Next, we describe the details of setting up the C&C servers.

3.2 Setting up the C&C Servers

As mentioned earlier, the botmaster can set 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 4, 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 themselves within the LN. In this way, the other LN nodes do not know about the existence of the C&C servers and cannot open channels to them without knowing their public keys. However, without opening any channels on the network, C&C servers cannot get botmaster’s payments on LN. Therefore, each C&C servers open a channel to at least $k$ different random public LN nodes. To open the channels, they need some Bitcoin in their lightning wallets. This Bitcoin is provided to C&C servers by the botmaster before deploying them. The number $k$ may be tuned depending on the size and topology of LN when LNBot will have deployed in the future.

3.3 Formation of Mini-botnets

After C&C servers are set up, we need bots to establish connections to C&C servers. An infected machine (bot) connects to one of the C&C servers. As mentioned earlier, 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 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 6, even if the C&C servers are compromised, this neither reveals the other C&C servers nor the botmaster.

3.4 Forming LNBot

Now that 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 public keys of all LN nodes running on C&C server machines. Since C&C servers have their LN channels ready, they can receive the commands from the botmaster. The botmaster uses an LN node called LNBot Master Server to initiate 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 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 C&C servers through LN, consequently controlling all the bots on the botnet.

3.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. The botmaster uses key send method mentioned in Section 2.4 to send the payments. We designed a command sending protocol for botmaster-to-C&C server communication as shown in Algorithm 1.

Before sending any payment, the botmaster 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). If the C&C server is not online, command sending is scheduled for a later time. Botmaster sends 5 satoshi as the special starting payment of a command before it sends the actual characters in the command one by one. Lastly, the botmaster sends 6 satoshi as the special ending payment to finish sending the command. Note that selection of 5 and 6 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 re-tried. If any of the payments fail for more than $k$ times in a row, command transmission to the respective C&C server is canceled and scheduled for a later time. The details of encoding and decoding are explained next.

Algorithm 1: Send Command

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

3.6 Encoding/Decoding Schemes

An important feature of LNBot is its ability to encode botmaster commands into a series of LN payments. We used two different encoding/decoding schemes for the purpose of determining the most efficient way of sending commands to C&C servers in terms of Bitcoin cost and time spent. We explain the details of each method below:

ASCII Encoding American Standard Code for Information Interchange (ASCII) is a character encoding standard that represents English characters as numbers, assigned from 0 to 127. Numbers 0-31 and 127 are reserved for control characters. The remaining 95 codes from 32 to 126 represent printable characters. The decimal equivalent of ASCII characters can easily be looked up from an ASCII table.

Useful information for enthusiasts:

Contact me via Telegram: @ExploitDarlenePRO