BlackTree Security · Infrastructure · Automation · AI

The Car Wasn’t the Target. Its Trusted Updater Became a Botnet Installer.

A trusted updater inside Android-based car head units installed malware that turned connected dashboards into residential proxy nodes. The car was not the attacker’s objective. Its privileged update path was.

Kaspersky says it found a multi-stage Android infection chain delivered through TWCore, a legitimate system application in head units associated with Chinese automotive software provider DoFun. TWCore normally collects analytics and installs software updates. In the cases observed by the researchers, it also installed a hidden dropper that ultimately loaded click-fraud and reverse-proxy capabilities.

The distinction matters. This is not a report about Google’s Android Auto phone-projection product, and it is not evidence that attackers reached braking, steering, powertrain or another safety-critical vehicle domain. It is a supply-chain trust failure in an internet-connected infotainment component.

That narrower finding is still consequential. A car head unit can remain online for long periods, connect through Wi-Fi or a SIM and present a mobile IP address that is useful to proxy operators. The device does not need valuable local data to become valuable infrastructure.

The updater already had the authority

TWCore, identified by the package name com.tw.core, receives instructions through an MQTT broker hosted under the cardoor.cn domain. Kaspersky found that update messages could include an installNotExists flag, allowing TWCore to install an APK even when that application was not already present on the device.

Researchers found previously unknown malware in TWCore’s external cache directory. Kaspersky says its telemetry showed that every observed installation came from the com.tw.core package.

The first malicious component, called JarService, had no user interface. It decrypted and executed a second-stage loader, which contacted command-and-control infrastructure and retrieved another encrypted payload. The final stage could open web content, execute supplied JavaScript, issue HTTP requests, use the clipboard, launch deep links and load additional code.

One of those additional modules was zhima, a reverse-proxy engine. Its role was to make the infected head unit an exit node for traffic controlled through the attacker’s infrastructure.

The supply-chain claim has an important boundary

The evidence supports malware delivery by the legitimate updater. It does not yet explain exactly how the attacker obtained the authority or access required to make that updater distribute the malicious APK.

Kaspersky says the firmware design enabled the distribution scheme and that DoFun reported fixing the security issues after notification. The public research does not provide a model list, affected firmware range, geographic exposure estimate, infection count or consumer-facing remediation matrix.

Those missing facts should prevent two opposite mistakes. It would be wrong to generalise the finding to every Android head unit or every vehicle using Android. It would also be wrong to dismiss it as ordinary app malware. A privileged system updater silently installed the first stage, bypassing the user decision that normally separates an application download from system-level software delivery.

MoYu brought the residential-proxy model into the dashboard

Kaspersky attributes the campaign with high confidence to the MoYu Group, one of the actors linked to the BADBOX malware ecosystem. The assessment is based on naming patterns and substantial infrastructure overlap.

The proxy component also has independent technical context. Nokia Deepfield researchers previously analysed zhima in an Android television and IPTV delivery chain. Their report describes a maintained residential-proxy engine that makes outbound connections to an operator relay and carries SOCKS5 or HTTP CONNECT traffic on behalf of proxy customers.

That architecture helps explain why a car head unit is useful. The infected device initiates the connection, so there is no obvious internet-facing proxy port for an external scanner to find. To the network, the device can look like an ordinary Android system making outbound connections. To the proxy buyer, it provides an exit point associated with a real consumer or mobile connection.

The head unit is therefore not the final target. It is rented infrastructure. Its bandwidth, location and network identity become the product.

A factory reset may not close the trust problem

Consumer guidance is difficult because Kaspersky did not publish exact affected models or firmware versions. Owners, installers and fleet operators should first establish what they actually have rather than assuming that an “Android” label proves exposure.

  • Record the head-unit manufacturer, seller, model, Android build and firmware version.
  • Check whether the system contains the com.tw.core package and preserve package, installer and network evidence before resetting or reflashing the device.
  • Compare observed domains, IP addresses and APK hashes with the indicators in Kaspersky’s primary report.
  • Keep a suspected unit away from trusted home, enterprise and fleet networks until its software provenance is understood.
  • Ask the supplier or installer for a fixed firmware build and a clear explanation of how the update channel was secured.

A factory reset is not a sufficient answer when the distribution path is a privileged system component. If the same updater and firmware return after the reset, the trust boundary has not changed. Remediation needs to address the firmware and update mechanism, not only the final malicious APK.

The operational lesson is larger than the car

Connected products often treat their update agents as permanently trusted. That trust is reasonable only when the entire delivery chain is controlled: authenticated instructions, signed packages, tightly scoped installation rules, protected broker credentials, auditable changes and a recovery path that does not depend on the same potentially compromised channel.

Security teams assessing embedded Android devices should ask who can instruct the updater, what it is allowed to install and whether administrators can independently verify the software currently on the device. A signature on the updater does not make every package it installs trustworthy.

This incident also widens the meaning of automotive cybersecurity. Not every meaningful vehicle compromise needs to cross into the CAN bus or affect driving. The dashboard can be abused as an internet-connected computing asset while the vehicle continues to operate normally. That makes the activity less dramatic, but potentially harder for an owner to notice.

DoFun’s updater was supposed to maintain the product. In the observed cases, that authority became the installation route for somebody else’s infrastructure.

Sources

Leave a Reply

Your email address will not be published. Required fields are marked *