Google Disrupts XCPE Android Botnet Hidden in 1.3 Million TV Boxes
Google and a coalition of industry partners dismantled a widespread XCPE backdoor that had quietly sewn into hardware and turned many devices into a coordinated criminal platform. Google attributes the backdoor and the broader botnet to Videostrong Technology Co., a Shenzhen-based Android OEM/ODM, and says the backdoor was embedded in firmware across multiple models and brands over several years. The effort disrupted the command-and-control infrastructure and disrupted access to thousands of additional devices via affiliate modules, with Google’s action suggesting at least 10 million more compromised devices could be affected through these downstream channels.
Anatomy of the XCPE backdoor and its monetization ecosystem
Since at least late 2024, Videostrong evolved its pre-installed malware from simple droppers to a modular, three‑stage architecture designed for resilience and multi‑tenant monetization. The core backdoor runs at system level and persists across reboots by reinstalling from the firmware partition, maintaining persistence even when users attempt to remove it. The architecture separates the initial backdoor from the loader and execution engine, and then from the monetization modules that drive the criminal revenues.
The primary backdoor, known as x.cpe (also referred to as com.oemservice in some builds), is preloaded into the firmware partition and operates with android.uid.system privileges. Its main job is to establish and sustain communications with the C2 infrastructure and coordinate the loader and execution engine. The loader, historically named com.abc.nexus, acts as the conduit for module updates and injections, using native anti-analysis utilities to evade security scans and to initialize monetization modules. In newer variants, x.cpe routes configuration and payloads to the Nexus loader, which then orchestrates the installed modules. In practice, this separation helps the backdoor remain functional while evading straightforward detection.
Monetization modules are loaded as native daemons or embedded SDKs and may be downloaded as secondary APKs. They contract with affiliates who operate the actual revenue-generating components, such as residential proxies and ad-fraud engines. Notable examples of these module families include Linkfog, AppSalt/Honeygain, GaGaNode, NetNut/Popanet, Traffmonetizer, and EarnFM, among others. The modules turn infected devices into residential proxy exits, enable ad fraud, or install additional backdoors to extend control and monetization. This multi‑layered approach shows Videostrong’s intent to monetize infected devices through several monetization channels, often running multiple proxy SDKs on a single device.
From an infrastructure standpoint, XCPE uses a two‑stage command-and-control (C2) approach and relies on MQTT for live, real-time control. Initial bootstrap configurations are fetched via HTTP, followed by a persistent MQTT connection to receive commands and module updates. The MQTT broker most commonly observed is mqtt.szbboys.com, with the broker’s activity tied to a broader set of transactional domains under the anyevonline family. In addition to standard C2 traffic, the malware downloads modules and stagers from GitHub releases, filehosting sites, and operator-controlled servers on IPs such as 38.145.197.135 and 23.94.49.57. The network activity is designed to be resilient and to keep operational control even as individual components are disrupted.
Beyond the core three-stage structure, researchers have documented newer persistence and loading techniques. Some variants disguise new droppers as system apps (for example com.android.system.ntp or com.android.sso.auth.handler) and use libexploit.so to restart the local adbd service as root, remount /system, copy themselves into /system/priv-app/, and create privilege XML files. These changes raise the bar for persistence and complicate remediation efforts beyond a simple factory reset. In several variants, the system app is signed with the maker’s key, and researchers note that cleanup may require vendor action, platform protection, or device replacement rather than a simple uninstall.
The backdoor’s operators also deployed anti‑analysis and process hardening utilities such as libseccomp_guard.so, which filters system calls to block sandboxing and tampering, and to protect the malware’s execution from automated instrumentation. The overall evolution shows a clear intent to maintain long-term presence on devices and to complicate detection and removal for consumers and even some enterprise defenses.
Infrastructure and defense indicators
The XCPE ecosystem uses a globally dispersed set of bootstrap and C2 endpoints. Initial bootstrap and configuration often migrate across a family of subdomains under anyevonline.com. The MQTT broker used for control is consistently hosted at mqtt.szbboys.com, which has been observed resolving to IPs such as 219.134.163.210 and 219.134.163.211, with non-standard MQTT ports 3885–3887. Software updates and monetization payloads are hosted on operator-controlled GitHub releases and file hosting services such as filemail.com, with other artifacts hosted on specific operator servers. Netflow telemetry and related indicators show these broker IPs and hosts are central to command and control and distribution activity.
Researchers also documented a suite of defender-relevant indicators associated with the XCPE ecosystem. Known infrastructure and indicators defenders can use to identify or block XCPE include bootstrap domains under anyevonline, the MQTT broker host mqtt.szbboys.com, and the broker IPs 219.134.163.210/211 operating on non-standard ports 3885–3887. Additional artifacts include the presence of GitHub/filemail staging, and operator-controlled servers on IPs like 38.145.197.135 and 23.94.49.57. For enterprise defenders, Synthient’s published model list (182 device models) provides a cross-reference for known devices that researchers observed in the wild, with the caveat that a model name alone does not confirm infection. A MECOOL KM9PRO Max has been identified as a confirmed infected device by Synthient, illustrating that model-brand associations are not definitive proof of compromise. These indicators should be used in concert with device isolation and network monitoring to assess risk and enforce containment.
To help defenders, there is also attribution context that strengthens the case for Videostrong’s role. Independent researchers documented evidence such as a MECOOL KM9PRO Max purchase linked to the backdoor installation, a PDF attributed to Videostrong’s R&D leadership in an open directory, and IP sharing between Videostrong and the C2 host. Researchers also found Videostrong email addresses used to sign backdoors, supporting the attribution to the manufacturer rather than a rogue actor. These elements together underpin the assessment that Videostrong deliberately infected devices rather than discovering the backdoor by accident.
What Google did and why it matters for OEMs and users
Google’s disruption included a combination of civil actions and policy controls aimed at stopping the botnet’s operations and constraining the actors’ ability to monetize infected devices. The company filed legal actions to shut down the XCPE domains and the command-and-control servers used by the backdoor and the various monetization modules loaded through XCPE. In addition, Google banned Videostrong and any future subsidiaries or affiliates from building or selling certified Android devices or supplying software to other certified vendors. Google also implemented improvements to its firmware integrity and device-review processes to reduce the likelihood that similar backdoors could bypass checks in the future.
Industry partners—Japan’s National Police Agency, Lumen, HUMAN Security, Plume, Synthient, and TrendAI—collaborated to analyze the botnet and its infrastructure, and to disrupt the ecosystem supporting the backdoor. The disruption is designed to cut off access to a broad network of criminals and to reduce the financial incentives that fuel such campaigns. The operators are part of an interconnected supply chain, and Google notes that even with significant disruption, the broader market for backdoors, ad fraud, and residential proxies remains persistent and adaptable.
It is important to understand that the takedown did not erase the malware from every infected device. The backdoor often reinstalls itself from the firmware partition if it is removed, and the ongoing presence on devices means remediation remains challenging for consumers and some organizations. Google’s position is that severing the C2 domains effectively renders the malware benign, but it acknowledges that a device may still be compromised and would require firmware replacement or other vendor-level protections to fully remove the infection.
Is your device affected? guidance for readers
Researchers from Synthient published a list of 182 device model names observed in the campaign and warn that a model name alone does not confirm infection. The list includes MECOOL-branded devices, and Synthient reported buying a MECOOL KM9PRO Max with the backdoor preinstalled. Plume reported multiple devices using the botnet control server, most of them MECOOL, while TrendAI tracked infections across many models. Because XCPE is embedded in firmware and can reinstall after attempted removal, readers should treat a device as potentially compromised even if a model name matches a commonly affected family.
When evaluating a device, readers should consult Synthient’s model list for a cross-check, but remember that exposure is not limited to a single model family. If a device is identified as MECOOL KM9PRO Max or matches other entries in Synthient’s list, it should be treated with heightened caution, but a model name alone does not guarantee infection. The remediation decisions differ among researchers: some advocate factory resets, some call for vendor actions or platform protections, and others recommend discarding the device entirely. Given this disagreement, readers should use a structured approach to decide whether to reset, replace, isolate, or discard a device, and they should consider vendor guidance and device-support status in their decision.
For organizations seeking a simple decision framework, a practical starting point is to compare the model against Synthient’s published list, verify whether any MECOOL KM9PRO Max instances have been observed, and then weigh remediation options: a factory reset may erase user data but may not remove a persistent backdoor, and in some cases remediation may require vendor‑level firmware replacement or even device replacement to ensure protection against reinstallation.
Prevention and what readers should do going forward
Google’s consumer-facing guidance is clear: consumers should be wary of applications that pay for “unused bandwidth” or “sharing your internet,” and should only purchase connected devices from reputable manufacturers. Android TV partners maintain a current list of certified devices, and readers should consult that list to buy from trusted sources. Keeping device protections enabled—such as Google Play Protect—and reviewing permissions for VPNs and proxy tools reduces risk. This guidance is intended to help readers reduce exposure and avoid becoming part of the next residential proxy or botnet campaign.
In concrete terms, readers should avoid paid bandwidth-sharing apps, review VPN or proxy permissions on devices, and prefer devices from Google-certified Android TV partners. This approach aligns with Google’s call to action and helps minimize the risk of future home-network infections. For organizations, this means enforcing network segmentation so residential proxy activity cannot readily reach sensitive enterprise resources, and ensuring devices on home networks are treated as potential attack surfaces that require monitoring and risk assessment.
What organizations should do to detect and block XCPE on networks
Defenders should act on known infrastructure and indicators for XCPE. Use the published indicators to identify MECOOL or similar devices on the network, disconnect affected devices, and block control domains and IPs listed in the defending reports. Keep home devices on separate network segments from sensitive corporate resources, and monitor for signs of unauthorized proxy activity or unusual data flows that could indicate compromised devices. Treat unmanaged consumer devices on remote-work networks as part of the overall attack surface and implement network-level controls to limit potential exposure.
Additionally, defenders should stay informed about evolving persistence techniques and follow vendor guidance on remediation. As researchers note, some infections may require vendor action, platform protection, or device replacement to fully mitigate the risk. Ongoing collaboration among device manufacturers, service providers, and security teams remains essential to reducing the risk from this class of firmware-injected threats.
Industry reform and ongoing risk
The XCPE disruption illustrates that even a centralized takedown cannot immediately eradicate a deeply embedded firmware threat. The botnet ecosystem remains adaptable, with operators able to pivot to new loaders or rival monetization SDKs when one component is disrupted. Lasting change requires accountability across the hardware supply chain, the residential proxy industry, and the broader technology ecosystem. OEMs and retailers should require independent security audits for ODMs, delist implicated manufacturers, and insist on robust firmware integrity checks as part of the certification process.
For consumers, staying informed and relying on trusted vendors reduces exposure. Residential proxies and related monetization models are powerful tools when used legitimately, but the XCPE case shows how malicious actors can weaponize such concepts in consumer devices. By prioritizing transparent consent, rigorous security testing, and responsible vendor practices, the ecosystem can better guard against similar threats in the future.