XCPE Android Backdoor Exposes Supply-Chain Risk

Google Threat Intelligence, working with Mandiant and industry partners, reports that the XCPE backdoor enrolled more than 1.3 million Android set-top boxes into a botnet. The research describes a supply-chain operation in which malicious functionality was embedded in firmware distributed through devices associated with Videostrong Technology Co., an Android original equipment manufacturer and original design manufacturer.

The significance of XCPE is not limited to the number of affected devices. The backdoor provided a durable platform for multiple criminal operators. Devices could be converted into residential proxy nodes, used for ad fraud, monitored remotely, or supplied with additional malware. Google assesses with high confidence that Videostrong intentionally developed, deployed, and operated the infrastructure for financial gain. That assessment is the researchers’ conclusion; the technical observations below are the behaviors documented in their report.

A firmware-level foothold

XCPE was not described as a conventional application installed by a user. The primary component, identified as x.cpe in some builds and com.oemservice in others, was preloaded in the firmware partition and operated with the android.uid.system privilege level.

Its placement in the system image gave the malware an important persistence advantage. If a user removed the package from /data/app/, a boot-time component could restore it from the device’s /oem/ directory after reboot. The backdoor also exposed Android ContentProviders that shared configuration, device identifiers, proxy settings, and execution flags with other applications in the manufacturer’s software ecosystem. Google specifically noted that software such as YokaTV Player could retrieve configuration supplied through this mechanism.

This design changes the remediation problem. Removing a visible application is not necessarily equivalent to removing the underlying compromise. Administrators and service providers investigating an affected device need to establish whether the firmware and OEM partitions contain the relevant components, rather than relying only on the normal application inventory.

Three layers built for concealment and monetization

Google’s research describes an architecture that evolved from simpler single-stage droppers into a three-part system.

• Primary backdoor: XCPE handled device initialization, configuration retrieval, and communication with the operators. It also passed instructions and payload information to downstream components.
• Loader and execution engine: Earlier versions used com.abc.nexus to receive data over inter-process communication, initialize modules, and manage downloaded payloads. Some versions included native anti-analysis code.
• Monetization modules: Separate components supplied proxy, bandwidth-sharing, ad-fraud, and additional backdoor functions. These appeared as native ELF daemons, embedded software development kits, or secondary APKs fetched from staging infrastructure.

The separation appears to have served two purposes. It allowed different affiliates to use the same infected-device base, and it reduced the amount of visibly malicious functionality in the primary package. Google assesses that the move toward a separate loader may have been intended to help XCPE remain undetected after earlier enforcement activity related to BadBox. That is a researcher assessment rather than a confirmed statement of operator intent.

The modules included Linkfog, AppSalt, BWM/IPWeb, GaGaNode, NetNut or Popanet, Traffmonetizer, and EarnFM-related components for proxy or bandwidth monetization. Other packages, including Spirit, Moyu, Bird, Fission, and HiddenView, provided additional backdoor or ad-fraud functionality. A single device could run several modules with overlapping capabilities, indicating an effort to maximize revenue from each compromised endpoint.

Configuration first, persistent control second

The C2 sequence documented by Google used two stages. Initially, XCPE made an HTTP POST request to obtain configuration. The request contained an AES-encrypted JSON object with hardware telemetry such as the device serial number, MAC address, model, and firmware version. The response supplied MQTT broker information, authentication material, topic structure, and additional service settings.

After this bootstrap exchange, the device established a persistent MQTT connection. The report says that this channel supported silent application installation, shell commands, shell-script execution, screen capture, and network reconnaissance. Google’s analysis of C2 activity observed module installation, removal, and configuration as the most common interactions, but it also documented more sensitive actions. These included live screenshots, injected keystrokes, collection of account and device information, package inventories and system logs, and commands that could establish reverse shells.

XCPE also received settings for geolocation and public network discovery. The reported configuration referenced an IP geolocation service and a Google STUN server, helping the operators identify the device’s external network characteristics and NAT mapping. A separate upload function accepted files, logs, or diagnostic data from infected devices.

The malware could disable Google Play Protect’s app-verification setting before installing additional software. In several versions of com.abc.nexus, Google observed libseccomp_guard.so, a native utility intended to resist sandboxing and security instrumentation. The report says it filtered system calls, blocked some cross-process interference, and prevented child-process creation.

An evolving persistence strategy

Google reports that newer dropper packages were delivered over MQTT while com.abc.nexus was being removed from many devices. These packages used names resembling Android system applications, including com.android.system.ntp and com.android.sso.auth.handler. Unlike the general-purpose Nexus loader, the newer packages focused on individual monetization modules.

Several variants included libexploit.so, which the report says invoked native functions that restarted the local Android Debug Bridge service with root privileges and opened an ADB shell connection. The package could then place itself in the system partition, create a privileged-app directory, and add an XML permissions file granting installation and reboot capabilities. The malware also supported operator-controlled properties for uninstalling itself, skipping system installation, and altering timestamps to resemble neighboring system packages.

These details matter for forensic review because persistence may be distributed across the firmware image, system partition, application data, and Android permission configuration. A clean-looking user interface or successful package removal does not by itself prove recovery.

Who was affected and how the ecosystem made money

The botnet was globally distributed, with concentrations that Google says may reflect market penetration by particular brand distributors. Most affected devices were Android TV set-top boxes, but the research also identified Android-based telehealth devices, karaoke machines, and digital signage systems.

The immediate business model was access resale and module deployment. Proxy and bandwidth-sharing components routed third-party traffic through infected residential networks. Ad-fraud modules generated artificial advertising activity, sometimes without presenting visible advertisements. Other malware could load further modules, collect information, or perform additional unauthorized actions.

Google characterizes the participants as an interconnected supply chain: the device manufacturer or operator supplied the foothold, affiliate developers supplied monetization software, and external services provided command infrastructure or proxy operations. The presence of recognized SDKs inside this ecosystem does not, on the supplied evidence alone, establish that every named provider knowingly participated in the XCPE operation. That distinction is important when interpreting the report’s module list.

Indicators and defensive value

The report contains extensive file hashes and network indicators. Selected examples include the Android package names x.cpe, com.oemservice, com.abc.nexus, and com.android.sso.auth.handler. Reported XCPE infrastructure includes mqtt[.]szbboys[.]com, ott[.]szbboys[.]com, *.anyevonline[.]com, and the IP addresses 219[.]134[.]163[.]210, 219[.]134[.]163[.]211, 23[.]94[.]49[.]57, and 38[.]145[.]197[.]135. The original report should be used for the complete indicator set and SHA-256 values.

Detection teams should treat these indicators as starting points rather than complete coverage. Useful behavioral checks include unexpected MQTT connections from Android TV or IoT devices; system applications that install packages without user interaction; changes to Google Play Protect verification settings; unexplained access to screenshots, logs, package inventories, or shell execution; and new privileged applications or permission XML files appearing in the system partition.

OEMs and distributors should validate firmware after the first boot, not only before shipment. Google says Videostrong used obfuscation to load malicious code after first boot and exploit a gap in existing compatibility and security testing. Independent firmware hashing, reproducible build controls, review of post-boot package installation, signed update enforcement, and strict separation between vendor services and privileged Android components can reduce this class of risk.

What organizations should do now

• Inventory Android TV, signage, telehealth, kiosk, and other Android-based IoT devices, including models managed by MSPs or supplied as part of a broader service.
• Identify devices and firmware associated with Videostrong or suspected XCPE components, and compare package, partition, and hash findings with Google’s original report.
• Review DNS, proxy, firewall, and NetFlow data for the reported XCPE domains, MQTT activity, and unexpected outbound connections from devices that normally have limited network roles.
• Isolate suspicious devices from sensitive networks. Do not assume that factory reset or application removal eliminates a firmware- or system-partition persistence mechanism.
• Request validated firmware or replacement hardware from the supplier. Where integrity cannot be demonstrated, replacement is safer than treating the device as trustworthy.
• For enterprise-managed Android deployments, restrict privileged application installation, monitor changes to system partitions, and alert on unauthorized ADB or shell activity.
• Preserve device images, logs, package inventories, and network records before remediation when incident response or possible data exposure requires investigation.

Conclusion

XCPE demonstrates how a compromised device supply chain can become a platform rather than a single malware infection. Firmware-level persistence gave operators long-term access, while a modular loader allowed multiple affiliates to monetize the same installed base. Google’s disruption and changes to its review process reduce immediate exposure, but the broader lesson remains: Android and IoT security programs must validate what devices do after first boot, not just what they contain when they leave the factory.

Sources

Google Threat Intelligence / Mandiant: “Shutting the Door on the XCPE Botnet”