Kaspersky researchers have documented a supply-chain attack that pushes proxy botnet malware onto Android-based car head units, the touchscreen systems that run a vehicle's infotainment, navigation, and settings. The operation is attributed to the MoYu group, a threat actor previously linked to the BadBox botnet. This analysis draws on reporting from BleepingComputer.

Kaspersky notes this is the first documented case of a malware infection chain built specifically for the targeted car head unit.

The affected hardware comes from DoFun, a Chinese automotive software, cloud services, and hardware provider owned by Shenzhen Driving Control Technology Co., Ltd. DoFun sells generic Android head units, which means the same firmware and update infrastructure sit behind a wide range of vehicles and aftermarket installs rather than a single branded model.

In June, researchers found a rogue APK being pulled down by TWCore, a legitimate DoFun system app that takes instructions from an MQTT server hosted at cardoor[.]cn. Because the delivery ran through the vendor's own update channel, the download looked like normal device maintenance.

The payload, named JarService, has no user interface. It decrypts and runs a second-stage loader that reaches a command-and-control server, retrieves an encrypted final payload, and then reports back device details including model, display resolution, Wi-Fi SSID, and MAC address.

The operators mainly deployed a reverse-proxy module called zhima, turning each head unit into a node in a residential proxy network, and also generated web requests for click fraud. Kaspersky says the malware does not interfere with driving or critical vehicle control systems.

The relevance for your organization is the attack surface, not the driving risk. If your fleet vehicles, pool cars, or service vans use aftermarket Android head units that join corporate or guest Wi-Fi, those units are network-connected Android devices that almost certainly sit outside your asset inventory and endpoint coverage. Kaspersky notified DoFun, and the company replied that it resolved the problem.

How MoYu Deploys BTMOB RAT and Companion Malware on Vehicle Systems

The delivery path runs through TWCore, a legitimate DoFun system app that ships on the head unit and handles device updates. TWCore receives instructions over an MQTT server hosted at cardoor[.]cn, and in June Kaspersky observed it pulling down a rogue APK through that same update channel. Because the fetch originates from a signed vendor component with system-level standing, nothing about the download looks unusual from the device's perspective.

That maps cleanly to MITRE ATT&CK for Mobile T1474.003 (Compromise Software Supply Chain). The practical consequence is that no user action is required. There is no sideloaded file, no third-party store, and no prompt for the driver to approve.

The downloaded APK is a malware family Kaspersky tracks as JarService. It has no interface and no launcher icon, so a technician looking at the head unit's app drawer sees nothing out of place. On launch, JarService decrypts and executes a second-stage loader, which opens communication with a command-and-control server and pulls down a further encrypted payload. Staging the real capability behind two layers of decryption keeps the initially delivered file thin and unremarkable, consistent with T1407 (Download New Code at Runtime).

The final payload periodically reports device details back to the operators:

• Device model
• Display resolution
• Wi-Fi SSID
• MAC address

That telemetry set (T1426, System Information Discovery) is what a proxy broker needs to price and route an exit node. The SSID and MAC in particular tell the operator roughly where the device sits and how stable its connection is. For a fleet operator, it also means the network names of your depots and yards are being catalogued by a third party.

Kaspersky documented nine supported commands, and the split between them shows what the operators actually built this for:

• return reads a specified value out of Android's SharedPreferences storage
• copy writes stored or downloaded content to the device clipboard
• http issues GET or POST requests and can retain part of the response
• web opens a URL in a WebView and runs attacker-supplied JavaScript
• deeplink opens a specified resource in the browser
• traceroute checks host reachability using ICMP ping
• loadlib2 downloads and executes arbitrary code or additional modules
• loadlib and loadlib3 were not fully implemented at the time of publication

The web and http pair is the click-fraud engine, generating ad requests and script execution inside a headless WebView the driver never sees. loadlib2 is the extensibility hook, and it is the reason a head unit compromised for ad fraud today can be assigned a different job tomorrow without a new infection.

In observed activity, the operators primarily pushed a reverse-proxy module named zhima, which converts the head unit into a node in a proxy botnet (T1604, Proxy Through Victim). Traffic from paying customers of that proxy service then exits through the vehicle's cellular or Wi-Fi connection and carries the vehicle owner's IP address. Residential and mobile IP space is valued precisely because it does not look like a datacenter, so fraud, scraping, and account abuse routed through these units inherit a clean reputation.

Kaspersky states the malware does not touch driving functions or critical vehicle control systems. The reporting does not include file hashes or C2 IP addresses, so cardoor[.]cn and the zhima module name are the concrete indicators available from this campaign. Other Android families named in adjacent reporting, including BTMOB RAT, Manic, Evooo1Bot, and the NetNut proxy network, are separate operations and were not part of this infection chain.

Operational and Liability Risks for Fleet Operators and Connected Vehicle Services

The malware reports device model, display resolution, Wi-Fi SSID, and MAC address back to its operators on a recurring basis. If your vehicles connect to depot, dealership, or corporate Wi-Fi, that SSID list becomes a map of where your fleet parks, services, and stages. The MAC address gives an attacker a persistent identifier for each unit, so individual vehicles can be tracked across sightings even without GPS data.

Kaspersky states the malware does not interfere with driving or critical vehicle control systems. That matters for safety assessments, and it should not end your risk analysis. The primary payload observed is zhima, a reverse-proxy module that turns the head unit into a node in a residential proxy network, alongside web requests used for click fraud.

Proxy nodes route someone else's traffic through your hardware and your connectivity. For fleet operators paying for cellular data per vehicle, that is billable bandwidth consumed by a third party, spread across every infected unit and easy to mistake for normal infotainment usage on a monthly invoice.

The liability question is sharper than the bill. Traffic exiting a proxy node carries the exit IP of the compromised device, which means fraud, credential stuffing, scraping, or worse can appear to originate from your organization's connectivity account. Investigators, abuse desks, and blocklist providers will attribute that activity to you first, and unwinding it requires forensic evidence that the traffic was relayed rather than generated.

The command set gives operators broader reach than proxying alone. The payload supports commands to send HTTP GET and POST requests and save portions of the response, open URLs in a WebView and execute supplied JavaScript, read values from Android's SharedPreferences storage, copy content to the clipboard, open resources in the browser, and run ICMP ping checks against specified hosts. Two of the module-loading commands were not fully implemented when Kaspersky published, and one, loadlib2, downloads and executes arbitrary code.

The traceroute capability deserves attention if your head units ever join an internal network. ICMP reachability checks against attacker-specified hosts let an operator probe what a vehicle can see, which turns a parked van on the shop Wi-Fi into a reconnaissance point inside your perimeter. Combined with arbitrary code execution, that gives an outside party a foothold on a device your asset inventory probably does not treat as an endpoint.

For OEMs and connected-vehicle service providers, the exposure sits in a different place. Head units sold as generic hardware end up under many brand names, so a customer who discovers their car was relaying commercial proxy traffic will raise it with the vehicle brand, not the component supplier. Consider what your disclosure obligations look like when the affected population is defined by a hardware component you did not manufacture and cannot enumerate from your own records.

Insurance and contract stakeholders should look at the data categories involved. Wi-Fi SSID and MAC address collection, tied to a driver's daily routine, falls within the scope of personal data under several privacy regimes, and telematics contracts frequently contain warranties about who may access vehicle-generated data. If your fleet leases include such terms, an infection puts you in breach of an agreement you signed, separate from any regulatory question.

Kaspersky notified DoFun, and the company replied that it resolved the problem. Vendor remediation does not clean units already in the field or account for traffic those units already relayed.

Detecting BTMOB RAT and Proxy Activity on Android Head Units

Start by putting your head units on a network segment where you can see their traffic. In most fleets these devices join depot or dealership Wi-Fi alongside laptops and handhelds, which means nobody is looking at their flows. Move them to their own VLAN with logging enabled at the gateway, and you get the visibility this campaign depends on you not having.

Once you can see the traffic, the malware's command set tells you what to look for. The nine supported commands include http (HTTP GET and POST requests with partial response capture), web (opening a URL in a WebView and running supplied JavaScript), deeplink (opening a resource in the browser), and traceroute (ICMP reachability checks against attacker-specified hosts). Each of those leaves a distinct trace on the wire.

• Outbound ICMP from an infotainment unit. A head unit has no legitimate reason to ping arbitrary external hosts. Alert on any ICMP egress from that VLAN.
• Long-lived outbound sessions while the vehicle is parked. Proxy relay traffic keeps a connection open and moves volume that has nothing to do with navigation or media playback.
• Repetitive HTTP requests to ad networks and unfamiliar domains. Click-fraud activity generates web requests in patterns no driver produces.
• DNS queries the unit has never made before. Log every resolution from the segment and baseline it over a week of normal use.

On the device itself, watch for the second-stage loader's footprint. The final payload decrypts and executes downloaded modules, which shows up as background CPU consumption and network activity when the screen is idle. If your units support an MDM agent for Android, enforce a policy that reports the full third-party package list on a schedule and flags any application with no launcher icon. An interface-free app on an infotainment system is worth investigating on its own.

The copy command writes stored or downloaded content to the device clipboard, and return reads values out of Android's SharedPreferences storage. Both matter if drivers pair phones, sign into streaming accounts, or enter Wi-Fi keys through the head unit, because that data sits in exactly the places those commands reach. Treat any credential ever typed into a suspect unit as exposed.

When you find a suspect device, isolate it before you touch it. Pull it off Wi-Fi and disable its cellular data path, then capture evidence with the unit powered on. Collect the installed package list and runtime logs over ADB before any factory reset, since a wipe destroys the loader, the downloaded modules, and the C2 addresses you need for blocklisting across the rest of the fleet. Preserve a copy of the rogue APK for your vendor and your insurer.

Then rotate. Change the pre-shared keys or 802.1X credentials for every network the affected unit joined, and force a password reset on any account signed in through the head unit. In environments Capstone manages, Adlumin correlates authentication events across those networks and surfaces logins from device identifiers that should not be authenticating at all.

Finally, report the affected serial numbers and firmware versions to the head unit supplier and your vehicle OEM in writing. Vendor confirmation of a fix is only useful if you can prove which of your units received it.

Remediation and Hardening for Automotive Head Unit Deployments

Start with your supplier. Ask DoFun, or whoever integrated the head units in your vehicles, for the specific firmware build that removes the rogue APK fetch, and get it in writing. Kaspersky reported the issue and the company said it resolved the problem, but "resolved" from a vendor statement is not the same as a version number you can verify against the units on your lot.

Build the inventory before you patch. For every vehicle, record head unit model, firmware version, the system apps present on the image, and whether the unit has ever joined a company network. Without that list you cannot tell which vehicles received the malicious payload and which were simply never online long enough to fetch it.

Factory reset is the obvious cleanup step and it is also the one most likely to waste your time. The infection arrived through a signed vendor component that ships on the image, so a reset restores that component and the device can be re-infected through the same update path. Sequence it correctly: fixed firmware first, reset second, then re-verify the installed package list.

Once units are clean, close the installation paths that let arbitrary code land on the device:

• Turn off installation from unknown sources and remove the install-packages permission from any app that does not need it.
• Disable developer options and ADB access, over USB and over the network, on production units.
• Allowlist the applications permitted to run on the infotainment system, and treat any unlisted package as an incident rather than a curiosity.
• Restrict outbound traffic from vehicle systems at the gateway so head units can reach vendor update endpoints and nothing else.

For fleets, enroll head units in mobile device management wherever the hardware supports it. MDM gives you enforced configuration, a package inventory you can query, and the ability to push a firmware update to 200 vehicles without physically touching them. If the units do not support enrollment, that is a procurement finding worth raising before the next purchase order.

Consumer and employee-owned vehicles need a different approach because you have no administrative control. Keep them on a guest network that cannot reach internal systems, and tell drivers plainly what to watch for: unexpected browser windows on the infotainment screen, ads appearing where they never did before, or data usage on a connected SIM that does not match how the car is used. When the OEM publishes an update, drivers should apply it rather than deferring it for months.

Aftermarket units deserve a security review before installation, not after. Generic Android head units from unbranded suppliers carry pre-installed system apps you did not choose and cannot easily remove, and the update channel behind them is often a single broker with no per-device authentication. Ask the supplier for the full list of pre-installed packages, the code signing chain used for OTA updates, and whether verified boot is enforced on the shipped image.

Longer term, put contract language behind it. Require the vendor to disclose changes to pre-installed applications, to sign every OTA package with a key you can verify independently, and to commit to a firmware support window with a stated vulnerability response time. Audit the update process itself on a schedule, pulling a test unit into a lab and watching what it downloads and from where.

The technical fix here takes an afternoon. The supply chain work, knowing what runs on your vehicles and who put it there, is the part that prevents the next one.

MoYu Campaign: Key Takeaways and Immediate Priority Actions

The takeaway from this campaign is about a device class, not a single piece of malware. An Android head unit is a general-purpose computer with persistent network access, and it arrives in your organization through vehicle purchasing rather than IT procurement. That means it usually sits outside the asset inventory, the patch cycle, and the endpoint agent coverage you apply to every laptop you own.

The command set Kaspersky documented includes loadlib2, which downloads and executes arbitrary code or additional modules. Proxy relaying and click fraud are what the operators chose to run, and the capability to swap that payload stays available without re-infecting the device. Your risk assessment should treat the observed behavior as the current use of the access, not the limit of it.

The direct cost to you is easy to underestimate because it does not look like a breach. When your vehicles relay third-party traffic, outbound connections from your IP space carry activity you did not generate, which affects address reputation and any allow-listing tied to your network ranges. On metered cellular data plans, that relayed traffic also shows up on the bill.

One action matters more than the rest at this stage. If your organization operates a connected vehicle fleet, or your employees drive company vehicles with these units installed, inventory your head unit deployments and initiate a security assessment within 30 days. You cannot evaluate exposure to a supply-chain compromise in a hardware line you have never counted.