A Trusted Automotive Update Path Can Become the Malware Delivery Path

The updater did what it was trusted to do

The most important feature of the campaign is not that Android malware reached a car display. Kaspersky reconstructed an infection chain in which malicious stages were distributed through the built-in firmware-update path of automotive head units. A legitimate update mechanism became the delivery channel.

That changes the defensive question. Traditional endpoint thinking starts after software lands on the device: detect the APK, block the domain, identify persistence and remove the payload. Product-security thinking has to move one step earlier and ask why the update authority was able to deliver software the device should never have trusted.

The update channel is therefore not plumbing around the product. It is part of the product's effective trust boundary. Backend services, CDN paths, supplier accounts, updater applications, signing or manifest infrastructure and the process that authorises a release can all become security-critical assets even if the final device is well hardened.

Legitimate authority is more dangerous than an obvious exploit path

An attacker who exploits a memory-corruption bug must first obtain code execution. A compromised update chain can start with something stronger: an existing mechanism already designed to install software at scale. That authority can bypass assumptions defenders make about user interaction or suspicious installation behaviour.

The documented head-unit campaign is especially instructive because the payload's purpose was monetisation rather than vehicle sabotage. The operational consequence was therefore limited compared with a safety-critical ECU compromise. But the assurance failure is still important: software arrived through a path the device owner had reason to trust.

This is why update security cannot be reduced to one cryptographic control. Signing and transport protection are valuable, but the organisation also needs to know who can cause a package to be published, what evidence binds a package to an approved release, whether a compromised supplier can reuse valid authority, and how an installed release can be revoked or blocked when trust is lost.

Aftermarket head units expose a fragmented ownership model

Many Android head units sit outside the governance model of a vehicle OEM. They may be supplied through aftermarket channels, combine hardware and cloud services from different companies, use generic Android components and depend on update infrastructure that the vehicle manufacturer neither operates nor monitors.

That fragmentation makes responsibility easy to lose. The hardware vendor may own the device. A software provider may own the updater. Another party may host the cloud service or content-delivery path. The installer and vehicle owner may have little visibility into any of them. Yet once the unit is connected to vehicle networks, mobile data, Wi-Fi or user accounts, the security consequences sit inside the vehicle environment.

The practical boundary therefore has to be based on capability, not branding. If an aftermarket component can install software, communicate externally, access vehicle data or influence vehicle functions, its update authority belongs in the threat model even when it is not part of the OEM's original E/E architecture.

R156 and ISO/SAE 21434 point to the lifecycle, not just the package

UN Regulation No. 156 formalises software update and software-update management expectations for regulated vehicle systems, while ISO/SAE 21434 frames cybersecurity engineering across the vehicle lifecycle and supply chain. The head-unit case shows why that lifecycle view matters beyond a single compliance boundary.

An organisation responsible for a connected automotive product needs evidence that links an authorised release to the exact software distributed, the infrastructure and identities used to publish it, the supplier dependencies behind that path, and the installed state on the device. It also needs a recovery mechanism for the uncomfortable case where the update service itself becomes suspect.

That recovery path should not depend on the same compromised authority. Independent release approval, protected signing roots, out-of-band revocation or deny-list capability, immutable release evidence and telemetry that can distinguish approved from anomalous update behaviour all reduce the chance that one backend compromise becomes persistent fleet authority.

Written by

Antonio González, PhD

Cybersecurity practitioner focused on product security, OT/ICS and cyber-physical systems. Cybersecurity Under Pressure translates incident evidence into engineering and business decisions.

About →LinkedIn ↗