A Backdoor Sat in the Firmware Partition of 1.3 Million Set-Top Boxes
Google and its partners dismantled XCPE, a backdoor built into set-top box firmware at system privilege, and attributes it to the manufacturer Videostrong.
TL;DR
- A botnet is a network of compromised devices that a remote operator controls, usually to rent out the devices or to run fraud at someone else's expense.
- On 2 November 2026 Google Threat Intelligence Group disclosed that Google and its partners dismantled XCPE, a backdoor that enrolled more than 1.3 million Android set-top boxes, and attributed it with high confidence to Videostrong Technology, an Android OEM and ODM.
- The backdoor sat in the firmware partition at
android.uid.systemprivilege, reinstalled itself from the/oem/partition when a user removed it, and handed module execution to a loader calledcom.abc.nexus. - Command and control runs in two stages: an HTTP POST that returns configuration, then a persistent MQTT connection to a broker that delivers app installs, shell commands, screen captures and network reconnaissance.
- Affiliates bought a place on the device and loaded their own business models: residential proxy exit nodes such as Linkfog, AppSalt and NetNut, ad-fraud engines such as CBOXTV and HiddenView, and further backdoors.
- The disruption cut off control domains, took down command servers used by more than a dozen affiliate malware families, and barred the vendor from certified Android devices; Google assesses it severs access to at least 10 million additional compromised devices.
- A television box in a shop or an office that nobody inventories is an inventory problem, because firmware shipped in the factory cannot be patched remotely.
- Detection leans on egress: look for long-lived MQTT sessions from devices that have no business holding one, and for downloads staged from operator-owned repositories.

On 2 November 2026 Google Threat Intelligence Group published Shutting the Door on the XCPE Botnet, with the disclosure that Google and industry partners had dismantled a backdoor enrolled on more than 1.3 million set-top boxes. The attribution is the part that changes how the story should be read: the researchers assess with high confidence that the malware was developed, deployed and operated for financial gain by Videostrong Technology, an Android original equipment and original design manufacturer.
Videostrong built the backdoor into the firmware partition
The malicious software arrived preinstalled, across many device models and brands, built directly into firmware over multiple years. Google found dedicated infrastructure, evolving configurations and tools for managing affiliates, and assessed with high confidence that Videostrong intentionally developed, deployed and operated the backdoor and botnet for financial gain. Its response was to cut ties with Videostrong and ban the company from making devices with preloaded Google apps.
Google's own account of how the code got past certification is worth reading twice. Certified Android devices pass a suite of compatibility and security tests, and the vendor used obfuscation to exploit a gap in those tests, loading malicious code after the device's first boot. Review processes changed as a result. For anyone who buys devices on the strength of a certification mark, this is the uncomfortable lesson: certification covers the tested state, and the vendor retains control over code loaded after first boot.

The stub runs at system privilege and hands execution to a loader
Three stages are documented, and the first one explains why removal fails. A stub package, shipped as x.cpe in some builds and com.oemservice in others, sits in the system partition and runs at android.uid.system privilege. On boot it checks the oem/ directory, installs the corresponding x.cpe package into /data/app/ and reinstalls itself after any user uninstall, which makes the device's own settings screen an unreliable place to look for the truth.
Stage two offloads the work. The backdoor acts mainly as the command-and-control communicator and passes module execution to com.abc.nexus, a file that carries native anti-analysis utilities to defeat sandbox detection and configures the monetisation modules. Since August 2026 that loader has been phased out in favour of tailored droppers that install a single module, delivered through the same command channel. Stage three is the modules themselves, arriving as native ELF daemons, as SDKs compiled into the loader's bytecode, or as secondary APKs fetched remotely. Google says a significant majority of the staging files—modules, shell scripts and legitimate applications—were hosted as GitHub releases on operator-owned GitHub pages.

The command channel is an MQTT broker on the public internet
The command channel starts with HTTP and then moves to MQTT. The malware first sends an HTTP POST with an AES-encrypted JSON payload of hardware telemetry, serial number, MAC address, model and firmware version, to an operator host whose name is derived from the device's Android version and type. The response supplies MQTT broker details, including hostname, port, authentication token and the topic structure /device/{model}/{chipId}/{action}. From then on the device holds a persistent MQTT session, and MQTT is a publish-and-subscribe protocol built for low-bandwidth and unreliable networks, which describes consumer hardware well.
The same bootstrap returns geolocation and STUN parameters so the device can find its public address and traverse NAT, a file-upload URL for logs and diagnostic dumps, and switches for individual advertising modules. All samples analysed to that point used a single broker hostname, mqtt.szbboys[.]com. Command traffic that looks like ordinary telemetry and a broker reachable over the public internet describe a detection problem that lives in network logs, where most small organisations look last.
The affiliates paid for a place on the device and brought their own business models
The economic design is a rented shop window. Videostrong sold backdoor access to criminal affiliates, and the loaded modules turn the box into a residential proxy exit node, an ad-fraud engine, or a host for further backdoors. The named SDKs are specific: Linkfog, AppSalt and NetNut among the proxy networks, CBOXTV and HiddenView among the ad-fraud engines, Moyu and Spirit among the backdoors that load more modules. AppSalt is the residential proxy SDK owned by Honeygain, which is owned by Oxylabs, a detail that shows how ordinary the corporate chains behind these modules look.
Greed shows in the stacking. A single device can run several modules with the same function, and the researchers report as many as three residential proxy SDKs installed on one device. A compromised box becomes a metered egress point for someone else's traffic, with the household or office IP address carrying the reputation damage.

The partner list behind the disruption reads like a cross-section of the industry: Japan's National Police Agency, Lumen, HUMAN Security, Plume, Synthient and TrendAI.
A device that cannot be patched is an inventory problem
This story turns firmware provenance into an inventory problem. A new image can fix a kernel or container flaw on every host that rebuilds. This backdoor was compiled into the firmware partition of devices already deployed in living rooms; the vendor is barred from certification and the hardware remains in the field.
Google's disruption made three moves worth noting for any operator. It took legal action against the domains and servers used to control the botnet and to install modules. It took legal action against command domains used by more than a dozen affiliate malware families, which the researchers assess severs access to at least 10 million additional compromised devices, since those affiliates distribute through other channels too. And it changed how firmware integrity is verified on certified Android TV devices.
Devices keep reporting while the broker answers, so the distribution below shows where the installed base sits.

The operator's version of that work starts with a list. Which Android boxes, signage players, conference-room dongles and kiosk displays are on the network, who bought them, which vendor built the firmware and whether that vendor still exists in a position to ship updates. Most small estates cannot answer the last question, and that gap is the exposure this campaign exploits.
What the disruption cut off, and what stays exposed
Google cut off command infrastructure and tightened firmware verification. Google took legal action to take down the domains, affiliate command servers are down, a manufacturer is out of the certified programme, and Google says it tightened firmware verification. A box already installed retains its backdoor. The researchers are explicit that the illicit market is resilient, with operators pivoting to new loaders or rival SDKs when a component is disrupted.
For a small organisation, the practical controls are unglamorous and cheap. Segment devices that need outbound internet from the rest of the network, deny egress to hosts nobody recognises, and watch for long-lived sessions to message brokers, which almost no television box needs. Prefer hardware whose firmware updates you can verify, and treat a bargain Android box from an unknown ODM as an untrusted endpoint with a screen attached. Prebuilt images carry their own provenance and inventory requirements. The earlier analysis of the Copy Fail container flaw argued from the software side; a full security audit and hardening is where an estate turns that reasoning into a list of devices it can defend.
“Backdoor operators, ad-fraud rings, and residential proxy providers operate as an interconnected supply chain.” The sentence closes the report, and it also describes the buying decision in front of any organisation refreshing its screens this quarter. The supply chain runs through the firmware partition, and the receipt is the only document most buyers keep.

Sources
- Shutting the Door on the XCPE Botnet, Google Threat Intelligence Group, cloud.google.com, 2026-11-02
- Copy Fail: container mitigation and Linux security, blog.neticslabs.com
Source: the Google Cloud Threat Intelligence post of 2 November 2026, read in full on 3 November 2026. The 1.3 million device figure, the Videostrong attribution, the 10 million additional devices assessment, the certification gap and obfuscation detail, the x.cpe and com.oemservice package names, the android.uid.system privilege, the /oem/ reinstall behaviour, the com.abc.nexus loader, the August 2026 dropper change, the HTTP bootstrap and MQTT channel with mqtt.szbboys[.]com, the named proxy, ad-fraud and backdoor modules, the three-proxy-SDK finding, the partner list and the legal actions all come from that post. The device-inventory recommendations are Netics analysis.