KadNap Botnet Hijacks Thousands of ASUS Routers, Hides Command Servers Inside Peer-to-Peer Network

Researchers recently identified a previously undocumented malware family named KadNap. This malware targets internet-connected routers, particularly ASUS devices, and converts them into nodes within a large proxy-based botnet.

Monitoring conducted since August 2025 indicates that the network has expanded to over 14,000 compromised devices worldwide. Once infected, routers are used to relay traffic for malicious operations through a proxy platform known as Doppelganger.

A distinctive feature of KadNap is its custom implementation of the Kademlia Distributed Hash Table (DHT) protocol. Instead of using traditional command-and-control infrastructure, KadNap hides the location of its control servers inside a peer-to-peer network, which significantly complicates detection and disruption.

Because the command servers are embedded within this decentralized structure, security teams cannot easily identify or block them through standard network monitoring techniques.

Source : Lumen

Background: IoT Botnets and Proxy Infrastructure

As homes and organizations increasingly deploy internet-connected devices, attackers have gained access to a growing number of poorly secured systems.

IoT routers, in particular, are attractive targets because they:

  • Remain online continuously
  • Often run outdated firmware
  • Frequently use weak or default credentials

Threat actors take advantage of these weaknesses to build botnets, which are networks of compromised devices controlled remotely.

Some large residential proxy services maintain millions of infected devices, and both legitimate customers and cybercriminals may use them.

However, smaller botnets such as REMPROXY or Quad7 operate differently. These networks are typically run exclusively by criminal operators and are designed to support targeted cyber operations.


Initial Detection

In early August 2025, automated analysis detected more than 10,000 ASUS routers communicating with a limited set of external servers.

Further investigation revealed that these devices were downloading a shell script from: 212.104.141[.]140

The script, named aic.sh, acts as the initial loader for the KadNap malware.

Its primary function is to prepare the infected device and integrate it into the malware’s peer-to-peer infrastructure.


Malware Installation Process

The aic.sh script establishes persistence on the router by creating a cron task.

This scheduled job executes every hour at minute 55 and performs the following actions:

  1. Downloads a malicious script from the attacker’s server.
  2. Renames the file to .asusrouter.
  3. Stores it in the directory:
/jffs/.asusrouter
  1. Executes the script automatically.

After persistence is established, the script downloads a malicious ELF executable, renames it kad, and launches it.

A monitoring loop continuously checks whether the kad process is running. If the process stops, the script deletes the old file and downloads a new copy from the server.

This ensures the malware remains active even if the system attempts to terminate it.


Kademlia Distributed Hash Table (DHT)

KadNap’s architecture is based on a modified version of the Kademlia DHT protocol.

Kademlia is widely used in peer-to-peer applications such as:

  • BitTorrent DHT
  • eMule
  • I2P
  • Ethereum

The protocol allows nodes to locate information across a decentralized network without requiring a central server.

A useful analogy is a chain of contacts used to find a phone number. Each person in the chain might not know the number directly but knows someone who is closer to the answer.

Similarly, in Kademlia networks:

  • Each node knows a subset of peers.
  • Queries are forwarded to nodes closer to the desired target.
  • The search gradually converges on the correct node.

KadNap uses this mechanism to hide the IP addresses of its command servers, making them difficult for defenders to identify.


Malware Initialization

When the kad ELF binary executes, it begins with several setup procedures:

  • The process forks to run in the background.
  • Standard input, output, and error streams are redirected to /dev/null.
  • The system identifies the device’s external IP address.
  • Runtime information is stored in an internal structure.

The malware then attempts to synchronize system time by connecting to multiple NTP servers, including:

  • time-a.nist.gov
  • time.windows.com
  • ntp.asql.co.uk
  • chronos.csr.net

If one server fails, the malware automatically attempts the next.

The retrieved timestamp and device uptime are later used to generate hash values for peer discovery.


Peer Discovery Mechanism

After initialization, the malware creates a child process responsible for locating peers in the network.

This component connects to the BitTorrent DHT network using bootstrap nodes.

The malware then constructs a customized infohash used to search for other infected devices.

The infohash is generated through several steps:

  1. A unique XOR key is calculated using the NTP timestamp and system uptime.
  2. A hardcoded string is combined with this key.
  3. The result is hashed using SHA-1.
  4. The value is inserted into a bencoded structure.

Finally, the entire structure is hashed again to produce the final infohash, which is used to locate peers in the botnet.


Peer Communication

A separate thread handles communication with discovered peers.

This thread performs the following operations:

  1. Reads peer IP addresses and ports from an internal pipe.
  2. Connects to the peer node.
  3. Receives an encrypted data buffer (approximately 0x1000 bytes).
  4. Decrypts the data using a hardcoded key.

The decrypted payload is then hashed using SHA-1.

This hash becomes the AES encryption key used to secure all further communication with the peer.


Secondary Payload Delivery

After successfully reaching a final peer, the malware receives an additional payload.

Two files were observed during analysis:

1. fwr.sh

A shell script that modifies firewall rules by executing: iptables -I INPUT -p tcp –dport 22 -j DROP

This blocks incoming SSH connections, preventing administrators from remotely accessing the device.

2. .sose

A binary configuration file stored in:

/tmp/.sose

This file contains:

  • Command-and-control server addresses
  • Port numbers
  • Additional configuration parameters

Command Execution Module

The main malicious thread runs continuously in a loop.

Its responsibilities include:

  • Reading commands received through an internal pipe.
  • Executing scripts or binaries delivered by the C2 infrastructure.
  • Maintaining communication with peer nodes.

If the file /tmp/.sose exists, the malware reads its contents to obtain a list of C2 server addresses.

The malware then attempts to connect to these servers to receive instructions.


Weakness in the Custom Kademlia Implementation

In a legitimate Kademlia network, the final peer in a lookup chain changes frequently due to its decentralized structure.

However, analysis of KadNap samples revealed that the same two intermediary nodes consistently appear before devices contact the command servers.

These nodes were identified as:

45.135.180[.]38
45.135.180[.]177

This suggests the attackers intentionally maintain persistent infrastructure nodes to maintain control of the botnet.


Global Telemetry Findings

Black Lotus Labs has tracked KadNap activity since August 2025.

Key observations include:

  • Average active infections: ~14,000 devices
  • Active command servers: 3–4 at any given time

Early in its lifecycle, the botnet experienced fluctuations in infection numbers. However, during late 2025 and early 2026, the network size stabilized.


Geographic Distribution

Victims are distributed globally, with the largest concentration located in the United States.

Estimated distribution:

  • United States: ~60%
  • Taiwan: ~5%
  • Hong Kong: ~5%
  • Russia: ~5%

Other infections were observed across Europe, Asia, and parts of South America.


Infrastructure Segmentation

Analysis indicates that infected devices do not communicate with every command server.

Instead, the attackers appear to divide infrastructure based on device type or model.

For example:

  • Most ASUS routers communicate with two specific C2 servers.
  • Other device categories connect to different servers.

This segmentation improves operational stability and reduces the impact of takedowns.


Relationship to Proxy Services

The purpose of KadNap was initially unclear.

However, collaboration with security company Spur revealed that the command servers are connected to a commercial proxy service known as Doppelganger.

Evidence suggests this platform may be a rebranded version of the now-defunct Faceless proxy network, which previously relied on TheMoon malware.

The botnet’s infected routers are sold as residential proxies, allowing customers to route traffic through legitimate household IP addresses.

These proxies are commonly used for:

  • Credential stuffing attacks
  • Password spraying
  • Targeted exploitation campaigns
  • Anonymized cybercrime operations

Security Implications

KadNap represents a notable evolution in botnet design.

Unlike traditional botnets that rely on centralized command servers, KadNap uses a peer-to-peer architecture to hide its infrastructure and maintain resilience.

The botnet’s integration with a commercial proxy service also means that every infected device becomes part of a criminal service platform.

This creates long-term risk for both organizations and individual users.


Defensive Recommendations

Enterprise Security Teams

Organizations should consider the following defensive measures:

  • Monitor for authentication attacks originating from residential IP ranges.
  • Deploy Web Application Firewalls (WAFs) to block password-spraying attempts.
  • Identify devices communicating with BitTorrent trackers or KadNap peer nodes.

Consumer and SOHO Router Owners

Individuals and small organizations should:

  • Regularly update router firmware.
  • Reboot networking equipment periodically.
  • Replace devices that have reached end-of-life (EOL).

Routers should also avoid using default passwords.


Organizations Managing Edge Devices

Network administrators should:

  • Restrict access to device management interfaces.
  • Prevent administrative services from being exposed to the public internet.
  • Monitor traffic for connections to known KadNap peer infrastructure.

KadNap demonstrates how modern botnets are evolving to evade traditional detection mechanisms.

By combining peer-to-peer communication with residential proxy services, the attackers have built a resilient infrastructure capable of supporting large-scale malicious activity.

Indicators of compromise will be shared with the security community to support broader disruption efforts.