KadNap's Broken Kademlia: The Two Nodes That Gave Away a Botnet

When Lumen Technologies' Black Lotus Labs published its findings on March 10, 2026, the headline was a botnet with a novel trick: it used the Kademlia distributed hash table protocol — the same protocol behind BitTorrent's peer discovery system — to hide the IP addresses of its command-and-control servers. The idea was sound in theory. Kademlia turns infrastructure lookup into a traversal across a decentralized mesh of nodes, and if you hide your C2 endpoints inside that mesh, defenders have no static address to block.

What the operators failed to account for was a detail embedded in how Kademlia is supposed to work. In a genuine Kademlia network, the path to any target changes continuously — different nodes handle the final routing hop each time. KadNap's implementation did not work that way. Every infected device, across every sample examined since August 2025, routed its traffic through exactly the same two nodes immediately before reaching the C2 servers. Those nodes sat at 45.135.180[.]38 and 45.135.180[.]177. That fixed chokepoint is what handed researchers the infrastructure on a platter.

This article covers how KadNap's architecture was built, why the Kademlia implementation was structurally weak, what the two-node chokepoint revealed, and what the botnet's connection to the Doppelganger proxy service tells us about the economics of router compromise in 2026.

What Kademlia Actually Does #

To understand why KadNap's implementation was weak, it helps to understand how Kademlia is supposed to work. Kademlia is a distributed hash table algorithm first described by Petar Maymounkov and David Mazières at New York University in their 2002 paper "Kademlia: A Peer-to-Peer Information System Based on the XOR Metric," presented at the First International Workshop on Peer-to-Peer Systems (IPTPS). It solves a specific problem: how do you find a piece of data across a large decentralized network without a central directory, efficiently and at scale?

Every node in a Kademlia network has a unique 160-bit identifier. When a node wants to locate a resource — identified by an infohash — it measures the XOR distance between its own ID and the target ID. It then queries the nodes it knows that are "closest" to the target in that XOR metric. Those nodes respond with the nodes they know that are even closer, and the process continues, converging on the target in O(log n) hops across a network of n nodes. The protocol powers the BitTorrent DHT, eMule, I2P, and parts of the Ethereum network.

The key property defenders need to understand is that in a true Kademlia implementation, the path to a target changes over time. Nodes join and leave the network. Routing tables update. The "closest" nodes to any given target shift continuously. This is precisely what makes a well-implemented Kademlia-based C2 so difficult to track: there is no persistent, enumerable set of relay nodes that defenders can monitor or block.

Black Lotus Labs describes the lookup process through a useful analogy: imagine passing a request through a chain of acquaintances, where each one does not hold the complete answer but knows someone who can get you closer to it. The chain converges quickly, and you assemble what you need from the final handoff. In Kademlia, that chain is the network of nodes routing toward the target infohash. (Formosa and Rudd, Black Lotus Labs, March 2026.)

Black Lotus Labs researcher Chris Formosa described how KadNap applies this process in direct operational terms. An infected device broadcasts what amounts to a secret passphrase into the DHT, passing it to nearby nodes that do not fully recognize it but can point toward nodes that might. The chain continues until it reaches a node that claims the passphrase as its own — and responds by handing over two files: a script to block port 22 via iptables, and a second file containing the C2 address. As Formosa put it, the node says: Yes! This is my passphrase, welcome in. (Chris Formosa, Black Lotus Labs, as quoted by Ars Technica and Technology.org, March 2026.)

KadNap was named after this protocol. The ELF binary delivered to infected routers was named kad, a direct reference to Kademlia. The design intent was clear: use peer discovery traffic that blends into the noise of the BitTorrent ecosystem to prevent defenders from enumerating and blocking C2 servers.

The Infection Chain #

KadNap's initial access vector, while not fully detailed in public disclosures, is consistent with a pattern well-established in router botnet campaigns: exploitation of unpatched firmware vulnerabilities, combined with exposed management interfaces and default or weak credentials. Researcher Chris Formosa stated directly that it is "unlikely" the attackers used any zero-day vulnerabilities — the ASUS concentration reflects operators having acquired a reliable exploit chain for specific models, not a novel capability. Lumen's detection algorithm first flagged the campaign in early August 2025, when over 10,000 ASUS devices began communicating with a common set of servers.

The infection chain begins with a shell script named aic.sh, downloaded from a server at 212.104.141[.]140. This script does two things immediately: it establishes persistence and it stages the main payload.

For persistence, aic.sh creates a cron job that fires at the 55-minute mark of every hour. The cron job pulls the malicious shell script from the staging server, renames it to .asusrouter, and executes it from the /jffs/.asusrouter path. The use of the /jffs filesystem is deliberate — this is the JFFS2 flash filesystem on ASUS routers that persists across reboots, unlike the /tmp directory.

After persistence is established, the script checks whether a process named kad is already running. If it is not, the script downloads the ELF binary, sets execute permissions, and runs it. The binary is compiled for both ARM and MIPS processor architectures, reflecting the diversity of ASUS router hardware across product lines.

Once the kad binary executes, it forks immediately, redirects all standard I/O to /dev/null to suppress any console output, and begins its initialization sequence. It resolves the device's external IP address and stores it in an internal struct. It then cycles through a hardcoded list of NTP servers — including time-a.nist.gov, time-b.nist.gov, time.windows.com, and several others — until it successfully retrieves the current time. The current time and the device's uptime are stored and used later to generate the custom infohash that drives peer discovery.

This NTP dependency is architecturally interesting. The infohash that KadNap uses to search for other infected nodes is derived from a combination of a hardcoded 64-byte seed string, an XOR key generated from the NTP timestamp and uptime, and a SHA-1 hash of the combined material. This means the infohash rotates over time — any given infected device will search for different-looking peers as its uptime and timestamp values change. From a defender's perspective, simple static signature matching on the infohash will miss devices at different points in their operational cycle.

That rotation is also potentially exploitable in reverse. If the derivation formula is known — and it is, because the binary can be analyzed — then a researcher who holds the 64-byte seed and can estimate a device's approximate uptime range can predict the infohash values that device will generate across a given window. This creates an active tracking primitive: deploy a DHT monitor configured to query the predicted infohash values and log any device that responds. Rather than passively waiting for infected devices to contact the fixed relay nodes, a resourced defender could probe the BitTorrent DHT for live KadNap infections. The Black Lotus Labs report does not document whether this avenue was pursued, but the arithmetic is not in the operators' favor once the seed material has been extracted from a captured binary.

The Find Peers Thread and the DHT Handshake #

After initialization, the kad binary spawns two key threads that run concurrently: a find-peers thread and a contact-peers thread. These two threads together implement the malware's version of the Kademlia lookup process.

The find-peers thread connects to the BitTorrent DHT network using known public bootstrap nodes. This is the first layer of camouflage: the initial connection traffic is indistinguishable from a BitTorrent client bootstrapping its peer table. The thread constructs a custom bencoded DHT packet — using the bencoding format native to the BitTorrent protocol — with the computed infohash embedded in the name field and a SHA-1 hash of the full bencoded structure in the pieces field.

This packet is sent as a get_peers request into the BitTorrent DHT. Infected nodes that receive this request and recognize the infohash respond with their own peer information. Legitimate BitTorrent nodes that receive the request and do not recognize the infohash simply ignore it or return an empty response — there is no flag raised, no anomaly logged. The malicious traffic sits inside the DHT's normal operating noise.

Peer responses are passed through a pipe to the contact-peers thread. This thread reads the IP:port pairs, attempts connections, and performs an AES-encrypted handshake with each peer. If the handshake succeeds, the thread downloads two additional payloads:

• fwr.sh — a shell script that inserts an iptables rule to drop all incoming TCP traffic on port 22, blocking SSH access to the device and locking out legitimate administrators
• .sose — a binary written to /tmp containing the C2 IP addresses, ports, and configuration data the malware needs to contact the botnet's command infrastructure

The SSH lockout via fwr.sh is a deliberate operational security measure. By inserting the iptables DROP rule early, the operators reduce the window during which a network administrator might notice the compromise and SSH into the device to investigate or remediate. This is consistent with the behavior of Linux-targeting malware that prioritizes persistence over stealth once initial access is secured.

What the AES Handshake Actually Protects

KadNap's peer handshake is AES-encrypted. This is frequently cited as a layer of operational security, and it is — but it is worth being precise about what it protects and what it does not.

The encryption prevents passive network observers from reading the content of peer exchanges. A defender watching encrypted DHT traffic at a network tap cannot trivially extract infohashes, peer lists, or payload URLs from the stream. This is the protection it was designed to provide, and it delivers on that goal for the majority of monitoring scenarios that a compromised home router would face.

What the AES encryption does not protect is the existence of the connection itself, the destination IP, or the traffic volume and timing patterns that behavioral analytics can exploit. A router generating periodic outbound AES-encrypted UDP traffic to a small, consistent set of non-standard IPs is behaviorally anomalous regardless of whether the content is readable. Lumen's detection algorithm operated at this layer — it identified the statistical signature of botnet coordination from traffic patterns, not from payload inspection. The encryption was irrelevant to the detection method that actually found KadNap.

There is also the key management question that the public disclosure leaves open. AES requires a shared key between communicating peers. If the key is hardcoded in the binary or derived from the same 64-byte seed used to generate the infohash, then extracting the binary and reversing the key derivation gives a researcher the ability to decrypt all captured peer traffic retroactively. The Black Lotus Labs report does not detail the key exchange mechanism, but this is a structural weakness inherent to any symmetric encryption scheme where the key material is embedded in a recoverable artifact.

The Broken Kademlia: Why the Two-Node Chokepoint Exposed Everything #

Here is where KadNap's design collapsed under its own implementation choices.

A correctly implemented Kademlia network has no persistent final-hop node. The path to any target resource changes as the network's topology evolves. A C2 operator using a genuine Kademlia implementation would benefit from this property: any attempt to track the "last hop" before the C2 would encounter a constantly shifting set of addresses drawn from the live botnet population.

KadNap did not implement this. Black Lotus Labs researchers Chris Formosa and Steve Rudd analyzed samples collected across the full operational history of the botnet — from August 2025 through the March 2026 disclosure — and found a consistent, unchanging pattern:

Formosa and Rudd noted that in a genuine Kademlia network the final peer node changes continuously, reflecting the protocol's decentralized nature. In KadNap's case, every sample they analyzed from August 2025 onward terminated at the same two final-hop nodes before reaching the C2 servers — a consistency that no legitimate Kademlia deployment would produce. (Formosa and Rudd, Black Lotus Labs, March 2026.)

Those two nodes were 45.135.180[.]38 and 45.135.180[.]177. Every infected device, regardless of model, geography, or infection date, contacted one of these two IP addresses immediately before receiving the .sose payload containing C2 connection details. These were not peers randomly selected by the DHT algorithm — they were attacker-controlled infrastructure maintained as persistent relay nodes.

The implication of this design choice is significant. The operators made a deliberate tradeoff: they sacrificed the distributed, dynamic routing that makes Kademlia difficult to trace in exchange for stronger operational control over the network. By maintaining centrally controlled penultimate-hop nodes, they could ensure that the C2 delivery pipeline remained reliable. A genuinely decentralized Kademlia implementation would have required infected devices to discover the C2 dynamically through the DHT, which introduces latency and failure modes. The hardcoded relay nodes removed those uncertainties.

The cost was that these two nodes became a permanent, observable chokepoint. Lumen's telemetry could see all infected devices passing through them. Once identified, the relay nodes served as a mapping anchor — follow 45.135.180[.]38 and 45.135.180[.]177, and you could enumerate a substantial portion of the botnet's active victims. The network capture tools routinely used in threat intelligence work are well-suited to exactly this kind of fixed-infrastructure tracking.

This is the fundamental tension at the heart of KadNap's architecture. P2P routing protocols provide resilience and evasion through genuine decentralization. The moment you re-introduce a centralized element — even a pair of relay nodes — you re-introduce the attack surface that centralization always creates. KadNap's operators got the aesthetics of Kademlia without the actual decentralization, and defenders noticed the seam.

Infrastructure Segmentation by Device Type

Beyond the two relay nodes, Black Lotus Labs documented another layer of intentional structure in the botnet's C2 architecture. The botnet does not route all infected devices to the same set of C2 servers. Instead, the operators maintain separate C2 infrastructure segmented by device type and model.

At the time of disclosure, the botnet operated three to four active C2 servers. Over half of the botnet — specifically the ASUS-device victims — connected to two dedicated "ASUS C2" servers. The remaining devices communicated with one of two separate C2 servers. This segmentation has operational benefits for the threat actor: different device types carry different residential IP characteristics, and keeping them separated allows the operators to package and sell proxy access to specific device pools without cross-contamination.

The segmentation also complicated attribution. Traffic from ASUS victims looks different from traffic from other edge device categories, and if security teams were monitoring only the ASUS-specific C2 servers, they would undercount the botnet's total reach. Lumen's backbone-level telemetry allowed them to observe across all C2 segments simultaneously, which is why the full scope of 14,000-plus devices became visible.

The Doppelganger Connection: Monetizing the Mesh #

Building a botnet is only half the operational picture. Sustaining it requires revenue, and KadNap's revenue stream runs through a proxy service called Doppelganger, operating at doppelganger[.]shop.

Doppelganger advertises residential proxy access across more than 50 countries, claiming complete anonymity. It launched in May or June 2025 — approximately two months before KadNap infections first appeared in Lumen's telemetry. The timing is consistent with an operator building the proxy service infrastructure first, then deploying the malware to populate it.

Lumen and its partner Spur — a residential proxy intelligence firm — assessed with high confidence that Doppelganger is a rebrand of the now-defunct Faceless proxy service. Faceless was previously powered by victims of TheMoon malware — another botnet that specifically targeted ASUS routers. The operational continuity between Faceless/TheMoon and Doppelganger/KadNap is striking: the same hardware target, the same proxy monetization model, and now the same evasion architecture evolution toward P2P C2 routing. Formosa and Rudd noted in their report that the Doppelganger launch in May–June 2025 preceded the first KadNap infections by roughly two months — consistent with a build-the-service-first, populate-it-second operational cadence.

Formosa and Rudd documented that KadNap's compromised devices are sold as proxy nodes through Doppelganger, where customers direct them toward brute-force campaigns and targeted exploitation operations. Every IP address tied to the botnet therefore carries active, ongoing risk — not just to its owner, but to any organization those addresses are pointed at. (Formosa and Rudd, Black Lotus Labs, March 2026.)

The value of residential proxy access in criminal marketplaces is straightforward: traffic routed through a residential IP appears to originate from a legitimate household user rather than a data center or known VPN range. Fraud detection systems, rate limiters, and IP reputation services are calibrated to distrust data center addresses and trust residential ones. A botnet populated with home and small-office routers is therefore more valuable per-device than a cloud-based proxy farm.

Doppelganger's customers use that access for credential stuffing, brute-force login campaigns, DDoS amplification, and targeted exploitation campaigns against specific organizations — all activities that benefit from distributing traffic across thousands of residential IPs. The infected ASUS router in a household in suburban Ohio becomes the apparent source of a login attempt against a financial institution's customer portal. The actual attacker's IP is never exposed.

The zero-trust network model exists in part as a response to precisely this threat: the assumption that source IP address alone is not a reliable trust signal, because residential addresses can be rented from proxy services like Doppelganger. Organizations that have not yet moved to device-aware authentication and behavioral anomaly detection remain exposed to this class of attack.

Victim Geography and Targeting Logic #

The geographic distribution of KadNap victims is not random. Over 60 percent of infected devices are located in the United States, with Taiwan and Hong Kong each accounting for approximately 5 percent of the victim pool. Russia, the United Kingdom, Australia, Brazil, France, Italy, and Spain make up additional clusters.

The United States concentration reflects several converging factors. American households and small businesses represent a large installed base of consumer-grade ASUS routers. Firmware update compliance rates among home users are historically low — many devices run firmware versions that are years out of date and vulnerable to techniques that have long since been patched. Remote management features, including ASUS's AiCloud service, are frequently left enabled with default credentials.

The Taiwan and Hong Kong concentrations are notable given ASUS's headquarters in Taiwan and its strong market share in the Asia-Pacific region. These markets tend to have high adoption of ASUS consumer hardware and similarly variable firmware maintenance practices.

The device segmentation the operators maintain — separate C2 paths for different device categories — suggests the threat actor has mapped out the proxy value of different victim pools and manages them accordingly. A United States-based residential IP has higher proxy market value than an equivalent address in some other regions, purely because US IPs are trusted more broadly by the fraud detection systems deployed at major financial and e-commerce platforms.

Why ASUS Specifically?

The ASUS concentration is not adequately explained by market share alone. ASUS is a large router vendor with strong penetration in the US consumer and SOHO markets, but so are Netgear, TP-Link, and Linksys. KadNap is not a broad-spectrum IoT campaign — it was built for ASUS hardware, with ARM and MIPS binaries sized for ASUS firmware environments and a persistence path (/jffs/.asusrouter) that directly mimics legitimate ASUS system file naming to evade casual inspection.

The most likely explanation is that the operators acquired or developed a reliable exploit chain for a specific ASUS vulnerability — or a set of them — before deploying the botnet. Researcher Chris Formosa assessed that zero-days are unlikely; the more probable scenario is a combination of known unpatched vulnerabilities and exposed management interfaces with weak credentials. The AiCloud service, in particular, has a history of severe CVEs and a user base that leaves it enabled by default without understanding its network exposure. An operator who had mapped ASUS's AiCloud attack surface and built tooling around it would rationally concentrate on that target population rather than expending effort on other hardware.

The Faceless/TheMoon lineage is also relevant here. TheMoon targeted ASUS routers specifically, which means the operators behind the rebrand as Doppelganger/KadNap were inheriting institutional knowledge of ASUS exploitation from a previous campaign. Tooling, credential lists, and vulnerability research do not disappear when a proxy service rebrands — they carry forward. The ASUS focus is likely as much a legacy artifact of that accumulated expertise as it is a rational market decision about residential IP value.

The P2P C2 Lineage: Overbot to Hajime to Mozi to KadNap #

KadNap does not represent an isolated innovation. The use of peer-to-peer protocols for botnet command-and-control has a documented research history stretching back nearly two decades, and KadNap's architecture fits squarely within that evolutionary lineage.

The concept was first formalized in a proof-of-concept called Overbot, presented at the ACM SecureComm 2008 conference by Guenther Starnberger, Christopher Kruegel, and Engin Kirda ("Overbot: A Botnet Protocol Based on Kademlia," SecureComm 2008, ACM DOI: 10.1145/1460877.1460894). Overbot demonstrated that a structured P2P protocol could provide a botnet operator a resilient, decentralized C2 channel with no central server to sinkhole — and crucially, that capturing individual nodes within the botnet would reveal nothing about other nodes or the botmaster's address. It remained a proof-of-concept, but the paper entered the threat research literature as a documented, prescient blueprint.

The practical application arrived with IoT-targeting malware. Hajime, first observed in 2016, used a BitTorrent-based P2P architecture to manage infected devices, positioning itself explicitly as a DHT-native botnet without any centralized C2 dependency. Mozi, discovered in 2019, extended Hajime's approach and scaled to hundreds of thousands of infected IoT devices before its operators were arrested and its kill switch was activated in 2023.

KadNap is the current state of this technique's evolution. It adapted the Kademlia model with custom obfuscation layers — the NTP-derived XOR key, the SHA-1 infohash computation, the AES-encrypted peer handshake — designed to resist both signature-based detection and network-layer analysis. The critical regression is the two-node chokepoint, which represents a step backward from Mozi's more genuinely distributed architecture. Whether this was a deliberate tradeoff for operational control or a technical limitation in the operators' implementation is not publicly known.

What is clear is the direction of travel. Each iteration of P2P malware learns from the forensic takedowns of its predecessors. The operators of whatever follows KadNap will have read the Black Lotus Labs report. The next implementation will likely eliminate the fixed relay nodes entirely, moving toward a truly dynamic peer routing model that forces defenders to operate without a static chokepoint to monitor.

Detection and Defense #

Standard C2 detection approaches — maintaining blocklists of known malicious IP addresses and domains — are specifically what KadNap was designed to defeat. An infected device querying the BitTorrent DHT with a custom infohash generates traffic that looks, from a network monitoring perspective, like ordinary peer discovery activity. Without behavioral analysis tuned to identify anomalous P2P traffic from infrastructure devices, the infection is silent.

Lumen's detection was possible because of their visibility into backbone-level traffic patterns. The algorithm that flagged KadNap was built to identify clusters of edge devices communicating with a common set of servers — not to flag individual infected devices, but to detect the statistical signature of botnet-scale coordination. That kind of detection capability is not available to the average network operator.

For organizations and individuals running ASUS routers, the practical defensive posture requires more than the standard checklist. The following layers address the specific attack surfaces KadNap exploited — and the gaps that made 14,000 infections possible in the first place.

Firmware and Patch Management

Running outdated firmware is the primary enabler here. The issue is not simply that patches exist — it is that firmware update mechanisms on consumer routers are either manual, easily missed, or disabled by users who disabled auto-update to prevent unexpected reboots. The deeper fix is to treat the router as a managed network asset rather than a set-and-forget appliance. On ASUS devices, auto-update can be enabled via Administration > Firmware Upgrade > Check > Auto Firmware Upgrade. If your ISP provides centrally managed router firmware, verify that the managed version is current and that AiCloud is not silently re-enabled after firmware updates, which has occurred in some ASUS firmware revision cycles.

For devices that are past their end-of-support date and will not receive further patches — a category that the WrtHug campaign specifically targeted in November 2025 — the correct decision is replacement, not continued operation with workarounds. Applying firewall rules to an actively exploitable device buys time but does not close the underlying attack surface.

Targeted Service Disablement

Generic advice to "disable unnecessary remote access" obscures what specifically needs to go. On ASUS routers, the services with direct relevance to this campaign are: AiCloud (Administration > Cloud Disk, disable all toggles), remote management via WAN (Administration > System > Enable Web Access from WAN, set to No), and DDNS unless explicitly needed. AiCloud in particular has a persistent history of severe CVEs — CVE-2025-59366 scored CVSS 9.8 — and its default state on many models is enabled. If you are not using it, you should not be running it.

Beyond ASUS-specific services: any router with an externally reachable management port (80, 443, 8080) that uses default or dictionary credentials is a candidate for this class of attack regardless of vendor. Credential stuffing against management interfaces is exactly the entry vector Formosa assessed as most likely for KadNap's initial access.

Network Behavioral Analytics for Infrastructure Devices

The Cloud Security Alliance's research note on KadNap identifies a specific defensive gap that most organizations have not closed: the absence of behavioral anomaly detection tuned to distinguish traffic generated by infrastructure devices from traffic passing through them. A workstation generating BitTorrent DHT traffic is expected. A router initiating the same traffic is not. SIEM rules and IDS signatures written for endpoint behavior will not catch this.

The practical implementation for organizations that can act on this: configure network monitoring to alert on BitTorrent DHT (get_peers / announce_peer bencoded UDP) originating from RFC 1918 gateway addresses rather than from hosts behind them. If you are running Zeek, a custom signature that matches DHT bencoding patterns on traffic sourced from your router's LAN-side IP can be written in a few lines. A router generating this traffic at regular intervals with a consistent small set of destination IPs — rather than a large, rotating population of DHT peers as a legitimate client would produce — is a strong behavioral signal.

Active Infohash Prediction as a Detection Primitive

This is the approach the article noted earlier as theoretically available to resourced defenders: because KadNap's infohash derivation is known from binary analysis (64-byte seed + NTP timestamp + uptime XOR), a defender who has extracted those values from a sample can predict the infohash values a given infected device will generate across a time window. Deploying a DHT monitor to query those predicted values and log responding devices gives you an active enumeration capability — rather than waiting passively for infected devices to surface through relay node contact, you can probe for them. This is a technique available to threat intelligence teams and ISPs rather than individual home users, but it represents a genuinely more aggressive detection posture than IoC blocking alone.

Perimeter Blocking of Known C2 Infrastructure

This layer is straightforward but should be understood correctly. Blocking outbound traffic to 45.135.180[.]38 and 45.135.180[.]177 at your network perimeter does not clean an existing infection — the kad process and the JFFS2 cron job continue running. What it does is prevent an uninfected device from completing the enrollment handshake, and prevent an already-infected device from completing the C2 delivery step (receiving the .sose payload containing C2 addresses). Apply the full Lumen IoC list to your upstream firewall or IDS — nftables rules are well-suited for this kind of IP-based outbound blocking on Linux-based gateway hosts — including the staging server at 212.104.141[.]140. Update the list as additional infrastructure is identified.

Isolation and Recovery

If compromise is suspected: isolate the device from the network before attempting any remote diagnosis. KadNap's fwr.sh payload drops all inbound TCP on port 22, which means SSH access will be unavailable on a device that has completed the full infection chain. Recovery requires console access or a factory reset — remote remediation is not an option once that iptables rule is in place. Perform the factory reset before reconnecting the device to any network, then install the latest firmware from ASUS's official download portal before powering it back on to prevent immediate re-infection.

For organizations managing a fleet of ASUS devices: the IoC to check at scale is the JFFS2 filesystem path /jffs/.asusrouter and the running process name kad. If you have management access to the device filesystem via ASUS's router management API or a deployed agent, automate a check for these indicators across all managed routers as a first pass. A cron entry firing at */55 * * * * on a router is a near-certain sign of infection.

At the organizational level, the Cloud Security Alliance's research note on KadNap identifies a specific defensive capability gap: the absence of network behavior analytics capable of flagging anomalous P2P activity from infrastructure devices. Workstations generating BitTorrent DHT traffic is expected behavior. Routers doing so is not. Deploying behavioral tracing tools and network anomaly detection that distinguishes endpoint categories is a high-value investment against this class of threat — and against whatever follows it.

Lumen's Response and IoC Distribution #

As of the March 10, 2026 publication date, Lumen stated it had proactively blocked all network traffic to and from KadNap's known control infrastructure on its own backbone. This action affects traffic traversing Lumen's network and provides direct protection for Lumen customers, but it does not disrupt the botnet globally — devices on other providers' networks remain operational.

Black Lotus Labs committed to distributing the indicators of compromise into public threat intelligence feeds to enable broader disruption by other security teams and providers. The IoC set includes the two relay node IP addresses, the initial staging server at 212.104.141[.]140, and the C2 server addresses recovered from the .sose payload.

Lumen also credited their partner Spur — a residential proxy intelligence firm — for their contributions to mapping the relationship between KadNap's C2 infrastructure and the Doppelganger proxy service. Spur's data identified the C2 servers as entry points for Doppelganger's proxy network, which allowed Black Lotus Labs to establish the monetization connection with confidence rather than inference.

The disclosure represents a coordinated threat intelligence operation: Lumen provided the malware analysis and network telemetry, Spur provided the proxy service attribution, and the combined picture is substantially more actionable than either piece alone. This is the model that tends to produce effective botnet disruption — not a single team working in isolation, but coordinated disclosure across organizations with complementary data sets.

Why Not Sinkhole It?

A question the disclosure naturally raises is why Lumen's response was limited to blocking traffic on their own backbone rather than attempting a sinkhole operation — registering or seizing the relay node IPs to redirect infected devices to a controlled destination and enumerate the full victim population.

The answer is structural. KadNap's relay nodes are IP addresses, not domains, and sinkholing IP infrastructure is a fundamentally different legal and operational problem than domain sinkholing. Registering an expiring domain is a routine law enforcement and threat intelligence operation with established procedures. Seizing IP address blocks requires coordination with the hosting provider, typically through legal process, and hosting providers in jurisdictions that are uncooperative with Western law enforcement requests are specifically chosen by botnet operators for this reason. Lumen can block traffic to 45.135.180[.]38 on their own backbone because it is their network — they cannot compel a foreign hosting provider to hand over control of those IPs.

What Lumen could do, and did, is publish the IoCs into public threat intelligence feeds and notify relevant parties. Whether law enforcement action against the relay node hosting infrastructure is underway is not addressed in the public disclosure.

What Happens to the 14,000 Devices Now?

Publication of the Black Lotus Labs report does not clean a single infected router. The kad binary is still running on every one of the 14,000-plus compromised devices. The hourly cron job in the JFFS2 filesystem is still firing at the 55-minute mark. The iptables rule blocking SSH access is still in place.

Devices on Lumen's network will no longer be able to reach the KadNap relay nodes through that backbone, which disrupts the C2 connection for traffic that transits Lumen infrastructure. But devices on other ISPs — which is the large majority of 14,000 — remain fully operational nodes in the botnet. The Doppelganger proxy service continues to have a functional device pool until individual owners perform factory resets.

The realistic remediation path depends entirely on whether device owners take action. For most home users, that means receiving a notification from their ISP, seeing press coverage, or noticing anomalous behavior — none of which are guaranteed. Router botnets persist for months and years after disclosure precisely because the remediation burden falls on individuals who have no visibility into their device's behavior. ASUS's own notification mechanisms reach customers who have registered products with optional update services, which is a subset of the installed base. The 14,000 number at disclosure is likely to decline slowly rather than rapidly.

What KadNap Gets Wrong About Kademlia #

KadNap is a competent piece of malware in many respects. Its multi-architecture ELF delivery, its NTP-derived rotating infohash, its AES-encrypted peer handshakes, and its JFFS2-resident persistence all reflect genuine engineering effort toward evasion and resilience. The operators understood enough about Kademlia to build a system that generates plausible BitTorrent DHT traffic and hides its C2 addresses from static blocklist-based defense. As Formosa and Rudd assessed, the botnet's use of P2P for decentralized control distinguishes it from its proxy-service predecessors — and the operators' intent was clear: evade detection and raise the cost of defense. (Formosa and Rudd, Black Lotus Labs, March 2026.)

What they failed to understand — or chose to sacrifice — is the property that makes Kademlia actually hard to track at the infrastructure level. True decentralization means there is no fixed point to observe. The moment you introduce a fixed relay node, you reintroduce the very observability you were trying to eliminate.

Two static IP addresses sitting at the penultimate hop of every C2 lookup in a 14,000-device botnet are not hidden infrastructure. They are a fixed beacon broadcasting the botnet's presence to anyone with backbone-level telemetry. The silence of the hops, to borrow Black Lotus Labs' title, turned out to be not quite silent enough.

The lesson extends beyond KadNap specifically. For defenders, the takeaway is that P2P-based C2 evasion is a genuinely difficult problem to detect with signature-based tools — but it is not impossible to detect with behavioral analytics, because implementations in the wild consistently introduce the kind of structural shortcuts that create observable patterns. For threat actors, the lesson from every KadNap postmortem they will inevitably read is the same: if you are going to use Kademlia for operational cover, you have to actually use Kademlia.

References

1. Formosa, C. and Rudd, S. (Lumen Technologies / Black Lotus Labs). "Silence of the Hops: The KadNap Botnet." Technical editing by Ryan English. March 10, 2026.
2. Cloud Security Alliance AI Safety Initiative. "KadNap Botnet: Kademlia DHT C2 Evasion on ASUS Edge Devices." March 11, 2026.
3. Maymounkov, P. and Mazières, D. "Kademlia: A Peer-to-Peer Information System Based on the XOR Metric." Proceedings of the First International Workshop on Peer-to-Peer Systems (IPTPS 2002). Springer LNCS vol. 2429. DOI: 10.1007/3-540-45748-8_5.
4. Starnberger, G., Kruegel, C. and Kirda, E. "Overbot: A Botnet Protocol Based on Kademlia." Proceedings of the 4th International Conference on Security and Privacy in Communication Networks (SecureComm 2008). ACM. DOI: 10.1145/1460877.1460894.
5. Toulas, B. "New KadNap botnet hijacks ASUS routers to fuel cybercrime proxy network." BleepingComputer. March 2026.
6. Goodin, D. (Ars Technica). "14,000 routers are infected by malware that's highly resistant to takedowns." March 2026.
7. The Hacker News. "KadNap Malware Infects 14,000+ Edge Devices to Power Stealth Proxy Botnet." March 2026.

How to Detect and Respond to KadNap Router Infection

Step 1: Check for indicators of compromise

Review Black Lotus Labs' published indicators of compromise. Look for suspicious cron jobs referencing .asusrouter, unexpected processes named kad, and outbound traffic to 45.135.180[.]38 or 45.135.180[.]177.

Step 2: Perform a factory reset and firmware update

If compromise is suspected, perform a full factory reset on the router. Before reconnecting, update to the latest available firmware directly from ASUS's official site to close the vulnerabilities used during initial access.

Step 3: Harden the device post-recovery

Change all default credentials to strong, unique passwords. Disable remote management and AiCloud services unless strictly required. Block inbound and outbound traffic to published KadNap C2 addresses and apply Lumen's IoC list to your firewall or IDS.

Frequently Asked Questions

What is the KadNap botnet?

KadNap is a malware botnet discovered by Lumen Technologies' Black Lotus Labs researchers Chris Formosa and Steve Rudd in August 2025. It primarily targets ASUS routers and edge networking devices, enrolling them into a peer-to-peer proxy network. By March 2026, the botnet had grown to over 14,000 infected devices, with more than 60 percent of victims located in the United States.

Why did KadNap's Kademlia implementation fail to protect the botnet's infrastructure?

KadNap used a non-true Kademlia implementation. In a genuine Kademlia distributed hash table network, the final hop node changes dynamically over time. KadNap's implementation always routed through the same two final-hop nodes at IP addresses 45.135.180[.]38 and 45.135.180[.]177 before reaching the command-and-control servers. This static chokepoint made the infrastructure visible to researchers and allowed them to map the entire botnet.

What is the Doppelganger proxy service linked to KadNap?

Doppelganger, operating at doppelganger[.]shop, is a criminal proxy service that sells access to devices compromised by KadNap as residential proxies. Researchers at Black Lotus Labs and partner firm Spur assess it to be a rebrand of the defunct Faceless proxy service, which previously used TheMoon malware to build its device pool. Customers use it for DDoS attacks, credential stuffing, and brute-force campaigns.

Which ASUS firmware vulnerabilities is KadNap associated with?

No zero-day vulnerabilities have been attributed to KadNap's initial access vector. Available evidence points to credential-based entry and exploitation of unpatched firmware. Two CVSS 9.8 vulnerabilities disclosed by ASUS in November 2025 are relevant to the broader ASUS threat landscape: CVE-2025-59366, an authentication bypass and Samba command injection enabling unauthenticated remote code execution on AiCloud-enabled routers, and CVE-2025-59367, an unauthenticated remote access flaw affecting DSL-AC51, DSL-N16, and DSL-AC750 devices. Devices running outdated firmware with exposed AiCloud interfaces represent the highest-risk attack surface.

Who discovered and analyzed KadNap?

KadNap was discovered and analyzed by Chris Formosa and Steve Rudd of Black Lotus Labs, the threat research arm of Lumen Technologies. Their report, titled 'Silence of the Hops: The KadNap Botnet,' was published on March 10, 2026. Partner firm Spur contributed proxy service attribution. The Cloud Security Alliance AI Safety Initiative published an independent analysis on March 11, 2026.

Why does KadNap specifically target ASUS routers?

The ASUS concentration reflects a combination of market share, vulnerability surface, and operational history. ASUS's AiCloud service has a history of critical CVEs and is frequently left enabled with weak credentials in consumer deployments. The operators behind KadNap are assessed to have inherited tools, credential lists, and vulnerability research from the earlier Faceless/TheMoon campaign, which also targeted ASUS routers specifically. When a threat actor has an established, working exploit chain for a particular hardware target, they tend to continue exploiting it.

Does the Black Lotus Labs disclosure clean infected routers?

No. Publication of the KadNap report does not remove the malware from any infected device. The kad binary and the JFFS2-resident cron job continue running on all compromised routers until the device owner performs a factory reset. Lumen blocked KadNap traffic on its own backbone, protecting customers whose traffic transits that network, but devices on other ISPs remain fully operational botnet nodes. Recovery requires a factory reset followed by a firmware update before the router is reconnected to the network.