x.cpe backdoor persists after Google's botnet takedown

Google says its takedown disrupted a botnet of more than 1.3 million Android devices, but the x.cpe backdoor remains in their firmware. Owners cannot remove it themselves. The immediate task is to identify suspect boxes, disconnect them where appropriate and avoid mistaking a server takedown for device cleanup.

Most infected devices in the botnet targeted by Google's operation are Android TV set-top boxes, but the backdoor also turned up on telehealth devices, karaoke machines and digital signage. Google says operators extracted account details and opened remote command lines. Criminal modules also turned home internet connections into traffic-routing services, making this more than an unwanted-app problem.

What Google's takedown actually stopped

The operation targeted the infrastructure issuing orders, not the firmware already installed in people's homes. In late October, Google used legal action to take down the botnet's control domains and servers. It also took down control domains belonging to more than a dozen malware families delivered through the backdoor.

TrendAI counted 1,472,554 infected devices across 206 models between June 3 and October 1, describing that count as a lower bound. Those measurements show the campaign's spread across device models; they do not establish whether any particular box is infected.

Google expects the operation to cut criminals' access to at least 10 million additional infected devices because the malware families also spread through other routes. I read that as an expected disruption of access, not a device-cleanup total. Google also warns that both backdoor operators and their criminal customers quickly change tools after infrastructure is disrupted.

How the x.cpe backdoor gained control of Android boxes

The backdoor runs inside the firmware as a system app with system-level access, according to Google's analysis. It contacts command-and-control (C2) servers and waits for instructions. Before silently installing software, it disables app checks in Google Play Protect, Android's built-in security feature.

Its capabilities extend beyond installing unwanted applications. Operators could execute commands, capture the screen and map the network containing the box. Google says it observed Videostrong's operators taking live screenshots, sending keystrokes and extracting account details, device information, application lists and system logs. They also opened reverse shells, providing a remote command line into the device.

Most criminal add-on modules monetised the connection itself. Residential proxy modules let customers route traffic through an owner's home connection so it appeared to originate from an ordinary household; other modules sold spare bandwidth or fabricated advertising views.

Why Google attributes the operation to Videostrong

Google says it has high confidence that Videostrong deliberately installed the backdoor and sold access to criminals. It does not attribute the operation to an accidental inclusion or a rogue employee. Videostrong makes devices under its own name and for other brands, so the manufacturer's name need not be the name printed on the box.

Google's account connects the x.cpe backdoor to other Videostrong software: it passes settings from the control server to applications including YokaTV Player. Synthient, which worked with Google, also concluded with high confidence that Videostrong runs the operation. Its evidence included a document signed by Videostrong's research and development director in an open server folder, plus a Videostrong domain sharing an IP address with the operators' control panel.

Plume also found that Videostrong supplied both device firmware and remote-management tools. I treat these as the organisations' attributed findings, not an admission from the manufacturer.

Check and isolate MECOOL and similar TV boxes

Start with device identification, but do not treat a matching product name as a diagnosis. Synthient published 182 model names observed in the campaign and explicitly warns that a name alone does not confirm infection. Its investigation focused on MECOOL-branded boxes linked to Videostrong; a MECOOL KM9PRO Max it purchased contained the backdoor before use.

For an organisation, Synthient recommends the following steps. Separate guidance covers Cisco IOS XE vulnerability risks and remediation.

1. Identify devices using the campaign indicators. Check for MECOOL or similar devices on the network using Synthient's published indicators, rather than relying only on branding or the model-name list.
2. Disconnect and discard devices identified through that investigation. Synthient recommends removing them permanently, rather than returning them to service after an attempted cleanup.
3. Block the control domains and IP addresses identified in Synthient's report. Treat this as an additional containment measure, not as removal of the firmware component.
4. Keep other smart devices on separate network segments, away from sensitive systems. This follows Synthient's recommendation for reducing their proximity to organisational assets.

I'd prioritise disconnecting an identified device over attempting to uninstall the system app. I find the persistence mechanism makes an apparently successful removal an unreliable basis for reconnecting it.

For remote staff, TrendAI recommends treating unmanaged consumer devices on home networks as part of the company's attack surface and keeping corporate access behind managed devices. I read that advice as addressing the home-network context without assuming that every device sharing the connection has also been infected.

Why a factory reset does not establish removal

Removing the component does not persist across a restart. TrendAI says it is a system app signed with the manufacturer's key. I conclude cleanup requires vendor action, platform protection or replacement of the device—not simply an owner deleting an application.

Plume recommends a full factory reset because modules delivered through the backdoor may have installed additional backdoors. However, I note that it does not say a reset removes x.cpe itself. Synthient takes the stronger position that consumers should permanently discard the affected boxes because of their malware risk.

I would not treat a factory reset as evidence that a box is safe to reconnect. I see the reset recommendation as concerning possible additional compromise, while the firmware persistence remains a separate issue. Likewise, I do not take the server takedown as establishing that installed modules disappeared or that the underlying backdoor was removed.

Google's certification response reaches beyond MECOOL

Google has banned Videostrong, including future subsidiaries and affiliates, from building or selling certified Android devices and from supplying software to other certified device makers. I view this as a restriction on the manufacturer's participation, not a cleanup delivered to existing owners.

Google says Videostrong hid code to bypass a gap in compatibility and security testing, then loaded malicious code after the device's first boot. Google has changed its review process and is improving firmware checks for certified Android TV devices.

Plume says the botnet included both Google-certified devices and devices running the Android Open Source Project (AOSP) version. Google has not specified how many certified devices were affected. As of November 2, Videostrong's website still described products as Google-certified Android TV boxes and sticks.

For procurement, my take is that the lesson is narrower than rejecting every Android box: a certification claim alone should not overrule evidence connecting a device to the x.cpe backdoor.