Kimwolf v7 Botnet: Defending Android IoT Devices Against ENS-Based C2 and HTTP/2 DDoS Operations

Unit 42 has published a detailed analysis of Kimwolf v7, the latest evolution of the Kimwolf compromised-device network, and it represents a meaningful escalation in botnet resilience engineering. This is not a commodity DDoS botnet recycling Mirai source code. Kimwolf v7 specifically targets Android-based IoT devices — set-top boxes, smart TVs, Android-powered signage, and similar embedded hardware — and it brings two capabilities that should change how your SOC approaches C2 detection: Ethereum Name Service (ENS) resolution for command-and-control and Tor as a backup routing channel, paired with HTTP/2-based DDoS fingerprinting for its attack operations.

If your organization has Android-powered IoT on any network segment — conference room displays, hospitality TVs, retail kiosks, warehouse scanners, OT-adjacent Android panels — you have exposure. Traditional C2 detection that relies on domain blocklists and DNS sinkholing is structurally blind to infrastructure resolved through a blockchain. This post breaks down what Kimwolf v7 does, how to detect it, and how to harden your environment before your devices become part of someone else's DDoS inventory.

Technical Analysis: How Kimwolf v7 Operates

Target Surface: Android IoT

Kimwolf v7 continues the family tradition of compromising Android-based IoT devices rather than conventional endpoints. These devices share a common defensive weakness profile:

Exposed or poorly secured ADB (Android Debug Bridge) interfaces, historically on TCP/5555
Weak or default credentials on management interfaces
Rarely patched firmware with long vendor support gaps
No EDR or endpoint telemetry — they are invisible to most SOC tooling
Persistent internet egress with little traffic baseline analysis

Once compromised, devices are enrolled into the botnet and used primarily as DDoS infrastructure, with HTTP/2 attack capability allowing more efficient, harder-to-filter floods against modern web front ends.

ENS-Based C2 Resolution: The Key Innovation

The most significant evolution in v7 is its use of the Ethereum Name Service to resolve C2 infrastructure. Instead of hardcoding domains or IPs — which defenders can blocklist, sinkhole, or seize — the malware queries Ethereum infrastructure to resolve a .eth name into its current C2 address.

From a defender's perspective, this changes the equation in several ways:

No DNS dependency for C2 resolution. The resolution happens via JSON-RPC calls to Ethereum nodes or public RPC gateways (e.g., services like Infura, Alchemy, Ankr, or public nodes). Blocking DNS entries does nothing.
Operator-controlled mutable records. The botnet operator can rotate the C2 address by updating the ENS record, and every bot worldwide follows — no payload update required.
Seizure resistance. Law enforcement cannot sinkhole an ENS name the way they can a registered domain. Takedown requires targeting the operator's Ethereum keys or the resolved infrastructure itself.

Tor Backup Routing

If primary C2 resolution fails — for example, if an organization blocks outbound access to public Ethereum RPC endpoints — Kimwolf v7 falls back to Tor for C2 communication. This is a deliberately layered resilience strategy: blockchain for primary resolution, anonymity network for fallback. A defender who blocks one channel without watching the other has accomplished nothing.

HTTP/2 DDoS Fingerprinting and Attack Operations

On the attack side, v7 performs HTTP/2 fingerprinting of targets and leverages HTTP/2 for its DDoS operations. HTTP/2 floods are attractive to operators because multiplexing allows a single TCP connection to carry large volumes of requests, evading per-connection rate limits designed for HTTP/1.1 traffic. If your web infrastructure accepts HTTP/2 and you haven't tuned flood protections accordingly, botnets like this will find that gap.

Exploitation Status

Kimwolf v7 is confirmed active in the wild as an operating botnet with an established compromised-device population. This is not a proof-of-concept. No CVE is associated with this campaign — the initial access vector is the chronic weakness of exposed Android IoT management interfaces and weak credentials, not a single patchable bug. That means there is no patch Tuesday fix here; remediation is architectural and operational.

Detection & Response

The practical detection surface for Kimwolf v7 in a typical enterprise is network egress, because the infected devices themselves are Android IoT with no endpoint agents. Your best telemetry comes from firewalls, proxies, DNS logs, and NetFlow/NDR platforms ingested into your SIEM.

Sigma Rules

YAML

---
title: Outbound Connection to Public Ethereum JSON-RPC Endpoints from Non-Browser Hosts
id: 3c9e2a71-4f8b-4d2a-9c16-7e5b1a8f4021
status: experimental
description: Detects outbound connections to public Ethereum RPC gateways (used for ENS resolution) from hosts unlikely to have legitimate blockchain workloads. Kimwolf v7 resolves C2 infrastructure via Ethereum Name Service queries over JSON-RPC. Legitimate use of these endpoints on corporate IoT VLANs should be near zero.
references:
  - https://unit42.paloaltonetworks.com/kimwolf-v7-botnet-malware/
  - https://attack.mitre.org/techniques/T1071/001/
author: Security Arsenal
date: 2026/04/06
tags:
  - attack.command_and_control
  - attack.t1071.001
logsource:
  category: proxy
  product: webserver
detection:
  selection:
    cs-host|contains:
      - 'infura.io'
      - 'alchemyapi.io'
      - 'alchemy.com'
      - 'rpc.ankr.com'
      - 'eth-mainnet.public.blastapi.io'
      - 'ethereum.publicnode.com'
      - 'cloudflare-eth.com'
      - 'eth.llamarpc.com'
      - 'mainnet.infura.io'
  filter_browser_ua:
    c-useragent|contains:
      - 'Mozilla/5.0'
      - 'Chrome/'
  condition: selection and not filter_browser_ua
falsepositives:
  - Corporate blockchain/Web3 development teams
  - Crypto treasury or custodial integrations (restrict to known hosts)
level: high
---
title: Direct Outbound Connection to Tor Network Ports from IoT Network Segments
id: 8d4f6b12-3a9c-4e7d-b581-2f6c9d0e3157
status: experimental
description: Detects outbound connections to common Tor entry/relay ports (9001, 9030, 9050, 9051, 9150). Kimwolf v7 uses Tor as a backup C2 routing channel when primary ENS-based resolution is blocked. Tor traffic originating from IoT or OT segments is almost never legitimate.
references:
  - https://unit42.paloaltonetworks.com/kimwolf-v7-botnet-malware/
  - https://attack.mitre.org/techniques/T1090/003/
author: Security Arsenal
date: 2026/04/06
tags:
  - attack.command_and_control
  - attack.t1090.003
logsource:
  category: firewall
detection:
  selection:
    dst_port:
      - 9001
      - 9030
      - 9050
      - 9051
      - 9150
    action: 'allowed'
falsepositives:
  - Rare legitimate Tor usage (should be policy-prohibited and allowlisted if required)
level: high
---
title: ADB Interface Exposure Detected on Android IoT Devices
id: 5b1c8e94-7d2f-4a6c-93e8-1b4a7c2d5963
status: experimental
description: Detects inbound connections to TCP/5555 (Android Debug Bridge) on internal network segments. Exposed ADB is a primary initial-access vector for Android IoT botnets including the Kimwolf family. No legitimate business process should expose ADB to the network.
references:
  - https://unit42.paloaltonetworks.com/kimwolf-v7-botnet-malware/
  - https://attack.mitre.org/techniques/T1190/
author: Security Arsenal
date: 2026/04/06
tags:
  - attack.initial_access
  - attack.t1190
logsource:
  category: firewall
detection:
  selection:
    dst_port: 5555
    action: 'allowed'
falsepositives:
  - Legitimate vendor maintenance windows (should be temporary and documented)
level: high

KQL Hunt: Sentinel / Defender

This query hunts for the two defining network behaviors — Ethereum RPC egress (ENS resolution channel) and Tor fallback connections — plus exposed ADB, across firewall/CEF and DNS telemetry. Scope it to IoT VLANs or subnets if you have them tagged in your asset inventory.

KQL — Microsoft Sentinel / Defender

// Kimwolf v7 network behavior hunt: ENS RPC egress, Tor fallback, exposed ADB
let EthRpcHosts = dynamic([
    "infura.io", "alchemyapi.io", "alchemy.com", "rpc.ankr.com",
    "blastapi.io", "publicnode.com", "cloudflare-eth.com", "llamarpc.com"
]);
let TorPorts = dynamic([9001, 9030, 9050, 9051, 9150]);
union isfuzzy=true
(
    CommonSecurityLog
    | where TimeGenerated > ago(7d)
    | extend IsEthRpc = DestinationHostName has_any (EthRpcHosts),
             IsTor = DestinationPort in (TorPorts),
             IsAdb = DestinationPort == 5555
    | where IsEthRpc or IsTor or IsAdb
    | extend Indicator = case(
        IsEthRpc, "Ethereum_RPC_Egress",
        IsTor, "Tor_Port_Connection",
        IsAdb, "ADB_5555_Exposure", "Other")
    | summarize ConnectionCount = count(),
                FirstSeen = min(TimeGenerated),
                LastSeen = max(TimeGenerated),
                Destinations = make_set(DestinationIP, 20),
                Ports = make_set(DestinationPort)
        by Indicator, SourceIP, DeviceAction
),
(
    DnsEvents
    | where TimeGenerated > ago(7d)
    | where Name has_any (EthRpcHosts) or Name endswith ".eth"
    | summarize QueryCount = count(),
                FirstSeen = min(TimeGenerated),
                LastSeen = max(TimeGenerated),
                QueriedNames = make_set(Name, 20)
        by ClientIP, Indicator = "DNS_to_Eth_RPC_or_ENS"
)
| order by ConnectionCount desc

Tuning note: If you have Web3 development teams, exclude their known subnets at the query level rather than deleting the detection. A .eth DNS lookup or an Infura connection from a smart TV subnet is a near-certain malicious signal; the same from a developer workstation is noise.

Velociraptor VQL

For managed Android gateway appliances or any Linux-based network appliances on IoT segments where you can deploy Velociraptor, hunt for established connections to Tor ports and Ethereum RPC endpoints, plus any listener on 5555:

VQL — Velociraptor

-- Hunt for Kimwolf v7 C2 indicators: Tor fallback, Ethereum RPC egress, exposed ADB
LET eth_ips = SELECT DestIp, DestPort, Pid, Status
FROM netstat()
WHERE Status =~ 'ESTAB'
  AND DestPort in (443, 8545)

LET tor_conns = SELECT DestIp, DestPort, Pid, Status
FROM netstat()
WHERE DestPort in (9001, 9030, 9050, 9051, 9150)
  AND Status =~ 'ESTAB'

LET adb_listen = SELECT Laddr, Port, Pid, Status
FROM netstat()
WHERE Port = 5555 AND Status =~ 'LISTEN'

SELECT * FROM chain(a=eth_ips, b=tor_conns, c=adb_listen)

Note: port 8545 is the standard Ethereum JSON-RPC port — legitimate full-node traffic uses it, so correlate eth_ips hits against process owners before escalating. The Tor and ADB sections are much higher fidelity.

Hardening and Verification Script

Run this from a management host against your IoT segments to enumerate exposed ADB interfaces, and verify egress controls block Tor ports and public Ethereum RPC gateways:

Bash / Shell

#!/bin/bash
# Kimwolf v7 exposure check: ADB exposure + egress control validation
# Usage: ./kimwolf_check.sh <iot_subnet_cidr>

SUBNET="${1:?Usage: $0 <subnet e.g. 10.20.0.0/24>}"
REPORT="kimwolf_exposure_$(date +%Y%m%d_%H%M).txt"

echo "=== Kimwolf v7 Exposure Assessment: $SUBNET ===" | tee "$REPORT"

# 1. Scan for exposed ADB (TCP/5555) on the IoT segment
echo -e "\n[1] Scanning for exposed ADB interfaces (TCP/5555)..." | tee -a "$REPORT"
nmap -p 5555 --open -oG - "$SUBNET" 2>/dev/null | grep "5555/open" | tee -a "$REPORT"
if ! nmap -p 5555 --open "$SUBNET" 2>/dev/null | grep -q "5555/tcp open"; then
    echo "    OK: No exposed ADB interfaces found." | tee -a "$REPORT"
else
    echo "    ALERT: Exposed ADB found above. Disable ADB over network immediately." | tee -a "$REPORT"
fi

# 2. Scan for open ADB alternate ports sometimes used (5554, 5037 local)
echo -e "\n[2] Checking alternate ADB ports..." | tee -a "$REPORT"
nmap -p 5554 --open "$SUBNET" 2>/dev/null | grep "5554/tcp open" | tee -a "$REPORT"

# 3. Verify egress blocks Tor relay ports from the IoT segment
echo -e "\n[3] Testing egress filter: Tor ports (expect all to FAIL/timeout)..." | tee -a "$REPORT"
for PORT in 9001 9030 9050 9051 9150; do
    if timeout 5 bash -c "echo > /dev/tcp/8.8.8.8/$PORT" 2>/dev/null; then
        echo "    ALERT: Egress to port $PORT is OPEN — Tor fallback channel available." | tee -a "$REPORT"
    else
        echo "    OK: Egress to port $PORT blocked." | tee -a "$REPORT"
    fi
done

# 4. Verify egress blocks public Ethereum RPC gateways (ENS resolution channel)
echo -e "\n[4] Testing egress filter: Ethereum RPC gateways (expect all to FAIL)..." | tee -a "$REPORT"
for HOST in mainnet.infura.io rpc.ankr.com ethereum.publicnode.com eth.llamarpc.com cloudflare-eth.com; do
    if timeout 5 curl -sk -o /dev/null "https://$HOST" 2>/dev/null; then
        echo "    ALERT: $HOST reachable — ENS-based C2 resolution possible." | tee -a "$REPORT"
    else
        echo "    OK: $HOST blocked." | tee -a "$REPORT"
    fi
done

# 5. Check for .eth DNS resolution capability (indicator of unrestricted egress)
echo -e "\n[5] Review: ensure proxy/DNS policy denies .eth TLD resolution from IoT VLANs." | tee -a "$REPORT"

echo -e "\n=== Assessment complete. Review ALERT lines and remediate. ===" | tee -a "$REPORT"

Remediation

There is no vendor patch for Kimwolf v7 because there is no single CVE — the vulnerability is operational: exposed, unmanaged Android IoT with unrestricted egress. Remediation is layered:

1. Kill the initial access vector.

Disable ADB over network (TCP/5555) on every Android IoT device. If the vendor requires it for maintenance, restrict it to a jump host via ACL and disable it outside maintenance windows.
Rotate all default credentials on device management interfaces.
Inventory every Android-powered device on your network. If you don't know it exists, it's already unmanaged risk.

2. Segment IoT aggressively.

Place all Android IoT on dedicated VLANs with default-deny egress. Permit only the specific destinations the device functionally requires (update servers, streaming services).
Block lateral movement from IoT segments to corporate and OT networks entirely. A compromised smart TV should be unable to touch anything.

3. Cut the C2 channels.

Block outbound access to public Ethereum RPC gateways (Infura, Alchemy, Ankr, PublicNode, BlastAPI, LlamaRPC, Cloudflare's eth gateway) from all segments except explicitly approved Web3 development subnets. This is the single highest-value control against ENS-based C2: no RPC access, no ENS resolution.
Block Tor ports (9001, 9030, 9050, 9051, 9150) and known Tor directory/relay IPs at egress. Deploy Tor blocklists that update daily.
Deny resolution of the .eth TLD at your DNS layer where feasible.

4. Harden DDoS-facing infrastructure.

If you operate public web properties accepting HTTP/2, verify your WAF/CDN enforces per-stream and per-connection rate limits that account for HTTP/2 multiplexing, not just connection counts. HTTP/1.1-era rate limiting is bypassed by multiplexed floods.
Confirm your DDoS scrubbing provider handles HTTP/2 attack profiles explicitly.

5. Detection and hunting.

Deploy the Sigma rules and KQL queries above, scoped to IoT segments.
Add Ethereum RPC gateway domains and Tor ports to your threat-hunting standing queries — these indicators generalize beyond Kimwolf to any malware adopting blockchain-resolved C2, a technique we expect to spread.
Baseline IoT egress volumes; DDoS enrollment typically manifests as sustained outbound spikes from devices that historically idle.

6. Firmware and lifecycle.

Patch Android IoT firmware where vendors provide updates; where they don't, treat the device as untrusted and segment accordingly.
Build Android IoT into your vulnerability management and asset lifecycle programs — these devices are endpoints, whether or not your EDR sees them.

The Strategic Takeaway

Kimwolf v7 is a signal about where botnet C2 architecture is heading. Blockchain-based resolution removes the defender's most reliable lever — DNS control — and Tor fallback punishes partial mitigation. The defensive answer is egress discipline: deny-by-default outbound policy on IoT segments, explicit blocking of blockchain RPC infrastructure and anonymity networks, and detection content tuned to these channels. Organizations that still treat Android IoT as "not real computers" will keep donating bandwidth to someone else's botnet.

Related Resources

Security Arsenal Healthcare Cybersecurity AlertMonitor Platform Book a SOC Assessment healthcare Intel Hub