Research

Google Took Down a 1.3 Million-Box Android TV Botnet That Shipped in the Firmware. Here Is What to Check, and What We Hold.

Google Took Down a 1.3 Million-Box Android TV Botnet That Shipped in the Firmware. Here Is What to Check, and What We Hold.

Google's Threat Intelligence Group disrupted a botnet it calls XCPE on November 2. More than 1.3 million Android TV set-top boxes were enrolled, and Google assesses with high confidence that the backdoor was built, deployed and run for profit by Videostrong Technology Co., an Android device maker. Google estimates its takedown of affiliate command servers cut access to at least 10 million more compromised devices, including telehealth hardware, karaoke machines and digital signage.

The unusual part is where it lived. The backdoor was in the firmware at the factory, not delivered by an exploit or a trick. It runs with system privileges, and the reports say it reinstalls itself from a protected partition if someone removes it.

A figure on the XCPE botnet. A table of where to look: the packages x.cpe, com.oemservice and com.abc.nexus; the /oem/ partition it reinstalls from; the setting package_verifier_user_consent set to minus one, which switches off Google Play Protect; the domains anyevonline.com and szbboys.com; and outbound ports 3885 to 3887. A side panel lists what the operators did: install apps silently, enroll boxes in residential proxy networks, fake ad impressions, and sell access to affiliates. A note says our feed holds 70 XCPE records from Google's report, cited from the report and not a lead. A footer says removal needs clean firmware and that legitimate services Google lists are deliberately left out of our feed.

What it does

The main backdoor, named x.cpe and com.oemservice in Google's report, lets the operator install apps without asking, run shell commands as the system, take screenshots, inject keystrokes, and collect account and device data. It turns off Google Play Protect by setting the package-verifier consent value to minus one. A loader called com.abc.nexus, in use since late 2024, ran modules for affiliates: residential proxy software, ad fraud and further backdoors. Since August 2026, smaller droppers disguised as system packages have replaced that loader.

Google's attribution rests on evidence in an open directory on the operator's file server and on infrastructure shared with the company's own domain: a document by the company's research and development director, company email addresses used to sign backdoors, and a command server that shares an address with the company's site.

What to check

If you run Android TV boxes, set-top boxes or other Android devices of unknown origin, treat them as a fleet to inventory, not a few gadgets.

  • Look for the packages x.cpe, com.oemservice and com.abc.nexus, and for unexpected packages under the system app directory.
  • Check whether the package-verifier consent setting reads minus one, which means Play Protect was switched off.
  • Watch DNS and egress for anyevonline.com and szbboys.com, and for outbound connections on ports 3885 to 3887.
  • Segment these devices from everything that matters. A box on your guest network can still be a residential proxy exit.

Disconnecting a box stops the traffic but does not remove the infection. Removal needs clean firmware, and for a cheap unbranded box, replacing it may be the honest answer. We have not tested whether a factory reset clears it; the reports say it reinstalls itself from the protected partition.

What we hold, and what we don't

We hold 70 XCPE records from Google's report, ingested November 2 under the source manual-batch-xcpe-2026-11 at confidence 85: four command-server IPs, six core domains, and sixty file hashes for the backdoor and its loader. This is an ingest of Google's research, not our detection and not a lead. The ingest date is when we wrote it down, not when anyone first saw the malware.

We left out on purpose the legitimate services Google lists as part of the proxy and ad ecosystem, such as earn.fm and traffmonetizer.com, and the GitHub accounts that hosted packages. Those must never land on a blocklist. We also did not add the roughly 130 domains tied to the affiliate proxy software or the affiliate sample hashes; that is a second batch.

Limits

This rests on Google's report as read through a summarizing tool, and on BleepingComputer's and Help Net Security's coverage of it. We did not analyze a sample or a device. The report does not name a CVE for the privilege-escalation step, and it names no device brands other than the vendor.

Five percent of this is wrong somewhere. It always is. The numbers will move again before you finish reading.

Was this useful? Rate this post. The widget is at the bottom of the page, and we read every response.


Every indicator in this post is in the feed. Free.

1.58M+ IOCs, STIX 2.1 / TAXII, 88% novel vs ThreatFox, exploited-CVE leads ahead of CISA. No credit card — a free API key in 30 seconds, and you can audit every claim above against the live endpoints.

Get your free key → analytics.dugganusa.com/stix/register