Blog · Signals

Car head units now join the residential proxy pool. OpenRTB still has no field for that device class.

August 25, 2026 · RTBlint

In June 2026, researchers found malware delivered through the built-in updater on Android-based automotive head units running DoFun firmware. The infection chain installs a clicker for fraudulent ad impressions and a reverse-proxy module that enrolls the infotainment system in a residential proxy botnet linked to the BADBOX ecosystem. That is the first documented in-the-wild case on car head units. For programmatic buyers, the punchline is not the novelty of automotive malware. It is that another device class now feeds the same residential IP pool your pre-bid datacenter blocklists treat as clean, and OpenRTB has nowhere to record that the impression came from a dashboard screen.

What the finding actually measures

This is endpoint security research, not an ad-tech measurement study. Kaspersky documented how attackers weaponized TWCore, a legitimate system application that pushes firmware updates on DoFun head units, to install JarService, a Trojan dropper with no user interface. JarService decrypts and launches a downloader that phones home to a command-and-control server, receives further payloads, and can execute a clicker: malware that inflates ad impressions by making HTTP requests and opening web pages under remote control.

The operators also install a module called zhima that adds infected head units to a botnet used for residential proxy services. Kaspersky tied the operation to MoYu Group and the broader BADBOX malicious platform, which centers on infecting Android devices and reselling their network access. Investigators found infrastructure overlaps with PXYEDGE and ProxyForU, commercial residential proxy services that route client traffic through compromised devices so buyers appear to browse from household IP addresses.

DoFun develops firmware and cloud services for aftermarket Android infotainment systems. Kaspersky cites DoFun's public claim of serving more than 30 million vehicle owners worldwide. The malware does not affect every automotive head unit: only units on DoFun software, delivered silently through the update channel rather than a store download a user could refuse. After disclosure, DoFun addressed the update-channel abuse Kaspersky identified.

That population is different from the defended campaigns in a verification dashboard. These are compromised edge devices monetized for proxy resale and click fraud, not publishers selling authorized inventory. Any bid request that exits through a zhima-infected head unit carries a residential IP and plausible consumer network metadata (model, screen resolution, Wi-Fi SSID, MAC address reported to C2). Post-bid IVT that scores individual impressions may eventually flag anomalous patterns. Pre-bid datacenter CIDR lists will not, because the address is not cloud-hosted.

The mechanism on the bidstream

Residential proxy botnets are not new to programmatic. BADBOX-linked operations already targeted cheap Android TV boxes, tablets, and projectors, running hidden ad activity and reselling proxy access. Kaspersky's conclusion explicitly places car infotainment alongside TV set-top boxes as the next expansion surface. Each new device class adds IPs that look like home broadband to a bidder who only checks whether the address belongs to AWS, Google, or Microsoft.

OpenRTB gives you device.ip, device.ua, device.devicetype, device.make, device.model, and for app traffic app.bundle. None of those fields assert device integrity or distinguish an aftermarket car dashboard from a phone on the same carrier NAT. A head unit running Android can plausibly emit app traffic with a mobile or connected-TV devicetype depending on how the SSP maps automotive hardware. The fraud is in the device state, not in a malformed bundle string.

// What the auction sees vs what happened
"device": {
  "ip": "73.42.18.104",           // residential; passes datacenter block
  "devicetype": 4,                 // phone or tablet, mapping varies
  "make": "Generic",
  "model": "Android head unit"
}

// Not present: compromised via supply-chain updater,
// enrolled in residential proxy + clicker, not a store-listed app surface

Proxy services sit adjacent to, and often upstream of, the ad fraud. Clients buy egress through infected hardware to scrape, credential-stuff, or route automated browsing that generates billable events. When the same module family (zhima) appears across device categories, the programmatic path and the security path converge on one fact: your filters key on network and app identity, while operators key on anything with Android, an update channel, and an always-on connection.

Click fraud on the head unit itself is cruder: remote HTTP and WebView commands under C2 direction. That is closer to classic invalid traffic generation than to spoofed CTV bundle IDs. It still clears pre-bid gates that only exclude datacenter ranges, because the requests originate on a consumer network interface, often the vehicle's Wi-Fi or tethered phone hotspot.

What to do

Treat residential proxy expansion as a supply-path problem, not only a malware headline. Device-class churn (TV boxes, then automotive dashboards) grows the pool of IPs that pass datacenter checks. Split reporting on pre-bid blocks by reason: datacenter CIDR, app deny list, device reputation. A stable datacenter IVT rate can hide proxy-sourced traffic.
Do not infer device class from IP alone. Sample raw CTV and in-app requests in the bid request tester and log when device.make, device.model, and device.devicetype disagree. Automotive aftermarket units often ship generic Android builds.
Keep app-level and network-level filters separate. Delisted bundle blocklists and datacenter IPv4/IPv6 feeds close different holes. Residential botnet traffic can carry a well-formed app.bundle on a clean residential IP.
Validate shape before policy. Reputation and blocklist rules assume parseable device objects. Gate OpenRTB payloads in CI per the validation guide so policy runs on fields that actually populated in production.
Ask SSPs what they reconcile beyond the request. Store listing status, update-channel integrity, and OEM attestation are outside OpenRTB. If the answer is nothing, proxy-sourced residential IPs remain indistinguishable at bid time.

The honest limit

A linter cannot detect compromise, botnet membership, or residential proxy routing. It detects malformed or inconsistent OpenRTB fields. Kaspersky's finding is a reminder that the device behind a clean residential IP is not necessarily the phone or TV your targeting assumed. During BADBOX-scale operations, that gap is large enough to matter in the bidstream even when headline IVT on defended campaigns looks stable.

Sources

Field names are from OpenRTB as published by IAB Tech Lab. The analysis is our own. RTBlint is independent and not affiliated with IAB, IAB Tech Lab, or Kaspersky.