In-app reader

Kimwolf v7: An Evolution of the Kimwolf Botnet

Unit 42August 12, 2026Sign in to save

Kimwolf v7: An Evolution of the Kimwolf Botnet

11 min read

By:

Published: August 11, 2026

Share

Content Warning

We are providing a content warning because the following article contains usage of a racial slur by a threat actor, which Unit 42 does not condone in any instance. We have partially redacted the racial slur, but preserved some references to it in order to provide researchers with the ability to identify it and check IoCs as needed.

Executive Summary

We identified a new version (v7) of the Kimwolf Android/internet-of-things (IoT) botnet. This version upgrades its distributed denial-of-service (DDoS) attack capabilities and the resilience of its command-and-control (C2) infrastructure. Kimwolf primarily affects Android TV boxes and set-top boxes.

Kimwolf v7 adds an HTTP/2-based DDoS flood that constructs complete browser fingerprints. This makes attack traffic more difficult to distinguish from legitimate browsing.

The threat’s binary includes five hard-coded public Ethereum-based endpoints for resolving Ethereum Name Service (ENS) domains. ENS is a blockchain-based naming system used to obtain C2 addresses.

Kimwolf also carries a hard-coded Tor .onion hidden service as a backup and a local proxy architecture for flexible routing between clearnet and Tor. The malware developers added this function to directly respond to C2 server takedown efforts in December 2025.

We discovered this variant on Feb. 3, 2026, through threat hunting that followed public disclosures by XLab, Synthient, Infoblox, Cloudflare and others.

Palo Alto Networks customers are better protected through the following products and services:

If you think you might have been compromised or have an urgent matter, contact the Unit 42 Incident Response team.

Related Unit 42 Topics Malware, Botnet, DDoS

Background

The Kimwolf botnet (also tracked as AISURU) has been active since August 2024. It initially targeted Linux IoT devices under the AISURU name. The botnet transitioned to Android TV boxes around August 2025.

This reflects two separate codebases under the same operators. AISURU covers the Linux IoT variants, and Kimwolf covers variants targeting Android.

Kimwolf spreads by misusing residential proxy services to reach unauthenticated Android Debug Bridge (ADB) instances on local networks. Some Android TV boxes ship with ADB enabled on port 5555. Once attackers tunnel through a proxy endpoint into the local network, they can install the malware without any authentication.

Kimwolf Sample Overview

The Kimwolf sample we analyzed as a baseline is a statically linked ARM Executable and Linkable Format (ELF) binary. The file was compiled with the Android Native Development Kit (NDK) using Clang and uses Bionic libc. It statically links BoringSSL for Transport Layer Security (TLS) operations and nghttp2 for HTTP/2 functionality.

The binary is stripped but retains some symbol information. It is not uncommon for malware authors to use racial slurs in their code. The Kimwolf malware family has historically included racial slurs. In our discussion of the v7 variant, we have partially redacted these slurs, but have left enough information present that defenders could identify the variant and check for IoCs.

Previous Kimwolf builds used the internal version strings such as n[redacted]boxv4 and n[redacted]boxv5 , establishing the naming pattern for the family. The version string n_[redacted]boxv7 , shown in Figure 1, identifies this sample as version 7. The binary creates a Unix domain socket @n[redacted]boxv7 to ensure only one instance runs at a time. _

On execution, the malware masks its process name as netd_service to blend in with legitimate Android system processes.

We identified six ELF samples that we clustered together based on multiple indicators:

They share an identical ELF section layout produced by a common Android NDK build environment, and the same hard-coded set of Ethereum remote procedure call (RPC) endpoints
Overlapping C2 infrastructure within the same hosting provider
Consistent process-name masquerading behavior

HTTP/2 Flood with Browser Fingerprint Spoofing

One of the most notable new capabilities in Kimwolf v7 is an HTTP/2 flood powered by the nghttp2 library. The function that performs the attack_case17_http2_flood constructs complete browser fingerprints. This makes the flood traffic difficult to distinguish from legitimate browser requests.

Figure 2 shows the header construction logic in the decompiled binary.

Three-Tier C2 Infrastructure

Kimwolf v7 uses a layered C2 resolution system designed to survive the domain takedowns that disrupted the botnet twice in December 2025.

Ethereum Name Service Resolution

The binary contains five hard-coded public Ethereum RPC endpoints stored in plaintext, shown in Figure 3:

hxxps[:]//0xrpc[.]io/eth
hxxps[:]//eth.llamarpc[.]com
hxxps[:]//ethereum-rpc.publicnode[.]com
hxxps[:]//eth-protect.rpc.blxrbdn[.]com
hxxps[:]//eth.merkle[.]io

These endpoints are legitimate public Ethereum RPC services. The malware misuses them to query ENS domain records and resolve C2 addresses. Organizations should monitor for unusual Ethereum RPC traffic from IoT and Android devices rather than blocking these endpoints outright.

The malware shuffles these endpoints using a pseudo-random number generator (PRNG) before each resolution attempt. The five-way redundancy makes blocking ENS-based C2 resolution harder.

Operator RPC Facade

While the five public RPC endpoints in the baseline binary are third-party services, our infrastructure investigation identified a sixth endpoint that we assess with moderate confidence to be under the operator's control: eth[.]rpcuniverse[.]com.

Several properties distinguish it from the legitimate providers:

The legitimate endpoints are established services with significant traffic and resolve to multiple anycast IP addresses across major cloud delivery network (CDN) and cloud providers
They have apex domains registered between 2005 and 2022
The rpcuniverse[.]com domain has no global traffic ranking
It resolves to a single IP address on a low-cost virtual private server (VPS) that was registered on Dec. 12, 2023
Its TLS certificate first appeared on the hosting IP address days later
Reverse passive DNS shows the IP address hosts only rpcuniverse[.]com subdomains with no other tenants
Two Kimwolf samples hardcode eth[.]rpcuniverse[.]com as an additional RPC endpoint alongside the five legitimate providers
Both ELF and Android APK variants contact the hosting IP address directly
We did not observe this direct-to-IP address contact pattern with any of the legitimate RPC endpoints

We cannot confirm domain ownership. However, the dedicated single-tenant hosting, the timing of its registration relative to Kimwolf activity and its exclusive presence in Kimwolf binaries suggest it is an operator-controlled facade rather than a public service.

Tor Hidden Service Backup

When ENS resolution fails, the v7 binary falls back to a hard-coded v3 Tor .onion address ( edctgwib2n5l34t525zkxqzk5bqb6e5il2yiq5r6zu7gtlxa4uosn3qd[.]onion ). Figure 4 shows the hard-coded address in the binary.

A function ( tor_proxy_state_machine ) manages the protocol states. To do this, it performs the following activities:

Sending the greeting ( 0x05 0x01 0x00 )
Building a CONNECT request with domain type 0x03 and the 62-byte .onion address
Waiting for the response and performing a TLS handshake over the tunnel

Figure 5 shows the greeting and TLS handshake states.

Additionally, it uses a local proxy architecture. All C2 traffic routes through a local proxy at 127.0.0[.]1:23075 shown in Figure 6, regardless of whether it is destined for clearnet or Tor. This modular design allows the proxy component to be updated independently from the main bot binary.

C2 Infrastructure Clustering

Analysis of Kimwolf v7 samples revealed C2 connections to several IP addresses, including:

212.193.31[.]119 and 212.193.31[.]122 on TCP port 13
212.193.31[.]92 and 212.193.31[.]158 on TCP port 443

None of these IP addresses had prior indicators of malicious activity or associations with public threat intelligence.

During infrastructure analysis, we observed that these hosts presented the same SSH host key. Pivoting on that shared key revealed 22 total IP addresses within the same range, presenting the identical key between Dec. 18, 2025, and Feb. 3, 2026. No hosts outside this range shared the key.

IP address 212.193.31[.]102 was the first host observed with this keyon Dec. 18, 2025, and it was the seed from which the configuration propagated. The remaining 21 hosts appeared over the following six weeks, with the last addition on Jan. 31, 2026. All 22 hosts reside in AS202799, geolocated to Saint Petersburg, Russia.

High-Performance UDP Flood

Kimwolf implements a dedicated high-performance UDP flood function that uses a Xorshift256 PRNG seeded from /dev/urandom . It ( prng_seed_from_urandom ) reads 32 bytes (four 64-bit state words) to initialize the full 256-bit state. A SplitMix64 fallback initializer activates if /dev/urandom is unavailable.

The flood function accelerates IP/UDP checksum computation with ARM NEON single instruction, multiple data (SIMD) instructions. The vectorized checksum loop processes four 16-bit halfwords simultaneously using VLD1.16, VADDW.U16 and VADD.I32 instructions.

This optimization is tailored for the ARM processors found in Android TV boxes. It reduces per-packet checksum overhead to maximize throughput.

Figure 7 shows the NEON SIMD instructions in the disassembled binary.

Complete Attack Method Inventory

The dispatch table supports 15 DDoS methods across Layers 3–7 of the Open Systems Interconnection (OSI) model. Cases 8, 11 and 13 are absent from the switch statement, suggesting they are either reserved for future use or were removed during consolidation from the 43 text-named methods in prior versions.

Table 1 lists all 15 attack methods.

Case number Function **Description **

0 attack_case0_tcp_socket_flood TCP socket-based flood

1 attack_case1_udp_flood_v1 UDP flood variant 1

2 attack_case2_game_server_udp Game server UDP flood (port 27015)

3 attack_case3_dns_flood DNS query flood

4 attack_case4_udp_flood_v2 UDP flood variant 2

5 attack_case5_tcp_syn_flood TCP SYN flood

6 attack_case6_tcp_ack_flood TCP ACK flood

7 attack_case7_tcp_synack_flood TCP SYN-ACK flood

9 attack_case9_udp_async_flood Asynchronous UDP flood

10 attack_case10_tcp_rst_flood TCP RST flood

12 udp_flood_attack High-performance UDP flood (NEON SIMD)

14 attack_case14_icmp_flood ICMP flood

15 attack_case15_tcp_connection_flood epoll-based TCP connection flood

16 attack_case16_tls_https_flood TLS/HTTPS flood (BoringSSL)

17 attack_case17_http2_flood HTTP/2 flood with Chrome fingerprints (nghttp2)

Table 1. Kimwolf v7 DDoS attack methods.

What Changed From Prior Versions

In Kimwolf v7, malware authors consolidated the attack count to 15 numbered methods. They removed all scanning, exploitation and brute-force functionality. The new additions target:

DDoS stealth through HTTP/2 with browser fingerprinting
C2 resilience through ENS, Tor and the local proxy

The removal of the scanner and exploit modules suggests the operators have separated the propagation pipeline from the DDoS bot. External loaders now handle initial access while the Kimwolf binary handles attacks and proxy relay.

The earliest dropped sample, targeting the x86 architecture with a Dirty COW exploit, suggests the family evolved from traditional Linux exploitation toward the current ADB-based Android propagation model. The transition from libn[redacted]kernel.so to the less conspicuous libdevice.so filename in November 2025, followed by a revert in December, indicates active operational security adjustments.

Android APK Variants

Alongside the standalone ELF payloads, the Kimwolf operators distribute Android APK packages that bundle an ELF kernel payload inside a Java wrapper. We identified eight APK samples spanning October through December 2025, all sharing the component class systemservice0644.N[redacted]Kernel .

These APKs masquerade as a system service called SystemService . On execution, they probe for root access and execute the embedded ELF kernel with commands shown below in Figure 8.

The earliest build (October 2025) used the com . Android prefix and bundled three kernel variants in a single APK. By late October, the package name shifted to com.n2.systemservice0644 , and the kernel was consolidated to a single binary. In November, the kernel filename changed from libn[redacted]kernel.so to libdevice.so , then reverted in the December builds.

Three signing certificates appear across the cluster:

The original Kimwolf APK certificate ( C=CN, CN=a ) used by the com.android.logcatd variants
An Android Debug certificate used during development
A self-signed certificate with subject C=XK, ST=lol, L=lol, O=lol, OU=lol, CN=lol (country code XK for Kosovo, all other fields set to lol ) used by five of the eight N[redacted]Kernel APK files

Dropped ELF Kernel Payloads

The APK wrapper drops one of three ELF kernel payloads, depending on the build. These are listed in Table 2.

SHA256 Hash Filename Architecture

9470c68f9b6fe5f90d61891b95623afd7b4298815b0f95e25610e1c09008dc24 libn[redacted]kernel.so ARM

8242443dfcec66e3fe04cbfa2fbd211ad34065ee07aa93813d792a437caab212 libdevice.so ARM

421111a57b0a4224c052fa4108d90429d579974b5b5111ed2e58516ba09422ca libn[redacted]kernel.so (v1) x86

Table 2. Dropped ELF kernel payloads.

The earliest sample (first seen Sept. 2, 2025) is notable for two reasons:

It targets x86 architecture rather than ARM
This indicates that the botnet originally targeted x86 Linux systems before pivoting to ARM-based IoT and Android devices
It drops a file named libcow.so , and renames its process to inetd to blend in with Unix network services
The name libcow.so is likely a reference to the Dirty COW privilege escalation vulnerability (CVE-2016-5195)

The libdevice.so sample renames its process to TVHelper , which explicitly targets Android TV set-top boxes by mimicking a legitimate TV helper service.

Neither the libn[redacted]kernel.so nor libdevice.so kernels embed the Ethereum RPC endpoints found in the standalone ELF builds. The C2 resolution layer resides in the outer APK wrapper or the standalone ELF binary, while the kernel handles lower-level bot operations.

Conclusion

Kimwolf v7 is a focused evolution of an already large-scale botnet. The HTTP/2 flood with Chrome browser fingerprinting complicates application-layer DDoS mitigation, as attack traffic now mirrors legitimate browser behavior at the protocol and header level.

The three-tier C2 system (Ethereum ENS, Tor .onion , local proxy) indicates that the operators are investing in infrastructure built to withstand takedown operations. Organizations should monitor for the following behavioral indicators of Kimwolf compromise on IoT and Android devices:

Outbound HTTPS connections to public Ethereum RPC endpoints (e.g., 0xrpc[.]io ) from devices that typically do not interact with blockchain services
Tor circuit establishment or SOCKS5 proxy traffic from Android TV boxes or IoT devices
Connections to port 23075 on localhost
A process named netd_service running on consumer Android devices

Organizations should treat Android TV boxes as untrusted and segment them from enterprise networks. Disabling ADB or restricting it to USB-only access removes the primary propagation vector for this botnet.

Palo Alto Networks customers are better protected through the following products and services:

The Advanced WildFire machine-learning models and analysis techniques have been reviewed and updated in light of the indicators shared in this research,
Advanced URL Filtering and Advanced DNS Security identify known domains and URLs associated with this activity as malicious.
Device Security is designed to proactively protect the entire device attack surface, from IT to IoT and OT, with a unified platform that helps deliver comprehensive visibility, actionable risk insights and adaptive security enforcement.

If you think you may have been compromised or have an urgent matter, get in touch with the Unit 42 Incident Response team or call:

North America: Toll Free: +1 (866) 486-4842 (866.4.UNIT42)
UK: +44.20.3743.3660
Europe and Middle East: +31.20.299.3130
Asia: +65.6983.8730
Japan: +81.50.1790.0200
Australia: +61.2.4062.7950
India: 000 800 050 45107
South Korea: +82.080.467.8774

Palo Alto Networks has shared these findings with our fellow Cyber Threat Alliance (CTA) members. CTA members use this intelligence to rapidly deploy protections to their customers and to systematically disrupt malicious cyber actors. Learn more about the Cyber Threat Alliance.