Kimwolf v7: An Evolution of the Kimwolf Botnet

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.

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.

Palot 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.

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.

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

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.

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

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.

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.

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.

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 key on 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.

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.

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.

Table 1. Kimwolf v7 DDoS attack methods.

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 rather than ARM, suggests that the botnet evolved from traditional Linux exploitation to the current ADB-based Android propagation model. The transition from libn[redacted]kernel.so to the less conspicuous libdevice.so filename in November 2025, then reverted in the December builds, indicates active operational security adjustments.

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 (first seen Sept. 2, 2025) is notable for two reasons:

• It targets x86 architecture rather than ARM
• This indicates that the botnet evolved from traditional Linux exploitation to the current ADB-based Android propagation model.

The command set used by the APKs includes:

• /system/bin/sh -c 'echo