// 2 CRITICAL · 2 ZERO-DAY · 11 CVE · 11 EXPLOIT · 1 ADVISORY IN THE LAST 24H
Kaspersky has identified the first malware with a dedicated infection chain for Android automotive head units. It exploits the privileged system app TWCore to infiltrate vehicles into a proxy botnet monetized by the MoYu Group. The vehicle shows no driving anomalies; it silently becomes a traffic relay node, leveraging onboard cellular and Wi-Fi connectivity.

Kaspersky has revealed the first malware with an infection chain dedicated to Android automotive head units, discovered on August 21 on aftermarket devices from the Chinese vendor DoFun. The code exploits the privileged system app TWCore — designed for firmware updates — to infiltrate vehicles into a proxy botnet monetized by the MoYu Group. The vehicle exhibits no driving anomalies; it silently becomes a traffic relay node, leveraging onboard cellular and Wi-Fi connectivity.

Key Takeaways
  • This malware is the first documented with an infection chain specific to car head units, not an adaptation of generic IoT code.
  • Entry occurs via TWCore, a legitimate system app that receives commands from an MQTT broker on cardoor[.]cn, abusing the installNotExists flag to install arbitrary APKs.
  • The multi-stage chain (JarService → loader → final payload) culminates in the "zhima" proxy module that converts the vehicle into a traffic relay.
  • Kaspersky attributes the activity with high confidence to the MoYu Group, identified by Human Security as the developer of the BADBOX 2.0 backdoor.

How TWCore Becomes the Vehicle Entry Vector

The attack surface is not an Android AOSP vulnerability but a vendor system app: TWCore, distributed on DoFun head units with elevated privileges to manage firmware updates. According to Kaspersky SecureList's technical analysis, the app registers as a persistent service and establishes a connection to an MQTT broker hosted on cardoor[.]cn.

The compromise mechanism unfolds in two documented steps. TWCore receives messages with the installNotExists flag, normally intended to install missing firmware components. The malware abuses this flag to silently install a dropper APK, JarService, which lacks a user interface. The dropper employs a single-byte XOR decryption with a sequential key — a rudimentary but effective scheme against automated static analysis — to extract the next payload.

From here the documented multi-stage chain proceeds: JarService contacts a C2 server to download the loader (stage 2), which in turn retrieves the final payload (stage 3). Kaspersky observed 7 distinct variants of the stage 3 payload, obtained by modifying the version number in the download URL, with the most recent configuration at version 3.82.

The "zhima" Module and Monetizing the Vehicle as a Proxy

The final payload establishes periodic communication with the C2 at intervals of approximately 90 minutes, transmitting device information and receiving commands in JSON format. Kaspersky identified 9 commands supported by the malware, including functionality for ad display and ad fraud. However, in the analyzed samples researchers observed only the execution of the loadlib2 command.

This command downloads the module named "zhima" — class com.miyc.transfer.Client — which configures the vehicle as a proxy relay with IP and port parameters specified by the server. The head unit's cellular or Wi-Fi traffic is thus monetized as residential proxy infrastructure, indistinguishable from that of any compromised IoT device. The novelty is not the business model — consolidated in residential botnets — but the target: an embedded automotive system with persistent connectivity and often overlooked in patch management programs.

"This is the first documented case of malware found on a car head unit with an infection chain specific to that type of device" — Kaspersky SecureList

Attribution operates on two convergent levels. Kaspersky links the analyzed sample "with high confidence" to the MoYu Group, an operator already associated with the BADBOX ecosystem. Human Security, through its Satori team, identifies the MoYu Group as the entity that "developed the backdoor for BADBOX 2.0, coordinated the variants of that backdoor and operated a botnet composed of a subset of BADBOX 2.0-infected devices." The group takes its name from the residential proxy services offered to affiliates.

The convergence between the two primary sources is significant: Kaspersky documents the technical mechanism on DoFun head units, while Human Security confirms that BADBOX 2.0 explicitly includes "vehicle infotainment units" among compromised devices, referencing an FBI Public Service Announcement dated June 2025. BADBOX 2.0 as a whole — primarily Android TV boxes compromised in the supply chain — would have involved over 10 million devices according to a lawsuit cited by SecurityWeek, with traffic observed in 222 countries and territories and impact on over 1 million consumer devices according to Human Security. The specific scale on automotive head units is not quantified in available sources.

What to Do Now

  • Verify the provenance of aftermarket head units: DoFun devices are widespread in China and APAC; in fleets or imported vehicles, identify their presence.
  • Inspect MQTT traffic to suspicious domains: The broker cardoor[.]cn is indicated by Kaspersky as command infrastructure; its resolution in vehicle networks signals compromise.
  • Check for the presence of the TWCore app or JarService services: The dropper's lack of a user interface makes it invisible to the user, detectable only through system process audits.
  • Request fix confirmation from the vendor: SecurityWeek reports that DoFun was notified and would have fixed the issue, though primary sources do not indicate details on the release or independent verification.

Why the Automotive Supply Chain Is the Next Frontier for Compromised IoT

The discovery marks a turning point in botnet targeting: the shift from static home devices — TV boxes, routers, cameras — to mobile vehicle systems with persistent connectivity. Aftermarket head units represent a particularly vulnerable segment: they combine Android AOSP with elevated system privileges, update mechanisms often unsigned or weakly verified, and an absence of the oversight typical of the automotive OEM sector.

For consumers the effect is asymmetric: no evident malfunction, no dashboard warning, while the vehicle transports third-party traffic through its own data connection. For the industry, the case highlights how the convergence between infotainment and vehicle systems — already complex for functional safety — gains a supply chain vector previously proper to consumer IoT. The boundary between "Android device" and "vehicle system" has proven more permeable than automotive risk model taxonomies assume.

Sources

Information verified against cited sources and current as of publication.

Sources


Sources and references
  1. securityweek.com
  2. securelist.com
  3. scworld.com
  4. gbhackers.com
  5. humansecurity.com
  6. podcast.securityweek.com