When the Manufacturer Is the Adversary: XCPE and Supply-Chain Trust

Key Takeaways

On November 2, 2026, the Google Threat Intelligence Group (GTIG) disclosed that it had disrupted XCPE, a botnet of more than 1.3 million Android set-top boxes. Google assessed “with high confidence” that the backdoor was “intentionally developed, deployed, and operated for financial gain” by the device’s own manufacturer, Shenzhen-based OEM/ODM Videostrong Technology Co. [1]. The case differs from most supply-chain compromises in one important way. GTIG assesses that the malicious code was not inserted by a third party or introduced by vendor error, but was deliberately built and operated by the manufacturer itself, which used obfuscation to exploit a gap in certification testing [1]. As of publication, Videostrong had not publicly responded to the findings [2][3].

The first lesson is that certification tests the image it is shown, not what a vendor does later. According to GTIG, Videostrong used obfuscation to “exploit a gap” in Google’s compatibility and security tests and to load malicious code after the device’s first boot [1]. Device certification remains a useful filter, but it cannot be the only control when the certified party is hostile. A second lesson follows from how the botnet persists: the takedown cut off command and control, but it did not clean the devices. XCPE reinstalls itself from a firmware partition the owner cannot modify, so getting rid of it requires clean firmware, and without that the only safe option is to take the device off the network [1][3].

The exposure also goes well beyond consumer TV boxes. Investigators found the same malware in telehealth devices, karaoke machines and digital signage [1][2]. Separately, GTIG assesses that taking down affiliates’ C2 domains will sever access to at least 10 million additional compromised devices [1]; according to BleepingComputer, those devices were compromised through malware distributed by means other than XCPE, and not all of them are Android devices [3]. For enterprises, the practical conclusion is that any network an infected device sits on should be treated as compromised. XCPE supports reverse shells, silent APK installation, screen capture and keystroke injection, and it runs residential-proxy SDKs that send strangers’ traffic out through the victim’s IP address [1].

Background

The XCPE Disclosure

GTIG and its partners took down XCPE’s command-and-control (C2) infrastructure in late October 2026 and published technical details on November 2 [1]. The partners were Japan’s National Police Agency, Lumen, HUMAN Security, Plume, Synthient and TrendAI [1][3]. The botnet takes its name from x.cpe, the core backdoor package. Google said it found this software “built directly into many different device models and brands over multiple years” [1]. Videostrong makes Android TV boxes under its own name and for other brands. MECOOL is a Videostrong brand [4]. Synthient found the backdoor preinstalled on a MECOOL KM9PRO Max box and reported that Videostrong’s domain shared an IP address with C2 infrastructure and that company email addresses were used to sign backdoor components [3]. Synthient’s Ben Brundage called the 1.3 million device count “highly conservative” [2].

Google took several steps against Videostrong. It ended its relationship with the company, revoked its license to ship devices with preloaded Google apps and services, and barred Videostrong and any future subsidiaries or affiliates from building or selling certified Android devices or supplying software to certified vendors [1][3]. Google also said it had changed its OEM review process and improved “how we ensure the integrity of firmware on certified Android TV devices” [1]. Google’s account says the malicious code was built to get past its certification testing, and Google responded by tightening controls for certified devices. Read together, these statements suggest that at least some affected builds made it into the certified device pipeline, although Google has not published a list of affected brands, models or certification status.

How XCPE Worked

GTIG describes a design that changed over several years from simple droppers into “a modular, three-stage architecture designed for resilience and multi-tenant monetization” [1]. A stub package sits in the firmware’s system partition and runs with android.uid.system privileges. On boot it installs x.cpe from the device’s oem/ directory into user-writable application storage. If the user uninstalls x.cpe, a boot receiver puts it back on the next restart [1]. Recent samples talk to their C2 only over MQTT, using a broker on non-standard ports. Operators can install APKs silently, run arbitrary shell commands and scripts, capture the screen, inject keystrokes and scan the local network, and GTIG saw them open reverse shells on devices [1]. Before loading anything else, the backdoor wipes the user-consent configuration and turns off Google Play Protect. A seccomp-based guard library makes the malicious processes harder to stop or inspect [1].

Monetization worked like a platform business. A loader component, com.abc.nexus, set up modules supplied by affiliates who paid Videostrong for access to its installed base. The modules came as native daemons, embedded SDKs or secondary APKs, downloaded from public hosting that included GitHub releases [1]. GTIG names more than a dozen modules. They include residential-proxy and bandwidth-sharing SDKs linked to Linkfog, Jaguar, AppSalt/Honeygain, BWM/IPWeb, GaGaNode, NetNut/Popa, Traffmonetizer and EarnFM, along with the ad-fraud and loader backdoors Spirit, Moyu, Bird, Fission and HiddenView. Moyu and Bird were previously associated with the BadBox operation [1]. GTIG observed as many as three residential-proxy SDKs on a single device, and it concluded that “silent opt-in without user consent remains the most prevalent means by which devices are turned into exit nodes” [1].

The operator responded to earlier enforcement. GTIG reports that in late 2024 Videostrong moved its malicious modules out of x.cpe and into com.abc.nexus, “possibly as a response to earlier Google enforcement related to BadBox.” In August 2026 new droppers appeared under system-app names such as com.android.system.ntp and com.android.sso.auth.handler. GTIG reports that they were installed via the MQTT channel and appeared to be synchronized with the mass uninstallation of com.abc.nexus, and that they used an exploit library to restart adbd as root, remount the system partition read-write and install themselves as privileged apps [1]. This sequence suggests a manufacturer that watched how defenders reacted and changed its approach to keep its access.

How XCPE Fits With Earlier Device-Supply-Chain Botnets

XCPE belongs to a series of related operations. In March 2025, HUMAN’s Satori team reported BADBOX 2.0, which it said had infected more than one million devices [5]. In June 2025, the FBI warned that home internet-connected devices, some compromised before purchase, were being enlisted as residential proxies. The FBI listed devices that are not Google Play Protect certified as one warning sign [6]. In July 2025, Google sued 25 unnamed operators of the BadBox 2.0 enterprise in federal court [7]. In July 2026, Google, the FBI and industry partners disrupted the NetNut/Popa residential proxy network, which Google tied to plugin components for botnets including BadBox 2.0 [8]. The table below compares XCPE with BADBOX 2.0 on the points that matter most for supply-chain trust.

Security Analysis

The Trust Model Breaks at Its Root

Supply-chain risk programs tend to treat the manufacturer as a party that may be careless or may itself be compromised, rather than as one that is hostile. NIST SP 800-161r1 explicitly identifies malicious insertion by suppliers as a supply-chain risk [9]. Yet many procurement controls in common use, such as vendor attestations, third-party certifications and self-reported compliance, depend largely on the vendor’s own good-faith participation. XCPE shows how that dependence fails. According to GTIG’s assessment, the party that writes the firmware, controls the signing keys, runs the update infrastructure and goes through certification was also the adversary [1]. Each control that depends on the vendor’s own statements becomes another place the vendor can deceive.

Certification programs are especially exposed to this. Compatibility and security test suites check a device image at a point in time, often under conditions the manufacturer can anticipate. A manufacturer that controls what happens after first boot can ship a clean-looking image, pass the tests and then fetch its payloads from the network. GTIG’s statement that Videostrong “employed obfuscation techniques to exploit a gap in our tests and load malicious code after the device’s first boot” describes exactly this pattern [1]. Google says it has closed that gap. The broader conclusion is that a test passed at one point in time does not, on its own, establish trustworthy later behavior when the certified party controls what code is loaded at runtime. This applies equally to the labeling and conformity schemes now being built, including the FCC’s Cyber Trust Mark and the EU Cyber Resilience Act. Both rely on manufacturer participation and lab testing, so their value against a hostile manufacturer will depend largely on how strong their post-market surveillance and enforcement turn out to be [10][11].

The case also complicates guidance given to buyers. After BADBOX 2.0, a common recommendation was to buy only Play Protect-certified devices [6], and Google’s XCPE report still points consumers to its certified partner list [1]. That advice remains sound, because certification raises the cost of abuse, and Google has now acted against a certified-channel supplier. But XCPE makes clear that certification is one control among several and cannot by itself justify trusting a device.

Enterprise Exposure

Organizations may think of TV boxes as a consumer problem. XCPE’s reach suggests otherwise. Investigators found the malware in telehealth devices and digital signage systems [1][2]. These device categories are common in clinics, retail locations, lobbies and conference rooms, and in many organizations they are purchased by facilities or marketing teams outside IT procurement. Whether affected models are present in a given enterprise will depend on brand and sourcing. Remote employees’ home networks are a second route. A backdoored streaming box on the same flat home network as a corporate laptop gives an operator an interactive foothold, network reconnaissance and the ability to install new tools whenever it likes [1]. The risk to a managed endpoint depends on its host controls, such as host firewalls, EDR and VPN; GTIG has not reported enterprise targeting through this route, but the capability is present.

The residential-proxy function adds a reputational and legal problem on top of the security one. Residential proxy networks carry account-takeover attempts, ad fraud and large-scale content scraping, including scraping for AI training data [2]. When an infected device sits on a corporate network, outsiders’ traffic leaves through the organization’s IP addresses. That can get the organization blocklisted, produce misleading fraud signals and attribute someone else’s activity to it. Some of the bundled proxy SDKs came from vendors that also sell through legitimate channels [1], which likely makes egress from these SDKs difficult to distinguish from traffic generated by consented apps.

Why Takedown Does Not Equal Remediation

Taking down C2 infrastructure reduces the immediate harm, but the backdoor is still on the devices. Infected units keep the system-partition stub, and the operator has a history of rebuilding: it moved modules into new packages after enforcement in 2024 and introduced root-exploiting droppers in 2026 [1]. Removing the infection completely requires clean firmware, and BleepingComputer’s reporting says that otherwise owners should disconnect the device [3]. For devices whose firmware comes only from the hostile manufacturer, clean firmware may never be available. In that case the realistic choice is to keep the device isolated permanently or to replace it. The table below summarizes how each layer of control fared against XCPE and what value each layer still offers.

Recommendations

Immediate Actions

Security teams should search their networks for the indicators GTIG published. These include connections to szbboys[.]com and its subdomains, MQTT traffic to TCP ports 3885–3887 on the listed broker addresses, HTTP POSTs to /router/config/* paths, and DNS lookups of the affiliate C2 domains in the report [1]. Any Android-based device in scope, including set-top boxes, signage players, kiosks, conference-room media devices and telehealth endpoints, should be inventoried and checked against those indicators. Devices that match should be disconnected or moved to an isolated segment with no internet access. They should not be “cleaned” in place, because the backdoor persists across reboot and uninstall [1][3]. Teams should also look for egress patterns typical of residential-proxy SDKs from any IoT or unmanaged segment, and should remind remote staff to keep work devices on networks separate from unmanaged streaming hardware.

Short-Term Mitigations

Over the next quarter, organizations should treat devices with manufacturer-controlled firmware as untrusted endpoints by default. Those devices should go on dedicated network segments with egress allowlists limited to the services they actually need. Because XCPE communicates over non-standard MQTT ports 3885–3887 [1], default-deny outbound policies on device segments would block its primary C2 channel. Procurement teams should add clauses that require disclosure of the ODM behind white-label products, provenance for preinstalled software, a software bill of materials covering system-partition packages, and a contractual right to receive clean firmware or replacement units if a supplier is implicated in deliberate abuse. Such clauses still depend on supplier cooperation, so their main value lies with non-hostile suppliers and in providing recourse after an incident. GTIG’s recommendation that retailers require independent security audits from ODMs and delist implicated manufacturers carries over directly to enterprise vendor-management programs [1]. Facilities and marketing teams that buy connected devices should go through the same intake process as IT.

Strategic Considerations

Over the longer term, threat models should include the possibility that the manufacturer itself is malicious, not only that a manufacturer might be careless or compromised. For high-assurance environments, three changes follow. Organizations should rely more on continuous behavioral monitoring and network-side observation than on one-time certification. Where the business case allows, they should favor platforms that support independent firmware verification or owner-controlled reflashing. They should also keep enough vendor diversity that banning one supplier does not take out an entire device fleet. Organizations that take part in standards and regulatory processes should press for post-market surveillance, revocation and enforcement in schemes such as the Cyber Trust Mark and the CRA [10][11]. XCPE suggests that, against a hostile manufacturer, these schemes’ effectiveness will depend largely on post-market surveillance and enforcement rather than on pre-market testing. Finally, GTIG urges that any proxy provider’s claims of “ethical sourcing” be backed by transparent, auditable proof of user consent [1]. Organizations that buy residential-proxy services, including for AI data collection, can enforce this by requiring such proof contractually. Demand for residential-proxy capacity was one of the main revenue streams that made Videostrong’s installed base profitable, alongside ad fraud [1].

CSA Resource Alignment

CSA’s Zero Trust Guidance for IoT (2025) provides an architectural approach directly applicable to XCPE [12]. Its five-step method categorizes devices by criticality, maps transaction flows, micro-segments devices and monitors them continuously. That approach assumes a device may already be compromised, and it covers firmware tampering, botnet enrollment and supply-chain verification as specific threat scenarios. Applying it to set-top boxes, signage players and conference-room media devices would limit both the reverse-shell foothold and the abuse of residential proxies that XCPE enables, whether or not the manufacturer can be trusted.

Zero Trust Guidance for Operational Resilience (2026) places supply-chain and third-party risk within enterprise resilience planning, including SBOM practices and removing single points of failure [13]. XCPE illustrates why that matters. When an entire device line has to be withdrawn because its manufacturer was banned, the organizations that recover fastest are the ones that already planned for losing a supplier and limited how much damage any one vendor’s products could do.

CSA’s Medical Devices in a Zero Trust Architecture (2023) applies the five-pillar Zero Trust Maturity Model to healthcare devices [14]. That guidance is directly relevant here, because XCPE malware was found in telehealth hardware. Healthcare delivery organizations should use its device-pillar and network-pillar controls on any Android-based patient-facing equipment and should not assume that a device’s regulatory or platform certification shows its firmware is trustworthy.

The AI Controls Matrix (AICM) v1.1 provides the governance controls [15]. Its Supply Chain Management, Transparency, and Accountability (STA) domain covers supplier risk assessment, contractual security requirements and provenance. Its Threat and Vulnerability Management and Infrastructure Security domains support the detection and segmentation steps recommended above. Organizations that use AICM to evaluate vendors should add hostile-manufacturer scenarios to supplier assessments. That matters most for white-label hardware and for data-sourcing vendors whose collection pipelines may depend on residential-proxy networks.

References

[1] Google Threat Intelligence Group. “Shutting the Door on the XCPE Botnet.” Google Cloud Blog, November 2, 2026.

[2] Krebs, Brian. “Tech Firms Dismantle Botnet That Turned 1.3M TV Boxes Into Proxies.” KrebsOnSecurity, November 2, 2026.

[3] Abrams, Lawrence. “Google disrupts million-device XCPE Android malware botnet, bans TV box maker.” BleepingComputer, November 2, 2026.

[4] Messe Berlin. “Videostrong Technology Co., Ltd | Exhibitor profile.” IFA Berlin, accessed November 2026.

[5] HUMAN Security. “HUMAN Exposes BADBOX 2.0 Scheme.” HUMAN Security, March 5, 2025.

[6] Federal Bureau of Investigation. “Home Internet Connected Devices Facilitate Criminal Activity (I-060525-PSA).” Internet Crime Complaint Center, June 5, 2025.

[7] Lyons, Jessica. “Google sues 25 alleged BadBox 2.0 botnet operators, all of whom are in China.” The Register, July 18, 2025.

[8] Google Threat Intelligence Group. “Google’s Continued Disruption of Malicious Residential Proxy Networks.” Google Cloud Blog, July 2, 2026.

[9] National Institute of Standards and Technology. “SP 800-161 Rev. 1: Cybersecurity Supply Chain Risk Management Practices for Systems and Organizations.” NIST, May 2022.

[10] Federal Communications Commission. “U.S. Cyber Trust Mark.” FCC, accessed November 2026.

[11] European Union. “Regulation (EU) 2024/2847 (Cyber Resilience Act).” Official Journal of the European Union, November 2024.

[12] Cloud Security Alliance. “Zero Trust Guidance for IoT.” CSA Zero Trust Working Group, 2025.

[13] Cloud Security Alliance. “Zero Trust Guidance for Operational Resilience.” CSA Zero Trust Working Group, 2026.

[14] Cloud Security Alliance. “Medical Devices in a Zero Trust Architecture.” CSA, 2023.

[15] Cloud Security Alliance. “AI Controls Matrix v1.1.” CSA, 2025.