XCPE Botnet Dismantled: Android OEM Videostrong Implicated

XCPE Botnet Takedown and Videostrong’s Supply Chain Compromise

Google, in collaboration with industry partners including Lumen, HUMAN Security, Plume, Synthient, and TrendAI, has successfully dismantled the XCPE botnet, a sophisticated operation that infected over 1.3 million Android set-top boxes. This pervasive threat, active since at least late 2024 (as stated in the source material), was intentionally developed and operated for financial gain by Videostrong Technology Co., an Android Original Equipment Manufacturer (OEM) and Original Design Manufacturer (ODM). The operation also targeted command and control (C2) domains used by affiliate modules, severing access to an estimated 10 million additional compromised devices, according to Google’s Threat Intelligence team.

The malicious software, identified as the XCPE backdoor, was found pre-built directly into numerous device models and brands over several years. Videostrong systematically monetized this backdoor by selling access to criminal affiliates who then loaded various malware modules onto the infected devices. These secondary modules engaged in activities such as ad-fraud, silently enrolling devices into residential proxy networks, and installing additional malware. Google has since cut ties with Videostrong, banning them from making devices with preloaded Google apps and implementing significant improvements to its firmware integrity review processes to prevent similar supply chain compromises.

Technical Analysis of the XCPE Botnet Architecture

The XCPE botnet employed a modular, three-stage architecture designed for resilience and multi-tenant monetization. This sophisticated approach allowed Videostrong and its affiliates to maintain persistent access and evolve their malicious capabilities while attempting to evade detection.

The Primary Backdoor: x.cpe

The initial compromise vector is x.cpe, sometimes appearing as com.oemservice. This primary backdoor operates at the android.uid.system privilege level and is preloaded directly into the device’s firmware partition. A key characteristic of its persistence mechanism is its ability to automatically reinstall from the /oem/ partition upon reboot if a user attempts to uninstall it, ensuring continuous system-level access. Its core function is to establish and facilitate communications between the command and control (C2) server and subsequent loader and execution engine components. This demonstrates a deep-seated intention by Videostrong to compromise devices from the manufacturing stage.

Loader and Execution Engine: com.abc.nexus

To further evade security analyses, x.cpe offloads module execution to an external loader, initially identified as com.abc.nexus. This component was engineered with native anti-analysis utilities specifically designed to thwart sandbox detection. Its role was to configure and initialize the monetization modules deployed by Videostrong’s criminal affiliates. More recently, the use of com.abc.nexus has evolved, with Videostrong shifting towards more tailored dropper malware that directly loads and executes single modules, streamlining the infection process for specific monetization goals.

Monetization Modules and Affiliate Activities

Videostrong’s primary method of monetizing its backdoored devices involved deploying a variety of monetization modules developed by affiliate entities. These modules were deployed in several forms:

• Native ELF daemons.
• Embedded SDKs compiled directly into the com.abc.nexus DEX bytecode.
• Secondary APKs fetched from the malware staging infrastructure.

These modules transformed infected devices into instruments for various illicit activities:

• Residential Proxy Networks: Devices became exit nodes for services like Linkfog, AppSalt, and NetNut, enabling cybercriminals to obscure their origins for malicious traffic.
• Ad-Fraud Engines: Modules such as CBOXTV and HiddenView facilitated fraudulent advertising practices, generating illicit revenue.
• Additional Backdoors: Some modules, like Moyu and Spirit, served as secondary backdoors, enabling the loading of even more monetization modules, creating a cascading infection potential.

Command and Control Infrastructure

The botnet utilized a two-stage C2 process to manage its vast network of compromised devices. Initially, infected devices made HTTP POST requests to fetch dynamic configuration settings, geolocation data, and STUN server parameters. Following this initial setup, a persistent, real-time Message Queuing Telemetry Transport (MQTT) connection was established. This MQTT connection allowed the C2 servers to transmit instructions for critical malicious actions, including:

• Silent application installations
• Execution of arbitrary shell commands
• Screen captures
• Network reconnaissance

This C2 architecture highlights the advanced capabilities of the XCPE botnet, providing operators extensive control over the compromised Android set-top box.

Actionable Recommendations and Mitigations

The takedown of the XCPE botnet underscores the severe risks associated with supply chain compromises and pre-installed malware. For security professionals, understanding how to detect XCPE botnet activity is crucial. While Google has taken decisive action, the following recommendations are vital for ongoing defense:

• Device Auditing: Organizations and individuals should be wary of uncertified Android devices or those from lesser-known OEMs. Regularly audit devices for suspicious applications (com.oemservice, com.abc.nexus) or unusual network traffic patterns, especially those involving MQTT connections to unknown hosts.
• Firmware Integrity: Ensure that any Android TV devices or set-top boxes are from reputable manufacturers and receive regular, verified firmware updates. Google’s actions to improve firmware integrity checks are a positive step, but vigilance remains essential.
• Network Monitoring: Implement network intrusion detection systems (IDS) and firewalls to monitor for outbound connections to suspicious IP addresses or domains associated with known botnets or ad-fraud operations. Specifically, look for unexpected MQTT traffic from internal devices.
• User Awareness: Educate users about the risks of third-party Android devices and the importance of verifying device provenance.
• Videostrong pre-installed malware mitigation: For devices that may have originated from Videostrong Technology Co., consider isolating them on the network or replacing them with certified alternatives. If replacement is not immediately feasible, rigorous network segmentation and traffic inspection are paramount.

This incident serves as a stark reminder that even devices intended for entertainment can become vectors for sophisticated cybercrime. Continued vigilance and proactive security measures are essential to mitigate the risks posed by such embedded threats and Android set-top box security vulnerabilities introduced at the manufacturing level.

Related: Android Car Head Unit Malware Spreads via Built-In Updaters, Anthropic Warns Small AI Models Could Self-Replicate on IoT