Dissecting the XCPE Botnet: Android OEM Firmware Backdoors

Supply-chain compromises operating at the silicon or firmware layer represent the most intractable threat model in modern computing. When the vector of infection is embedded during manufacturing, conventional endpoint detection and user vigilance are rendered largely ineffective. The discovery and subsequent dismantling of the xcpe botnet expose a systemic vulnerability in the Android Original Equipment Manufacturer (OEM) and Original Design Manufacturer (ODM) ecosystem. Developed and operated by Videostrong Technology Co., this multi-stage backdoor infected more than 1.3 million set-top boxes and Internet of Things (IoT) devices globally.

By embedding malicious capabilities directly into firmware partitions, the manufacturer transformed consumer hardware into a persistent infrastructure asset. The actors monetised this footprint by leasing access to criminal affiliates for ad-fraud, residential proxy networks, and secondary malware loading. According to Google Threat Intelligence and partner organisations including Japan’s National Police Agency, Lumen, HUMAN Security, Plume, Synthient, and TrendAI, the operation relied on sophisticated evasion techniques, low-bandwidth command-and-control (C2) protocols, and programmatic disabling of security verification mechanisms.

This analysis examines the architecture of the XCPE firmware compromise, detailing the progression from low-level system persistence and MQTT-based tasking to native root exploitation, ecosystem monetisation, and the regulatory sanctions levied against the manufacturer.

Architectural Overview of the XCPE Firmware Compromise

The XCPE campaign demonstrates a sophisticated approach to supply-chain monetisation, engineered for longevity and multi-tenant tasking. Scale estimates indicate that over 1.3 million devices—predominantly Android TV set-top boxes, alongside telehealth units, digital signage, and karaoke machines—were co-opted into the botnet. Videostrong Technology Co. leveraged its position as an OEM and ODM to bake malicious code directly into firmware images distributed to downstream brands and consumers.

Unlike conventional malware that relies on user interaction, social engineering, or exploitation of runtime vulnerabilities, the XCPE compromise relies on manufacturing-stage injection. Google requires OEMs to undergo rigorous compatibility and security evaluations. However, Videostrong employed obfuscation methods and staged execution patterns to bypass first-boot checks, deploying the active components only after the device reached the end user.

Once active, the infrastructure supported diversified revenue streams:

• Residential Proxy Networks: Enrolling infected devices as exit nodes to route third-party traffic, leveraging residential IP reputations.
• Ad-Fraud Engines: Executing background ad clicks and rendering invisible impressions via modules such as CBOXTV and HiddenView.
• Secondary Payload Delivery: Serving as a distribution tier to drop additional malware families onto compromised endpoints.

Affiliates leveraged these capabilities without needing independent distribution channels, while the operators maintained centralised control via dynamic C2 infrastructure.

Anatomy of the Primary Backdoor and System-Level Persistence

The core persistence mechanism relies on a stub package—identified as `x.cpe` in modern iterations and `com.oemservice` in legacy builds—preloaded directly within the read-only firmware partitions during manufacturing. Operating under the `android.uid.system` privilege level, this component possesses high-tier system capabilities that ordinary user-installed applications cannot access.

The persistence loop is designed to survive manual interference:

1. If a user or administrative script uninstalls the package from the `/data/app/` directory, the service remains resident in the immutable `/oem/` or `/system/` firmware partitions.
2. Upon system reboot, the initialization routine scans the firmware storage, extracts the package, and reinstalls it into `/data/app/`.
3. Inter-process communication (IPC) is managed via exported ContentProvider instances, notably structured configuration tables that store runtime parameters, device identifiers, and proxy configurations.

Co-installed legitimate applications and bundled streaming players (such as YokaTV Player) interact with these ContentProviders to retrieve operational parameters, tightly coupling the malicious telemetry stack with normal device operation.

Two-Stage Command-and-Control: HTTP Bootstrap and MQTT Telemetry

Network communications within the XCPE ecosystem are bifurcated into an initial HTTP bootstrap phase and a persistent, real-time Message Queuing Telemetry Transport (MQTT) control channel. This design balances the need for heavy payload retrieval with low-overhead, reliable instruction delivery.

The bootstrap routine dynamically derives its C2 endpoint by querying local configuration providers and system properties:

• It checks content://com.release.debug.provider/configs for the private_url parameter using x.cpe.util.ExtraReadUtils.
• It evaluates the Android system property ro.mecool.device. If true, it defaults to http://mcstb.anyevonline.com:8000. If false, it dynamically formats the string: http://stb[AndroidVersion][Type].anyevonline.com:8000.

The client then transmits an AES-encrypted JSON payload containing hardware telemetry (serial number, MAC address, model identifier, and firmware version) via HTTP POST to several dedicated configuration endpoints:

Following bootstrap, persistent tasking transitions to an MQTT connection directed at mqtt.szbboys[.]com. MQTT topics map directly to operational directives, enabling the operators to issue silent application installations, execute arbitrary shell scripts under system UID privileges, capture compressed JPEG screenshots via Java reflection on hidden APIs (`android.view.SurfaceControl.screenshot`), and perform network reconnaissance using embedded binaries like `libtraceroute.so`.

Execution Engines and Evasion: From com.abc.nexus to Native Root Exploits

The modular architecture of the malware evolved significantly over time to evade automated analysis and static security scans. Between late 2024 and mid-2026, the primary backdoor (`x.cpe`) decoupled its communication logic from its execution engine by routing instructions to an intermediary package designated `com.abc.nexus` via IPC.

com.abc.nexus acted as a general-purpose execution engine, unpacking embedded native ELF daemons and DEX bytecode modules while deploying native anti-analysis utilities such as `libseccomp_guard.so`. This utility intercepts system calls to prevent sandbox instrumentation, blocks thread termination attempts, and restricts process spawning.

Beginning in August 2026, the operators phased out `com.abc.nexus` in favour of tailored single-module droppers disguised as core Android system components, such as `com.android.system.ntp` and `com.android.sso.auth.handler`. These newer droppers execute the following native escalation sequence:

# Conceptual representation of native privilege escalation flow observed in analysis
# Tested in staging environments only; do not execute on production systems.
adb shell
su
# Native library libexploit.so executes nativeAdbRoot() to restart adbd as root
# Remounts system partition as read-write and replicates to /system/priv-app/
mount -o remount,rw /system

Once root privileges are secured, the dropper writes an XML configuration file to `/system/etc/permissions/privapp-permissions-.xml`, granting itself privileged permissions such as `android.permission.INSTALL_PACKAGES` and `android.permission.REBOOT`. Timestomping properties like `persist.networkstack.install_time` are then applied to blend the malicious binaries into the legitimate system file inventory.

Disabling Security Controls and Defeating Google Play Protect

A critical requirement for the XCPE operational model was the systematic neutralisation of host-level security verifications. Without disabling evaluation checks, sideloaded affiliate modules and secondary APKs would trigger operating system warnings or be blocked entirely by Google Play Protect (GPP).

The backdoor achieves this programmatic disarmament via targeted Java API manipulation:

// Extracted programmatic routine demonstrating GPP disablement
public static void disablePackageVerify() {
    PreferenceUtils.setPackageVerifyFromUser(CPEApp.instance, true);
    AppUtils.setPackageVerify(-1); // Actioning a bypass against GPP evaluation
}

By executing `Settings.Global.putInt` to set the global parameter `package_verifier_user_consent` to `-1`, the malware suppresses all installation dialogs and safety evaluations. This allows silent, unattended execution of arbitrary application packages pushed down through the MQTT broker channel, completing the loop from remote command to unhindered execution.

Affiliate Ecosystem and Monetisation Modules

Videostrong operated the XCPE framework as an infrastructure-as-a-service model, leasing access to criminal syndicates and monetization affiliates. Once a device was compromised, a rotating cast of secondary payloads was deployed depending on the affiliate’s current campaign requirements.

The observed modules fall into distinct operational categories:

• Residential Proxy SDKs: Binaries and libraries associated with networks such as Linkfog, AppSalt, and NetNut. These packages tunnel external traffic through the victim’s residential or enterprise connection, monetising downstream bandwidth.
• Ad-Fraud Engines: Background background rendering tools such as CBOXTV and HiddenView that consume video ads and generate fraudulent click-through metrics without user visibility.
• Nesting Backdoors: Secondary management layers such as Moyu and Spirit, which establish redundant communication channels to load additional tertiary modules.

Staging infrastructure for these modules relied heavily on GitHub release repositories controlled by the operators, supplemented by secondary file-hosting servers that delivered APKs and shell scripts on demand.

Ecosystem Disruption, Legal Actions, and OEM Sanctions

Disrupting a supply-chain botnet of this scale required coordinated international collaboration between technology platforms and law enforcement agencies. Google, working alongside Japan’s National Police Agency, Lumen, HUMAN Security, Plume, Synthient, and TrendAI, executed a multi-pronged takedown strategy.

The enforcement actions encompassed several structural interventions:

• Domain and Infrastructure Seizure: Legal actions were launched to seize C2 domains and server infrastructure operated by Videostrong, alongside C2 nodes tied to more than a dozen affiliate malware families.
• OEM Sanctions: Google banned Videostrong, its subsidiaries, and affiliates from manufacturing or selling certified Android devices, and cut off their ability to supply software components to other certified ecosystem vendors.
• Firmware Integrity Enhancements: Implementation of stricter cryptographic verification checks within the Android TV certification pipeline to detect unauthorized modifications to system and OEM partitions.

While these point-in-time actions successfully severed access for over 1.3 million XCPE-infected devices and disrupted affiliate networks affecting an estimated 10 million additional endpoints, defenders note that supply-chain resilience requires continuous monitoring of firmware provenance.

Defensive Engineering Guidance: Auditing and Hardening Android Deployments

Detecting and mitigating firmware-level backdoors requires shifting from traditional endpoint monitoring to network perimeter telemetry and binary attestation. Platform engineers and SREs managing Android deployments—particularly in enterprise, hospitality, or education environments—should implement specific hardening controls.

To identify anomalous outbound MQTT communication patterns from IoT endpoints, network engineers can deploy ingress/egress filtering rules using standard firewall tooling:

# Example iptables rule to flag or log unrecognised MQTT traffic in staging environments
# Test in staging before deploying to production firewalls
iptables -A FORWARD -p tcp --dport 1883 -d ! <trusted_mqtt_broker_ip> -j LOG --log-prefix "UNAUTH_MQTT_ATTEMPT: "
iptables -A FORWARD -p tcp --dport 8883 -d ! <trusted_mqtt_broker_ip> -j LOG --log-prefix "UNAUTH_MQTTS_ATTEMPT: "

Key Takeaways

The XCPE botnet campaign highlights structural risks inherent in global hardware manufacturing supply chains. When an OEM compromises firmware during production, traditional security controls fail because the malicious code occupies privileged system spaces trusted by the operating system itself.

Defenders must adapt to threats that leverage lightweight IoT protocols like MQTT for clandestine C2, bypassing heavy HTTP inspection. Ultimately, mitigating firmware supply-chain risks demands rigorous vendor vetting, strict cryptographic verification of boot partitions, and continuous network anomaly detection capable of identifying proxy traffic and unauthorised broker associations before they impact organizational security.

Frequently asked questions

How did the XCPE backdoor achieve persistence across factory resets and user uninstallations?

The primary backdoor package was embedded directly into read-only firmware partitions (`/oem/` and `/system/`) during manufacturing. When a user or script uninstalled the service from `/data/app/`, the internal boot receiver routine automatically recopied and reinstalled the package upon the next system reboot. Because the persistence logic resided within immutable firmware layers supplied by the manufacturer, standard user-level removal methods were ineffective.

Why did the operators transition from the com.abc.nexus execution engine to native root droppers?

The operators transitioned away from the `com.abc.nexus` modular loader to single-purpose dropper packages (such as `com.android.system.ntp`) to evade detection mechanisms tuned against older multi-stage bytecode patterns. These newer droppers leverage native ELF exploits like `libexploit.so` to restart the local `adbd` service as root, remount system partitions as read-write, and replicate directly into `/system/priv-app/` with elevated system permissions.

What role did the MQTT protocol play in maintaining long-term control over infected set-top boxes?

Following an initial HTTP bootstrap phase for configuration and telemetry upload, the malware maintained a persistent, real-time Message Queuing Telemetry Transport (MQTT) connection to `mqtt.szbboys[.]com`. MQTT provided a lightweight, low-bandwidth publish-and-subscribe channel ideally suited for unreliable IoT networks. This channel allowed operators to push silent installation commands, execute shell scripts, capture live screenshots, and perform network reconnaissance instantaneously.

How did the malware successfully disable Google Play Protect without triggering user alerts?

The backdoor executed programmatic routines targeting the Android global settings provider. Specifically, the malware invoked `Settings.Global.putInt` on the `package_verifier_user_consent` parameter, setting its value to `-1`. This programmatic modification bypassed security evaluation prompts, allowing secondary payloads and affiliate APKs to install silently without displaying user warnings or triggering Google Play Protect blocking evaluations.

What specific enforcement actions were taken against Videostrong following the discovery?

In response to the supply-chain compromise, Google and international partner organisations implemented coordinated disruptions. Google enacted a permanent ban preventing Videostrong, its subsidiaries, and affiliates from building or selling certified Android devices or supplying software to certified vendors. Legal actions were also executed to seize C2 domains and server infrastructure used to control the botnet and distribute affiliate malware families.