How BADBOX-Linked Malware Turned Automotive Head Units into Proxy Nodes

Key points in this blog 

• BADBOX-linked activity has reached automotive systems. Attackers used the legitimate updater in DoFun-powered Android head units to distribute malware linked to the BADBOX 2.0 ecosystem uncovered by HUMAN Security in 2025. 

• Weak update controls enabled silent malware installation. Hardcoded MQTT credentials, plaintext communications, MD5-only checks, and excessive installer privileges allowed malware to be installed without a zero-day exploit or user interaction. 

• Securing the update path is the central defense. The malware used infected devices for ad fraud and proxy services, underscoring the need to secure automotive update channels. 

How BADBOX-linked malware reached automotive head units 

In March 2025, HUMAN Security’s Satori Threat Intelligence team published “BADBOX 2.0: The Sequel No One Wanted.” The report documented a China-based operation that had compromised more than one million off-brand Android devices, including smart TVs, tablets, and aftermarket in-vehicle infotainment (IVI) systems. Expanding on the original BADBOX campaign disclosed in 2023, the operation used devices compromised at the supply chain level to build a large residential proxy and ad-fraud network, showing that automotive IVI units had already been incorporated into the ecosystem.

Kaspersky’s August 2026 report, “The Invisible Passenger in Your Car,” documented a multistage malware chain distributed through the built-in updater of DoFun-powered Android head units. Kaspersky attributed the activity with high confidence to MoYu Group, an actor linked to the BADBOX malware platform.  

Figure 1. Key milestones connecting BADBOX investigations to the discovery of malware in automotive head units 

Building on Kaspersky’s disclosure, VicOne CyberThreat Research Lab retrieved and reverse-engineered two JarService dropper variants and a production build of TWCore, the legitimate update and device-management application used to distribute them.  

How the TWCore infection path worked 

VicOne’s analysis identified additional weaknesses in TWCore’s design and found that the infection chain did not rely on a traditional zero-day exploit. Instead, the attackers abused built-in remote installation commands in the system-signed over-the-air (OTA) update component, which used hardcoded credentials shared across devices. Through this delivery path, VicOne analyzed two JarService variants. 
 

Table 1. TWCore-based delivery path and observed JarService payload variants 

Figure 2. Reconstructed TWCore-based infection chain, from malicious MQTT command delivery to JarService deployment and monetization 

The diagram presents the infection chain as a linear sequence. However, VicOne’s analysis found that the same MQTT-controlled device-management channel could support additional operations, including: 

• Remotely uninstalling applications 

• Replacing the default HOME launcher 

• Disabling another vendor’s SIM while accessing information associated with it  

• Retrieving APK files from the device 

• Collecting logcat output under remote control 

Once the JarService dropper was installed, the subsequent stages followed a more conventional multistage Android loader pattern. The most consequential element appeared earlier in the chain: a privileged installer could silently deploy the initial malware through a trusted update path without requiring user interaction. 

What VicOne found in TWCore and JarService 

While public reporting identified TWCore as the delivery mechanism and JarService as the first-stage dropper, VicOne expanded on those findings through in-depth static analysis of a production TWCore build (V7.3.0.240119, versionCode 81) and two JarService variants. The analysis uncovered several architectural weaknesses in TWCore that broaden the potential attack surface and help explain why abuse of the application could have consequences beyond the observed malware installation. 

TWCore is a legitimate system component embedded in DoFun-powered Android head units. It functions as an OEM-side software update and device management agent: collecting device analytics, receiving backend instructions via MQTT, and remotely downloading, updating, and installing APK packages, including applications that were not previously installed on the device. 

Security weaknesses identified 

• Elevated privileges and exposed local interfaces. The analyzed TWCore build runs under android.uid.system. It also exposes the entire external storage via an exported FileProvider configured with path="." and allows local apps to dispatch arbitrary system-level commands through an exported MessengerService. 
• Silent installation of arbitrary APKs. TWCore can download APKs from externally supplied URLs without validating the server certificate. It checks downloaded files using only MD5, which verifies file consistency but does not establish the software's authenticity or source. On non-China builds, TWCore also disables Android package verification and invokes a hidden MainActivity to install staged APKs without visible user interaction. 
• Insecure network and fleet control. TWCore communicates through plaintext MQTT over port 1883 and contains hardcoded shared credentials across devices (d**** / d************). Its networking implementation also disables TLS/HTTPS certificate validation, while its wildcard subscriptions allow unsigned broadcast commands to reach the entire fleet. 

How the JarService variants evolved 

VicOne’s comparison of JarService v1.10 and v1.12 identified changes in their payload handling, on-disk artifacts, and communication mechanisms. The later variant introduced additional protection for its update process and embedded key material. 

Table 2. Technical comparison of the JarService v1.10 and v1.12 dropper variants 

Conclusion 

Kaspersky’s disclosure, reinforced by VicOne’s analysis, illustrates how a legitimate OEM update mechanism can become a malware delivery channel. In the observed infection chain, malicious update commands caused TWCore to use its built-in remote installation capabilities to silently deploy the BADBOX-linked JarService malware. 

The case demonstrates how shared credentials, insufficient command authentication, and excessive installer privileges can turn legitimate OTA-management functions into a path for compromise. 

Automotive OEMs and suppliers should treat update agents as critical trust boundaries. Appropriate safeguards include mutual TLS, cryptographically signed commands and authorized payloads, restrictive MQTT broker access controls, certificate validation, and strict least-privilege isolation. 

IVI platforms that continue to rely on static credentials and unrestricted package installers remain exposed to future campaigns, regardless of the malware family or threat actor involved.