Listen to this Post
Introduction: The Hidden Computer Inside Your Car
Modern cars are no longer just machines built around engines, batteries, brakes, and wheels. Increasingly, they are rolling computers packed with internet-connected systems, Android-based infotainment platforms, cloud services, navigation tools, wireless connectivity, and third-party applications. That transformation has created enormous opportunities for drivers—but it has also opened a new battlefield for cybercriminals.
A recent investigation by Kaspersky has uncovered a particularly unusual supply-chain attack targeting Android-based car head units. Instead of going directly after a smartphone, laptop, or traditional server, the attackers abused a legitimate software-update application installed on automotive infotainment systems.
The malware campaign, attributed to the MoYu threat group, appears designed to transform compromised car head units into monetizable internet infrastructure. In practice, infected systems can become residential proxy nodes or tools for advertising fraud, allowing criminals to generate revenue from devices that their owners may never realize have been compromised.
The discovery is significant because researchers say this is the first documented malware infection chain specifically created for targeted automotive head units. While connected cars have been discussed as cybersecurity risks for years, attacks against their infotainment ecosystems are becoming increasingly practical.
The good news is that Kaspersky says the malware does not appear to interfere with critical driving functions. The bad news is that the campaign demonstrates just how easily a trusted automotive software component can become the doorway into a much larger criminal operation.
The Attack Begins With a Trusted Automotive Application
At the center of the campaign is TWCore, a legitimate system application associated with DoFun, a Chinese automotive software and hardware provider owned by Shenzhen Driving Control Technology Co., Ltd.
DoFun provides generic Android-based head units that can serve as the central interface for infotainment, navigation, connectivity, and various vehicle settings. Because these systems are integrated into vehicles and often have privileged access to the Android environment, software installed on them can carry considerably more trust than an ordinary third-party application.
That trust is exactly what makes the discovery concerning.
In June, Kaspersky researchers observed a rogue APK being downloaded through the legitimate TWCore application. The application reportedly receives instructions through an MQTT server hosted at cardoor[.]cn.
Rather than immediately displaying a suspicious interface or asking the driver for permissions, the malicious application operates quietly in the background.
JarService: Malware With No Visible Interface
Kaspersky identified the unknown application as JarService, a malware component that does not provide a conventional user interface.
When executed, JarService decrypts and launches a second-stage loader. That loader then establishes communication with a command-and-control infrastructure controlled by the attackers and retrieves another encrypted payload.
This layered architecture is important.
Instead of placing all malicious functionality inside a single easily detectable APK, the attackers separate the infection into multiple stages. Such a design can make analysis more difficult and allows criminals to modify or replace later components without necessarily rebuilding the entire infection chain.
The result is a modular malware platform hiding inside a device that the vehicle owner may consider part of the manufacturer’s trusted software ecosystem.
What Information Does the Malware Collect?
Once the final payload is installed, the malware periodically reports information about the compromised head unit.
Researchers observed the collection of technical information including the device model, display resolution, Wi-Fi SSID, and MAC address.
Individually, some of these details may appear relatively harmless. Together, however, they provide attackers with a useful fingerprint of the infected environment.
Device identification can help operators understand what hardware they control, distinguish individual installations, manage infected nodes, and determine which capabilities may work reliably on particular configurations.
The campaign therefore appears less like a simple piece of opportunistic Android malware and more like an organized infrastructure designed to manage a distributed fleet of compromised automotive devices.
Nine Commands Give Attackers Broad Control
The final payload supports nine commands that provide attackers with a surprisingly broad range of capabilities.
return — Reading Stored Android Data
The return command retrieves a specified value from Android’s SharedPreferences storage.
SharedPreferences is commonly used by Android applications to store configuration information and small pieces of application data. Access to such information can provide attackers with useful operational data depending on what applications have stored there.
copy — Manipulating the Clipboard
The copy command allows the malware to copy stored or downloaded content to the device clipboard.
Clipboard manipulation is particularly interesting because it can provide a bridge between malware-controlled information and user interaction, even if the malware itself has no visible interface.
http — Network Requests
The http command allows the malware to perform HTTP GET or POST requests and save portions of responses.
This gives the operators a flexible mechanism for communicating with external services and retrieving information without requiring every operation to be hard-coded into the malware.
web — WebView and JavaScript Execution
The web command can open a URL inside a WebView and execute supplied JavaScript.
This capability is especially relevant to the
loadlib — Additional Module Loading
The loadlib functionality was not fully implemented when Kaspersky published its findings.
Even so, its presence suggests that the malware was designed with modular expansion in mind.
loadlib2 — Downloading and Executing Code
The loadlib2 command is considerably more powerful. It can download and execute arbitrary code or additional modules.
That capability means the attackers are not necessarily limited to the functionality originally included in the payload.
loadlib3 — Another Incomplete Capability
Like loadlib, loadlib3 was not fully implemented at the time of the researchers’ analysis.
Its inclusion nevertheless reinforces the impression that the malware platform was still under development or designed to support additional capabilities.
deeplink — Opening Resources
The deeplink command allows attackers to open a specified resource in the browser.
Combined with the WebView functionality, this can provide additional flexibility for directing infected systems toward attacker-controlled content.
traceroute — Network Reachability Testing
The traceroute command checks whether specified hosts are reachable using ICMP ping.
This can help attackers understand network conditions and determine whether infected devices can communicate with particular infrastructure.
The Real Objective: Monetizing the Car
Despite the dramatic nature of the discovery, researchers found no evidence that the attackers were attempting to interfere with steering, braking, acceleration, or other critical vehicle-control systems.
Instead, the operation appears financially motivated.
The infected head units are valuable because they provide internet connectivity and can potentially be made to look like ordinary consumer devices operating from residential networks.
That makes them useful for proxy services and other forms of online abuse.
The zhima Proxy Module
Kaspersky discovered that the operators primarily loaded a reverse-proxy module named zhima.
Its purpose is to transform the compromised Android head unit into a proxy-botnet node.
This is a major clue about the
Rather than stealing information directly from the vehicle owner, criminals can monetize the victim’s internet connection. Traffic routed through the infected vehicle can potentially appear to originate from the victim’s network rather than from the attacker’s infrastructure.
Compromised residential-style IP addresses can be attractive on underground markets because they may bypass certain reputation systems that block traffic originating from known data centers or suspicious hosting providers.
The vehicle therefore becomes an unwitting participant in a criminal proxy network.
Advertising Fraud Adds Another Revenue Stream
The attackers also used the infected devices to make web requests associated with click fraud.
Advertising fraud can generate revenue by creating artificial interactions with advertisements, websites, or campaigns.
An infected car head unit is particularly interesting for this purpose because it provides another ordinary-looking internet-connected endpoint from which automated requests can originate.
The victim might simply see their infotainment system operating normally while their device quietly participates in background network activity.
Why This Supply-Chain Attack Matters
The most important lesson from this incident is not necessarily the malware itself.
It is the attack path.
Cybercriminals did not need to convince a driver to install a suspicious application manually. They appear to have exploited the trusted software ecosystem surrounding an automotive device.
That changes the threat model.
When consumers install applications on smartphones, they are often aware that downloading software from an unknown source can be dangerous. But few drivers expect their car’s system-update mechanism to become a potential malware delivery channel.
A trusted update process can therefore become an extremely powerful distribution mechanism when its security is compromised.
The MoYu Connection
Kaspersky attributed the operation to the MoYu group, a threat actor previously associated with the BadBox malware botnet.
That connection gives the campaign additional context.
BadBox has been associated with compromised Android devices and monetization schemes involving fraudulent activity and proxy infrastructure. The automotive campaign appears to fit into the same broader criminal economy, where large numbers of compromised consumer devices can be converted into revenue-generating infrastructure.
The move into automotive head units could represent an expansion of that model rather than an entirely new criminal strategy.
A New Frontier for Android Malware
Android malware has traditionally focused on smartphones, tablets, televisions, streaming devices, and other consumer electronics.
Cars expand that ecosystem considerably.
An Android-based head unit is still an Android computer, but it exists inside a different hardware and network environment. It may have persistent power, Wi-Fi connectivity, Bluetooth capabilities, access to vehicle-specific information, and a trusted position within the automotive software architecture.
Even when attackers are not interested in vehicle control, these characteristics can make automotive systems attractive targets.
The Important Difference Between Infotainment and Vehicle Control
It is important not to confuse this discovery with a successful remote takeover of a car’s steering or braking systems.
According to
The campaign instead targets the infotainment and connectivity layer.
That distinction matters because cybersecurity reporting about connected vehicles can sometimes create the impression that every malware infection automatically represents a direct physical safety threat.
Here, the immediate risk appears different: unauthorized use of the vehicle’s computing resources, network connection, and digital environment for criminal monetization.
Nevertheless, the separation between infotainment and safety-critical systems should never become an excuse for weak security.
DoFun Responded to the Discovery
Kaspersky said it notified DoFun about the findings.
According to the researchers, the company responded that it had resolved the problem.
That is an important development, but it does not answer every question surrounding the incident.
One of the biggest remaining mysteries is the initial compromise vector: exactly how the malicious APK became available through the legitimate update mechanism in the first place.
Understanding that entry point is essential because removing one malicious package does not necessarily eliminate the underlying vulnerability.
The Bigger Supply-Chain Problem
Supply-chain attacks are dangerous because organizations often concentrate security efforts on their own code while overlooking dependencies, update servers, third-party components, distribution systems, and vendor relationships.
A compromised update channel can defeat many traditional security controls.
The software may be digitally signed, delivered through a legitimate application, installed by a trusted process, and executed with permissions that ordinary malware would struggle to obtain.
That makes supply-chain security one of the most important challenges facing connected-device manufacturers.
Why Automotive Manufacturers Need to Pay Attention
The automotive industry is increasingly becoming a software industry.
Vehicles now depend on operating systems, cloud APIs, mobile applications, over-the-air updates, third-party libraries, telematics systems, digital keys, infotainment platforms, and remote services.
Every additional software dependency creates another potential attack surface.
The lesson from this campaign is straightforward: manufacturers cannot treat infotainment systems as harmless accessories.
Even when they cannot directly control a vehicle, compromised systems can become valuable assets for cybercriminals.
Deep Analysis: How the Infection Chain Works
The observed architecture can be simplified into a multi-stage infection chain:
Legitimate DoFun System
|
v
TWCore
|
| MQTT instructions
v
Malicious APK
JarService
|
v
Decrypted Loader
|
v
Encrypted Payload
|
v
Command & Control
|
+-+
| |
v v
zhima Proxy Web Requests
| |
v v
Residential Proxy Advertising Fraud
Botnet
Investigating the Android Environment
Security teams examining potentially compromised Android head units can begin with basic package and process inspection:
adb shell pm list packages
adb shell ps -A
adb shell dumpsys package
adb shell dumpsys activity activities
These commands can help identify installed packages, running processes, package metadata, and active Android components.
Inspecting Network Connections
Network activity should also be investigated because proxy malware needs communication with external infrastructure:
adb shell ip addr
adb shell ip route
adb shell dumpsys connectivity
adb shell dumpsys netstats
For controlled forensic environments, packet captures can provide additional evidence:
tcpdump -i any -nn
Security analysts should specifically investigate unexpected outbound connections, persistent connections to unknown servers, unusual HTTP requests, and traffic that continues when the infotainment interface is apparently idle.
Searching for Suspicious APKs
A forensic investigation can identify recently installed packages and APK locations:
adb shell pm list packages -f
adb shell find /data/app -type f -name ".apk" 2>/dev/null
Analysts should avoid deleting suspicious files before preserving evidence.
A safer forensic workflow is to isolate the device, collect relevant logs and binaries, calculate hashes, and analyze copies rather than modifying the original environment.
Static Analysis of an APK
Once an APK has been safely obtained, analysts can inspect it with tools such as JADX:
jadx -d output_dir suspicious.apk
APK metadata can also be examined with
aapt dump badging suspicious.apk
For malware such as JarService, analysts should pay particular attention to encrypted strings, dynamically loaded libraries, HTTP endpoints, MQTT configuration, WebView usage, clipboard APIs, JavaScript execution, and code-loading mechanisms.
Detecting Suspicious MQTT Activity
Because the campaign reportedly involved MQTT communications, defenders should investigate unexpected MQTT traffic:
tcpdump -i any -nn 'tcp port 1883 or tcp port 8883'
The presence of MQTT traffic is not automatically malicious. Automotive systems may legitimately use MQTT or similar messaging technologies.
The important question is whether the destination, certificate, authentication behavior, topics, and message patterns are consistent with the manufacturer’s documented infrastructure.
Network-Level Blocking
Organizations managing fleets of connected vehicles can use DNS and firewall controls to block confirmed malicious infrastructure:
Block confirmed malicious domains
Block known malicious IP addresses
Monitor unexpected outbound proxy traffic
Alert on unauthorized MQTT destinations
Restrict arbitrary outbound HTTP/HTTPS where practical
Blocking should be based on verified indicators rather than broad assumptions that could disrupt legitimate vehicle functionality.
What Undercode Say:
1. Cars Are Becoming Endpoints
The modern car should increasingly be treated like an enterprise endpoint with wheels.
2. Infotainment Is Not “Just a Screen”
Behind the dashboard is a computer with software, storage, networking, and update mechanisms.
3. Criminals Follow Monetization
Attackers do not always need to steal passwords or crash systems.
4. Bandwidth Has Value
A compromised internet connection can itself become a commodity in underground markets.
5. Residential IP Addresses Are Attractive
Criminal operators can use compromised devices to obtain traffic that appears to originate from ordinary consumer networks.
6. Proxy Botnets Are Scalable
Once malware can convert thousands of devices into proxy nodes, the criminal infrastructure can grow rapidly.
7. Automotive Systems Offer Interesting Hardware
Cars often provide permanently powered computing environments.
8. Supply Chains Remain a Weak Point
A trusted update application can become more dangerous than a random malicious download.
9. Trust Can Become the Attack Surface
The victim does not necessarily need to make a bad decision for the compromise to occur.
10. Updates Need Security Too
Software-update mechanisms must be protected with the same seriousness as the operating system itself.
11. Cryptographic Signing Is Not Enough
A signed application can still be dangerous if the signing infrastructure or distribution pipeline is compromised.
12. MQTT Deserves Attention
Messaging infrastructure used by connected devices must be properly authenticated and monitored.
13. Automotive Vendors Need Better Telemetry
Manufacturers should know which packages are installed and what network destinations their systems contact.
14. Fleet-Wide Visibility Matters
A vulnerability affecting thousands of generic head units can become a large-scale infrastructure problem.
15. Modular Malware Is More Dangerous
Dynamic loading allows attackers to change capabilities without replacing the entire malware platform.
16. loadlib2 Is Particularly Concerning
The ability to retrieve and execute additional code gives operators considerable flexibility.
17. WebView Can Become an Abuse Engine
Automated browser functionality can be repurposed for fraudulent web activity.
18. Clipboard Access Is Another Warning Sign
Even apparently simple Android capabilities can become useful when combined with other functions.
19. Device Fingerprinting Helps Attackers
Model, display, Wi-Fi, and MAC information can help operators manage infected fleets.
20. Criminals Think in Infrastructure
The objective is not necessarily one infected car.
It can be thousands of connected devices working together.
21. Cars Could Become Botnet Nodes
This campaign demonstrates that possibility without requiring control of the vehicle itself.
22. Cybersecurity Must Follow the Software
As automotive systems become more software-defined, security responsibilities must expand accordingly.
23. Generic Hardware Creates Extra Risk
Standardized Android head units may be widely deployed across different vehicles.
- One Weak Vendor Can Have Broad Consequences
A vulnerability in a shared supplier can potentially affect many downstream products.
25. Consumers Have Limited Visibility
Drivers rarely know which background processes are running inside their infotainment systems.
- Silent Malware Is More Dangerous Than Loud Malware
A malicious application that crashes the screen gets noticed.
A proxy running quietly may remain invisible for months.
27. Financially Motivated Attacks Can Be Persistent
If a compromised device generates money, criminals have an incentive to maintain access.
28. Detection Must Include Network Behavior
Traditional application scanning alone may not reveal a compromised proxy node.
29. Manufacturers Should Monitor Outbound Traffic
Unexpected external communication can provide an important detection signal.
30. Security Updates Must Be Verifiable
Users and fleet operators need confidence that updates originate from legitimate infrastructure.
- Incident Response Must Include the Supply Chain
Manufacturers cannot investigate only the vehicle itself.
32. Vendors Need Clear Security Ownership
Responsibility should be defined across hardware suppliers, software developers, cloud providers, and vehicle manufacturers.
- Connected Cars Are Part of the Internet
That sounds obvious, but security strategies often lag behind technological reality.
34. The Attack Surface Is Expanding
Every new connectivity feature creates another potential path for abuse.
- Proxy Abuse Could Become a Larger Automotive Problem
If attackers discover reliable distribution mechanisms, automotive devices could become attractive additions to proxy networks.
36. Advertising Fraud Is Evolving
Fraud operators continuously search for new endpoints capable of generating believable traffic.
- This Is a Warning, Not a Doomsday Scenario
There is no evidence here that criminals remotely took control of vehicles’ critical driving functions.
- But Ignoring the Warning Would Be a Mistake
Today’s monetization malware can reveal tomorrow’s architectural weaknesses.
39. Automotive Security Needs Continuous Monitoring
Security cannot stop after a vehicle leaves the factory.
- The Dashboard Is Now Part of the Cybersecurity Battlefield
The most important takeaway is simple: anything connected to the internet can become someone else’s computing resource if its software supply chain is not properly protected.
✅ Fact: The Campaign Targets Android-Based Automotive Head Units
Kaspersky reported a malware infection chain specifically targeting Android-based car head units associated with DoFun.
Researchers described it as the first documented infection chain of this type specifically created for targeted car head units.
✅ Fact: MoYu Was Linked to the Operation
Kaspersky attributed the campaign to the MoYu group, which has previously been associated with BadBox-related activity.
The connection places the incident within a broader ecosystem of Android malware and device monetization.
✅ Fact: The Malware Can Turn Devices Into Proxy Nodes
Researchers identified the zhima reverse-proxy module being loaded onto compromised systems.
This supports the assessment that infected head units were being monetized as proxy infrastructure.
✅ Fact: Advertising Fraud Was Also Observed
Kaspersky observed web requests associated with click-fraud activity.
This indicates that the attackers were pursuing multiple monetization opportunities rather than relying exclusively on proxy services.
✅ Fact: Critical Vehicle Functions Were Not Reported as Targeted
Kaspersky stated that the malware did not interfere with driving or critical vehicle-control systems.
The observed activity instead focused on the Android head unit, networking, and monetization.
❌ Fact: This Does Not Mean Connected Cars Are Completely Safe
The absence of evidence for attacks against steering or braking should not be interpreted as proof that automotive systems are immune to dangerous cyberattacks.
The incident demonstrates that attackers can already exploit software surrounding connected vehicles for criminal purposes.
❌ Fact: A Compromised Infotainment System Is Not Automatically a Remote Car Takeover
The available findings do not establish that attackers could remotely steer, accelerate, or brake the affected vehicles.
The demonstrated threat is primarily cybercrime involving compromised computing and networking resources.
Prediction
(+1) Automotive Cybersecurity Will Move Toward Endpoint-Style Protection
As Android-based and cloud-connected infotainment platforms become more common, manufacturers will increasingly adopt security controls resembling those already used for smartphones, enterprise endpoints, and IoT devices.
(+1) Proxy Botnets Will Expand Into Unexpected Connected Devices
Cybercriminals are constantly looking for new sources of reliable internet connectivity. Smart TVs, routers, cameras, vehicles, and other embedded systems can all become valuable candidates.
(+1) Automotive Software Supply Chains Will Receive More Scrutiny
Manufacturers are likely to place greater emphasis on secure update infrastructure, application signing, build integrity, vendor security assessments, and continuous monitoring.
(-1) Weak Update Ecosystems Could Create Larger Automotive Botnets
If compromised update channels remain poorly protected, attackers could potentially infect large numbers of devices at once, turning a localized software problem into a distributed criminal network.
(-1) Consumers May Remain Unaware of Background Abuse
The most profitable malware does not always announce itself. A vehicle can continue displaying maps, music, and navigation normally while its network connection is quietly being monetized.
The Bigger Lesson: Your Car Is Becoming Another Computer
The most unsettling part of this story is not that criminals discovered a new way to attack cars. It is that they found a way to make cars economically useful without needing to touch the steering wheel.
That distinction reveals how cybercrime is changing.
Attackers do not necessarily need catastrophic control over a system. Sometimes, all they need is a device with electricity, an internet connection, processing power, and a trusted software environment.
An Android head unit can provide all four.
The MoYu campaign is therefore an important warning for the entire automotive technology industry. As vehicles become increasingly dependent on software and connectivity, security has to extend far beyond traditional vehicle-control systems.
The dashboard may look like a harmless entertainment interface, but underneath it sits another internet-connected computer—and cybercriminals have already started treating it that way.
The future of automotive cybersecurity will not be defined only by whether hackers can take control of a car.
It will also be defined by whether they can quietly turn that car into part of their own infrastructure.
🕵️📝Let’s dive deep and fact‑check.
🎓 Live Courses & Certifications:
Join Undercode Academy for Verified Certifications
🚀 Request a Custom Project:
Secure, high-velocity infrastructure and disruptive technological engineering. Contact our engineering team for high-tier development and proprietary systems:
[email protected]
💎 Smart Architecture | 🛡️ Secure by Design | ⭐ Trusted by Thousands
References:
Reported By: www.bleepingcomputer.com
Extra Source Hub (Possible Sources for article):
https://www.reddit.com
Wikipedia
OpenAi & Undercode AI
Image Source:
Unsplash
Undercode AI DI v2
🔐JOIN OUR CYBER WORLD [ CVE News • HackMonitor • UndercodeNews ]
📢 Follow UndercodeNews & Stay Tuned:
𝕏 formerly Twitter 🐦 | @ Threads | 🔗 Linkedin | 🦋BlueSky | 🐘Mastodon | 📺Youtube
