Critical Vulnerabilities in Harman Kardon Infotainment Systems Expose Android Car Screens
Key Takeaways A new Android malware campaign, attributed to the MoYu Group, has been discovered targeting in-car infotainment systems. The malware leverages a legitimate software update mechanism in...
Key Takeaways
- A new Android malware campaign, attributed to the MoYu Group, has been discovered targeting in-car infotainment systems.
- The malware leverages a legitimate software update mechanism in Android-based head units, specifically the TWCore application, to install malicious payloads.
- Instead of direct vehicle control, the malware transforms infected car screens into participants in an ad fraud scheme and a proxy botnet.
- The vendor of the affected firmware has reportedly issued a fix for the identified security vulnerabilities.
Malware Campaign Hijacks Android Car Infotainment Systems via Updates
A novel Android malware operation has surfaced, turning car infotainment screens into an unexpected vector for cybercrime. This sophisticated campaign bypasses typical user interaction by exploiting the inherent software update pathways within Android-based head units, rather than relying on social engineering tactics like deceptive app installations.
Table Of Content
The multi-stage malware acts as a downloader, facilitating ad fraud and integrating affected devices into a proxy botnet. It specifically targets connected vehicle screens, which manage functions ranging from music and navigation to certain vehicle controls, by exploiting their internet connectivity—the same access point used for routine software updates. This strategy transforms a seemingly trusted maintenance feature into a critical entry point for a broader criminal enterprise.
Analysts at Securelist detected this malware while tracking Android threats in June 2026, subsequently reconstructing the entire infection chain. Researchers have highlighted this as the first documented instance of head-unit malware utilizing a device-specific infection route. They have linked the operation to the MoYu Group, an entity previously associated with the BADBOX malware.
Securelist said in a report, which was shared with Cyber Security News (CSN), that the design of the affected firmware enabled this distribution method. The vendor has since indicated that the security issues have been addressed. This discovery broadens the scope of concern beyond traditional Android devices like phones and televisions, underscoring the growing risks associated with connected screens becoming a standard feature in modern vehicles.
Exploiting the Update Mechanism
The core of this attack revolves around TWCore, a legitimate system application designed for collecting analytics and managing software updates on head units. Threat actors leveraged an MQTT broker, hosted on the cardoor[.]cn infrastructure, to transmit details of malicious APK files for download. A specific setting within TWCore, named installNotExists, could be manipulated to instruct the application to install software not originally present on the device, thereby creating an opening for the malicious package.
Telemetry data revealed that the unknown malware was placed into TWCore’s update cache and subsequently installed by the com.tw.core package. The initial component, JarService, operates without a user interface. Its primary function is to decrypt embedded data and launch the subsequent payload, ensuring the infection remains hidden from the driver.
Following this, a second-stage loader communicates device information to an attacker-controlled server and retrieves a link for the next component. The third stage maintains regular check-ins, gathering details such as the device model, display resolution, Wi-Fi network name, and MAC address, then receiving updated configuration data or commands.
This attack chain significantly differs from typical phone scams, which often commence with phishing texts, malicious advertisements, or deceptive app store lures. Prior instances of BADBOX Android device infections have demonstrated how compromised firmware can expose connected devices without immediate user awareness. This new case extends that vulnerability directly into the automotive environment.
From Screen to Proxy Network
The final payload of the malware is capable of displaying advertisements, generating fraudulent clicks, downloading additional code, and opening web content discreetly in the background. Researchers observed that the operators issued commands to fetch a reverse-proxy module named “zhima.” This module enables an infected head unit to relay network traffic for external parties, effectively transforming a car screen into an active node within a clandestine network.
Attribution of this campaign to the MoYu Group is based on consistent malware naming conventions, shared infrastructure, and overlaps with previously documented activities linked to the group. The researchers also identified connections between this operation and a malicious TV-box application, noting common infrastructure with campaigns associated with BADBOX. This pattern can be compared to the Vo1d Android TV botnet, which similarly illustrated the expansive scale that interconnected Android devices can offer to attackers.
While the report does not indicate that the malware directly controls safety-critical vehicle systems like steering or braking, any compromise of an infotainment device can introduce significant privacy, connectivity, and trust issues. The broader risks within the automotive sector are evident from past incidents, such as a Nissan Leaf infotainment flaw, where a separate vulnerability could potentially bridge an in-car system to vehicle functions.
What You Should Do
- Only Install Verified Updates: Always ensure that software updates for your vehicle’s head unit are sourced exclusively from verified manufacturer or authorized dealer channels. Avoid connecting unknown software or USB media.
- Inquire About Security Fixes: Contact your vehicle manufacturer or dealership to confirm whether your head unit has received the necessary security patches for this vulnerability.
- Manufacturers: Implement Strict Controls: Vehicle manufacturers should enforce strict controls, including requiring signed packages for all update services and validating every remote instruction. Establish a clear process for revoking malicious updates.
- Monitor for Anomalies: Be vigilant for any unexplained app installations, unusual network prompts, or abnormal system behavior on your infotainment screen. Report any suspicious activity to the manufacturer immediately.
Indicators of Compromise (IoCs):-
| Type | Indicator | Description |
|---|---|---|
| SHA-256 hash | ba27951b4ee1c341f4415d033369ecd3 |
JarService stage 1 sample |
| SHA-256 hash | d63bacd6d6709dd68a10ef9d374c7835 |
JarService stage 1 sample |
| SHA-256 hash | 6c2e34b30da42085240ede53ab6107d4 |
JarService stage 1 sample |
| SHA-256 hash | 8b5e513144a6138a966ea59e68bf9da2 |
JarService stage 1 sample |
| SHA-256 hash | e119845877089d6f4b0a70dc7388f316 |
JarService stage 1 sample |
| SHA-256 hash | e9f3a0dab6949ce2cddab9e0aa80ae1a |
Stage 2 loader sample |
| SHA-256 hash | 0fbaa7092204f4b1494e0b840b014774 |
Stage 3 loader/clicker sample |
| SHA-256 hash | 1dcf031c40ce456b6a36a00b0acf3d11 |
Stage 3 loader/clicker sample |
| SHA-256 hash | 44b6b213a6a3f299eaf88e078de95ecb |
Stage 3 loader/clicker sample |
| SHA-256 hash | 67dc78e544ebce16b85dc7c195dfbc58 |
Stage 3 loader/clicker sample |
| SHA-256 hash | 9642ae619b3165d23c6349002d1abe24 |
Stage 3 loader/clicker sample |
| SHA-256 hash | b067d5b0dbecbd6498bcdfba45dba77e |
Stage 3 loader/clicker sample |
| SHA-256 hash | f0e3f7eba2cde91e2dedb921bab47422 |
Stage 3 loader/clicker sample |
| SHA-256 hash | 412e9243f2981bbea3894254d105b3b8 |
zhima reverse-proxy module |
| SHA-256 hash | 71ab5517f71866279d0d87d37f2ae320 |
zhima reverse-proxy module |
| SHA-256 hash | 89ef78f716a75964539f2db6520be362 |
zhima reverse-proxy module |
| SHA-256 hash | a4223ce4288a230d1e6c3ff2c7639045 |
zhima reverse-proxy module |
| SHA-256 hash | bd4d81cd27125ad3d9a114922d468499 |
zhima reverse-proxy module |
| SHA-256 hash | c6bfb1643ac7474ed8a7b4f96a187fdb |
zhima reverse-proxy module |
| MD5 hash | de77c3303e93c9450424759f1741441c |
zhima reverse-proxy module |
| SHA-256 hash | f8cf8c23ff597700d471fb7767df8bac |
zhima reverse-proxy module |
| SHA-256 hash | 2a64c3efc11bf224aa54f24e876446c9 |
TWCore updater sample |
| SHA-256 hash | 7a4d3ba2dacccfdda55859a5dfee2671 |
TWCore updater sample |
| SHA-256 hash | ea24487996eb70c1780922fb3063bcc5 |
TWCore updater sample |
| MD5 hash | 3AD4BF5A86D26FFBF09CAE42AF330A98 |
Related TV-box app, com.abc.nexus |
| Domain | xmsae[.]sbs |
Malware infrastructure |
| Domain | ishano456[.]sbs |
Malware infrastructure |
| Domain | xshaon123[.]sbs |
Malware infrastructure |
| Domain | kshahnd[.]sbs |
Malware infrastructure |
| Domain | mdsjhd[.]sbs |
Malware infrastructure |
| Domain | nmnsny[.]sbs |
Malware infrastructure |
| Domain | kookjar[.]com |
Malware infrastructure |
| Domain | ty54fgd435[.]my |
Malware infrastructure |
| Domain | ue886578433[.]online |
Malware infrastructure |
| Domain | ty4523[.]space |
Malware infrastructure |
| Domain | cardoor[.]cn |
MQTT update-message infrastructure |
| Domain | admin.uipoxy[.]com |
zhima administration infrastructure |
| Domain | pxyedge[.]com |
Related registration document host |
| Domain | proxyforu[.]com |
Related proxy-service infrastructure |
| IP address | 144.217.243[.]201 |
Payload-hosting and command infrastructure |
| IP address | 107.151.248[.]132 |
zhima module configuration |
| IP address | 128.14.210[.]58 |
zhima command-and-control infrastructure |
| URL | hxxp://144.217.243[.]201/vr34der34/dex3.68.png |
Stage 3 payload download |
| URL | hxxp://144.217.243[.]201/vr34der34/sh65.io |
zhima module download |
| URL | hxxps://api.kookjar[.]com/sayhi?channel=daihai&uuid={get_uuid_10} |
HTTP command endpoint |
| URL | hxxp://t2.kshahnd[.]sbs |
Stage 3 command host |
| URL | hxxp://t2.mdsjhd[.]sbs |
Stage 3 command host |
| URL | hxxp://t2.nmnsny[.]sbs |
Stage 3 command host |
| URL | hxxps://t2.nmnsny[.]sbs |
Stage 3 command host |
| URL | hxxp://a2.kshahnd[.]sbs |
Stage 3 update host |
| URL | hxxp://a2.mdsjhd[.]sbs |
Stage 3 update host |
| URL | hxxp://a2.nmnsny[.]sbs |
Stage 3 update host |
| URL | hxxps://a2.nmnsny[.]sbs |
Stage 3 update host |
| URL | hxxp://admin.uipoxy[.]com/proxy/u/login |
zhima administration panel |
| URL | hxxps://proxyforu[.]com |
Related proxy-service website |
| URL | hxxp://ovcloudcontrol.cdn.cardoor[.]cn/upgrade/2026-06-08/bd80bd3c3d0e4bf6b5b4a825650d01f5.apk |
JarService download address |
| URL | hxxp://ovcloudcontrol.cdn.cardoor[.]cn/upgrade/2025-06-10/fe71af9ecf174de48d2b2ccc2c15fb04.apk |
JarService download address |
| URL | hxxp://ovcloudcontrol.cdn.cardoor[.]cn/upgrade/2024-11-07/fa831c3c23824b99871163387bcda7ad.apk |
JarService download address |
| Android package | com.tw.core |
TWCore updater package associated with installation |
| Android package | com.tw.jar1 |
JarService package reported to the attacker server |
| Android package | com.abc.nexus |
Related malicious TV-box application |
| Module name | zhima |
Reverse-proxy payload module |
Note: IP addresses and domains are intentionally defanged (e.g., [.]) to prevent accidental resolution or hyperlinking. Re-fang only within controlled threat intelligence platforms such as MISP, VirusTotal, or your SIEM.
Disclaimer: HackersRadar reports on cybersecurity threats and incidents for informational and awareness purposes only. We do not engage in hacking activities, data exfiltration, or the hosting or distribution of stolen or leaked information. All content is based on publicly available sources.



No Comment! Be the first one.