--- url: "https://www.xcademia.com/news/google-and-industry-partners-disrupt-xcpe-botnet-that-infected-more-than-1-3-million-android-devices" title: Google and Industry Partners Disrupt XCPE Botnet That Infected More Than 1.3 Million Android Devices description: "Google disrupts the XCPE botnet that infected 1.3 million Android devices, exposing firmware backdoors, proxy abuse and advertising fraud." publishedAt: "2026-11-03T09:12:49.593+00:00" updatedAt: "2026-11-03T12:36:31.278264+00:00" type: news category: cybersecurity source_name: Google Cloud Blog source_url: "https://cloud.google.com/blog/topics/threat-intelligence/shutting-the-door-on-the-xcpe-botnet" tags: - "#XCPEBotnet" - "#AndroidSecurity" - "#GoogleThreatIntelligence" - "#Cybersecurity" - "#AndroidMalware" - "#Botnet" - "#FirmwareSecurity" - "#ThreatIntelligence" --- # Google and Industry Partners Disrupt XCPE Botnet That Infected More Than 1.3 Million Android Devices > Google and industry partners have disrupted the XCPE botnet, which compromised more than 1.3 million Android devices. The investigation uncovered pre-installed malware, residential proxy abuse, ad fraud and a financially motivated malware distribution operation. Source: **Google Cloud Blog** · 3 November 2026 ## Google Disrupts XCPE Botnet Targeting Android Devices Google and several industry partners have disrupted the XCPE botnet, a large-scale malware operation that enrolled more than 1.3 million Android-based devices without users' knowledge or consent. In its investigation published on 2 November 2026, Google's Threat Intelligence Group (GTIG) attributed the development, deployment and operation of the backdoor and botnet, with high confidence, to Videostrong Technology Co., an Android Original Equipment Manufacturer (OEM) and Original Design Manufacturer (ODM). The investigation revealed that the operation went beyond conventional malware distribution. Videostrong allegedly monetised compromised devices by providing criminal affiliates with backdoor access and allowing them to deploy additional malicious software. These secondary payloads were used for advertising fraud, residential proxy operations, data exfiltration and the installation of further malware. Google also reported taking action against command-and-control (C2) infrastructure associated with the affiliate malware modules. Because these affiliates operate through additional distribution channels, Google assesses that disrupting their C2 domains could sever access to at least 10 million additional compromised devices. ## How the XCPE Malware Operation Worked The XCPE ecosystem was designed to maintain persistent access to infected devices while allowing different criminal affiliates to deploy and operate their own malware modules. Google identified a modular, three-stage architecture that evolved from simpler malware delivery techniques into a more flexible system. The architecture consisted of three primary components: **1. Primary backdoor: **`x.cpe` The `x.cpe` backdoor was embedded in device firmware and operated with Android system-level privileges. In some builds, it appeared under the package name `com.oemservice`. It maintained communication with the operators' command-and-control infrastructure and coordinated the delivery of additional malware modules. Its persistence mechanism was particularly concerning. Even if users removed the application from the normal Android application directory, the firmware's `/oem/` partition could reinstall it after a device reboot. **2. Loader and execution engine: **`com.abc.nexus` The second component handled the execution and management of additional malicious payloads. It received instructions from `x.cpe` through inter-process communication (IPC), downloaded modules and coordinated their execution. Google also identified anti-analysis mechanisms designed to make automated security inspection more difficult. In newer variants, operators began replacing this general-purpose loader with more specialised dropper packages. **3. Monetisation modules** The third stage consisted of additional malware and software development kits (SDKs) supplied by affiliate operators. These modules enabled compromised devices to perform different activities, including residential proxy operations, bandwidth sharing, advertising fraud and additional backdoor installations. ![info-1](https://0a515t3ure77wbvx.public.blob.vercel-storage.com/articles/1793697042205-info1--153-.webp) ## How the Malware Communicated With Infected Devices Google identified a two-stage command-and-control communication mechanism in earlier XCPE versions. Initially, infected devices contacted HTTP endpoints to retrieve configuration information, including broker details, authentication credentials and module instructions. After receiving the configuration, devices established persistent MQTT connections to receive commands and additional payloads. MQTT is a lightweight messaging protocol commonly used in connected-device environments. Its publish-and-subscribe architecture allows devices to receive instructions through a central broker. Google identified several capabilities available through this communication channel: - Silent application installation without user interaction. - Remote execution of shell commands. - Downloading and executing shell scripts. - Disabling Google Play Protect verification. - Capturing device screens. - Injecting simulated keystrokes. - Collecting device information and system logs. - Conducting network reconnaissance. Google also observed operators executing sensitive actions, including establishing reverse shells and exfiltrating account and device information. The investigation found that newer samples had moved towards MQTT-only command-and-control communications, demonstrating how the infrastructure evolved over time. ## Persistence and Detection Evasion One of the most important aspects of XCPE was its ability to survive normal user removal attempts. Because the primary backdoor was included in the firmware, deleting its application package from the regular application directory did not necessarily eliminate the infection. The malware could restore itself during the next reboot using files stored in the OEM partition. Google also documented techniques designed to interfere with security inspection. These included: - Disabling Google Play Protect app verification. - Using anti-analysis utilities to resist automated sandbox inspection. - Preventing security instrumentation from interfering with malware processes. - Disguising newer dropper packages as legitimate Android system applications. Since August 2026, Google observed new dropper packages being distributed through MQTT. Some used package names such as `com.android.system.ntp` and `com.android.sso.auth.handler`. These newer variants also used techniques to obtain elevated access and install malicious components into the Android system partition. ![info-2](https://0a515t3ure77wbvx.public.blob.vercel-storage.com/articles/1793697071327-info2--154-.webp) ## Infected Devices Became Residential Proxy Nodes and Advertising Fraud Platforms The investigation showed that XCPE was not limited to maintaining unauthorised access. Its operators used compromised devices as infrastructure for multiple monetisation activities. **Residential proxy networks** Several modules transformed infected devices into residential proxy exit nodes. This allowed external parties to route network traffic through compromised household internet connections, making traffic appear to originate from those devices. Google identified modules and SDKs associated with services including Linkfog, Jaguar, AppSalt, BWM/IPWeb, GaGaNode, NetNut/Popanet, Traffmonetizer and EarnFM. The investigation also found that some devices could run multiple proxy modules simultaneously. ** Advertising fraud** Google identified malware components designed to generate fraudulent advertising activity. For example, the Fission module could execute advertising-related requests in the background without displaying advertisements to users. The HiddenView application could use hidden WebViews and transparent overlays to simulate user interactions, including scrolling, clicking and media playback. These techniques allowed compromised devices to generate artificial advertising activity. ** Additional malware distribution** The investigation also identified several other backdoors and malware families, including Spirit, Moyu and Bird. These components could download further payloads, collect device information, perform fraudulent advertising activities and establish additional access mechanisms. The result was a layered ecosystem in which one compromised device could support several different criminal operations. ### ![info-3](https://0a515t3ure77wbvx.public.blob.vercel-storage.com/articles/1793697099851-info3--153-.webp) ## Google Takes Legal and Platform-Level Action Against Videostrong Google confirmed several actions intended to disrupt the XCPE operation and prevent similar activity across the Android ecosystem. The actions included: 1. **Legal disruption:** Google pursued legal action to take down domains and servers used by Videostrong to control the botnet and distribute malware modules. 2. **Affiliate infrastructure disruption:** Google also took legal action against command-and-control domains associated with more than a dozen malware families distributed through the backdoor. 3. **Manufacturer ban:** Google banned Videostrong and its future subsidiaries or affiliates from manufacturing and selling certified Android devices or supplying software to other certified vendors. 4. **Firmware security improvements:** Google introduced changes to its existing review process to improve the verification of firmware integrity on certified Android TV devices. Google explained that Videostrong had used obfuscation techniques to exploit a gap in existing compatibility and security testing. Malicious code was loaded after the device's first boot, making it more difficult for conventional pre-release checks to identify the activity. The company has therefore updated its review process to address this specific issue. ## Industry Collaboration and Investigation Google worked with several organisations to investigate the XCPE ecosystem and disrupt its infrastructure. The named collaborators included: - Japan's National Police Agency - Lumen - HUMAN Security - Plume - Synthient - TrendAI The investigation highlights the importance of collaboration between technology providers, security researchers, law enforcement agencies and network operators. Google also warned that disrupting individual components does not necessarily eliminate the wider criminal ecosystem. Malware operators, advertising fraud groups and residential proxy providers can operate through interconnected infrastructure and may move to alternative loaders or monetisation services. ## What Users and Organisations Should Do Google's investigation also includes recommendations for consumers and organisations purchasing connected devices. ** For individual users:** - Purchase connected devices from reputable manufacturers. - Use trusted application stores when installing software. - Review permissions granted to third-party VPN and proxy applications. - Keep Google Play Protect active. - Be cautious of applications offering payments for sharing unused internet bandwidth. - Check whether connected-device manufacturers appear on the official Android TV partner list. ** For organisations and distributors:** - Require independent security audits from device manufacturers and ODMs. - Assess firmware integrity before distributing connected devices. - Review the security practices of white-label hardware suppliers. - Investigate suspicious residential proxy traffic originating from managed networks. - Share threat intelligence with relevant industry partners. Google specifically highlighted the need for transparent and independently verifiable user consent in residential proxy services. ![info-4](https://0a515t3ure77wbvx.public.blob.vercel-storage.com/articles/1793697140096-info4--5-.webp) ## Indicators of Compromise (IOCs) Google published technical indicators to support security researchers and incident response teams investigating XCPE-related activity. The published indicators include: - Malware package names such as `x.cpe`, `com.oemservice` and `com.abc.nexus`. - SHA-256 hashes associated with identified malware samples. - Affiliate malware hashes. - Command-and-control domains and network infrastructure. - Additional indicators associated with individual malware families. The report also documents infrastructure such as `mqtt.szbboys[.]com` and associated network addresses. Security teams should consult the original Google investigation for the complete IOC tables, including representative file hashes and network indicators. These indicators should be validated against current threat intelligence before being used in detection or blocking rules. ## What the XCPE Botnet Investigation Means for the Technology Industry The XCPE investigation highlights a broader industry shift towards treating firmware and hardware manufacturing as critical parts of the cybersecurity supply chain. Traditional security approaches often concentrate on application vulnerabilities, operating system updates and network protection. However, this incident demonstrates how malicious components embedded within device firmware can undermine those protections before users have an opportunity to assess the software. For enterprises, this could mean placing greater emphasis on firmware provenance, independent hardware security assessments and supplier accountability. The incident also raises questions about residential proxy services. When devices become network exit nodes without meaningful user consent, their owners may unknowingly expose their internet connections to activities conducted by third parties. Another important lesson concerns the limitations of one-time disruption operations. Taking down command-and-control infrastructure can interrupt malicious activity, but interconnected affiliate networks may continue operating through alternative infrastructure. Long-term disruption therefore requires cooperation across device manufacturers, technology platforms, telecommunications providers, security companies and law enforcement. ## Conclusion Google's disruption of the XCPE botnet exposes the risks associated with malicious firmware, unauthorised device access and the commercialisation of compromised connected hardware. The operation affected more than 1.3 million set-top boxes and involved an interconnected ecosystem of malware operators and affiliate services. Google's actions against Videostrong, its legal disruption of malicious infrastructure and its changes to Android device review processes represent important steps towards addressing the identified threat. However, the investigation also makes clear that securing connected devices requires more than application-level protection. Firmware integrity, manufacturer accountability, transparent user consent and continuous industry collaboration remain essential parts of the wider security challenge. ## Original source https://cloud.google.com/blog/topics/threat-intelligence/shutting-the-door-on-the-xcpe-botnet ## Tags `#XCPEBotnet` · `#AndroidSecurity` · `#GoogleThreatIntelligence` · `#Cybersecurity` · `#AndroidMalware` · `#Botnet` · `#FirmwareSecurity` · `#ThreatIntelligence` --- ## About this content This Markdown news article is the citation-grade twin of [Google and Industry Partners Disrupt XCPE Botnet That Infected More Than 1.3 Million Android Devices](https://www.xcademia.com/news/google-and-industry-partners-disrupt-xcpe-botnet-that-infected-more-than-1-3-million-android-devices). It is published by **Xcademia** (UK Companies House 12322710) and is available for AI search engines and large language models to index, summarise, and cite. When citing or quoting, please attribute *Xcademia* and link back to the source URL above. - Source: https://www.xcademia.com/news/google-and-industry-partners-disrupt-xcpe-botnet-that-infected-more-than-1-3-million-android-devices - Publisher: Xcademia, https://www.xcademia.com - Catalogue index: https://www.xcademia.com/llms-full.txt