DEV Community

Anoymask
Anoymask

Posted on

Kimwolf v7: Android/IoT Botnet with HTTP/2 Browser Spoofing DDoS and ENS/Tor Three-Layer C2

#security #threatintel

Kimwolf v7: Android/IoT Botnet with HTTP/2 Browser Spoofing DDoS and ENS/Tor Three-Layer C2

1. Basic Information

2. Executive Summary

This is a new version of the botnet that uses residential proxies to reach unauthenticated ADB and turn Android TV devices into bots. It maintains DDoS and proxy relay capabilities using Chrome-like HTTP/2 floods and a fault-tolerant C2 that combines ENS, Tor, and local SOCKS proxies.

3. Attack Flow

Chain A: Infection and Bot Registration

  1. The attacker uses a residential proxy exit node as a stepping stone to reach ADB TCP/5555 on the local network.
  2. The attacker finds Android TV boxes or set-top boxes where ADB is active and requires no authentication.
  3. The attacker drops and runs an ARM ELF payload via an external loader or APK wrapper.
  4. For APK variants, a Java wrapper disguised as SystemService runs an embedded ELF such as libdevice.so. Some samples check for root access, but public sources do not explain how this affects execution. Some samples use BootReceiver to run after reboot.
  5. The ELF creates a Unix domain socket to prevent multiple instances and changes its process name to netd_service or TVHelper.
  6. It gets the C2 address and waits for DDoS and proxy commands from the operator.

Chain B: Three-Layer C2 Resolution

  1. It shuffles five legitimate Ethereum RPC endpoints using a pseudo-random order.
  2. It queries ENS records through RPC to resolve the C2 address.
  3. Some samples also use eth.rpcuniverse[.]com, which is operator-managed and rated with medium confidence.
  4. If the ENS path fails, it falls back to a hardcoded Tor v3 hidden service.
  5. It performs a SOCKS5 greeting, .onion CONNECT, and a TLS handshake over the tunnel.
  6. It sends all C2 traffic (whether clearnet or Tor) to a local proxy at 127.0.0.1:23075.

Chain C: DDoS Execution

  1. It receives commands from the C2, including the attack method, target, and duration.
  2. It chooses from 15 methods, such as TCP, UDP, DNS, SYN, ACK, RST, ICMP, and TLS/HTTPS.
  3. For HTTP/2, it uses nghttp2 to build headers and browser fingerprints that look like Chrome or Safari.
  4. For high-performance UDP, it uses Xorshift256 (seeded with /dev/urandom) and ARM NEON SIMD to speed up checksum processing.
  5. The target receives the traffic as a large volume of HTTP/2 requests or L3/L4 packets that look like regular browsers.

4. Attacker Positioning and Execution Locations

  • External Operator: Manages the C2, ENS records, and Tor hidden service, and issues DDoS commands.
  • Residential Proxy Exit: Acts as a stepping stone to reach ADB from the same LAN side as the victim device.
  • Infected Android/IoT Device: Runs the APK wrapper, ELF bot, and local proxy.
  • Legitimate External Services: Ethereum RPC is abused for C2 resolution, but this does not mean the service itself is compromised.
  • DDoS Target: Receives attack traffic directly from the infected device or through the bot's proxy features.

5. Visibility for Victims and Administrators

Device Users

  • TV functions keep working, and there may be no noticeable screen changes.
  • Bandwidth, CPU load, video delays, or device instability may occur during a DDoS attack.
  • Names like SystemService, netd_service, and TVHelper look legitimate, making them hard to identify.

Network Administrators and SOCs

  • HTTPS traffic from Android TV/IoT devices to Ethereum RPC, which is usually unnecessary.
  • Tor/SOCKS5 traffic or use of localhost 23075 from the IoT segment.
  • TCP/13 or long-lived connections to suspicious direct IPs.
  • High-rate HTTP/2, UDP,SYN, etc., from a single device to many destinations.
  • ADB/5555 connections and APK/ELF transfers within the LAN or via residential proxies.
  • On devices without EDR, network-level observation is the main evidence.

6. Success and Failure Conditions

Success Conditions

  • ADB TCP/5555 is enabled and has no authentication or weak authentication.
  • The target LAN is reachable via residential proxies or similar methods.
  • The attacker has permissions to place and run APKs/ELFs.
  • Outbound traffic from IoT devices to Ethereum RPC, Tor, and direct IPs is allowed.
  • Processes, persistence, and egress of IoT devices are not monitored.
  • The DDoS target uses only HTTP/2 fingerprints to identify legitimate browsers.

Failure Conditions

  • Disabling ADB, restricting it to USB only, or requiring authentication.
  • Isolating residential proxy features and IoT devices from the corporate LAN.
  • Restricting Ethereum RPC, Tor, and unnecessary direct IP traffic from the IoT segment.
  • Detecting netd_service/TVHelper, unknown APKs, and added BootReceivers.
  • Blocking DDoS by correlating request rates, connection distribution, and TLS/HTTP/2 behavior, not just HTTP/2 headers.

7. What Happens Upon Success

  • Android TV/IoT devices are used as DDoS bots and communication relay nodes.
  • They join up to 15 types of L3-L7 floods, putting load on the victim organization's network and services.
  • ENS record changes, Tor fallback, and local proxies make reconnection easy even if the C2 is stopped.
  • The global IP of the organization where the infection originated may be observed as the attack source, leading to abuse reports and blocking.
  • Inference: Direct lateral movement to business endpoints on the same segment seems removed from v7 itself, but further compromise via external loaders or other components cannot be ruled out.

8. Observable Logs

Email

  • No initial compromise via email is found in public sources.

Proxy / SWG / DNS

  • HTTPS from IoT to 0xrpc[.]io/eth, eth.llamarpc[.]com, ethereum-rpc.publicnode[.]com, eth-protect.rpc.blxrbdn[.]com, eth.merkle[.]io.
  • Direct communication to eth.rpcuniverse[.]com or 23.94.221[.]104.
  • DNS alone does not reveal the final ENS-resolved C2, so HTTP request bodies, SNIs, and destination contexts are important.
  • Tor bootstrap, SOCKS5 for .onion, and direct IP connections to known C2s.

Endpoint / EDR

  • ARM 32-bit statically linked ELF, libdevice.so, libn…kernel.so, suspicious APKs.
  • Process name spoofing to netd_service, TVHelper, inetd.
  • Abstract Unix socket @n…boxv7, localhost TCP/23075 listeners/connections.
  • BootReceiver, APKs signed with self-signed or Android debug certificates.
  • push/install/shell execution via ADB.

Identity / IdP

  • No direct abuse of corporate IdPs in public sources.
  • The lack of Android/ADB management authentication is the main access control issue.

SaaS / Cloud

  • Unnatural read-only RPC requests to public Ethereum RPCs from IoT devices.
  • ENS record lookup counts and rapid failover to multiple RPCs from the same device.

Network

  • Internal reachability to ADB TCP/5555, APK/ELF transfers.
  • TCP/13, TCP/443, Tor, SOCKS5, localhost 23075.
  • High-rate HTTP/2 requests, mismatch between Chrome-like headers and device types.
  • UDP/SYN/ACK/RST/ICMP/DNS floods, destination concentration, and sudden surges in sending rates.

9. Attack Success Determination

  • Contact Only: Only ADB/5555 scans or connection failures are confirmed.
  • User Action: Usually not needed. If manual APK installation occurred, check for user action artifacts.
  • Initial Execution: Confirm the start of a suspicious APK/ELF, Unix socket creation, and process name change.
  • Malware Success: Confirm ENS queries, C2 connections, use of localhost 23075, and receipt of bot commands.
  • Attack Participation: Confirm the start of HTTP/2, UDP, or other floods to specific destinations after receiving C2 commands.
  • Subsequent Compromise Check: If additional payloads, ADB operations to other hosts, or credential searches occur, classify them as compromises outside of v7 itself.

10. Investigation Playbook

Trigger

  • Ethereum RPC or Tor traffic from IoT devices.
  • netd_service or TVHelper with outbound high-rate traffic.
  • ADB/5555 access in the IoT segment.
  • Time-series match between localhost 23075 and external C2.

Initial Verification

  1. Identify device MAC, IP, vendor, model, firmware, and ADB settings.
  2. Check if the source is used for legitimate blockchain purposes.
  3. Preserve not only C2 IOCs, but also communication start times, TLS/SOCKS, and DDoS destinations.
  4. Understand the infected device and residential proxy features separately.

Endpoint

  1. Gather the APK list, signing certificates, BootReceivers, running processes, and open sockets.
  2. Hash libdevice.so and other files and check them against Unit 42 IOCs.
  3. Collect ADB history, package installation times, and file modification times.
  4. Check for root access, unknown loaders, and additional ELFs.

Identity / Cloud

  • Check ADB authentication keys and management settings, and disable unnecessary keys and remote ADB.
  • Check why Ethereum RPC access was allowed and verify source policies.

Subsequent Actions

  • Identify the DDoS target, start time, and method.
  • Search across other ADB devices on the same LAN for the same hash, certificate, or C2.
  • Check for residential proxy software or suspicious proxy enrollment.

Containment

  • Isolate the device and disable ADB.
  • Factory reset or re-image with trusted firmware if necessary.
  • Use an allowlist for internet access from the IoT VLAN, and restrict Tor and unnecessary RPCs.
  • Use IOCs for blocking or monitoring based on expiration and shared serviceability.

Decision Stage

ADB Exposure → Payload Executed → C2 Established → Bot Enrolled → DDoS Participated → Additional Compromise

11. Defense and Detection Ideas

Single Event

  • First communication from Android TV to public Ethereum RPC or Tor.
  • netd_service or TVHelper on an IoT device.
  • TCP/13 or ADB/5555 from the IoT VLAN.
  • Localhost 23075 listener.

Time-Series Correlation 

ADB Connection → APK/ELF Placement → Process Name Change → Ethereum RPC/ENS Query
→ localhost:23075 → C2 Connection → High-Rate Flood to Specific Destination
Enter fullscreen mode Exit fullscreen mode

Threat Hunting Perspectives

  • "Mismatch between device attributes and fingerprints": An IoT device sending a large volume of browser-like HTTP/2 traffic.
  • Short-duration traffic failing over sequentially to five Ethereum RPCs.
  • Devices connecting to new IPs right after an RPC, even though ENS cannot resolve the C2.
  • SSH host key clusters and past communications for the same C2 groups.

Log Gaps

  • IoT process/APK inventory, ADB audit, East-West flow, full proxy metadata, and Tor identification are often missing.

Priority Measures

  1. Disable ADB or restrict it to USB only.
  2. Isolate Android TVs and IoT devices from business and management networks.
  3. Use IoT egress allowlists and detect anomalies in Ethereum RPC and Tor traffic.
  4. Correlate network device attributes with HTTP/TLS fingerprints.
  5. Combine DDoS rates, C2 failover, and process behavior, not just IOCs.

12. Facts / Inference / Hypothesis

Facts

  • v7 builds complete browser fingerprints in HTTP/2 floods.
  • It uses five legitimate Ethereum RPCs, ENS, Tor hidden services, and a localhost 23075 proxy.
  • It has 15 DDoS methods.
  • The v7 ELF does not contain scanner, exploit, or brute-force functions.
  • Kimwolf is confirmed to use an infection model where it reaches unauthenticated ADB from residential proxies.
  • Some APK variants have BootReceiver persistence and disguise themselves as SystemService.

Inference

  • Propagation and the DDoS core are separated, and v7 likely shifted to depend on external loaders.
  • Blocking all legitimate RPCs causes high false positives and business impact; focus should be on mismatches with device types.
  • Cheap TV boxes in corporate environments are often excluded from EDR, which may allow them to participate in DDoS attacks for a long time.

Hypothesis

  • Short-time correlation from ENS queries to direct IP connections provides detection that is more resilient to future C2 changes than single IOCs.
  • Even if HTTP/2 fingerprints look like Chrome on the DDoS side, differences in session reuse, request rates, device ASNs, and header combinations can potentially be used for identification.

13. MITRE ATT&CK Mapping

  • T1190 – Exploit Public-Facing Application (Medium): Past/external loaders like Dirty COW. v7 itself has no exploit features.
  • T1210 – Exploitation of Remote Services (Medium): Broadly mapped to unauthenticated ADB abuse.
  • T1105 – Ingress Tool Transfer (Medium): APK/ELF placement via ADB.
  • T1036 – Masquerading (High): SystemService, netd_service, TVHelper.
  • T1547 – Boot or Logon Autostart Execution (Medium): BootReceiver in some APKs.
  • T1071.001 – Web Protocols (High): HTTPS/HTTP/2 C2 and attacks.
  • T1090.001 – Internal Proxy (High): Proxy on localhost 23075.
  • T1090.003 – Multi-hop Proxy (High): Tor fallback.
  • T1584.001 – Compromise Infrastructure: Domains (Low): ENS/RPC are abused, but service compromise is unconfirmed, so confidence is low.
  • T1498 – Network Denial of Service (High): TCP/UDP/SYN/ACK/RST/ICMP, etc.
  • T1499.003 – Application Exhaustion Flood (High): HTTP/2/TLS floods.

14. Unknowns and Further Investigation

  • Current external loaders and the initial intrusion vector.
  • Scale of infection, actual numbers within enterprise networks, and global device counts.
  • ENS names, update frequency, and the complete specification of C2 command formats.
  • The extent to which proxy relays are used for criminal traffic other than DDoS.
  • Whether the combination of APKs with BootReceiver and v7 ELFs is current practice.
  • Actual detection accuracy of DDoS mitigation providers against spoofed browser fingerprints.

15. Impact on SOCs and Organizations

In meeting rooms, retail stores, hotels, digital signage, and break rooms, inexpensive Android TV boxes are sometimes installed without being tracked as managed assets. If the network configuration allows residential proxies or boundary devices to reach the local LAN, ADB can become an entry point even if devices are not directly exposed to the internet.

SOCs should not simply treat Ethereum and Tor as universally dangerous. Instead, they should look at asset contexts such as "RPCs from TV devices," "RPCs immediately following ADB activity," "direct IPs after RPC failovers," and "high-rate Chrome-like HTTP/2 traffic from TV devices." Keeping IoT devices off the same VLAN as business endpoints limits not only bot infections, but also future lateral movement risks.

16. Summary by Target Audience

For SOCs

  • Correlate IoT-initiated Ethereum RPC, Tor, TCP/13, and localhost 23075 traffic.
  • Check for netd_service/TVHelper and high-rate sending to DDoS destinations.
  • Determine success based on the time-series flow of ADB → C2 → flood, rather than single IOCs.

For Administrators

  • Disable ADB on Android TVs or restrict it to USB only.
  • Minimize egress traffic for TV/IoT VLANs and isolate them from the business LAN.
  • Inventory unmanaged TV boxes, residential proxies, and unknown APKs.

For Users

  • Do not install unofficial APKs on TV boxes.
  • If you notice unusual heating, increased traffic, or slow performance, disconnect the device from the network and contact your administrator.
  • Contact the SOC before resetting the device to preserve necessary evidence.

Top comments (0)