DHTs, Botnets, and KadNap

The DHT examples we covered (CAN, Chord, and Dynamo) were motivated by legitimate problems: distributing storage, routing lookups efficiently, and scaling key-value stores. The same properties that make DHTs attractive for those purposes also make them attractive for attackers. A March 2026 disclosure by Lumen Technologies’ Black Lotus Labs gives us an interesting and recent example worth looking at.

What Is a Botnet?

A botnet is a network of computers that have been compromised by malware and are under the remote control of an attacker. The word is a contraction of “robot network.” Each infected machine is called a bot or zombie. The attacker communicates with the bots through a command-and-control (C2) server, issuing instructions such as “send spam,” “attack this website,” or “relay this traffic.”

The owner of the infected machine typically has no idea that anything is wrong. Bots are designed to run quietly in the background, consuming minimal resources and avoiding detection. A botnet can include anything with a network connection: laptops, desktop computers, servers, and increasingly, home routers and IoT devices. Routers are especially attractive targets because they run continuously, have high bandwidth, are rarely monitored by their owners, and are seldom updated.

Botnets are used for a wide range of criminal purposes, including distributed denial-of-service (DDoS) attacks, credential stuffing, spam campaigns, and the operation of anonymous proxy services that hide the true origin of malicious traffic.

Kademlia DHT: A Brief Introduction

The KadNap botnet uses a protocol called Kademlia, which is also the DHT that BitTorrent uses to allow peers to find each other and locate content without relying on a central tracker. Kademlia is worth understanding in the context of what you already know about Chord.

Like Chord, Kademlia assigns every node and every key a position in a large identifier space (160 bits, using a SHA-1 hash). Like Chord, each node is responsible for the keys closest to its own ID, and lookups are routed hop by hop, with each hop getting closer to the target. The number of hops is O(log n).

The key difference from Chord is how Kademlia measures “closeness.”

Chord uses a position on a ring: node N20 is responsible for keys just clockwise from N5 up to N20 (for example). Kademlia uses an XOR distance: the distance between two IDs is computed by XORing them together as integers. A node is responsible for keys whose XOR distance to its own ID is smaller than the XOR distance to any other node’s ID.

XOR distance has a useful geometric interpretation. If you think of a 160-bit ID as a path from the root to a leaf in a binary tree, two nodes are “close” if their IDs share a long common prefix, meaning they branch off from each other deep in the tree.

Nodes keep a routing table organized into k-buckets: one bucket per bit position, each holding up to k nodes whose IDs differ from the local node’s ID in that bit position. This plays the same role as Chord’s finger table, providing a compact set of references that allows the lookup to halve the remaining distance at each hop, but the geometry is a tree rather than a ring.)

One difference in the structure is that the XOR distance is symmetric, meaning the distance from A to B equals the distance from B to A. This is not true on a Chord ring, where clockwise and counterclockwise distances differ. Symmetry makes Kademlia’s routing table easier to maintain because queries and replies traverse the same paths.

Kademlia is the DHT used by BitTorrent (for peer discovery), IPFS (to locate peers and content in the InterPlanetary File System), and several other large-scale peer-to-peer systems. Its 160-bit ID space and XOR routing are well understood and have been deployed at enormous scale.

The Ethereum blockchain uses a Kademlia-like peer-discovery protocol to help nodes find one another in a decentralized way. A new node contacts a small set of bootnodes, then uses Kademlia-style lookups based on XOR distance between node IDs to discover additional nearby peers and build its routing table.

Why Botnets Use DHTs

A traditional botnet has a key weakness: it relies on a C2 server, which it contacts periodically for instructions. If defenders find that server by monitoring network traffic, obtaining a court order, or convincing the hosting provider to take it down, the botnet goes dark.

Defenders have become very good at this. They call it sinkholing: redirect the domain or IP to a controlled server, and the bots check in harmlessly while the operators lose control.

A DHT-based botnet eliminates that single point of failure. There is no C2 server to seize because the location of the C2 is not hardcoded anywhere. Instead, it is stored as a key-value pair distributed across the botnet’s own nodes.

A newly infected device joins the DHT, routes a lookup for the key corresponding to “where is the C2 today?”, and retrieves the current address. The lookup path passes through other infected nodes, none of which individually knows the full answer. Defenders have no single target to block.

This same architecture is why BitTorrent has proven impossible to shut down through traditional legal means. There is no central tracker to seize. DHT-based botnets borrow exactly that property.

The KadNap Botnet

KadNap was first detected in August 2025 and publicly disclosed by Lumen’s Black Lotus Labs on March 10, 2026. By that point, the botnet had grown to over 14,000 infected devices, averaging about 14,000 active nodes per day. Roughly 60% of infected devices are in the United States, with additional victims in Taiwan, Hong Kong, Russia, the UK, France, and elsewhere.

The primary target is ASUS routers. The malware runs as a compiled binary targeting both ARM and MIPS processor architectures, covering most consumer ASUS hardware. Infection happens through known, unpatched vulnerabilities; no zero-day exploits were involved.

To survive reboots, the malware installs a scheduled task that runs every hour and re-downloads and re-executes the malicious script. Rebooting the router does not remove the infection because the scheduled task is stored in a part of the router’s memory that persists across reboots. A simple reboot, therefore, does not help; a full factory reset is required, followed by a firmware update, a strong administrative password, and disabling remote access unless needed.

How KadNap Uses Kademlia

Once installed, KadNap’s binary (named kad) bootstraps into the Kademlia DHT by reaching out to known BitTorrent entry nodes, the same bootstrap nodes a BitTorrent client would use on first launch. This is deliberate: KadNap’s lookup traffic blends into legitimate BitTorrent DHT traffic, making it difficult to distinguish from normal peer-to-peer activity.

To locate its C2 server, an infected node computes a custom infohash by XOR-ing a hardcoded key with a value derived from the current time and system uptime, then hashing the result with SHA-1. It uses that hash as a lookup key in the DHT, routing through other infected nodes via the XOR distance metric to retrieve the current C2 address. The C2 address is not stored anywhere on the device; it is fetched fresh at each check-in.

Formosa described the lookup process in plain terms: the bot reaches out to BitTorrent entry nodes carrying a secret passphrase and asks which neighbors might recognize it. Each neighbor either passes it along to nodes that are closer in XOR distance or, if it is the right node, responds with two files: one instructing the bot to firewall port 22, and a second containing the current C2 address.

A Weak Implementation

Kademlia’s design calls for the final peer (the one actually holding the looked-up value) to vary over time as the DHT membership changes. Black Lotus Labs found that KadNap’s implementation does not actually achieve this. Analysis of samples going back to August 2025 consistently showed the same two intermediate nodes being contacted before reaching the C2. This suggests a simplified or partially implemented Kademlia that does not fully deliver on the decentralized promise. Despite this, the architecture was still effective enough to evade traditional detection for months.

What Infected Routers Do

Compromised routers are enrolled in a residential proxy service called Doppelganger, assessed to be a rebrand of the Faceless network previously associated with the TheMoon malware. Customers of Doppelganger pay to route their internet traffic through the infected routers. Because residential IP addresses have clean reputations and high bandwidth, this kind of proxy is valuable for evading IP-based blocklists and for launching credential-stuffing, brute-force, and DDoS attacks that appear to originate from ordinary home broadband connections.

The operators also segment their infrastructure by device type rather than running all infected routers through the same control servers. More than half the botnet – all the ASUS victims – connects to a dedicated pair of C2 servers, while devices of other types connect to separate servers. This compartmentalization limits the damage if defenders succeed in taking down part of the infrastructure.

Takedown and Defenses

Lumen states it has blocked all traffic to and from KadNap’s known control infrastructure on its own network and has published indicators of compromise for other organizations to use. Because the botnet is decentralized, this disruption is partial: it affects traffic crossing Lumen’s network but does not take the botnet offline globally.

The broader lesson is that a DHT-based C2 infrastructure trades the efficiency of a centralized server for resilience against takedown. Defenders cannot easily sinkhole a DHT the way they sinkhole a domain. Disruption requires either blocking the underlying protocol network-wide (which would also block legitimate BitTorrent traffic) or identifying and neutralizing enough nodes to degrade routing, which is a much harder problem.

The Takeaway

CAN, Chord, Dynamo, and Kademlia were all designed to solve legitimate distributed systems problems. The properties that make them useful (decentralization, fault tolerance, and resistance to single points of failure) are exactly the properties that make them attractive for malicious infrastructure. KadNap is a clear example of a well-understood academic protocol being repurposed for criminal use. The XOR routing and k-bucket structure you would encounter in a graduate distributed systems paper are the same mechanisms hiding the command servers of a 14,000-node router botnet.

References

• Black Lotus Labs, Silence Of The Hops: The KadNap Botnet, March 10, 2026.

• Dan Goodin, 14,000 routers are infected by malware that’s highly resistant to takedowns, ArsTechnica, March 11, 2026.

• P. Maymounkov and D. David Mazières, Kademlia: A Peer-to-peer Information System Based on the XOR Metric, IPTPS ‘01, The First International Workshop on Peer-to-Peer Systems, Pages 53-65, March 2002.

• Kademlia, Wikipedia article.