Malware infects Android-based automotive head unit firmware

In June 2026, security researchers discovered a novel piece of malware targeting Android-based automotive head unit firmware. Unlike typical Android malware, this malicious software installed itself as a standard user application, with no visible interface or attempts to appear legitimate. This led investigators to suspect it might be covertly installed on unsuspecting devices.

Further analysis revealed that the malware infiltrated head units through their update mechanism. A legitimate TWCore system application, designed for collecting analytics and updating head units, was exploited to distribute the malware. An MQTT message broker hosted on a compromised server sent a message containing information about APK files to be downloaded and installed on the head unit. The MQTT message included an installNotExists flag, allowing TWCore to install apps not originally present on the device.

Upon installation, a small dropper app named JarService was activated, with no user interface of its own. JarService decrypted encrypted blocks of data within the malware's code, each block XOR-encrypted with a single-byte key. The decrypted data contained serialized information about the payload version, entry point, and the malware's own code for further loading. The entry point for the next-stage payload was the wa method of the com.c.j.qbh class.

The next stage was a malicious loader, whose code contained encrypted strings used as class names to execute the third stage payload using a reflection mechanism. The loader sent implant information to an attacker's server via a POST request. In response, the C2 server returned a link for downloading the subsequent stage payload. The Trojan also used this link to download serialized data, which began with a single-byte integer and a four-byte floating-point value to XOR-decrypt the stage 3 payload.

The malware communicated with the C2 server every 90 minutes, transmitting information about the infected device, including display resolution, device model, Wi-Fi network SSID, and MAC address. It also requested an updated configuration, which the C2 server provided, containing new C2 addresses and HTTP request paths if the configuration was outdated.