Android Car Malware Abuses Built-In Updaters to Enable Ad Fraud and Proxy Botnet

Cybersecurity researchers have identified a malware campaign specifically targeting Android-based vehicle head units.

The malware abuses a legitimate software-update mechanism built into the firmware of multiple DoFun-powered Android car head units. According to Kaspersky, the threat was discovered in June 2026 and represents the first documented case of malware using an infection chain specifically designed for automotive head units. 

The ultimate objective is to deploy additional malicious modules for ad fraud and proxy-botnet activity.

Key Highlights

• Target: Android-based vehicle head units
• Firmware platform: DoFun-powered systems
• Malware delivery: Built-in software updater
• Legitimate updater: TWCore (com.tw.core)
• Dropper: JarService
• C2 communication: HTTP POST
• Update infrastructure: MQTT broker associated with cardoor[.]cn
• Reported payload server: 144.217.243[.]201
• Payload naming pattern: dex3.68.png
• Seven observed payload variants, from version 3.57 through 3.68
• Default C2 polling interval: 90 minutes
• Supports nine remote commands
• Capable of downloading and executing additional code
• Collects device and network information
• Deploys the Zhima reverse-proxy module
• Activity attributed with high confidence to MoYu Group
• Campaign linked to the broader BADBOX ad-fraud and residential-proxy ecosystem. 

Targeting Android Vehicle Head Units

A vehicle head unit functions as a central multimedia and connectivity platform inside a vehicle.

Modern Android-based head units can provide:

• Navigation
• Multimedia
• Internet connectivity
• Software updates
• Bluetooth connectivity
• Wi-Fi connectivity
• Other vehicle-related functions

Many aftermarket and factory-installed systems include a SIM card slot, allowing the device to connect directly to the internet.

This connectivity creates an additional attack surface that can be abused by malware operators. 

Abuse of Legitimate Software Updates

The attack chain begins with a legitimate system application called:

TWCore
com.tw.core

TWCore is designed to collect analytics and distribute software updates to the head unit.

The updater receives APK files through an MQTT-based infrastructure and places downloaded packages under:

<TWCore external cache dir>/push/apk/

Attackers weaponized this legitimate update mechanism to distribute malicious software directly to affected head units. 

JarService Dropper

The malicious update delivers a previously unknown dropper identified as:

JarService

JarService launches a loader that communicates with attacker-controlled infrastructure.

The loader first sends information about the infected device through an HTTP POST request.

The server then responds with a URL for downloading the next-stage payload.

One observed payload URL was:

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

The .png extension is notable because the downloaded file is actually used as a malicious payload rather than an image. 

Multiple Malware Variants

The payload name contains a version identifier.

For example:

dex3.68

Researchers were able to identify seven different versions by modifying the version number, with observed versions dating back to:

3.57

This indicates that the malware infrastructure had been maintained and updated over time. 

Background Trojan

After the infection chain completes, the malware is installed as a regular Android user application.

It does not provide a visible user interface.

Instead, it runs silently in the background and periodically communicates with its command-and-control infrastructure.

The malware sends a POST request to:

/cpc/api/task

every 90 minutes by default.

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

Dynamic C2 Configuration

The malware uses a configuration-management mechanism to maintain its command-and-control infrastructure.

If the local configuration is outdated, the C2 server can provide:

• Updated C2 addresses
• New HTTP request paths
• Updated configuration information

If the configuration is current, the server instead provides integer command identifiers referred to as:

productId

The malware stores the corresponding command information as serialized JSON in Android SharedPreferences. 

Remote Commands

Researchers identified nine supported commands:

return
copy
http
web
loadlib
loadlib2
loadlib3
deeplink
traceroute

Their capabilities include:

• Reading values from SharedPreferences
• Modifying clipboard contents
• Making HTTP GET/POST requests
• Opening URLs through WebView
• Executing JavaScript in WebView
• Downloading additional code
• Opening URLs in the browser
• Performing network connectivity checks

The loadlib2 command can download and execute arbitrary code from a URL, making it particularly significant from a security perspective. 

Device Reconnaissance

The malware can collect information about the infected head unit, including:

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

This information can be used by the threat actor to identify and manage infected devices. 

Ad Fraud

One of the primary objectives is to generate fraudulent advertising activity.

The malware can display unwanted advertisements and perform automated ad-fraud operations.

Compromised devices can therefore become part of an infrastructure designed to generate fraudulent advertising revenue.

Proxy Botnet

The campaign also deploys Zhima, a reverse-proxy module previously observed in malicious IPTV applications and inexpensive Android TV devices.

The malware uses the loadlib2 and http commands to retrieve and activate Zhima.

This allows compromised vehicle head units to potentially participate in a proxy network, turning the devices into infrastructure through which other traffic can be routed. 

Connection to BADBOX

Researchers attributed the campaign with high confidence to MoYu Group.

The group has previously been associated with the broader BADBOX ecosystem involving ad fraud and residential proxy services.

The campaign demonstrates that actors associated with this ecosystem are expanding their targets beyond inexpensive Android TV devices and IPTV applications into automotive platforms. 

Supply-Chain Security Concern

The campaign is particularly significant because the malware is delivered through a legitimate software-update mechanism.

This creates a supply-chain-style attack path:

Legitimate Firmware
        ↓
TWCore Updater
        ↓
Compromised Update Channel
        ↓
JarService Dropper
        ↓
Loader
        ↓
Android Trojan
        ↓
Ad Fraud / Proxy Botnet

The trusted nature of the update process makes this delivery mechanism considerably more dangerous than simply distributing a malicious APK through an untrusted website.

Detection and Hunting Opportunities

Security teams and automotive-device vendors should monitor for:

• Unexpected APK installations by com.tw.core
• Unusual activity involving the TWCore updater
• Files created under /push/apk/
• Unexpected MQTT communication
• HTTP POST requests from head units
• Requests to /cpc/api/task
• Communication occurring approximately every 90 minutes
• Connections to 144.217.243[.]201
• Downloads using .png filenames that are actually executable payloads
• dex3.* payload naming patterns
• Unexpected WebView JavaScript execution
• loadlib2 behavior
• Unexpected code downloads
• Suspicious proxy traffic from vehicle head units
• Unusual outbound traffic from automotive Android devices
• Unexpected modifications to Android SharedPreferences

Recommended Detection Logic

A high-confidence behavioral detection could correlate:

TWCore / com.tw.core
        +
APK Download
        +
Unexpected Background Application
        +
HTTP POST to /cpc/api/task
        +
Periodic 90-Minute Communication
        +
Additional Code Download

A second detection path should identify:

Android Head Unit
        +
Unexpected Reverse Proxy Traffic
        +
Unknown External C2

Recommended Mitigations

1. Verify the integrity of automotive firmware updates.
2. Ensure software-update channels use strong authentication and integrity validation.
3. Restrict updater communication to approved infrastructure.
4. Monitor unexpected APK installations.
5. Audit applications installed on Android head units.
6. Monitor MQTT communication from automotive systems.
7. Detect unexpected executable payloads disguised as images.
8. Monitor outbound connections from vehicle head units.
9. Restrict unnecessary internet connectivity.
10. Maintain an inventory of connected automotive Android devices.
11. Monitor for unexpected proxy traffic.
12. Investigate unauthorized changes to updater applications.
13. Apply firmware and updater security fixes provided by vendors.
14. Segment automotive systems from sensitive enterprise networks where possible.
15. Monitor for unexpected downloads and dynamic code execution.

Threat Assessment

This campaign represents a High-severity automotive malware threat because it abuses a trusted software-update mechanism to compromise connected Android vehicle systems.

The primary objectives identified by researchers are ad fraud and proxy-botnet activity rather than direct manipulation of vehicle safety functions.

However, the ability to remotely execute additional code on connected automotive systems creates a broader security concern if similar infrastructure is later adapted for more disruptive purposes. 

Conclusion

The campaign demonstrates that connected vehicle head units are becoming part of the broader Android malware ecosystem.

Automotive manufacturers, aftermarket head-unit vendors and fleet operators should treat software-update mechanisms as high-value security boundaries.

Strong update integrity controls, application monitoring, network visibility and restrictions on unauthorized code execution are essential to prevent legitimate update infrastructure from becoming a malware delivery mechanism.