Kaspersky documents first malware infection chain targeting Android car head units

Malware rode the head unit's own updater

Kaspersky says it discovered a previously unknown Android Trojan in June 2026 while monitoring mobile threats, and the unusual part was how it arrived. According to the firm's Securelist report, the malware was delivered to Android-based automotive head units through the firmware's built-in update mechanism. Kaspersky describes this as the first documented case of head-unit malware whose infection chain was tailored specifically to that type of device.

The app itself hinted that something was wrong: it installed like an ordinary user application but shipped with no user interface and made no effort to pass itself off as legitimate software. That oddity led the researchers to dig into how it was reaching devices without their owners knowing.

The end goal, they concluded, was ad fraud plus the construction of a proxy botnet. Kaspersky attributes the operation, with high confidence, to the MoYu Group, an actor previously associated with the BADBOX botnet.

An update app that installs whatever it is told

The report traces the infections to DoFun head units. The weak point was TWCore, a legitimate system application on those units that handles analytics collection and software updates. TWCore takes its instructions from an MQTT message broker hosted on a subdomain of cardoor.cn, which tells it which APK files to fetch and install.

The critical detail is a field called installNotExists in those messages. Set the right way, it lets TWCore install apps that were never part of the device to begin with; the app only verifies whether software is already present when the flag is false. Downloaded packages land in a cache path under TWCore's push/apk directory, and Kaspersky's telemetry placed the unknown malware at exactly those locations — in every observed case, installed by the package com.tw.core.

Kaspersky says it notified the vendor about the distribution scheme and that the vendor subsequently reported fixing the security problems.

A dropper, a loader and a clicker

Stage one is a small dropper the researchers named JarService. It carries its payload as XOR-encrypted blocks, each decrypted with a single-byte key that shifts from one block to the next. Once decrypted, the data holds serialized metadata — the payload's version and entry point — along with the code for the next stage, which begins at a method of a class called com.c.j.qbh.

Stage two is a loader. It keeps its class names encrypted until runtime, invokes the third stage through Java reflection, and checks in with the attackers' infrastructure via a POST request that reports details such as its version, channel ID and the package name com.tw.jar1. The server responds with a download link — in one example, a URL ending in .png — pointing to serialized data that begins with its own decryption keys and ends with the stage-three payload. By changing the version number embedded in that URL, the researchers pulled down seven distinct payload variants; the oldest, numbered 3.57, used a different decoding scheme, which the report suggests points to an earlier generation of the chain.

Stage three is described as a clicker and reverse proxy loader. By default it contacts a task endpoint every 90 minutes, transmitting device information including screen resolution, model, the SSID of the connected Wi-Fi network and the MAC address. When its configuration falls behind, the server hands back a refreshed one — version 3.82 at the time of the research — containing new command-and-control hosts, a new polling interval and updated API paths.

Kaspersky products flag the various components under detection names that include HEUR:Trojan-Dropper.AndroidOS.Agent.vu, HEUR:Trojan-Downloader.AndroidOS.Agent.ov and HEUR:Trojan-Proxy.AndroidOS.Zhima.

Why it matters

Head units are an attractive botnet recruit precisely because many carry SIM card slots and maintain their own internet connections for navigation and updates. Like compromised routers or other IoT gear, they are always-on devices that can quietly generate revenue for operators through ad clicks and by proxying traffic, and the owner sees nothing: the malware has no interface, and an infotainment system has no obvious way to signal that it is infected.

The deeper lesson concerns the update channel itself. A firmware updater willing to install arbitrary packages on the say-so of a remote message broker turns every unit in the field into a remote installation target, and buyers of aftermarket head units have no practical way to audit that pipeline.

There is also a boundary worth noting. Kaspersky points out that head units combine multimedia duties with partial control over vehicle functions, and while this campaign stuck to monetization, the same delivery path could carry something more intrusive. The incident is a reminder that Android malware follows Android wherever it runs — most smartphone apps, malicious ones included, will execute unmodified on a head unit.