deniz.in

Markets

Weather

Loading weather

· via dev.to (home feed)

Google and partners dismantle XCPE firmware backdoor that enrolled 1.3 million set-top boxes

Google disclosed that the XCPE backdoor shipped inside the firmware of over 1.3 million Android set-top boxes, and attributes it to device maker Videostrong Technology; the takedown severs access to millions more devices.

Google and partners dismantle XCPE firmware backdoor that enrolled 1.3 million set-top boxes

Google's Threat Intelligence Group disclosed on 2 November 2026 that Google and a group of industry partners had dismantled XCPE, a backdoor that arrived preinstalled in the firmware of more than 1.3 million Android set-top boxes. According to a dev.to writeup of the Google post "Shutting the Door on the XCPE Botnet", the company assesses with high confidence that the malware was built, deployed and operated for profit by Videostrong Technology, an Android original equipment and original design manufacturer whose hardware shipped under many device models and brands over several years.

A backdoor that survives removal

The malware starts as a stub package — x.cpe in some builds, com.oemservice in others — placed in the system partition and running with android.uid.system privileges. On boot it checks the oem directory, installs a package into /data/app, and reinstalls itself whenever a user uninstalls it. The consequence, as the dev.to article notes, is that the device's own settings screen cannot be trusted to reveal whether the box is infected.

Execution of extra modules is delegated to a loader named com.abc.nexus, which bundles native tooling to evade sandbox analysis and configures the monetisation components. Since August 2026, Google found, the loader has been phased out in favour of tailored droppers that each install a single module over the same command channel. The modules themselves arrive as native ELF daemons, as SDKs compiled into the loader's bytecode, or as secondary APKs fetched remotely, with a large majority of staging files hosted as GitHub releases on operator-run GitHub pages.

Command and control over MQTT

The control channel works in two steps. The infected device first sends an HTTP POST carrying an AES-encrypted JSON payload — hardware telemetry, serial number, MAC address, model and firmware version — to a host whose name is derived from the device's Android version and type. The response returns MQTT broker details: hostname, port, an authentication token and a topic structure of /device/{model}/{chipId}/{action}. From then on the box holds a persistent MQTT session, using a lightweight publish-subscribe protocol well suited to consumer hardware. Every sample analysed so far pointed to a single broker hostname, mqtt.szbboys[.]com. The same bootstrap response also returns geolocation and STUN parameters for NAT traversal, a file-upload URL for logs and diagnostics, and switches for individual advertising modules.

A platform rented to affiliates

According to Google's findings as reported on dev.to, Videostrong sold access to the infected devices, and criminal affiliates brought their own business models. Named components include residential proxy SDKs Linkfog, AppSalt and NetSalt alternatives AppSalt and NetNut, ad-fraud engines CBOXTV and HiddenView, and further backdoors named Moyu and Spirit. AppSalt belongs to Honeygain, which is in turn owned by Oxylabs — a reminder of how ordinary the corporate structures behind such modules can look. Google observed single devices running as many as three residential proxy SDKs simultaneously, turning a home or office IP address into an exit point for someone else's traffic, with the owner absorbing the reputational fallout.

The takedown

The disruption cut off the control domains and took down command servers used by more than a dozen affiliate malware families. Google also ended its relationship with Videostrong, barring the company from certified Android devices with preloaded Google apps, and assesses that the operation severs access to at least 10 million additional compromised devices. Partners credited alongside Google include Japan's National Police Agency, Lumen, HUMAN Security, Plume, Synthient and TrendAI.

Google's own account of how the code reached certified hardware is the detail buyers should dwell on: the vendor reportedly used obfuscation to exploit a gap in Android's compatibility and security tests, loading malicious code after a device's first boot. Certification covered only the tested state, and review processes have since changed.

Why it matters

This is one of the largest disclosed compromises of consumer hardware, and it was allegedly carried out by the manufacturer itself rather than an outside attacker. It exposes a structural weakness in device certification: testing verifies a snapshot, while the vendor retains the ability to load code afterwards. The detection guidance that follows is egress-focused — flag long-lived MQTT sessions on devices that have no business holding them, and watch for downloads staged from operator-run repositories. Because the backdoor lives in the firmware partition of boxes that rarely get inventoried, it cannot be patched remotely; anyone running Android TV hardware of uncertain provenance should treat those devices as untrusted until they are replaced.

  • #botnet
  • #malware
  • #android
  • #security
  • #firmware

Related posts