What happened
On 2 November 2026, Google Threat Intelligence Group said it and industry partners had disrupted the XCPE backdoor and botnet, which had enrolled more than 1.3 million set-top boxes. Google says the disruption severed access to at least 10 million additional compromised devices used by affiliate malware families, but it did not remove XCPE from already infected firmware. Google banned Videostrong and future subsidiaries or affiliates from building certified Android devices or supplying software to certified vendors.
Google says the XCPE architecture had evolved since at least late 2024 from single-stage droppers into a modular three-stage system. Google says x.cpe, also seen as com.oemservice, was preloaded in firmware, ran with android.uid.system privileges and reinstalled from the /oem/ partition after reboot if removed. The loader com.abc.nexus handled module execution, while x.cpe maintained command-and-control communications and passed configuration through inter-process communication. Google says new dropper packages appeared from August 2026, including com.android.system.ntp and com.android.sso.auth.handler.
Published XCPE infrastructure includes mqtt.szbboys[.]com, *.anyevonline[.]com, intermedia-arts[.]tv, ott.szbboys[.]com and yokatvonline[.]com; published IP addresses include 219.134.163[.]210, 219.134.163[.]211, 23.94.49[.]57 and 38.145.197[.]135. Google reports MQTT command traffic on ports 3885-3887 and operator-management activity on ports 8082, 8083 and 18083. Representative published SHA256 values include 3768f470934a111f1c3e3d098eb1392a3cb6f3e298ef5fd2a6309e6a98ee1e18 for x.cpe and 42be8f18d6006ca092de191331d38e70a0d8383db701a759466dec59a0986135 for libexploit.so. Google observed operators capturing screenshots, injecting keystrokes, exfiltrating account and device information, inventorying packages and logs, executing shell commands and establishing reverse shells.
Why this matters now
The disruption of command infrastructure does not clean devices whose backdoor is built into firmware and reinstalls after removal. An organisation may therefore see reduced malicious traffic while retaining a persistent system-level implant. Closure requires a device-level decision: validated clean firmware, permanent network isolation or physical replacement. Ordinary application uninstalling, endpoint scans and assumptions based on Android certification are insufficient.
XCPE turns low-cost consumer and embedded hardware into an enterprise supply-chain concern. Google found affected device classes beyond set-top boxes, including telehealth equipment and digital signage. These devices are often weakly inventoried, share networks with business systems and may display, process or observe sensitive information. Residential-proxy use can also make an enterprise’s public IP space appear to originate unrelated malicious traffic.
The attribution and Google ban change procurement posture. Security and sourcing teams should not limit review to the Videostrong name because an original design manufacturer can supply firmware and hardware to multiple front-facing brands. Supplier identity, firmware build provenance, update authority and the ability to re-image a device need to become acceptance criteria rather than post-incident questions.
The decision for security leaders
Treat this as a hardware and firmware supply-chain incident, not a conventional endpoint clean-up. Network engineering should identify candidate devices through traffic, package names and hashes, while procurement maps front-facing brands to their original manufacturer or firmware supplier. Any match should move to an isolated network until a clean-image or replacement decision is documented.
Require supplier evidence that reaches below certification badges and reseller assurances. Acceptable evidence should identify the OEM and ODM, firmware signer, build pipeline, update authority, shipped package inventory and a verifiable clean image. Where the supplier cannot produce those artefacts, replacement is the defensible outcome because the published persistence mechanism survives application removal and reboot.
Prioritise devices with access to clinical environments, meeting spaces, digital signage, guest networks, credentials or sensitive visual content. The same malware family supported screenshots, keystroke injection, data collection and reverse shells, but the evidence does not show that every capability ran on every infected device. Scoping should therefore combine indicator matches with local network and data-access context.
Evidence of closure
- Asset register identifying device brand, OEM, model, firmware, network and business owner.
- Negative enterprise-wide telemetry search against published XCPE infrastructure, packages and hashes.
- Verified clean-firmware provenance or approved physical-replacement record for every matched device.
- Supplier assurance package identifying firmware signer, build process and update authority.
The Security.io assessment
Attribution posture: Google assesses with high confidence that Videostrong Technology Co. intentionally developed, deployed and operated the XCPE backdoor and botnet for financial gain. Synthient independently describes evidence linking Videostrong personnel, domains and signed backdoors to the operation. This remains vendor and researcher attribution rather than a cited public judicial finding.
The cited sources did not publish a definitive model-level list of every affected branded device. That limitation materially complicates enterprise closure because original design manufacturers can supply multiple brands, and absence of a known retail name does not establish clean firmware. Asset discovery must therefore use manufacturer lineage, local telemetry, packages and hashes together.
The disruption is valuable but incomplete from an enterprise-risk perspective. Command infrastructure can be replaced, and the implant remains resident unless clean firmware is installed or the device is removed. Security.io therefore assesses that a negative traffic result after the takedown is not closure; organisations need evidence at the device, firmware and supplier levels.
Questions for the morning meeting
- Can the organisation identify the actual OEM behind every white-label Android device?
- Which unmanaged Android appliances can reach sensitive networks or display confidential information?
- Can suppliers prove firmware provenance and provide independently verifiable clean images?
- Which affected devices require replacement rather than remediation?