Kimwolf v7 Android/IoT Botnet: Detecting and Defending Against HTTP/2 DDoS Attacks That Mimic Legitimate Browsing

Palo Alto Networks Unit 42 has disclosed a significant evolution of the Kimwolf/AISURU botnet — version 7 — discovered in February 2026. This isn't a minor iteration. Kimwolf v7 introduces HTTP/2-based attack traffic engineered to blend into legitimate web browsing patterns, which breaks one of the oldest assumptions in DDoS defense: that attack traffic is distinguishable from real users at the protocol layer.

For defenders, this matters on two fronts simultaneously. First, if your organization operates Android-based devices, smart TVs, set-top boxes, or IoT endpoints — particularly in logistics, hospitality, healthcare, or retail environments where unmanaged Android devices proliferate — you may be hosting botnet nodes. Second, if you operate any public-facing web property, you are a potential target of HTTP/2 floods that your existing rate-limiting and WAF rules may wave through as legitimate sessions.

This post breaks down how Kimwolf v7 operates from a defender's perspective and delivers concrete detection logic, hunt queries, and hardening guidance.

Technical Analysis

What Is Kimwolf/AISURU?

Kimwolf (also tracked as AISURU) is a compromised device network built primarily on Android and IoT platforms. Like its predecessors in the Mirai lineage of IoT botnets, it monetizes compromised consumer and embedded devices as DDoS-for-hire infrastructure. What separates v7 from earlier builds is operational resilience and traffic sophistication.

The HTTP/2 Evasion Problem

The headline capability in Kimwolf v7 is its HTTP/2-based attack module. To understand why this is dangerous, you need to understand what HTTP/2 changes at the protocol layer:

• Multiplexing: HTTP/2 allows dozens of concurrent streams over a single TCP connection. A botnet node can generate enormous request volumes per connection while maintaining low connection counts — defeating connection-rate-based DDoS detection.
• Persistent connections: Long-lived HTTP/2 sessions look like real browsers, not the short, bursty connections typical of HTTP/1.1 floods.
• Header compression (HPACK): Compressed headers reduce the byte-level signatures that network-based detection tools rely on, and defeat naive payload inspection.
• Browser-like framing: When the botnet crafts HTTP/2 frames with realistic header ordering, pseudo-headers (:method, :path, :authority, :scheme), and plausible user-agent strings, the traffic is nearly indistinguishable from genuine Chrome or Firefox sessions at layer 7.

Historical context matters here: HTTP/2-specific abuse techniques (such as the Rapid Reset attack pattern disclosed in 2023, where streams are opened and immediately cancelled at massive scale) proved that HTTP/2's design features can be weaponized. Kimwolf v7 operationalizes this class of technique inside a commodity botnet, lowering the bar for attackers considerably.

Infection and C2 Behavior

Based on the botnet family's established tradecraft and the Unit 42 findings, defenders should assume the following attack chain:

1. Initial compromise — Android devices exposed via ADB (TCP/5555), default/weak credentials on IoT management interfaces, or exploitation of unpatched firmware. Devices with internet-facing ADB remain a persistent, well-documented infection vector for Android botnets.
2. Payload staging — The bot downloads architecture-appropriate binaries (ARM/MIPS/x86) via shell commands executed through adb shell, /system/bin/sh, or wget/curl invocations from device shells.
3. Persistence — Installation as a background service, often masquerading as a legitimate system package, with watchdog mechanisms to survive reboots and process kills.
4. C2 and tasking — Encrypted command channels to operator infrastructure, receiving target lists and attack parameters.
5. Attack execution — HTTP/2 floods launched against victim web properties, with traffic shaped to resemble browser sessions.

Exploitation Status

This is confirmed active, in-the-wild activity documented by Unit 42 — not a theoretical capability. The botnet is operational and its v7 build represents the current deployed version. No CVE is associated with this campaign; the threat is the botnet's technique and the population of exposed, poorly managed Android/IoT devices that feed it.

Detection & Response

Detection has to happen on two planes: identifying compromised devices inside your network (you're a botnet source) and identifying incoming HTTP/2 floods (you're a target). The rules below address both.

Sigma Rules

The following rules target (a) shell-based payload staging on Android/IoT Linux systems, (b) suspicious outbound connection behavior consistent with botnet tasking, and (c) inbound HTTP/2 anomaly patterns visible in web server and WAF logs.

---
title: Android IoT Shell-Based Payload Download (Kimwolf Botnet Staging)
id: 4c9e2b17-8a3d-4f61-b2c9-7d5e1a8f3c42
status: experimental
description: Detects shell-executed download-and-execute patterns commonly used by Android/IoT botnets such as Kimwolf/AISURU to stage architecture-specific payloads on compromised devices.
references:
  - https://thehackernews.com/2026/08/kimwolf-v7-android-botnet-makes-http2.html
  - https://attack.mitre.org/techniques/T1105/
author: Security Arsenal
date: 2026/08/10
tags:
  - attack.command_and_control
  - attack.t1105
  - attack.t1059
logsource:
  category: process_creation
  product: linux
detection:
  selection_img:
    Image|endswith:
      - '/sh'
      - '/bash'
      - '/busybox'
  selection_cli:
    CommandLine|contains:
      - 'wget '
      - 'curl '
      - 'tftp '
  selection_exec:
    CommandLine|contains:
      - 'chmod 777'
      - 'chmod +x'
      - ' /tmp/'
      - ' /var/run/'
      - ' /dev/shm/'
  condition: selection_img and selection_cli and selection_exec
falsepositives:
  - Legitimate firmware update scripts on managed IoT devices
  - MDM-initiated package installs on enterprise Android deployments
level: high
---
title: Exposed ADB Interface Remote Command Execution
id: 8f3a1c94-2d7e-4b58-a9c1-6e4d2f7b8a51
status: experimental
description: Detects inbound connections to the Android Debug Bridge port (TCP/5555), a primary infection vector for Android botnets including the Kimwolf/AISURU family. Internet-facing ADB should not exist in any production environment.
references:
  - https://thehackernews.com/2026/08/kimwolf-v7-android-botnet-makes-http2.html
  - https://attack.mitre.org/techniques/T1190/
author: Security Arsenal
date: 2026/08/10
tags:
  - attack.initial_access
  - attack.t1190
logsource:
  category: firewall
  product: zeek
detection:
  selection:
    dst_port: 5555
  filter_local_admin:
    src_ip|cidr:
      - '10.0.0.0/8'
      - '172.16.0.0/12'
      - '192.168.0.0/16'
  condition: selection and not filter_local_admin
falsepositives:
  - Internal device lab or QA testing where ADB is intentionally enabled (scope to authorized subnets instead of suppressing entirely)
level: critical
---
title: HTTP/2 Stream Anomaly Consistent With Botnet DDoS (Kimwolf v7)
id: 1b7d4e28-6c3f-4a92-9d18-3f5b2e8c7a64
status: experimental
description: Detects inbound HTTP/2 request anomalies indicative of multiplexed DDoS floods that mimic browser traffic — extremely high request-per-connection ratios from single sources, a hallmark of HTTP/2-based attack tooling described in Kimwolf v7.
references:
  - https://thehackernews.com/2026/08/kimwolf-v7-android-botnet-makes-http2.html
  - https://attack.mitre.org/techniques/T1498/
author: Security Arsenal
date: 2026/08/10
tags:
  - attack.impact
  - attack.t1498
  - attack.t1498.002
logsource:
  category: webserver
detection:
  selection:
    cs-method|contains:
      - 'GET'
      - 'POST'
    Protocol|contains:
      - 'HTTP/2'
      - 'h2'
  condition: selection
falsepositives:
  - API gateways and service meshes that legitimately multiplex high volumes over HTTP/2 — tune with per-source request-rate thresholds in your SIEM (alert on >100 requests per source IP per 60 seconds per connection as a starting baseline)
  - Load balancer health checks
level: medium

A note on the third rule: Sigma alone can't express per-connection stream ratios, so treat it as an enrichment filter and enforce the actual thresholding in your SIEM or WAF analytics layer. Alerting on "HTTP/2 GET" by itself would be pure noise — the value is in pairing it with rate aggregation, which the KQL below demonstrates.

KQL — Microsoft Sentinel Hunt Queries

The first query hunts inbound HTTP/2 floods by identifying source IPs generating abnormal request volumes against your web properties (assumes WAF/load balancer logs ingested via CommonSecurityLog or custom tables). The second hunts compromised internal devices behaving as botnet nodes — Android/IoT endpoints establishing sustained outbound sessions to low-reputation or uncommon destinations.

// Hunt 1: Inbound HTTP/2 DDoS pattern — per-source request-rate anomaly
// Tune 'threshold' against your 14-day baseline. Start at 500 req/5min/source for mid-traffic properties.
let threshold = 500;
CommonSecurityLog
| where TimeGenerated > ago(1h)
| where DeviceProduct has_any ("WAF", "NGINX", "Apache", "Cloudflare", "Akamai", "LoadBalancer")
| where RequestProtocol has "HTTP/2" or AdditionalExtensions has "HTTP/2"
| summarize RequestCount = count(),
            DistinctPaths = dcount(RequestURL),
            DistinctUserAgents = dcount(RequestClientApplication)
    by SourceIP, bin(TimeGenerated, 5m)
| where RequestCount > threshold
// Botnet floods often show LOW path diversity per source (hammering '/' or one endpoint)
// or LOW UA diversity (single spoofed browser string) — flag both
| extend SuspicionScore = iff(DistinctPaths <= 3 or DistinctUserAgents <= 2, "High", "Medium")
| project TimeGenerated, SourceIP, RequestCount, DistinctPaths, DistinctUserAgents, SuspicionScore
| order by RequestCount desc;

// Hunt 2: Compromised internal Android/IoT device acting as botnet node
// Looks for IoT-segment devices with sustained outbound connections to rare destinations
let iot_subnet_prefixes = dynamic(["10.20.", "10.30.", "192.168.50."]); // <-- replace with YOUR IoT VLAN prefixes
DeviceNetworkEvents
| where TimeGenerated > ago(24h)
| where LocalIP has_any (iot_subnet_prefixes)
| where RemoteIPType == "Public"
| summarize ConnCount = count(),
            DistinctDestinations = dcount(RemoteIP),
            BytesSent = sum(SentBytes),
            FirstSeen = min(TimeGenerated)
    by DeviceName, LocalIP, RemoteIP, RemotePort
| where ConnCount > 200 or BytesSent > 100000000
| where RemotePort !in (443, 80, 123, 53)  // exclude standard service ports
| join kind=leftouter (
    DeviceProcessEvents
    | where TimeGenerated > ago(24h)
    | project DeviceName, ProcessCommandLine, FileName, TimeGenerated
) on DeviceName
| where ProcessCommandLine has_any ("wget", "curl", "busybox", "chmod", "/tmp/", "/dev/shm/") or isempty(ProcessCommandLine)
| project FirstSeen, DeviceName, LocalIP, RemoteIP, RemotePort, ConnCount, BytesSent, FileName, ProcessCommandLine;

If you ingest Syslog/CEF from network devices rather than Defender, swap DeviceNetworkEvents for CommonSecurityLog and adjust field names — the logic (IoT segment + rare destination + volume anomaly) holds regardless of telemetry source.

Velociraptor VQL — Endpoint Hunt for Botnet Staging Artifacts

For Linux-based IoT gateways, Android-x86 deployments, or embedded Linux appliances under Velociraptor coverage, hunt for the staging artifacts botnets leave behind: dropped binaries in world-writable paths and suspicious network states.

-- Hunt: Botnet staging artifacts on Linux/Android-x86 endpoints (Kimwolf/AISURU pattern)
-- Looks for recently written executables in paths abused by IoT botnets,
-- plus processes with outbound connections to non-standard ports.

LET staged_files = SELECT FullPath, Size, Mtime, Mode.String AS Mode
FROM glob(globs=['/tmp/*', '/var/run/*', '/dev/shm/*', '/data/local/tmp/*'])
WHERE NOT IsDir
  AND Mtime > now() - 86400 * 3
  AND (Mode =~ 'x' OR FullPath =~ '\\.(elf|bin|sh)$')

LET suspicious_conns = SELECT Pid, Name, Family, Type, Status,
  Laddr.IP AS LocalIP, Laddr.Port AS LocalPort,
  Raddr.IP AS RemoteIP, Raddr.Port AS RemotePort
FROM netstat()
WHERE Status = 'ESTABLISHED'
  AND RemotePort NOT IN (22, 53, 80, 123, 443, 853)
  AND RemoteIP =~ '^([0-9]{1,3}\\.){3}[0-9]{1,3}$'
  AND RemoteIP !~ '^(10\\.|172\\.(1[6-9]|2[0-9]|3[01])\\.|192\\.168\\.)'

SELECT * FROM staged_files
UNION ALL
SELECT 
  Name AS FullPath,
  Pid AS Size,
  NULL AS Mtime,
  format(format='CONN: %v:%v -> %v:%v', 
         args=[LocalIP, LocalPort, RemoteIP, RemotePort]) AS Mode
FROM suspicious_conns

Remediation / Hardening Script

This Bash script is designed for managed Linux-based IoT gateways and Android-x86 devices in your fleet. It audits for the most common compromise indicators — exposed ADB, unauthorized listeners, world-writable staging directories with fresh executables, and unexpected outbound sessions.

#!/bin/bash
# Kimwolf/AISURU IoT Compromise Audit & Hardening Script
# Run on managed Android-x86 / embedded Linux devices. Review output before acting in production.

echo "=== [1] Checking for exposed ADB (TCP/5555) ==="
if command -v ss >/dev/null 2>&1; then
  ss -tlnp | grep ':5555' && echo "[!] ADB LISTENING — disable unless explicitly required" || echo "[OK] No ADB listener"
else
  netstat -tlnp 2>/dev/null | grep ':5555' && echo "[!] ADB LISTENING" || echo "[OK] No ADB listener"
fi

echo "=== [2] Disabling ADB over network (Android) ==="
if command -v setprop >/dev/null 2>&1; then
  setprop service.adb.tcp.port -1
  stop adbd 2>/dev/null
  echo "[+] ADB TCP disabled"
else
  echo "[-] Not an Android shell — skipping setprop"
fi

echo "=== [3] Scanning staging directories for recent executables ==="
for dir in /tmp /var/run /dev/shm /data/local/tmp; do
  if [ -d "$dir" ]; then
    find "$dir" -type f -mtime -3 -perm -u+x 2>/dev/null | while read -r f; do
      echo "[!] Suspicious recent executable: $f"
      file "$f" 2>/dev/null
    done
  fi
done

echo "=== [4] Reviewing established outbound connections on non-standard ports ==="
netstat -tnp 2>/dev/null | grep ESTABLISHED | grep -vE ':(22|53|80|123|443|853)\b' || echo "[OK] No anomalous outbound sessions"

echo "=== [5] Checking for unexpected running download/staging tools ==="
ps aux 2>/dev/null | grep -E 'wget|curl|tftp|busybox' | grep -v grep || echo "[OK] No staging processes"

echo "=== [6] Locking down world-writable exec paths (noexec where supported) ==="
for mnt in /tmp /dev/shm; do
  if mount | grep "$mnt" | grep -qv noexec; then
    echo "[!] $mnt is executable — remount with noexec in /etc/fstab (requires reboot on some firmware)"
  fi
done

echo "=== Audit complete. Investigate any [!] findings immediately. ==="

Remediation

There is no patch for a botnet technique — remediation is architectural. Prioritize in this order:

If You're a Potential Botnet Source (IoT/Android Fleet Owners)

1. Eliminate exposed ADB. Scan your external attack surface and internal ranges for TCP/5555. There is no legitimate reason for internet-facing ADB in 2026. Disable ADB-over-network on all fleet devices (setprop service.adb.tcp.port -1) and enforce via MDM policy.
2. Segment IoT into deny-by-default VLANs. Android/IoT devices should have no path to the internet except through an explicit egress proxy allowlist. This single control breaks C2 for the overwhelming majority of IoT botnets, including Kimwolf.
3. Default-credential audit. Enforce unique credentials on every embedded device at provisioning. Rotate anything still running factory defaults — this remains the cheapest infection vector for this botnet class.
4. Egress monitoring. Alert on IoT-segment devices initiating connections to destinations outside an approved list, especially on non-standard ports, and on outbound volume anomalies (a compromised TV or set-top box generating sustained multi-Mbps egress is not watching Netflix).
5. Firmware lifecycle. Decommission or isolate devices that no longer receive firmware updates. Unpatchable Android devices are permanent botnet candidates.

If You're a Potential DDoS Target (Web Property Operators)

1. Enforce HTTP/2 stream and connection limits at the edge. Configure maximum concurrent streams per connection and maximum requests per connection on your reverse proxies (e.g., NGINX http2_max_concurrent_streams, keepalive_requests; equivalent controls exist in Envoy, HAProxy, and all major CDN/WAF platforms). Rapid stream churn against limits is a strong attack signal.
2. Rate-limit per source IP AND per HTTP/2 connection. Kimwolf v7's whole point is defeating per-connection-naive defenses. Your controls must account for multiplexed request volume, not just connection counts.
3. Deploy managed DDoS absorption. If you aren't behind a cloud DDoS mitigation provider (Cloudflare, Akamai, Fastly, AWS Shield, Azure DDoS Protection, GCP Cloud Armor), you are structurally unprepared for a botnet of this scale. This is not optional for internet-facing revenue systems.
4. Validate WAF behavioral rules. Signature-only WAF rules will not catch browser-mimicking HTTP/2 floods. Confirm your WAF supports behavioral/bot-scoring detection (TLS fingerprint analysis, header-order analysis, request-timing analysis) and that it's enabled — not in monitor mode.
5. Pre-build your runbook. DDoS response decided mid-attack is failed response. Document upstream provider escalation contacts, BGP Flowspec/RTBH procedures, and WAF emergency rule deployment now.

Recommended Reading and Vendor Guidance

• Palo Alto Networks Unit 42 research on Kimwolf/AISURU (referenced in the source disclosure)
• Your CDN/WAF vendor's HTTP/2-specific DDoS guidance — every major provider published HTTP/2 mitigation documentation following the 2023 Rapid Reset disclosures; those controls remain directly applicable here

Bottom Line

Kimwolf v7 is a signal, not an anomaly: DDoS tooling has matured past the point where "attack traffic looks weird" is a viable detection premise. Defenders on both sides of this botnet — the organizations unknowingly hosting nodes and the organizations absorbing floods — need to shift from signature and rate-based assumptions to behavioral, segmented, and edge-enforced controls. The telemetry and rules above will get you started; the segmentation work is what actually closes the door.

Related Resources

Security Arsenal Penetration Testing Services AlertMonitor Platform Book a SOC Assessment vulnerability-management Intel Hub