Kimwolf Android Botnet Infects Over 2 Million Devices via Exposed ADB and Proxy Networks

Kimwolf Android Botnet Infects Over 2 Million Devices via Exposed ADB and Proxy Networks

Jan 05, 2026Ravie LakshmananIoT Security / Mobile Security

The botnet known as Kimwolf has infected more than 2 million Android devices by tunneling through residential proxy networks, according to findings from Synthient.

“Key actors involved in the Kimwolf botnet are observed monetizing the botnet through app installs, selling residential proxy bandwidth, and selling its DDoS functionality,” the company said in an analysis published last week.

Kimwolf was first publicly documented by QiAnXin XLab last month, while documenting its connections to another botnet known as AISURU. Active since at least August 2025, Kimwolf is assessed to be an Android variant of AISURU. There is growing evidence to suggest that the botnet is actually behind a series of record-setting DDoS attacks late last year.

The malware turns infected systems into conduits for relaying malicious traffic and orchestrating distributed denial-of-service (DDoS) attacks at scale. The vast majority of the infections are concentrated in Vietnam, Brazil, India, and Saudi Arabia, with Synthient observing approximately 12 million unique IP addresses per week.

Cybersecurity

Attacks distributing the botnet have been primarily found to target Android devices running an exposed Android Debug Bridge (ADB) service using a scanning infrastructure that uses residential proxies to install the malware. No less than 67% of the devices connected to the botnet are unauthenticated and have ADB enabled by default.

It’s suspected that these devices come pre-infected with software development kits (SDKs) from proxy providers so as to surreptitiously enlist them in the botnet. The top compromised devices include unofficial Android-based smart TVs and set-top boxes.

Kimwolf Android Botnet Infects Over 2 Million Devices via Exposed ADB and Proxy Networks

As recently as December 2025, Kimwolf infections have leveraged proxy IP addresses offered for rent by China-based IPIDEA, which implemented a security patch on December 27 to block access to local network devices and various sensitive ports. IPIDEA describes itself as the “world’s leading provider of IP proxy” with more than 6.1 million daily updated IP addresses and 69,000 daily new IP addresses.

In other words, the modus operandi is to leverage IPIDEA’s proxy network and other proxy providers, and then tunnel through the local networks of systems running the proxy software to drop the malware. The main payload listens on port 40860 and connects to 85.234.91[.]247:1337 to receive further commands.

Kimwolf Android Botnet Infects Over 2 Million Devices via Exposed ADB and Proxy Networks

“The scale of this vulnerability was unprecedented, exposing millions of devices to attacks,” Synthient said.

Furthermore, the attacks infect the devices with a bandwidth monetization service known as Plainproxies Byteconnect SDK, indicating broader attempts at monetization. The SDK uses 119 relay servers that receive proxy tasks from a command-and-control server, which are then executed by the compromised device.

Cybersecurity

Synthient said it detected the infrastructure being used to conduct credential-stuffing attacks targeting IMAP servers and popular online websites.

“Kimwolf’s monetization strategy became apparent early on through its aggressive sale of residential proxies,” the company said. “By offering proxies as low as 0.20 cents per GB or $1.4K a month for unlimited bandwidth, it would gain early adoption by several proxy providers.”

“The discovery of pre-infected TV boxes and the monetization of these bots through secondary SDKs like Byteconnect indicates a deepening relationship between threat actors and commercial proxy providers.”

To counter the risk, proxy providers are recommended to block requests to RFC 1918 addresses, which are private IP address ranges defined for use in private networks. Organizations are advised to lock down devices running unauthenticated ADB shells to prevent unauthorized access.



Source link