How Malware Turned an Android Car Head Unit Into a Proxy Bot

Start the car. The dashboard wakes, the radio plays, and the navigation screen looks normal. Nothing suggests that the computer behind the display might be downloading software for someone else.

A report published on August 21, 2026, described a multistage Android malware campaign that spread through built-in update functionality in DoFun automotive head units. The infection chain ended in ad fraud and a proxy botnet, and researchers described it as the first documented malware chain specific to this type of vehicle device. (securelist.com)

A head unit is more than a screen

An automotive head unit is the in-dash computer responsible for entertainment, navigation, connectivity, and sometimes limited access to vehicle functions. It may be factory-installed or added later as an aftermarket upgrade. Because many Android-based units include Wi-Fi, cellular connectivity, or software-update services, they have the same basic ingredients that make other connected devices attractive to botnet operators.

The terminology can be confusing here. Android Automotive OS, usually shortened to AAOS, is a full Android-based operating system running directly on vehicle hardware. Android Auto is different: it runs on a phone and projects a driving-focused interface onto a compatible car display. The incident described in the report concerns Android-based head-unit firmware and vendor software, not every car that supports Android Auto. ()

Why target a dashboard computer? It may not contain the banking credentials or private photographs found on a phone, but it can remain online for long periods and offer a useful network connection. That makes it valuable as an invisible node in an internet-of-things botnet, where compromised devices are controlled in groups. ()

The trusted updater was the doorway

How can malware reach a car's Android head unit without a driver installing an app? In this case, the answer was a legitimate system application called TWCore.

TWCore was designed to collect analytics and update the head unit's software. It received instructions through MQTT, a lightweight messaging protocol built around publishers, subscribers, and a central message broker. One field in the update message, installNotExists, determined whether TWCore could install an application that was not already present on the device. When the field was enabled, the updater downloaded an Android package, or APK, into an update cache before installing it. An APK is the installable archive used to deliver an Android application. ()

That detail changes the story. This was not a driver tricked by a fake navigation app or a malicious attachment. The attack traveled through a maintenance path that already had permission to place new software on the device. An updater is supposed to be a repair crew; here, the same authority became the delivery vehicle.

Three stages, one quiet infection

The malware was split into separate pieces so that no single component had to reveal the whole operation at once:

TWCore updater
 -> JarService dropper
 -> second-stage loader
 -> clicker and reverse-proxy controller
 -> zhima proxy module

Stage one: JarService

JarService was a small dropper. A dropper is a program whose main job is to unpack or launch another malicious component. It had no visible user interface, which meant there was no suspicious icon or screen for the owner to notice. Instead, it carried encrypted data inside its code and decoded that data while running, revealing instructions for the next stage. (securelist.com)

Stage two: the loader

The second component acted as a loader, meaning it fetched and started additional code. It contacted a command-and-control server, commonly abbreviated as C2, and sent information describing the installed component. The server then returned a download location for the next payload.

That payload used DEX code, Android's executable bytecode format. The loader also relied on reflection, a programming technique that lets software find and call classes or methods by name while it is running. Reflection has legitimate uses, but in malware it can make the real execution path harder to see during a quick inspection. ()

Stage three: the money-making machinery

The third stage checked in with the operators roughly every 90 minutes. Its reports included details such as the head unit's display resolution, device model, connected Wi-Fi network name, and MAC address, which is a hardware network identifier. The server could answer with new configuration data or commands.

Researchers documented commands for making HTTP requests, opening links in Android's embedded browser component, executing JavaScript inside a WebView, and downloading more code. The software also behaved as a clicker, generating activity that could support ad fraud. Its most important payload was a reverse proxy module named zhima.

A reverse proxy turns a compromised device into a relay. Instead of an operator connecting directly to a destination, traffic can pass through the infected head unit first. That can help conceal the original source of the traffic and lets the operator sell access to a large pool of apparently ordinary internet connections. The same zhima module was also found in television set-top boxes, reinforcing the assessment that the campaign was building a cross-device proxy network. ()

This was not demonstrated remote driving

The phrase infected automotive firmware sounds alarming, but the report describes compromise of the Android software and its update ecosystem. It does not demonstrate control of steering, braking, or other safety-critical driving functions. That distinction matters.

In compliant Android Automotive designs, the Vehicle Hardware Abstraction Layer, or Vehicle HAL, provides a controlled boundary between Android and vehicle subsystems. Android's documentation also describes verified boot, restricted car-service updates, and permission checks intended to protect vehicle functions. Those protections are valuable, but a custom aftermarket Android build should not automatically be assumed to implement the same boundaries or update guarantees. (source.android.com)

The incident still matters even without a dramatic driving exploit. A head unit that silently serves advertisements, downloads arbitrary modules, or relays other people's traffic consumes bandwidth, creates privacy risks, and gives attackers a foothold inside a device that many owners never think of as a computer.

What a safer update process looks like

For owners, the practical response is to identify the exact head-unit model and firmware build, then obtain updates from the manufacturer or a trusted installer rather than from an unverified forum. A suspected device should be taken off Wi-Fi or cellular service when practical and checked against vendor guidance. Because the entry point was a system updater, a factory reset should not be treated as proof that the update layer is clean.

Security teams can look for unexpected instances of com.tw.core, com.tw.jar1, JarService, and the network indicators published with the research. Repeated outbound traffic from an infotainment device, especially traffic unrelated to navigation or media, deserves attention.

Vendors need stronger controls around the update broker: cryptographically signed packages, strict server authentication, an allowlist of installable applications, clear audit logs, and a default-deny rule for packages that were not part of the original image. Factory AAOS platforms also receive recurring security bulletins; the August 2026 bulletin was published on August 3 with an August 1 security patch level. ()

The lesson is easy to miss because the screen remains calm. Malware does not need to flash a warning or take over the steering wheel to be profitable. Sometimes it only needs a trusted updater, a quiet internet connection, and a computer hidden behind the dashboard.