Google Disrupts 1.3M-Device XCPE Android TV Botnet — Detection and Containment Guide for Compromised Streaming Boxes

Google, working with industry partners, has disrupted the XCPE botnet — a network of more than 1.3 million compromised Android TV streaming boxes — and banned the device manufacturer Google says intentionally pre-installed the malware before the devices ever reached consumers. This is not a case of users side-loading a shady APK. These devices left the factory already enrolled in criminal infrastructure, generating revenue through ad fraud, click fraud, and residential proxy services the moment they were plugged in.

For defenders, this matters for two reasons. First, if any of these off-brand streaming boxes are sitting on your corporate guest network, your hospital waiting-room TVs, your hotel properties, or your employees' home networks (a real concern for remote-work egress trust), they are actively beaconing to criminal C2 and potentially proxying third-party traffic through your IP space. Second, this is a supply-chain compromise of the firmware itself — which means factory resets and user-side cleanup do not work. Detection and containment at the network layer is your only reliable control short of physically replacing the hardware.

What Happened

According to reporting on Google's enforcement action, the XCPE operation compromised low-cost, off-brand Android TV boxes — the kind sold under rotating brand names on major e-commerce platforms at prices well below certified devices. Google's assessment is that the infection was intentional and manufacturer-driven: the malware was embedded in the device firmware or system image, not delivered post-sale. The botnet was monetized through classic crimeware services — fraudulent ad impressions, click fraud, and selling the infected devices' bandwidth as residential proxies, which downstream actors then use to launder the origin of other attacks, credential stuffing, and scraping operations.

Google's disruption targeted the botnet's command-and-control infrastructure and its monetization pipeline, and the manufacturer has been banned from Google's ecosystem, meaning its devices lose access to Play Protect certification and Google services. That kills the revenue model, but it does not de-infect the 1.3 million devices already deployed. Those boxes are still compromised, still attempting C2 contact, and still proxy-capable until they are unplugged or contained.

Technical Analysis

Affected Products and Platforms

• Affected class: Off-brand / white-label Android TV streaming boxes (set-top boxes and HDMI sticks) running Android Open Source Project (AOSP) builds without Google Play Protect certification
• Distribution channel: Online marketplaces selling devices under frequently-changing brand names, typically marketed as "fully loaded" streaming devices
• Not affected: Certified Android TV / Google TV devices from legitimate vendors (Chromecast with Google TV, NVIDIA Shield, onn., etc.) that ship with Play Protect and signed firmware
• Exposure surface: Home networks, hospitality networks, corporate guest wireless, waiting rooms, break rooms, and any flat network where a user can plug in an unmanaged device

How the Compromise Works (Defender's View)

The attack chain here is supply chain, not exploitation. There is no CVE because there is no vulnerability in the traditional sense — the malware is baked into the device image at the factory:

1. Pre-infection at manufacture: Malicious components are integrated into the system partition or privileged app layer of the firmware image. Because they live in the read-only system area or are re-delivered by a privileged system app, user-level removal (uninstall, factory reset) fails — the malware re-installs or survives.
2. First-boot enrollment: On first network connection, the device contacts C2 infrastructure — commonly resolved through dynamic DNS providers or hard-coded fallback domains — and registers itself as a bot.
3. Monetization modules: The C2 pushes tasking: hidden WebView-based ad fraud (loading and clicking ads invisibly), and residential proxy enrollment (the box begins accepting inbound relay connections or making outbound proxied connections on behalf of paying customers of the proxy service).
4. Your network becomes the product: Once proxy-enrolled, arbitrary third-party traffic — potentially including attack traffic against other targets — egresses from your public IP space.

Observable Behaviors

From a network telemetry standpoint, infected boxes exhibit behavior that is highly anomalous for a streaming device:

• Persistent low-and-slow C2 beaconing to domains with no legitimate relationship to streaming services, frequently on dynamic DNS infrastructure
• Outbound connections on non-streaming ports — a legitimate TV box talks almost exclusively on 443/80 (plus DNS/NTP); connections to SOCKS/proxy-associated ports (1080, 3128, etc.) or broad high-port ranges are red flags
• Abnormally high connection and destination diversity — a proxy node touches hundreds of unique destinations per hour; a real TV box touches a handful of CDN endpoints
• Inbound listening behavior — proxy modules often bind local listeners, and many of these devices also ship with ADB (TCP/5555) exposed, which is both a symptom of sloppy/insecure firmware and a secondary infection vector
• Traffic with no user present — sustained egress while the TV is off

Exploitation Status

• Scale: 1.3 million+ confirmed compromised devices — this is mass, active, in-the-wild criminal infrastructure, not theoretical
• Status: C2 disruption by Google and partners degrades current monetization, but devices remain infected and will attempt reconnection or be re-tasked if operators re-establish infrastructure
• KEV: Not applicable — no CVE; this is intentional supply-chain implantation

Detection & Response

The right detection posture here is network-layer hunting. These devices cannot run your EDR agent, so your visibility comes from DNS logs, firewall/NetFlow telemetry, and Defender/Sentinel ingestion of network device logs. The detections below are scoped to what an infected streaming box actually does — not generic IoT noise.

Sigma Rules

Tune the CIDR scopes and the action field values to match your firewall log pipeline before deployment.

---
title: IoT or Streaming Device DNS Query to Dynamic DNS Provider
id: 4f2a8c1d-3b6e-4f9a-9d21-7c5e8a2b6f10
status: experimental
description: Detects DNS queries to dynamic DNS providers originating from IoT/media subnets. Consistent with botnet C2 resolution behavior observed in pre-infected Android TV boxes such as those enrolled in the XCPE botnet. Legitimate streaming devices have no business resolving DDNS hostnames.
references:
  - https://www.bleepingcomputer.com/news/security/google-disrupts-million-device-xcpe-android-malware-botnet-bans-tv-box-maker/
  - https://attack.mitre.org/techniques/T1568/
author: Security Arsenal
date: 2026/01/12
tags:
  - attack.command_and_control
  - attack.t1568.002
logsource:
  category: dns
detection:
  selection:
    query|contains:
      - '.duckdns.org'
      - '.no-ip.com'
      - '.no-ip.org'
      - '.ddns.net'
      - '.hopto.org'
      - '.dyndns.org'
      - '.zapto.org'
      - '.servehttp.com'
      - '.sytes.net'
  filter_iot_subnet:
    src_ip|cidr:
      - '192.168.50.0/24' # Adjust to your IoT/media VLAN(s)
  condition: selection and filter_iot_subnet
falsepositives:
  - Self-hosted hobbyist services (Home Assistant remote access, personal VPN endpoints) on the IoT VLAN
  - Some cheap IP cameras legitimately using DDNS for remote viewing
level: medium
---
title: Android Debug Bridge (ADB) Exposure on Network
id: 8b3d5e7a-1c4f-4a2b-8e6d-9f1c3a5b7d20
status: experimental
description: Detects connections to TCP/5555 (Android Debug Bridge) targeting devices on the network. Off-brand Android TV boxes frequently ship with ADB exposed, enabling unauthenticated shell access and secondary malware enrollment. Observed as both a symptom of insecure streaming-box firmware and an infection vector for IoT botnets.
references:
  - https://www.bleepingcomputer.com/news/security/google-disrupts-million-device-xcpe-android-malware-botnet-bans-tv-box-maker/
  - https://attack.mitre.org/techniques/T1021/
author: Security Arsenal
date: 2026/01/12
tags:
  - attack.lateral_movement
  - attack.t1021
  - attack.discovery
  - attack.t1046
logsource:
  category: firewall
detection:
  selection:
    dst_port: 5555
    action:
      - 'allowed'
      - 'permit'
      - 'accept'
  condition: selection
falsepositives:
  - Legitimate developer ADB access to test devices (should be rare and attributable)
  - Some MDM/preview tooling for Android-based signage
level: high
---
title: IoT Device Outbound Connection on Residential Proxy Ports
id: c9e4f2a7-6d1b-48e3-b5a2-2f8d1c9e3a40
status: experimental
description: Detects outbound connections from IoT/media subnets to ports commonly associated with SOCKS and HTTP proxy services. Infected streaming boxes enrolled as residential proxy nodes relay third-party traffic over these ports. A legitimate TV box should egress almost exclusively on 80/443.
references:
  - https://www.bleepingcomputer.com/news/security/google-disrupts-million-device-xcpe-android-malware-botnet-bans-tv-box-maker/
  - https://attack.mitre.org/techniques/T1090/
author: Security Arsenal
date: 2026/01/12
tags:
  - attack.command_and_control
  - attack.t1090
  - attack.exfiltration
logsource:
  category: firewall
detection:
  selection:
    src_ip|cidr:
      - '192.168.50.0/24' # Adjust to your IoT/media VLAN(s)
    dst_port:
      - 1080
      - 1081
      - 3128
      - 8081
      - 9999
    action:
      - 'allowed'
      - 'permit'
      - 'accept'
  condition: selection
falsepositives:
  - Rare legitimate proxy configurations; verify before scoping to IoT VLAN
level: high

KQL — Microsoft Sentinel Hunt

This hunt assumes firewall/syslog ingestion into CommonSecurityLog (CEF). It surfaces streaming-class devices exhibiting proxy-node or beaconing behavior: high destination diversity, non-standard egress ports, or periodic low-and-slow connections. Scope IoTScope to your media/guest VLANs.

// Hunt 1: High destination diversity from IoT devices (proxy-node behavior)
// A legit streaming box talks to a handful of CDNs; a proxy node touches hundreds of hosts.
let IoTScope = dynamic(["192.168.50.", "10.30."]); // Adjust to your IoT/media subnets
CommonSecurityLog
| where TimeGenerated > ago(24h)
| where DeviceAction in~ ("allow", "permit", "accept", "allowed")
| where SourceIP has_any (IoTScope)
| summarize ConnectionCount = count(),
            UniqueDestinations = dcount(DestinationIP),
            UniquePorts = dcount(DestinationPort),
            PortsUsed = make_set(DestinationPort, 25)
    by SourceIP, bin(TimeGenerated, 1h)
| where UniqueDestinations > 50 or (UniquePorts > 15 and ConnectionCount > 200)
| sort by UniqueDestinations desc;

// Hunt 2: Beaconing pattern — periodic connections to the same destination
// Infected boxes re-register with C2 at regular intervals even when idle.
CommonSecurityLog
| where TimeGenerated > ago(7d)
| where SourceIP has_any (IoTScope)
| summarize Connections = count(), FirstSeen = min(TimeGenerated), LastSeen = max(TimeGenerated)
    by SourceIP, DestinationIP, DestinationPort
| where Connections >= 20 and DestinationPort !in (80, 443, 53, 123)
| extend SpanHours = datetime_diff("hour", LastSeen, FirstSeen)
| where SpanHours >= 24
| extend AvgIntervalMinutes = (SpanHours * 60) / Connections
| sort by AvgIntervalMinutes asc;

// Hunt 3: ADB (5555) and proxy-port exposure / usage anywhere on the network
union CommonSecurityLog, DeviceNetworkEvents
| where TimeGenerated > ago(7d)
| extend DstPort = coalesce(DestinationPort, RemotePort),
          DstIP = coalesce(DestinationIP, RemoteIP)
| where DstPort in (5555, 1080, 3128, 8081, 9999)
| summarize Connections = count(), Sources = make_set(SourceIP, 10) by DstIP, DstPort
| sort by Connections desc

Velociraptor VQL — Endpoint Hunt

The TV boxes themselves cannot run Velociraptor, but infected endpoints on your network can be enrolled into the same proxy monetization, and managed devices communicating with compromised boxes are worth surfacing. This artifact hunts for proxy-ware processes and endpoints with suspicious listener/egress patterns.

-- Hunt for processes and connections consistent with residential proxy enrollment
-- (the same monetization model used by the XCPE botnet)

-- Part 1: Known proxy-ware process names on managed endpoints
SELECT Pid, Name, CommandLine, Exe, Username, CreateTime
FROM pslist()
WHERE Name =~ '(?i)(microsocks|3proxy|socks5|proxyfier|bright.?data|honeygain|peer2profit|iproyal|packetstream)'
   OR CommandLine =~ '(?i)(socks5?|proxy).*(1080|3128)'

-- Part 2: Listeners and high-volume outbound connections on proxy-associated ports
SELECT Pid, Name, Status, Laddr, Raddr,
       Laddr.Port AS LocalPort, Raddr.Port AS RemotePort
FROM netstat()
WHERE (Status =~ 'LISTEN' AND LocalPort =~ '^(1080|3128|5555|8081|9999)$')
   OR (Status =~ 'ESTABLISHED' AND RemotePort =~ '^(1080|3128|8081|9999)$')

Remediation

There is no patch for this threat — the malware is in the factory firmware. Remediation is identification, containment, and replacement.

1. Inventory and identify suspect devices. Pull the list of Android-based devices on your network (DHCP leases, mDNS/Chromecast discovery traffic, MAC OUI lookup). Flag any streaming device that is not from a certified vendor. Google's Play Protect certification status can be checked on-device under Play Store → Settings → Play Protect certification — uncertified devices should be treated as suspect by default. Cross-reference against Google's enforcement communications regarding the banned manufacturer.

2. Contain immediately — do not attempt cleanup. Factory resets do not remove firmware-implanted malware. For any suspect box: quarantine it to a dead-end VLAN with no internet access, or block its MAC at the edge. Do not simply factory reset and return to service.

3. Replace with certified hardware. The durable fix is procurement policy: only permit Play Protect–certified Android TV / Google TV devices from reputable vendors. The $25 marketplace box is cheap because the buyer is the product.

4. Enforce egress restrictions on IoT/media VLANs. Streaming devices need TCP 80/443 to a manageable set of destinations, plus DNS and NTP — nothing else. Deny-all-else egress neutralizes proxy enrollment and most C2 tasking even if a compromised device slips in.

The following script identifies devices with exposed ADB on your network segments and applies a restrictive egress policy to the IoT VLAN on a Linux-based edge/firewall (adjust subnets and interface names to your environment):

#!/bin/bash
# XCPE-class compromised streaming box containment helper
# 1) Scan segments for exposed ADB (TCP/5555) — a hallmark of insecure/pre-infected Android TV boxes
# 2) Apply restrictive egress on the IoT VLAN: allow 80/443/DNS/NTP, deny everything else

IOT_SUBNET="192.168.50.0/24"   # Adjust to your IoT/media VLAN
IOT_IFACE="eth1"               # Adjust to the interface serving the IoT VLAN

# --- Step 1: Find exposed ADB listeners ---
echo "[*] Scanning $IOT_SUBNET for exposed ADB (TCP/5555)..."
nmap -p 5555 --open -oG - "$IOT_SUBNET" | awk '/open/{print $2}' | tee adb_exposed_hosts.txt
echo "[+] Exposed hosts written to adb_exposed_hosts.txt — quarantine these devices."

# --- Step 2: Restrictive egress for the IoT VLAN (nftables) ---
echo "[*] Applying restrictive egress policy on $IOT_IFACE..."
nft add table inet iot_egress 2>/dev/null
nft add chain inet iot_egress forward '{ type filter hook forward priority 0; policy drop; }'
# Allow established/related return traffic
nft add rule inet iot_egress forward ct state established,related accept
# Allow only what a streaming device legitimately needs
nft add rule inet iot_egress forward iifname "$IOT_IFACE" ip saddr "$IOT_SUBNET" tcp dport '{80,443}' accept
nft add rule inet iot_egress forward iifname "$IOT_IFACE" ip saddr "$IOT_SUBNET" udp dport '{53,123}' accept
nft add rule inet iot_egress forward iifname "$IOT_IFACE" ip saddr "$IOT_SUBNET" tcp dport 53 accept
# Explicitly log-and-drop everything else from the IoT VLAN (catches proxy/C2 tasking attempts)
nft add rule inet iot_egress forward iifname "$IOT_IFACE" ip saddr "$IOT_SUBNET" log prefix "IOT_EGRESS_DENY: " drop

echo "[+] Egress policy applied. Monitor 'IOT_EGRESS_DENY' log lines — denied proxy-port attempts identify infected boxes."
echo "[!] Note: run 'nft list table inet iot_egress' to verify; persist rules per your distro's nftables service."

5. Block ADB network-wide. There is no legitimate reason for TCP/5555 to be reachable on user, guest, or media segments. Block it at the edge and alert on attempts — it catches both pre-exposed boxes and secondary botnet enrollment attempts.

6. Hunt historical egress. If your org's public IP space was used as a residential proxy exit, you may find your IPs on abuse lists, and you may see reputation damage affecting email deliverability and third-party rate limiting. Check your egress IPs against major blocklists (Spamhaus, AbuseIPDB) and review CDN/SaaS provider abuse notices.

7. Address the remote-work angle. Employees' home networks are full of these devices. You cannot control that, but it reinforces why zero-trust posture matters: never extend network-level trust based on source IP for home users, and ensure conditional access evaluates device and identity signals rather than network location.

8. Report and share. If you identify compromised devices, report to Google via its Android/security reporting channels and share observed C2 indicators with your ISAC — post-disruption infrastructure reconstitution is exactly what community intel catches early.

Related Resources

Security Arsenal Managed SOC Services AlertMonitor Platform Book a SOC Assessment soc-mdr Intel Hub