Android Car Head Units Targeted by New Malware Linked to BADBOX Proxy Botnet

Cybersecurity researchers have uncovered a new malware family specifically designed to compromise Android-based automotive head units, marking what researchers describe as the first documented infection chain specifically tailored to car infotainment systems.

The malware was discovered by Kaspersky in June 2026 and is designed to turn compromised head units into tools for advertising fraud and proxy-botnet operations.

Kaspersky attributed the activity with high confidence to the MoYu Group, a threat actor previously associated with the BADBOX ecosystem, a large-scale operation involving Android devices used for ad fraud and residential proxy services

Malware Exploits Legitimate Vehicle Firmware Updates

Unlike conventional Android malware that relies on malicious applications installed directly by users, this campaign abuses a legitimate software update mechanism built into Android-based vehicle head unit firmware.

The affected systems were developed by DoFun, and the attack abuses a system application called TWCore, identified by the package name com.tw.core.

TWCore is a legitimate component responsible for analytics collection and software updates on supported automotive head units.

The application uses an MQTT message broker hosted under the cardoor[.]cn domain to receive update instructions.

APK files delivered through this mechanism are downloaded to:

<TWCore external cache dir>/push/apk/

They can then be installed on the head unit.

Attackers abused this legitimate update channel to distribute previously undocumented malware directly to affected vehicles.

Following responsible disclosure, Kaspersky said the issue that enabled the abuse of the software distribution mechanism has been addressed.

The Attack Begins With the JarService Dropper

The malicious software is delivered through a dropper called JarService.

The dropper launches a loader that communicates with attacker-controlled infrastructure and retrieves additional components.

The loader performs several actions during the infection process.

First, it sends information about the infected head unit to an attacker-controlled server through an HTTP POST request.

The server then responds with a URL pointing to the next-stage payload.

One observed payload URL was:

144.217.243[.]201/vr34der34/dex3.68.png

Despite the .png extension, the file is used as a malware payload.

The version number embedded in the filename also allowed researchers to identify multiple versions of the malware.

Kaspersky was able to retrieve seven different variants, with versions dating back to 3.57.

Malware Runs Silently in the Background

Once the infection chain is complete, the malware is installed as a normal Android user application.

However, it does not provide a visible user interface.

Instead, it operates silently in the background.

The malware periodically communicates with its command-and-control infrastructure.

By default, it sends a POST request to:

/cpc/api/task

approximately every 90 minutes.

The request contains information about the infected device and its configuration version.

The C2 server can then respond in two different ways.

If the malware's configuration is outdated, the server sends an updated configuration containing:

  • New C2 addresses
  • New HTTP request paths
  • Updated operational parameters

If the configuration is already current, the server instead returns integer command identifiers known by the attackers as productId values.

The malware maps these identifiers to commands and stores the command information as serialized JSON objects through Android's SharedPreferences API.

Nine Commands Give Attackers Remote Control

Kaspersky identified nine commands supported by the malware.

1. return

Returns a value stored in Android SharedPreferences.

2. copy

Places attacker-specified content into the device clipboard.

3. http

Allows the malware to perform HTTP GET or POST requests against specified resources.

4. web

Opens a URL inside a WebView and allows arbitrary JavaScript code to be executed.

5. loadlib

A partially implemented command intended for loading additional libraries.

6. loadlib2

Downloads and executes arbitrary code from a supplied URL.

7. loadlib3

Another partially implemented library-loading function.

8. deeplink

Opens a supplied URL through the device's browser.

9. traceroute

Checks whether a resource is reachable using ICMP ping functionality.

Together, these capabilities provide the operators with a flexible mechanism for remotely modifying the behavior of compromised head units and delivering additional payloads.

Used for Ad Fraud and Proxy Operations

The primary objective of the malware is not necessarily to directly interfere with vehicle functions.

Instead, compromised head units can be incorporated into an infrastructure designed for ad fraud and proxy operations.

The malware can display unwanted advertisements and perform activities associated with advertising fraud.

It can also download additional malicious components, allowing the operators to expand the capabilities of infected devices.

The ability to use the infected head unit as a network proxy is particularly significant because modern Android automotive systems can have direct internet connectivity.

Zhima Reverse Proxy Module

Kaspersky found that the attackers use the malware's loadlib2 and http commands to download a module known as zhima.

The module was previously documented by the Nokia Deepfield Emergency Response Team.

Zhima is a reverse-proxy component that has also been observed being selectively delivered through IPTV applications installed on inexpensive Android TV boxes.

Its presence suggests that the operators are using a broader ecosystem of compromised Android devices rather than limiting their operations to automotive systems.

This also strengthens the connection between the campaign and the wider BADBOX-related infrastructure.

Extensive Device Information Can Be Collected

The malware is capable of collecting detailed information about the infected head unit.

Examples include:

  • Device model
  • Display resolution
  • Wi-Fi network identifier
  • MAC address
  • Configuration version
  • Other device and system information

This information allows operators to understand the characteristics of individual compromised devices and potentially determine which payloads or configurations should be deployed.

Why Android Car Head Units Are Becoming Attractive Targets

A vehicle head unit acts as a central multimedia hub within a car.

Depending on the vehicle and installation, it can provide:

  • Navigation
  • Multimedia playback
  • Connectivity
  • Internet access
  • Software updates
  • Integration with other vehicle systems

Android-based head units have become increasingly common in both factory-installed systems and aftermarket upgrades.

Many aftermarket units also include SIM-card connectivity, providing direct internet access without requiring the user to connect the system to a smartphone.

This connectivity creates an attractive environment for attackers.

A compromised head unit can potentially maintain persistent communication with remote infrastructure while remaining largely invisible to the vehicle owner.

Connection to MoYu Group and BADBOX

Kaspersky attributed the activity with high confidence to the MoYu Group.

The group has previously been linked to the BADBOX ecosystem.

BADBOX became known for compromising Android-based devices and turning them into components of large-scale ad fraud and residential proxy networks.

The HUMAN Satori Threat Intelligence and Research team previously exposed the activity, while Google later took legal action against entities allegedly involved in operating the BADBOX botnet and associated infrastructure.

The latest discovery shows that the operators' activities have expanded into an unusual category: automotive Android systems.

First Documented Car Head Unit Infection Chain

Kaspersky described the discovery as the first documented case of malware found on a car head unit using an infection chain specifically designed for that type of device.

The distinction is important.

The malware isn't simply generic Android malware accidentally found running inside a vehicle.

Instead, the attack chain specifically abuses a component of the automotive firmware responsible for software updates.

That provides attackers with a powerful delivery mechanism because the compromised update process can distribute the malicious application directly to vulnerable head units.

Supply-Chain Risk in Automotive Systems

The incident also highlights a broader security issue involving connected automotive ecosystems.

Modern vehicles increasingly rely on:

  • Software updates
  • Cloud services
  • Connected applications
  • Third-party components
  • Remote management systems
  • Internet-connected infotainment systems

If one of these trusted components is compromised, attackers may be able to reach large numbers of vehicles without directly attacking each vehicle individually.

In this case, the abuse of a legitimate updater demonstrates how trusted software distribution channels can become malware delivery mechanisms.

No Evidence of Direct Vehicle Control

The information provided by Kaspersky focuses on the malware's use for ad fraud, proxy operations, information collection, and additional payload delivery.

The reported capabilities do not establish that the malware directly controls critical vehicle functions such as steering, braking, or acceleration.

However, the discovery still represents a significant cybersecurity concern because it demonstrates that automotive Android platforms can be compromised and incorporated into larger criminal infrastructure.

Kaspersky's Warning

Kaspersky researcher Dmitry Kalinin warned that malware delivery methods targeting connected devices are becoming increasingly sophisticated.

Attackers have previously relied on:

  • Pre-installed backdoors
  • Compromised applications
  • Malicious IPTV software
  • Modified Android firmware

The newly observed campaign adds another technique: abusing legitimate automotive software-update functionality.

The researchers emphasized that modern automotive platforms require stronger protections against malware as their connectivity and software dependency continue to grow.

Key Takeaways

The campaign demonstrates several important trends in the security of connected vehicles:

  • Android-based car head units are emerging malware targets.
  • Attackers abused a legitimate firmware update mechanism rather than relying solely on user-installed applications.
  • The malware was delivered through the TWCore system application.
  • The attack uses a multi-stage loader and additional payloads.
  • The malware communicates with a remote C2 infrastructure approximately every 90 minutes.
  • Attackers can remotely issue multiple commands.
  • The malware supports ad fraud and proxy-botnet operations.
  • The campaign is strongly linked to the MoYu Group and BADBOX ecosystem.
  • The malware can download additional modules such as zhima.
  • The discovery represents the first documented infection chain specifically targeting Android automotive head units.
  • The incident highlights the security risks created by connected vehicle software-update infrastructure.