Android Car Malware Hijacks DoFun Head Unit Updaters for Ad Fraud and Proxy Botnet — Detection and Response Guide

Kaspersky researchers have disclosed a new malware family purpose-built to infect Android-based vehicle head unit firmware developed by DoFun — and the delivery mechanism should concern every security team responsible for connected vehicle fleets or automotive aftermarket hardware. Rather than relying on user-installed apps or phishing, this threat spreads through the head units' built-in firmware updater, turning a trusted system component into an initial-access vector.

Once resident, the malware deploys a multi-stage downloader whose endgame is twofold: ad fraud (monetizing the infected unit through fraudulent ad impressions and click simulation) and enrollment into a proxy botnet (renting out the compromised device's network connectivity as a relay node for third-party traffic). This is a supply-chain-adjacent compromise of embedded Android firmware — the same class of threat we've seen hit low-cost Android TV boxes and aftermarket tablets, now firmly established in the automotive space.

For defenders, the urgency is practical: these head units sit on cellular or Wi-Fi networks, often unmanaged by any EDR, and a proxy botnet node inside your vehicle fleet means your IP space and bandwidth are being abused — potentially implicating your organization in the downstream traffic routed through it. Fleet operators, automotive OEM security teams, and enterprises whose executives drive vehicles with aftermarket DoFun-based head units all need detection and containment strategies now.

Technical Analysis

Affected Products and Platforms

• Affected firmware: Android-based vehicle head unit firmware developed by DoFun
• Affected platform: Android Automotive-style aftermarket head units (Android OS on ARM-based embedded hardware)
• Discovery: Kaspersky, June 2026

DoFun firmware is used across a range of aftermarket Android head units — the large touchscreen infotainment replacements commonly sold through online marketplaces and installed in consumer and commercial vehicles alike. These units typically run outdated Android builds with vendor-signed system apps, broad permissions, and little to no independent security review.

Attack Chain

The attack chain, as described by Kaspersky, is notable for its abuse of trust in the update channel:

1. Initial access via the built-in updater. The malware spreads through the head unit's native firmware/OTA update mechanism. This implies either a compromised update server/infrastructure or updater logic that fails to validate the authenticity of downloaded packages — a classic firmware supply-chain weakness. Because the updater runs with system-level privileges on Android, anything it installs inherits elevated trust.

2. Multi-stage downloader. The initial payload is a staging downloader. Rather than shipping the full malicious functionality in one package (which would increase detection surface in firmware images), it pulls down additional modules at runtime. This modular architecture lets the operators rotate payloads and evade static analysis of the firmware itself.

3. Ad fraud module. The infected unit is monetized through fraudulent advertising activity — background ad loading, impression fraud, and likely automated click simulation. On a head unit that is powered whenever the vehicle is running, this generates steady fraudulent revenue for the operators.

4. Proxy botnet enrollment. The second monetization path converts the compromised head unit into a proxy node. Infected devices relay third-party traffic — effectively selling the device's cellular/Wi-Fi connectivity as residential/mobile proxy bandwidth. This is the higher-risk capability from a defender's perspective: traffic routed through a proxy node in a corporate fleet vehicle carries that fleet's IP reputation, and proxy networks are routinely abused for credential stuffing, scraping, fraud, and anonymizing intrusion traffic.

Why This Matters Beyond Consumer Cars

Embedded Android devices are a blind spot in nearly every enterprise security program. They are not enrolled in MDM, not covered by EDR, rarely patched, and frequently run Android versions years out of support. This campaign demonstrates a mature operator playbook: compromise the trusted update channel of a low-scrutiny firmware vendor, stage a downloader, and monetize through fraud plus proxy resale. The same technique works against Android-based point-of-sale systems, kiosks, digital signage, and telematics units.

Exploitation Status

• Confirmed active in the wild — Kaspersky identified infections in June 2026; this is an ongoing campaign, not a proof of concept.
• No CVE has been assigned to this activity as of disclosure; the root weakness (untrusted update channel on DoFun firmware) is a vendor security posture issue rather than a discrete patched vulnerability.
• Not listed in CISA KEV at time of writing. Organizations should monitor KEV and Kaspersky's published indicators for updates.

Detection & Response

Because these are Android embedded devices, traditional endpoint telemetry is limited. Detection has to lean heavily on network-layer observables: egress patterns consistent with ad fraud and proxy relay traffic, plus hunting for the characteristic process and network behavior where the devices or their network segments are monitored. The detections below are engineered to be useful against the behavior (downloader staging, proxy relaying, ad-fraud beaconing) rather than brittle hashes that the operators will rotate.

Sigma Rules

The following rules target observable behaviors of this threat class: unexpected HTTP(S) retrieval of executables by system/updater components, and listening proxy-style services or high-volume egress relay patterns from hosts that should be endpoints-only. Deploy them against telemetry ingested from your network security stack (Zeek/Suricata/Sysmon-on-segment, or EDR covering any managed Android-adjacent infrastructure).

---
title: Suspicious Executable Download Following Updater Activity
description: Detects retrieval of executable/APK payloads over HTTP(S) shortly after updater-related requests, consistent with a multi-stage downloader abusing a built-in update channel, as observed in the DoFun Android head unit malware campaign.
references:
  - https://thehackernews.com/2026/08/android-car-malware-spreads-through.html
  - https://attack.mitre.org/techniques/T1105/
  - https://attack.mitre.org/techniques/T1195/
author: Security Arsenal
date: 2026/08/15
status: experimental
id: 3f8a2c91-6d4e-4b1a-9c72-7e5f1a8d2b44
tags:
  - attack.command_and_control
  - attack.t1105
  - attack.t1195.002
logsource:
  category: webserver
  product: zeek
  service: http
detection:
  selection_useragent:
    user_agent|contains:
      - 'Dalvik/'
      - 'okhttp'
      - 'Android'
      - 'Update'
  selection_uri:
    uri|endswith:
      - '.apk'
      - '.dex'
      - '.so'
      - '.bin'
  condition: all of selection_*
falsepositives:
  - Legitimate OTA firmware updates from vendor-signed update servers (whitelist known vendor update FQDNs)
level: high
---
title: Endpoint Acting as Inbound Proxy Relay
description: Detects hosts that simultaneously maintain an inbound listening service on common proxy ports and generate sustained outbound connections to many distinct destinations, a pattern consistent with enrollment into a proxy botnet as described in the DoFun head unit malware campaign.
references:
  - https://thehackernews.com/2026/08/android-car-malware-spreads-through.html
  - https://attack.mitre.org/techniques/T1090/
author: Security Arsenal
date: 2026/08/15
status: experimental
id: 91c4d7e2-3a68-4f5b-8e1c-2d9a6b4f7e11
tags:
  - attack.command_and_control
  - attack.t1090
logsource:
  category: network_connection
detection:
  selection_listen:
    DestinationPort:
      - 1080
      - 3128
      - 8080
      - 8118
      - 9050
  selection_inbound:
    Initiated: 'false'
  condition: all of selection_*
falsepositives:
  - Legitimate forward proxy servers and web caches (scope rule to endpoint/IoT VLANs, exclude known proxy infrastructure)
level: medium
---
title: High-Volume Egress Beaconing from IoT or Vehicle Network Segment
description: Detects sustained periodic outbound HTTPS connections from IoT/vehicle segments to a small set of rare external destinations, consistent with ad-fraud beaconing and botnet check-in traffic from compromised Android head units.
references:
  - https://thehackernews.com/2026/08/android-car-malware-spreads-through.html
  - https://attack.mitre.org/techniques/T1071.001/
author: Security Arsenal
date: 2026/08/15
status: experimental
id: b27e5f09-4c1d-4a83-9f55-8c3e7a1d6b92
tags:
  - attack.command_and_control
  - attack.t1071.001
logsource:
  category: firewall
detection:
  selection:
    SourceZone|contains:
      - 'iot'
      - 'vehicle'
      - 'guest'
    DestinationPort: 443
    Action: 'allow'
  condition: selection
falsepositives:
  - Legitimate infotainment services, mapping updates, and streaming traffic (tune with per-destination frequency baselining before alerting)
level: low

KQL — Microsoft Sentinel / Defender Hunting

This hunt assumes vehicle/IoT network telemetry is reaching Sentinel via firewall CEF/Syslog ingestion (CommonSecurityLog) or Sysmon-equivalent network connection data. It looks for the two money-making behaviors: devices sourcing high-destination-count egress (proxy relay signature) and repeated small-payload connections to rare domains (ad-fraud/check-in signature).

// Hunt 1: Devices on IoT/vehicle segments exhibiting proxy-relay egress behavior
// (fan-out to many rare destinations over a short window — characteristic of a proxy node)
let rareDests = CommonSecurityLog
    | where TimeGenerated > ago(7d)
    | summarize DeviceCount=dcount(DeviceAddress) by DestinationHostName
    | where DeviceCount < 5
    | project DestinationHostName;
CommonSecurityLog
| where TimeGenerated > ago(24h)
| where DestinationHostName in (rareDests) or DestinationIP in (rareDests)
| where DeviceProduct has_any ("Fortinet", "Palo Alto", "Check Point", "Cisco", "pfSense") or DeviceVendor == "Microsoft"
| summarize DistinctDestinations = dcount(DestinationIP),
            Destinations = make_set(DestinationHostName, 25),
            TotalBytesOut = sum(tolong(SentBytes)),
            ConnectionCount = count()
    by SourceIP, DeviceName
| where DistinctDestinations > 50
| project SourceIP, DeviceName, DistinctDestinations, ConnectionCount, TotalBytesOut, Destinations
| order by DistinctDestinations desc;

// Hunt 2: Periodic small-payload beaconing consistent with ad-fraud / botnet check-in
CommonSecurityLog
| where TimeGenerated > ago(24h)
| where DestinationPort in (443, 80, 8443)
| summarize Connections = count(),
            AvgSentBytes = avg(tolong(SentBytes)),
            FirstSeen = min(TimeGenerated),
            LastSeen = max(TimeGenerated)
    by SourceIP, DestinationIP, DestinationPort
| where Connections > 100 and AvgSentBytes < 2000
| extend BeaconRegularity = datetime_diff("minute", LastSeen, FirstSeen) / Connections
| where BeaconRegularity between (0.5 .. 30)   // connections at regular sub-30-minute intervals
| project SourceIP, DestinationIP, DestinationPort, Connections, AvgSentBytes, BeaconRegularity
| order by Connections desc;

// Hunt 3 (Defender for Endpoint-managed Android or adjacent hosts): process/network correlation
// for updater-spawned download activity
DeviceNetworkEvents
| where TimeGenerated > ago(7d)
| where InitiatingProcessFileName has_any ("updater", "ota", "update", "downloadmanager")
   or InitiatingProcessCommandLine has_any ("update", "ota", "firmware")
| join kind=inner (
    DeviceProcessEvents
    | where TimeGenerated > ago(7d)
    | where FileName has_any ("curl", "wget", "sh", "pm", "install")
    | project ProcessTime=TimeGenerated, DeviceId, FileName, ProcessCommandLine, InitiatingProcessId
) on DeviceId
| project TimeGenerated, DeviceName, InitiatingProcessFileName, InitiatingProcessCommandLine,
          RemoteUrl, RemoteIP, FileName, ProcessCommandLine
| order by TimeGenerated desc;

Velociraptor VQL

For incident responders who gain shell-level access to a suspect head unit (via ADB) or who are hunting Android-adjacent Linux infrastructure that mirrors this tradecraft, this artifact enumerates processes and listeners consistent with proxy-node and downloader behavior.

-- Artifact: Hunt for proxy listeners and suspicious child processes of update components
-- Scope: run against Android head units via ADB-hosted collection or Linux-based telematics gateways

-- Part 1: Processes spawned by or related to updater/OTA components with network-relevant children
SELECT Pid, Ppid, Name, Exe, CommandLine, Username, CreateTime
FROM pslist()
WHERE CommandLine =~ '(?i)(update|ota|firmware|dalvik|app_process)'
   OR Exe =~ '(?i)(/system/bin/(sh|curl|wget|pm)|/data/local/tmp)'
   OR Name =~ '(?i)(proxy|socks|relay)'

-- Part 2: Listening sockets on common proxy/relay ports from non-system processes
SELECT Pid, Name, LocalIP, LocalPort, RemoteIP, RemotePort, State
FROM netstat()
WHERE (LocalPort in (1080, 3128, 8080, 8118, 9050) AND State =~ 'LISTEN')
   OR (State =~ 'ESTABLISHED' AND RemotePort in (443, 8443) AND Name !~ '(?i)(system_server|netd|vold)')

-- Part 3: Recently dropped payloads in world-writable / staging directories
SELECT FullPath, Size, Mtime, Ctime
FROM glob(globs=['/data/local/tmp/**', '/sdcard/Download/**', '/cache/**.apk', '/data/data/**/files/*.dex'])
WHERE Mtime > ago("168h")
ORDER BY Mtime DESC

Remediation / Verification Script

This Bash script is intended for responders with ADB access to a suspect DoFun-based head unit. It inventories installed packages, flags recently installed or suspicious packages, dumps running processes and listeners, and checks the updater configuration for tampered update endpoints. Run it against each unit in a fleet during triage.

#!/bin/bash
# DoFun Android Head Unit Triage Script — run via: adb shell 'bash -s' < triage_dofun.sh
# Requires: rooted ADB shell or shell with sufficient privileges

OUT=/data/local/tmp/triage_$(date +%Y%m%d_%H%M%S).txt
echo "=== DoFun Head Unit Malware Triage — $(date) ===" > "$OUT"

# 1. Device and firmware fingerprint
echo -e "\n[+] Build fingerprint:" >> "$OUT"
getprop ro.build.fingerprint >> "$OUT"
getprop ro.product.manufacturer >> "$OUT"
getprop ro.product.model >> "$OUT"
getprop ro.build.version.security_patch >> "$OUT"

# 2. All installed packages with install timestamps — flag recent/unexpected installs
echo -e "\n[+] Installed packages (3rd-party focus):" >> "$OUT"
pm list packages -3 -f >> "$OUT"
echo -e "\n[+] Recently installed/updated packages:" >> "$OUT"
for pkg in $(pm list packages -3 | sed 's/package://'); do
  INSTALL=$(dumpsys package "$pkg" 2>/dev/null | grep -E 'firstInstallTime|lastUpdateTime')
  echo "$pkg -> $INSTALL" >> "$OUT"
done

# 3. Packages holding dangerous permissions (proxy/ad fraud typically need these)
echo -e "\n[+] Packages with SYSTEM_ALERT_WINDOW / accessibility / device-admin:" >> "$OUT"
pm list packages -g | grep -iE 'SYSTEM_ALERT_WINDOW|BIND_ACCESSIBILITY|DEVICE_ADMIN' >> "$OUT"
dumpsys device_policy | grep -A5 'Active admin' >> "$OUT"

# 4. Running processes — look for downloader/proxy signatures
echo -e "\n[+] Suspicious running processes:" >> "$OUT"
ps -A -o PID,PPID,NAME,ARGS 2>/dev/null | grep -viE 'system_server|netd|vold|zygote|surfaceflinger' | grep -iE 'proxy|socks|relay|curl|wget|/data/local/tmp|\.dex|ad' >> "$OUT"

# 5. Listening sockets — proxy nodes must listen or maintain persistent tunnels
echo -e "\n[+] Listening sockets and established connections:" >> "$OUT"
netstat -anp 2>/dev/null | grep -E 'LISTEN|ESTABLISHED' >> "$OUT"
cat /proc/net/tcp /proc/net/tcp6 2>/dev/null | head -100 >> "$OUT"

# 6. Updater configuration — check for tampered update endpoints
echo -e "\n[+] Updater-related packages and configs:" >> "$OUT"
pm list packages | grep -iE 'updat|ota|firmware' >> "$OUT"
getprop | grep -iE 'update|ota|server|url' >> "$OUT"

# 7. World-writable staging directories commonly abused by droppers
echo -e "\n[+] Files in staging directories (last 7 days):" >> "$OUT"
find /data/local/tmp /sdcard/Download /cache -type f -mtime -7 2>/dev/null >> "$OUT"

echo -e "\n=== Triage complete: $OUT ==="
adb_pull_hint="Pull with: adb pull $OUT"
echo "$adb_pull_hint"

Remediation

There is currently no vendor patch or CVE to track for this campaign — the remediation path is defensive hardening and containment, since the root cause is a compromised/abused update channel in DoFun firmware.

Immediate containment actions:

1. Isolate affected head units at the network layer. Vehicles with DoFun-based head units should not have their infotainment systems bridged to corporate Wi-Fi or fleet management networks. Enforce VLAN/SSID segmentation so head units sit on a restricted IoT segment with tightly scoped egress (deny-by-default outbound except explicitly required services such as mapping and streaming endpoints).

2. Block proxy-relay egress. At the perimeter for the IoT segment, alert on and block inbound connection attempts to listening services on endpoint devices, and cap outbound destination diversity. A legitimate head unit talks to tens of destinations, not thousands.

3. Suspend OTA updates on suspected vulnerable firmware. Until DoFun provides clarity on the integrity of its update channel, disable or firewall the built-in updater's network access. If the updater cannot authenticate its server and validate package signatures, it must be treated as a hostile component.

4. Demand vendor assurance. Contact DoFun (or the head unit reseller) and request: signed firmware with verified boot enforcement, HTTPS-pinned update channels with certificate validation, and a published security advisory addressing this campaign. Absent a credible response, plan hardware replacement — an unpatchable, compromised-by-design update channel is an unmanageable risk.

5. Firmware re-flash from verified media. For confirmed-infected units, a factory reset is insufficient if the updater itself is the vector — the same channel can re-deliver the payload. Re-flash firmware only from media whose integrity you can independently verify, or replace the unit.

Longer-term hardening:

• Inventory embedded Android. You cannot protect what you haven't cataloged. Add automotive head units, telematics gateways, and other Android-based embedded devices to your asset inventory and vulnerability management scope.
• Egress allowlisting for IoT segments. Ad fraud and proxy botnets both require broad outbound connectivity. Default-deny egress with an allowlist breaks both monetization paths even on an infected device.
• Monitor IP reputation. If fleet vehicles share egress IP space with corporate assets, subscribe to IP reputation feeds and alert on your ranges appearing in abuse/proxy lists — this is often the first external indicator of a proxy botnet infection.
• Track the disclosure. Monitor Kaspersky's research blog and CISA KEV for indicators of compromise, C2 infrastructure, and any CVE assignment as the investigation matures. Source: The Hacker News — Android Car Malware Spreads Through Built-In Updaters.

Executive Summary

A new malware family is abusing the trusted built-in updater in DoFun Android-based vehicle head units to deliver a multi-stage downloader, then monetizing infected units through ad fraud and enrollment into a proxy botnet. This is an active, in-the-wild campaign discovered by Kaspersky in June 2026, with no patch available because the weakness is the vendor's update channel itself. Defenders should segment and egress-restrict vehicle/IoT networks immediately, hunt for proxy-relay and beaconing behavior at the network layer, triage suspect units via ADB, and treat unpatchable embedded Android as a replace-not-remediate asset class. The broader lesson: embedded Android firmware supply chains are now a proven initial-access vector, and your detection architecture almost certainly has a blind spot where those devices live.

Related Resources

Security Arsenal Managed SOC Services AlertMonitor Platform Book a SOC Assessment soc-mdr Intel Hub