Cybersecurity teams have identified a new upgrade in the Kimwolf v7 Android botnet, a malware operation targeting Android and Internet of Things (IoT) devices. The update brings notable improvements aimed at keeping the botnet operational and increasing the effectiveness of distributed denial-of-service (DDoS) attacks.
What stands out most is a new HTTP/2-based flood technique that attempts to look like real user traffic. Instead of sending obvious, easily distinguishable requests, the attackers build browser-like fingerprints at the protocol and header level. At the same time, they have adjusted how their command-and-control (C2) infrastructure is reached, with the goal of making takedown efforts harder.
What researchers found in Kimwolf v7
The Kimwolf v7 Android botnet was reported after researchers at Palo Alto Networks Unit 42 discovered the new version in February 2026. The malware is associated with the Kimwolf family on Android devices and with a related Linux-focused counterpart, AISURU, aimed at Linux IoT systems. Public reporting indicates the campaign has been active since at least mid-2024.
In previous and ongoing activity, the botnet has frequently targeted Android TV boxes. The infection path often relies on residential proxy services to reach devices running Android Debug Bridge (ADB) enabled on local networks, particularly where ADB is exposed on port 5555.
HTTP/2 DDoS that mimics legitimate browsing
One of the core upgrades in Kimwolf v7 is its ability to conduct an HTTP/2 DDoS flood. Researchers describe that the flood is powered by the nghttp2 library and that it constructs complete browser fingerprints to mirror legitimate browser behavior.
This is significant because many DDoS campaigns rely on traffic patterns that differ from normal browsing. By aligning protocol handling and headers with what a real browser would send, the attackers attempt to make their traffic harder to separate from legitimate sessions.
More automation, less obvious behavior
Beyond HTTP/2, the botnet also focuses on blending into the environment once deployed. For example, the malware attempts to masquerade as seemingly legitimate Android system processes (such as a process name resembling netd_service) to reduce the likelihood of detection.
Harder-to-takedown command-and-control design
In addition to improving attack traffic, Kimwolf v7 updates how it retrieves C2 instructions. Researchers report a tiered approach that combines multiple components intended to increase resilience.
- ENS lookups: The malware uses Ethereum Name Service (ENS) domain records to obtain a C2 address.
- Hidden service: A hard-coded Tor .onion hidden service is included in the binary as a backup mechanism.
- Local proxy relay: All C2 traffic is routed through a local proxy endpoint, described as 127.0.0.1:23075, regardless of whether the destination is clearnet or Tor.
According to the reporting, these design choices are meant to make the operational infrastructure more resistant to disruption attempts. If one resolution or routing path fails, the fallback pathways can still keep the infected device connected to C2.
Separation of propagation and the core payload
Another change observed in Kimwolf v7 is the removal of functionality tied to scanning, exploitation, and brute-force activity within the main bot binary. In practice, this suggests the attackers split their operation into separate stages.
Researchers interpret this as a shift where propagation is handled by an external loader for initial access, while the Kimwolf component itself focuses on DDoS duties and proxy relaying. By removing the scanning and exploitation modules from the primary binary, the attackers can reduce what defenders see from the core payload and potentially limit exposure during each stage.
Targeting patterns and device-specific activity
Kimwolf is reported to focus on Android TV boxes, and this is reflected in its performance choices. The updated malware includes a high-performance UDP flood function that specifically targets ARM processors commonly found in Android TV hardware.
Researchers also note changes in how attack commands are represented. In the latest version, DDoS attack instructions are consolidated into 15 numbered methods, down from 43 text-named methods reported in prior versions. Fewer and more structured methods can reduce signature variance and make behavior harder to classify by text-based indicators.
ADB-based propagation and disguised Android packages
Beyond the DDoS engine, the operation relies on propagation through Android devices where ADB is exposed. The botnet typically abuses residential proxy services and looks for reachable Android TVs configured with ADB enabled on 5555 within local networks.
Once an initial foothold is established, the malware attempts to install components that enable both attack capability and relaying of malicious traffic. Researchers also report that distributed Android APK packages may masquerade as a system service named SystemService.
Root checks and bundled native payloads
Observed behavior includes probing for root access. The APKs also execute a bundled ELF kernel payload inside. Over a period from October to December 2025, researchers identified eight APK artifacts tied to this behavior.
Evolution from Linux exploitation toward Android ADB
Unit 42 highlights that early samples suggest the campaign has evolved over time. The earliest dropped example they describe targeted the x86 architecture and used a Dirty COW exploit, pointing to a more traditional Linux exploitation approach in earlier iterations.
Later activity indicates a shift toward the ADB-based Android propagation model. Researchers also observed naming changes in native libraries used by components over time, including adjustments from a more conspicuous library name (described as libn[redacted]kernel.so) to a less conspicuous filename (libdevice.so) in November 2025, followed by a revert in December 2025.
These adjustments align with an operational security mindset—reducing obvious artifacts while keeping core functionality intact.
Context: other recent IoT and botnet threats
The Kimwolf v7 disclosure comes alongside reporting on several other botnet and malware families detected in recent months. While these are separate campaigns, they underline a broader trend: criminals continuously refine IoT compromise methods and network abuse tactics.
- AryStinger targets older, vulnerable home routers for distributed reconnaissance and proxying.
- RustDuck hijacks routers, IP cameras, Android boxes, and poorly secured servers to conduct DDoS attacks.
- NadMesh combines scanning, exploitation, and intelligence harvesting into a single autonomous platform designed to identify and leverage many services, drop an SSH backdoor, and collect credentials and cloud configuration data.
- Tengu, a Mirai-derived IoT malware, uses Telnet brute-force to compromise devices and run instructions that support DoS activity and other follow-on actions.
What organizations can do to reduce risk
Unit 42’s recommendations focus on treating affected device categories as untrusted and limiting their ability to reach broader environments. For defenders, the most direct mitigation is to reduce or remove the propagation vector.
Key steps include:
- Treat Android TV boxes as untrusted and segment them away from enterprise networks.
- Disable ADB where possible.
- If ADB is required, restrict access so it is limited to USB-only access rather than exposing it over the network.
Conclusion
The newly observed Kimwolf v7 Android botnet demonstrates how botnets keep evolving: it now pairs HTTP/2 DDoS flooding with browser-like fingerprints, while also strengthening its C2 resilience using ENS lookups, Tor-based hidden service fallback, and a local proxy routing layer. At the same time, the propagation pipeline appears to be split so the core DDoS component avoids scanning and exploitation duties.
For organizations, the takeaway is straightforward: harden and isolate Android TV devices, and eliminate network-exposed ADB access to disrupt the botnet’s primary entry path.
Source: https://thehackernews.com/2026/08/kimwolf-v7-android-botnet-makes-http2.html
