Google's XCPE botnet takedown leaves backdoors in place

The XCPE botnet lost its control infrastructure in late October 2026, but its firmware component was not removed. The network consists of compromised Android devices, mostly used as TV set-top boxes.

Google took legal action against the domains and servers controlling the devices, according to The Hacker News. The action also targeted control domains for malware distributed through the backdoor. Announced on November 2, 2026, the coordinated operation involved Japan's National Police Agency, Lumen, HUMAN Security, Plume, Synthient, and TrendAI.

What did the XCPE botnet takedown disrupt?

The operation disrupted command-and-control infrastructure, including domains used by more than a dozen malware families loaded through the XCPE botnet. The firmware component was not removed, though, and that is the component that gave the operators persistent access to the devices in the first place.

The reported figures describe different parts of the operation. They are not interchangeable counts of the same device population:

Criminal affiliates distribute malware through channels other than the XCPE botnet, so taking down their control domains is expected to affect more devices than disrupting this particular backdoor network.

TrendAI observed the highest device counts in Malaysia, Brazil, Iraq, Mexico, and Taiwan. Researchers also found the backdoor on telehealth devices, karaoke machines, and digital signage, which means an organization checking only its entertainment hardware could miss affected devices elsewhere in the same inventory.

How x.cpe kept system access and loaded malware

The persistent component is x.cpe. It runs inside the firmware with system-level privileges, and Google's technical analysis traces its evolution from simple droppers into a modular system. That progression dates back to at least late 2024.

Some builds name the primary backdoor x.cpe; others call it com.oemservice. Either way, it runs at the android.uid.system privilege level. After a reboot, it reinstalls from the /oem/ partition, and TrendAI found that the system app also carries the manufacturer's signature.

In the modular architecture, x.cpe mainly handles communications. The loader and execution engine, com.abc.nexus, uses native anti-analysis utilities to evade sandbox detection and initializes the monetization modules. Google says com.abc.nexus has more recently been phased out in favor of tailored droppers, each loading and executing individual modules rather than relying on that engine.

Control starts with HTTP POST requests. These retrieve configuration settings, geolocation information, and STUN server parameters; the device then establishes a persistent MQTT connection to receive instructions. MQTT is a lightweight publish-and-subscribe protocol designed for constrained or unreliable networks.

The commands covered silent application installation, arbitrary shell commands, screenshots, and network reconnaissance. Before silently installing software, the backdoor disables application checks in Google Play Protect. Google also observed live screenshots, keystrokes sent to devices, extraction of account and device information, collection of application lists and system logs, and reverse shells being opened.

Affiliate modules came in several forms: native ELF daemons, SDKs embedded in the loader's DEX bytecode, and secondary APKs downloaded from staging infrastructure. A significant majority of staged files were hosted as releases on operator-owned GitHub pages; the rest came from operator-controlled servers and file-hosting sites.

Residential proxies put household connections to work for operators

Most modules turned compromised boxes into residential proxies or sold their spare bandwidth. Other modules generated fraudulent advertisement views, while some installed additional backdoors on the same equipment.

A residential proxy sends a customer's traffic through someone else's home connection. To the service receiving it, that traffic appears to come from an ordinary household. Device owners in this campaign got no consent request, no notification, and no opt-out. The joint announcement also identifies video delivery as a revenue source, along with paid application installation in earlier versions of the operation.

For a service evaluating incoming traffic, I'd avoid treating a household IP address as proof that a request represents the household's user. The XCPE botnet exposes the failure in that assumption: a device can route third-party traffic through the address without its owner knowing anything about it.

Inside the device owner's network, remote command execution and network reconnaissance raise the prospect of lateral movement. Plume also warns that an apparently functioning streaming box can generate unexplained traffic.

Videostrong attribution exposed a gap in Android certification

Google assesses with high confidence that Videostrong intentionally developed, deployed, and operated the backdoor for financial gain. Videostrong is a Shenzhen-based device manufacturer supplying both its own brand and other brands. Google's assessment is not that a rogue insider acted alone. Nor does Google regard the campaign as a development mistake.

The attribution rests on technical and infrastructure connections. Google found x.cpe passing control-server settings to other Videostrong applications, including YokaTV Player, and identified a package-hosting GitHub account named yf-videostrong. Synthient, which worked with Google, also concluded with high confidence that Videostrong runs the operation. It cited a document signed by Videostrong's research and development director on a botnet server, plus a Videostrong domain sharing an IP address with the operators' control panel. Plume's finding connects the device software and its management: Videostrong supplied both the firmware and the remote-management tools.

Google says Videostrong used obfuscation to exploit a gap in Google's compatibility and security tests, then loaded malicious code after the device's first boot. Google has since changed its review process and is improving firmware-integrity checks for certified Android TV devices.

Plume found Google-certified devices in the XCPE botnet as well as devices running the Android Open Source Project version. A certification check therefore cannot rule out a device by itself.

Google banned Videostrong and future subsidiaries or affiliates from building or selling certified Android devices, or supplying software to other certified vendors. Yet as of November 2, 2026, Videostrong's website still advertised products it described as Google-certified Android TV boxes and sticks.

Find affected equipment, then remove it from the organization

Synthient's list contains 182 observed model names.

MECOOL warrants attention in that investigation. Synthient links the brand to Videostrong and found the backdoor preinstalled on a MECOOL KM9PRO Max it purchased. Plume identified more than a dozen different devices contacting the XCPE botnet's control server, most of them MECOOL-branded.

1. Identify relevant equipment using Synthient's indicators. Use the model list to find candidates for investigation, not to declare every matching device infected.
2. Disconnect and discard affected devices. Synthient recommends this for equipment identified through the investigation.
3. Block the control domains and IP addresses listed in Synthient's report. Do not substitute the package names below: those are references for investigating a device, not network-blocking indicators.
4. Separate other smart devices from sensitive systems. Synthient recommends distinct network segments.

Google's analysis provides package identifiers and a persistence location that can guide reverse engineering. They are not instructions for removing the backdoor, and the list should not be read or used as a removal script:

x.cpe
com.oemservice
com.abc.nexus
/oem/

I'd use those markers as leads, not treat their absence as grounds for declaring a device clean.

For remote employees, TrendAI recommends treating unmanaged consumer devices on home networks as part of the organization's attack surface and keeping corporate access behind managed devices.

A factory reset is not confirmed removal of x.cpe

For a confirmed affected box, I'd choose replacement over repeated uninstall attempts. Google warns that backdoor operators and criminal affiliates quickly switch tools when infrastructure is disrupted. A quiet connection after the takedown is not evidence of trusted firmware.