Android TV Box Botnet Takedown: How to Detect and Remove Residential Proxy Malware From 1.3M Compromised Devices

Google and industry partners have dismantled a massive compromised device network comprising more than 1.3 million Android TV set-top boxes that shipped from manufacturers with pre-installed malicious software. This wasn't a post-purchase infection — the devices arrived compromised, turning consumer internet connections into residential proxies rented to strangers and fueling large-scale advertising fraud operations.

The takedown is expected to sever the botnet's access to an additional 10 million compromised systems, including Android-based healthcare devices and karaoke machines. This is a supply-chain compromise at scale: inexpensive Android-based IoT devices entering the market with malware baked into firmware, creating persistent proxy infrastructure for threat actors.

For SOC teams and defenders, this matters because residential proxy networks are the backbone of modern fraud, credential stuffing, and anonymized attack infrastructure. If your organization uses Android-based IoT devices — or if employees connect compromised home devices to corporate resources — you're exposed to traffic manipulation, data leakage, and attribution challenges when attacks route through your IP space.

Technical Analysis

Affected Products and Attack Chain

This botnet leverages Android TV set-top boxes sold through various online retailers, often under generic or white-label branding. The devices run legitimate Android TV OS but include pre-installed malicious applications embedded in the system image or vendor app store.

The attack chain operates as follows:

Supply-Chain Compromise: Malicious APKs (Android Package Kits) are integrated into the firmware or system partitions during manufacturing or by compromised ODM/OEM vendors.
Persistence: The malware survives factory resets in many cases because it resides in read-only system partitions or is re-downloaded by compromised update mechanisms.
Proxy Network Enrollment: Once connected to the internet, infected devices register with command-and-control (C2) infrastructure and enroll in a residential proxy network.
Bandwidth Monetization: The device acts as an exit node for paid proxy services, routing third-party traffic through the victim's internet connection.
Ad Fraud: Infected devices generate fraudulent ad impressions and clicks, often running hidden WebView instances or headless browsers.

Technical Indicators

Infected Android TV boxes exhibit the following observable behaviors:

High outbound bandwidth consumption inconsistent with streaming or normal usage patterns
Connections to known proxy/VPN service endpoints not initiated by the user
DNS queries to dynamic DNS (DDNS) domains or domains associated with residential proxy providers
Listening services on non-standard ports (e.g., SOCKS5 proxies on 1080, HTTP proxies on 8080, 3128)
Processes running with system or root privileges that don't correspond to legitimate Android TV components
Outbound connections to multiple IPs on ports 80/443 with sustained data transfer but no corresponding user activity

Related Threats and Context

This campaign shares tactics with other recent Android-based botnets, including Badbox (disrupted in 2024) and Triada variants that targeted budget Android devices. The residential proxy model — where compromised consumer devices are rented to cybercriminals — is a growing trend because it provides:

Legitimate IP reputation: Traffic appears to originate from residential ISPs, bypassing IP-based blocking
Geographic distribution: Exit nodes in target countries for localized fraud
Low detection rates: Consumer devices lack enterprise monitoring

While no specific CVE is associated with this botnet (the compromise is supply-chain based, not exploiting a software vulnerability), defenders should be aware that these devices often run outdated Android versions (8.0, 9.0) with unpatched vulnerabilities that enable privilege escalation and persistence.

Exploitation Status

This botnet represents confirmed, active exploitation in the wild. Google's takedown action, coordinated with industry partners, disrupted C2 infrastructure and is expected to impact over 11.3 million total devices. The malware was operational at the time of the takedown, actively generating revenue through proxy rentals and ad fraud.

Detection & Response

Sigma Rules

The following Sigma rules target observable behaviors associated with residential proxy malware on network-connected devices. These are designed for environments with network monitoring, DNS logging, or endpoint visibility into IoT segments.

YAML

---
title: Suspicious SOCKS Proxy Port Activity from IoT Device
description: Detects network connections on common SOCKS proxy ports originating from IoT network segments, indicative of residential proxy malware.
references:
  - https://krebsonsecurity.com/2026/11/tech-firms-dismantle-botnet-that-turned-1-3m-tv-boxes-into-proxies/
author: Security Arsenal
date: 2026/11/05
tags:
  - attack.command_and_control
  - attack.t1090
logsource:
  category: network_connection
  product: firewall
detection:
  selection:
    DestinationPort:
      - 1080
      - 1081
      - 8080
      - 3128
      - 8888
    SourceIP|cidr:
      - '10.0.0.0/8'
      - '172.16.0.0/12'
      - '192.168.0.0/16'
  filter:
    DestinationIP|cidr:
      - '10.0.0.0/8'
      - '172.16.0.0/12'
      - '192.168.0.0/16'
  condition: selection and not filter
falsepositives:
  - Legitimate internal proxy servers
  - Development testing
level: medium
---
title: High Volume Outbound Connections from Single IoT Device
description: Detects abnormally high numbers of outbound HTTPS connections from a single IoT device IP, consistent with proxy relay or ad fraud activity.
references:
  - https://krebsonsecurity.com/2026/11/tech-firms-dismantle-botnet-that-turned-1-3m-tv-boxes-into-proxies/
author: Security Arsenal
date: 2026/11/05
tags:
  - attack.command_and_control
  - attack.exfiltration
logsource:
  category: network_connection
  product: firewall
detection:
  selection:
    DestinationPort:
      - 443
      - 80
    SourceIP|cidr:
      - '10.0.0.0/8'
      - '172.16.0.0/12'
      - '192.168.0.0/16'
  timeframe: 5m
  condition: selection | count(DestinationIP) by SourceIP > 50
falsepositives:
  - Software update servers
  - Content delivery networks
level: high
---
title: DNS Query to Dynamic DNS Provider from IoT Segment
description: Detects DNS queries to dynamic DNS providers from IoT devices, often used by botnets for C2 resolution.
references:
  - https://krebsonsecurity.com/2026/11/tech-firms-dismantle-botnet-that-turned-1-3m-tv-boxes-into-proxies/
author: Security Arsenal
date: 2026/11/05
tags:
  - attack.command_and_control
  - attack.t1071.001
logsource:
  category: dns
  product: windows
detection:
  selection:
    QueryName|contains:
      - '.ddns.net'
      - '.no-ip.com'
      - '.duckdns.org'
      - '.dynu.com'
      - '.afraid.org'
    SourceIP|cidr:
      - '10.0.0.0/8'
      - '172.16.0.0/12'
      - '192.168.0.0/16'
falsepositives:
  - Legitimate DDNS for remote access
  - Home automation systems
level: medium

KQL (Microsoft Sentinel / Defender)

This hunt query identifies IoT devices exhibiting proxy-like behavior by analyzing network connection patterns. It's designed for environments ingesting firewall logs or using Defender for Endpoint on Android Enterprise devices.

KQL — Microsoft Sentinel / Defender

// Hunt for IoT devices with high outbound connection diversity (proxy behavior)
let IoTSubnet = dynamic(["10.0.0.0/8", "172.16.0.0/12", "192.168.0.0/16"]);
CommonSecurityLog
| where TimeGenerated > ago(24h)
| where ipv4_is_in_range(SourceIP, IoTSubnet[0]) or ipv4_is_in_range(SourceIP, IoTSubnet[1]) or ipv4_is_in_range(SourceIP, IoTSubnet[2])
| where DestinationPort in (80, 443, 8080, 1080, 3128)
| where not(ipv4_is_private(DestinationIP))
| summarize ConnectionCount = count(), UniqueDestinations = dcount(DestinationIP), TotalBytesSent = sum(SentBytes), Ports = make_set(DestinationPort) by SourceIP, DeviceHostName
| where UniqueDestinations > 30 or ConnectionCount > 500
| extend ProxyPortsUsed = set_intersect(Ports, dynamic([1080, 3128, 8080]))
| where array_length(ProxyPortsUsed) > 0 or TotalBytesSent > 100000000
| project SourceIP, DeviceHostName, ConnectionCount, UniqueDestinations, TotalBytesSent, ProxyPortsUsed
| order by UniqueDestinations desc

Velociraptor VQL

For organizations with Velociraptor deployed on Android-based endpoints or Linux-based IoT management systems, this artifact hunts for processes listening on proxy ports and suspicious network connections.

VQL — Velociraptor

-- Hunt for processes listening on common proxy ports and suspicious outbound connections
SELECT 
    Pid,
    Name,
    CommandLine,
    Exe,
    Username,
    netstat().LocalAddress.IP as LocalIP,
    netstat().LocalAddress.Port as LocalPort,
    netstat().RemoteAddress.IP as RemoteIP,
    netstat().RemoteAddress.Port as RemotePort,
    netstat().State as ConnectionState
FROM pslist()
WHERE netstat().LocalAddress.Port in (1080, 3128, 8080, 8888)
   OR (netstat().State = 'ESTABLISHED' AND netstat().RemoteAddress.Port in (80, 443))
GROUP BY Pid
HAVING count(netstat().RemoteAddress.IP) > 10

Remediation Script

The following Bash script is designed for network administrators to identify potentially compromised IoT devices on a network segment by checking for devices listening on proxy ports and generating high outbound traffic. Run this from a Linux jump box or network monitoring system.

Bash / Shell

#!/bin/bash
# Android TV Botnet Detection Script
# Scans local network for devices listening on proxy ports and high-bandwidth IoT devices

NETWORK="192.168.1.0/24"  # Adjust to your IoT subnet
PROXY_PORTS="1080 3128 8080 8888"
LOG_FILE="/var/log/iot_botnet_scan_$(date +%Y%m%d_%H%M%S).log"

echo "[*] Starting IoT botnet detection scan at $(date)" | tee -a "$LOG_FILE"
echo "[*] Scanning network: $NETWORK" | tee -a "$LOG_FILE"

# Scan for devices listening on proxy ports
for port in $PROXY_PORTS; do
    echo "[*] Scanning for open port $port..." | tee -a "$LOG_FILE"
    nmap -p $port --open "$NETWORK" | grep -E "Nmap scan report|open" | tee -a "$LOG_FILE"
done

# Identify high-bandwidth devices (requires iftop or similar)
echo "[*] Checking for high-bandwidth devices..." | tee -a "$LOG_FILE"
echo "[!] Run 'iftop -i eth0 -P' manually to identify top talkers" | tee -a "$LOG_FILE"

# Check DNS logs for DDNS queries (if using local DNS resolver)
if [ -f /var/log/syslog ]; then
    echo "[*] Checking DNS logs for DDNS queries..." | tee -a "$LOG_FILE"
    grep -E "ddns|no-ip|duckdns|dynu" /var/log/syslog | tail -20 | tee -a "$LOG_FILE"
fi

# Generate ARP table for device inventory
echo "[*] Current ARP table (device inventory):" | tee -a "$LOG_FILE"
arp -a | tee -a "$LOG_FILE"

echo "[*] Scan complete. Results saved to $LOG_FILE" | tee -a "$LOG_FILE"
echo "[!] Recommended actions:" | tee -a "$LOG_FILE"
echo "    1. Isolate devices listening on proxy ports" | tee -a "$LOG_FILE"
echo "    2. Block outbound traffic from IoT VLAN except required ports" | tee -a "$LOG_FILE"
echo "    3. Review DNS logs for suspicious DDNS usage" | tee -a "$LOG_FILE"

Remediation

Immediate Actions for Organizations

Inventory and Isolate IoT Devices: Identify all Android-based IoT devices on your network (TV boxes, healthcare devices, digital signage, karaoke machines). Segment them into isolated VLANs with strict egress filtering.
Block Proxy Ports at the Perimeter: Implement firewall rules blocking outbound connections on common proxy ports (1080, 3128, 8080, 8888) from IoT segments unless explicitly required for business operations.
Monitor for Bandwidth Anomalies: Deploy network monitoring to alert on IoT devices consuming disproportionate bandwidth or maintaining sustained outbound connections.
DNS Filtering: Block queries to known dynamic DNS providers and domains associated with residential proxy services at your DNS resolver.
Vendor Scrutiny: For procurement teams, require security attestations for Android-based devices. Avoid white-label or unbranded Android TV boxes from unknown manufacturers.

For Consumers and Home Users

Factory Reset and Monitor: If you own an Android TV box, perform a factory reset and monitor network traffic. Note that some malware survives resets if embedded in system partitions.
Check for Suspicious Apps: Navigate to Settings > Apps and look for unfamiliar applications with names like "System Update," "Media Service," or generic Android icons that don't match legitimate Google services.
Router-Level Blocking: Configure your router to block outbound connections on proxy ports and monitor per-device bandwidth usage.
Replace Compromised Devices: If a device exhibits persistent malicious behavior after factory reset, discontinue use. The cost of replacement is lower than the risk of your internet connection being used for criminal activity.

Long-Term Defensive Measures

Zero Trust for IoT: Treat all IoT devices as untrusted. Implement certificate-based authentication where possible and deny-by-default firewall policies.
Supply Chain Security: Demand transparency from device manufacturers. Request firmware hashes, signed updates, and documentation of pre-installed software.
Threat Intelligence Integration: Subscribe to feeds tracking residential proxy networks and botnet C2 infrastructure. Block known malicious IPs at the perimeter.
Employee Awareness: Educate staff about the risks of connecting compromised home devices to corporate VPNs or using personal devices for work on networks with infected IoT equipment.

Vendor and Government Resources

Google Security Blog: Monitor Google's security blog for updates on this takedown and related Android security initiatives.
CISA IoT Guidance: Review CISA's IoT security resources for enterprise IoT risk management frameworks.
FBI IC3: Report suspected botnet activity or residential proxy abuse to the Internet Crime Complaint Center.

This takedown demonstrates the scale of supply-chain compromises in consumer IoT. Defenders must extend visibility beyond traditional endpoints to the growing ecosystem of Android-based devices that share our networks and internet connections.

Related Resources

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