Google takes down XCPE, the 1.3-million-device Android TV box botnet: what it means for an ISP

This post summarizes what is known so far, what was left unresolved, and what an ISP can do with the boxes in its base. The information comes from press coverage of Google's announcement (sources at the end); we have no per-country breakdown of infections, so we can't say how many affected boxes there are in Brazil or Argentina.

What happened

• The botnet. It's called XCPE and grouped more than 1.3 million devices, the vast majority Android TV boxes. The same backdoor also turned up in other Android devices, such as telehealth equipment, karaoke machines and digital signage.
• Who is responsible. Google's Threat Intelligence Group (GTIG) attributes it, with high confidence, to Videostrong Technology, a Shenzhen-based manufacturer. According to Google, the company installed the backdoor on purpose and sold access to criminal affiliates who loaded their own modules.
• The response. Google took down the command servers (which, by its estimate, gave access to about 10 million more devices infected through other means), took legal action against the domains and servers, and cut ties with Videostrong: it revoked its Android TV license and banned it from making certified Android devices. It also changed its certification review process, because the company used obfuscation to evade security testing.
• The partners. Lumen (Black Lotus Labs), HUMAN Security, Plume, Synthient and TrendAI took part, and Japan's National Police Agency helped coordinate.

Why this is different from "just another malware"

Most of the infections discussed on this blog arrive through a pirated app or a dubious download. XCPE did not: the backdoor was in the firmware, put there on the production line. There is nothing the subscriber did wrong, and no vulnerability to patch. It's the scenario we described in why your Android TV Box ships with malware from the factory, now with a name, a scale and a manufacturer singled out by Google.

According to the reports, the backdoor runs with system privileges and can install apps, disable Google Play Protect, run commands, take screenshots, log keystrokes and open a remote shell. It was used mostly for three things: residential proxy (renting the subscriber's connection to third parties), ad fraud, and installing other backdoors.

What it means for an ISP

The residential proxy is what matters most to a provider. A box used as a proxy lets traffic that neither the subscriber nor the ISP generated leave through the subscriber's IP: that traffic takes up access and uplink capacity (the cost chain we covered in generic TV boxes in Brazil and Argentina) and also ties the IP to someone else's activity, which can bring abuse complaints or blocklisted IPs. That last part is a reasonable consequence of proxy use, not something we've seen measured on a specific network.

What the takedown did not resolve

This is the most important part of the news and the part headlines repeat least:

• Google acted on the command infrastructure. The devices still carry the backdoor.
• The malware reinstalls itself from the /oem/ partition, so uninstalling an app or doing a factory reset isn't enough. Clean firmware is needed.
• Until then, the only mitigation the reports cite is disconnecting the box from the internet.
• Since August 2026, according to BleepingComputer, the operators have moved to smaller droppers disguised as system apps. In other words, the picture keeps moving.

What you can do with your box base

A point of honesty before the list: AdminSTB does not remove XCPE. Its agent only sees the boxes where it's installed, and removing a backdoor that reinstalls from /oem/ requires replacing the firmware, which is outside what the panel does. What does help is knowing which boxes are suspect and prioritizing them:

1. Inventory by model. Build a list of the models and brands in your fleet and compare it against the models named in the Google and Synthient reports. If you don't know which models you have, that's the first finding (see the fleet audit).
2. Installed app list. AdminSTB shows each box's apps, with their install origin and a danger score. Look for the packages x.cpe, com.oemservice and com.abc.nexus. Treat it as a lead, not a verdict: a system component may not appear, and its absence doesn't prove the box is clean.
3. Per-app usage and outbound traffic. A box that constantly uploads data while nobody is watching video is suspect, whether or not it has a package with those names. The per-app usage ranking is where to start.
4. DNS queries. The reports mention the command domain anyevonline[.]com and the broker mqtt.szbboys[.]com. If you keep DNS query history (for example with LintraTech's Pico-Server), searching for those names identifies which subscribers have a compromised box, even though Google has already stepped in on the servers. Blocking them in your DNS or firewall (MoniTik helps centralize that policy on MikroTik) cuts the communication in the meantime.
5. Replacement or clean firmware. For boxes you confirm or suspect, the real way out is swapping them for a certified one or reflashing them with trusted firmware. On the certified models we've tested (onn, ZTE), updates aren't silent and ask for on-screen confirmation, but the hardware has passed Google's compatibility and security tests.

What to do now

1. List the box models in your base and compare them with the ones named in the Google and Synthient reports.
2. Check your DNS logs for any subscriber that queried the domains mentioned.
3. Decide how you'll replace or reflash the boxes that test positive, and who bears the cost.
4. If you hand boxes to your subscribers, demand audited firmware and certified models from your supplier, or ask for written guarantees.

Sources

Data taken from coverage of Google's November 2, 2026 announcement. We did not review the original GTIG report, so the figures and attributions are those reported by the press:

• BleepingComputer
• KrebsOnSecurity
• Help Net Security
• The Hacker News