BADBOX Proxyware Hits Android Car Head Units: Detection, Containment, and Remediation Guide

In June 2026, Kaspersky researchers published findings on a campaign that should concern every organization operating a fleet of Android-based automotive infotainment systems — and every security team responsible for segmenting IoT/OT-style devices from production networks. The malware in question abuses the infotainment update mechanism on aftermarket and OEM Android car head units to silently install proxy software, enrolling those devices as nodes in the BADBOX network.

The detail that made Kaspersky's analysts stop and look twice: an Android application with no user interface at all, installed like any ordinary app, making zero effort to disguise itself. That brazenness tells you something important — the operators behind this campaign know that head units are effectively unmanaged endpoints. Nobody runs EDR on a dashboard. Nobody reviews installed packages on a car stereo. That visibility gap is exactly what's being monetized.

This is not a hypothetical. BADBOX — first exposed in 2023 for shipping pre-installed on low-cost Android devices — has evolved into a persistent, large-scale operation that converts compromised Android devices into residential proxy exit nodes. Those proxies are then sold or rented to other criminals for ad fraud, credential stuffing, account takeover, and anonymized attack infrastructure. If your head units are talking to the internet, they can be drafted into someone else's botnet.

Technical Analysis

What's affected

• Platform: Android-based automotive head units — primarily aftermarket units (often white-labeled, sourced from the same ODM supply chains that seeded the original BADBOX firmware compromises), but any Android infotainment system that accepts third-party or sideloaded updates is in scope.
• Delivery vector: The infotainment update channel — either a compromised/malicious OTA update server, a tainted firmware update package, or an update mechanism that accepts unauthenticated or unsigned packages.
• Payload: A headless Android application (no launcher icon, no activity, no UI) whose sole function is to install and operate proxyware — software that relays third-party traffic through the device's internet connection.

Attack chain (defender's view)

1. Delivery: The malicious APK arrives via the update path — either pushed through a compromised update infrastructure or bundled into a firmware image the user/dealer installs.
2. Installation: The app installs silently. On many aftermarket head units, the update process runs with system or elevated privileges, so the payload can install without user consent dialogs.
3. Persistence: As a package on the device, it survives reboots via Android's BOOT_COMPLETED broadcast receiver — standard Android persistence, no exploit required.
4. C2 enrollment: The headless app beacons out to BADBOX command-and-control infrastructure to register the device as an available proxy node, typically over HTTPS to blend with legitimate traffic.
5. Monetization: The device begins relaying third-party traffic. From the network's perspective, this looks like an infotainment unit generating sustained outbound sessions to unusual destinations on non-standard ports.

Why the "no disguise" detail matters

Traditional Android malware hides: fake system app names, icon-less launchers, obfuscated package names masquerading as Google services. This sample doesn't bother. That's a strong indicator the threat actors' threat model assumes no human will ever audit the installed package list on a head unit. For defenders, that flips the script: a simple package inventory is a high-fidelity detection mechanism because the malware isn't evading it.

Exploitation status

• Confirmed in the wild. This is an active campaign documented by Kaspersky in June 2026, not a theoretical proof of concept.
• No CVE has been assigned in the reporting — this is a supply-chain/update-channel abuse, not a memory-corruption bug. The "vulnerability" is the trust model of the update mechanism and the absence of package auditing on automotive Android builds.
• Connection to BADBOX: The installed proxy software feeds the BADBOX residential proxy network, which has been the subject of prior FBI and industry disruption efforts. The operation has repeatedly reconstituted itself by shifting to new device classes — head units are the latest frontier.

The enterprise risk most people miss

"It's just a car stereo" is the wrong mental model. Consider:

• Fleet vehicles with cellular-connected head units become mobile proxy exit nodes on your corporate data plans.
• Head units that join workshop, dealership, or depot Wi-Fi inherit that network's egress identity — meaning criminal traffic (fraud, scanning, C2 relay) exits from your IP space, creating attribution and abuse-desk headaches, potential blocklisting of corporate IP ranges, and legal exposure.
• A device with an established outbound C2 channel and proxy capability is a pivot point. Residential proxy networks are routinely abused to launder traffic for intrusions. A compromised head unit bridged onto a flat network is an attacker-controlled relay inside your perimeter.

Detection & Response

SIGMA Rules

These rules target the network-observable behaviors of proxyware enrollment and operation. They assume you are ingesting firewall/DNS logs with device VLAN attribution — if your head units live on a dedicated IoT VLAN (and they should), these fire with high fidelity and low noise.

---
title: Outbound Connection from IoT/Infotainment VLAN on Non-Standard Port
id: 3f8a1c24-7b6e-4d91-a2f5-9c4e8b1d6a30
status: experimental
description: Detects outbound connections originating from IoT/infotainment device segments to high-numbered non-standard ports, consistent with proxyware enrollment and residential proxy relay behavior seen in BADBOX-infected Android head units.
references:
  - https://securityaffairs.com/197700/hacking/malware-hijacks-android-car-head-units.html
  - https://attack.mitre.org/techniques/T1090/
author: Security Arsenal
date: 2026/07/01
tags:
  - attack.command_and_control
  - attack.t1090
logsource:
  category: firewall
  product: network
detection:
  selection_src:
    src_ip|cidr:
      - '10.60.0.0/24'
      - '172.20.0.0/24'
  selection_dst_port:
    dst_port|gte: 1025
  filter_common:
    dst_port:
      - 8080
      - 8443
      - 3478
      - 5060
    action: 'allowed'
  condition: selection_src and selection_dst_port and not filter_common
falsepositives:
  - Legitimate OTA update traffic to vendor CDNs on high ports - baseline vendor update destinations and allowlist them
  - Streaming media services legitimately used by infotainment units
level: medium
---
title: Sustained Egress Session Volume from Single IoT Device
id: 8c2d5e17-4a9b-4f38-b6c1-2e7a9d3f5b84
status: experimental
description: Detects an infotainment/IoT device maintaining an abnormally high count of distinct outbound destination IPs within a short window, consistent with residential proxy node operation relaying third-party traffic as documented in the BADBOX head unit campaign.
references:
  - https://securityaffairs.com/197700/hacking/malware-hijacks-android-car-head-units.html
  - https://attack.mitre.org/techniques/T1090.002/
author: Security Arsenal
date: 2026/07/01
tags:
  - attack.command_and_control
  - attack.t1090.002
logsource:
  category: firewall
  product: network
detection:
  selection:
    src_ip|cidr:
      - '10.60.0.0/24'
      - '172.20.0.0/24'
    action: 'allowed'
  condition: selection
falsepositives:
  - Navigation/map tile downloads and streaming services generate multiple CDN connections - correlate with session count thresholds (e.g., >50 distinct destinations per 10 minutes) at the SIEM layer
level: high
---
title: DNS Query for Dynamic DNS Domain from IoT Segment
id: 5b1e9c83-6d4f-4a72-9e8b-1f3c7a2d8e56
status: experimental
description: Detects DNS resolution of free dynamic-DNS provider domains from IoT/infotainment network segments. BADBOX-family proxyware frequently uses DDNS infrastructure for resilient C2 enrollment on unmanaged Android devices.
references:
  - https://securityaffairs.com/197700/hacking/malware-hijacks-android-car-head-units.html
  - https://attack.mitre.org/techniques/T1568.001/
author: Security Arsenal
date: 2026/07/01
tags:
  - attack.command_and_control
  - attack.t1568.001
logsource:
  category: dns
  product: network
detection:
  selection:
    query|contains:
      - '.duckdns.org'
      - '.no-ip.com'
      - '.ddns.net'
      - '.hopto.org'
      - '.zapto.org'
      - '.sytes.net'
  filter_iot_dns:
    src_ip|cidr:
      - '10.60.0.0/24'
      - '172.20.0.0/24'
  condition: selection and filter_iot_dns
falsepositives:
  - Rare - infotainment devices have virtually no legitimate reason to resolve dynamic DNS hostnames
level: high

A note on tuning: Replace the example CIDRs (10.60.0.0/24, 172.20.0.0/24) with your actual IoT/infotainment segments. If your head units are not yet segmented, these rules won't work — which is itself the first remediation finding.

KQL — Microsoft Sentinel / Defender

This hunt assumes firewall and DNS logs are ingested into Sentinel via CEF/Syslog (CommonSecurityLog, Syslog) or that Defender for Endpoint network events cover managed Android devices in the fleet. It looks for the behavioral signature of proxy enrollment: an IoT-segment device building an unusually broad outbound connection graph.

// Hunt: Infotainment/IoT devices with proxy-like egress behavior (BADBOX head unit campaign)
// Tuning: replace the IoT subnet list with your environment's segments
let IoTSegments = dynamic(["10.60.0.0/24", "172.20.0.0/24"]);
let Lookback = 24h;
CommonSecurityLog
| where TimeGenerated > ago(Lookback)
| where ipv4_is_in_any_range(SourceIP, IoTSegments)
| where isnotempty(DestinationIP) and DestinationPort > 1024
| summarize
    DistinctDestinations = dcount(DestinationIP),
    DistinctPorts = dcount(DestinationPort),
    TotalConnections = count(),
    SampleDestinations = make_set(DestinationIP, 20),
    FirstSeen = min(TimeGenerated),
    LastSeen = max(TimeGenerated)
    by SourceIP, DeviceName
| where DistinctDestinations > 40 or DistinctPorts > 25
| project SourceIP, DeviceName, DistinctDestinations, DistinctPorts, TotalConnections, SampleDestinations, FirstSeen, LastSeen
| order by DistinctDestinations desc;
// Secondary: DNS layer - DDNS resolution from IoT segments
let IoTSegments = dynamic(["10.60.0.0/24", "172.20.0.0/24"]);
Syslog
| where TimeGenerated > ago(24h)
| where SyslogMessage has_any ("duckdns.org", "no-ip.com", "ddns.net", "hopto.org", "zapto.org", "sytes.net")
| extend SourceIP = extract(@"src=(\d{1,3}\.\d{1,3}\.\d{1,3}\.\d{1,3})", 1, SyslogMessage)
| where ipv4_is_in_any_range(SourceIP, IoTSegments)
| project TimeGenerated, Computer, SourceIP, SyslogMessage
| order by TimeGenerated desc;

The thresholds (DistinctDestinations > 40) are starting points. Baseline one known-clean head unit for a week first — legitimate navigation and streaming traffic clusters around a small set of CDN destinations, so proxy relay behavior stands out sharply once baselined.

Velociraptor VQL

Velociraptor does not deploy to Android head units directly, but it is valuable in two adjacent scenarios: (1) hunting workshop/service PCs and dealer management systems that flash or push firmware to head units (a likely upstream compromise point in an update-channel abuse), and (2) hunting for proxyware-style listening services on any managed endpoints that share segments with fleet devices.

-- Hunt: Suspicious listening services and proxy-relay connections on systems
-- that manage or share network segments with Android head units.
-- Looks for unexpected listeners on high ports and processes with
-- proxy-typical connection fan-out.
SELECT Pid,
       Name,
       Path,
       Address AS LocalAddress,
       Port AS LocalPort,
       Status,
       Family
FROM netstat()
WHERE Status =~ 'LISTEN'
  AND Port > 1024
  AND NOT Name =~ '(?i)(svchost|system|lsass|dnsmasq|sshd|cups|nginx|apache|postgres|mysql|mssql)'
ORDER BY Port ASC

-- Hunt: Processes with high outbound connection fan-out (proxy relay behavior)
-- on endpoints adjacent to fleet/IoT segments.
SELECT Pid,
       Name,
       Path,
       Address AS RemoteAddress,
       Port AS RemotePort,
       Status
FROM netstat()
WHERE Status =~ 'ESTABLISHED'
  AND Family =~ 'tcp'
  AND Port > 1024
  AND NOT Address =~ '^(10\.|192\.168\.|172\.(1[6-9]|2[0-9]|3[01])\.)'

Review hits for unsigned binaries, binaries executing from user-writable or temp paths, and processes whose names spoof system services but resolve to unexpected Path values — all classic proxyware tells.

Remediation & Verification Script

The following Bash script audits an Android head unit over ADB (Android Debug Bridge) — the standard field method for fleet operators and forensic examiners. Run it per device during a service window. It inventories packages, flags headless/suspicious installs, checks persistence hooks, and captures network state for offline analysis.

#!/bin/bash
# badbox_headunit_audit.sh - Audit an Android head unit for BADBOX-style proxyware
# Usage: ./badbox_headunit_audit.sh <device_serial_or_ip:port>
# Prereq: ADB enabled on the head unit (USB or network), adb in PATH

DEVICE="$1"
OUTDIR="./headunit_audit_$(date +%Y%m%d_%H%M%S)"
mkdir -p "$OUTDIR"

if [ -z "$DEVICE" ]; then
  echo "Usage: $0 <device_serial_or_ip:port>"; exit 1
fi

echo "[*] Connecting to $DEVICE ..."
adb connect "$DEVICE" 2>/dev/null || true
ADB="adb -s $DEVICE"

# 1. Full package inventory - baseline this against a known-good unit
echo "[*] Dumping installed packages..."
$ADB shell pm list packages -f > "$OUTDIR/packages_full.txt"
$ADB shell pm list packages -3 > "$OUTDIR/packages_thirdparty.txt"

# 2. Flag packages with NO launcher activity (headless apps - the Kaspersky tell)
echo "[*] Identifying headless packages (no launcher activity)..."
for pkg in $(cat "$OUTDIR/packages_thirdparty.txt" | sed 's/package://'); do
  LAUNCHER=$($ADB shell cmd package resolve-activity --brief -a android.intent.action.MAIN -c android.intent.category.LAUNCHER "$pkg" 2>/dev/null | tail -1)
  if echo "$LAUNCHER" | grep -qi "No activity found"; then
    echo "HEADLESS: $pkg" >> "$OUTDIR/suspicious_headless.txt"
  fi
done

# 3. Flag packages holding BOOT_COMPLETED (persistence) and proxy/VPN-relevant permissions
echo "[*] Checking persistence and proxy-relevant permissions..."
$ADB shell dumpsys package | grep -B2 "android.permission.RECEIVE_BOOT_COMPLETED" > "$OUTDIR/boot_receivers.txt"
$ADB shell dumpsys package | grep -B2 -E "android.permission.(BIND_VPN_SERVICE|FOREGROUND_SERVICE|SYSTEM_ALERT_WINDOW)" > "$OUTDIR/risky_permissions.txt"

# 4. Check for recently installed/updated packages (matches update-channel abuse timeline)
echo "[*] Recent installs/updates..."
$ADB shell dumpsys package | grep -E "Package \[|firstInstallTime|lastUpdateTime" > "$OUTDIR/install_timeline.txt"

# 5. Live network state - look for established sessions to unusual external IPs/ports
echo "[*] Capturing network state..."
$ADB shell netstat -anp 2>/dev/null > "$OUTDIR/netstat.txt" || $ADB shell cat /proc/net/tcp > "$OUTDIR/netstat_proc.txt"

# 6. VPN interface check - active tun interfaces on a head unit are a red flag
echo "[*] Checking for VPN/tunnel interfaces..."
$ADB shell ip addr show 2>/dev/null | grep -E "tun|ppp|wireguard" > "$OUTDIR/vpn_interfaces.txt"

# 7. ADB-over-network exposure check - port 5555 listening is a lateral movement risk
$ADB shell netstat -an 2>/dev/null | grep ":5555" > "$OUTDIR/adb_exposure.txt"

echo "[*] Audit complete. Review artifacts in $OUTDIR"
echo "[!] Priority review: suspicious_headless.txt, vpn_interfaces.txt, adb_exposure.txt"

Any package appearing in suspicious_headless.txt that is not a documented vendor component should be treated as malicious until proven otherwise: capture the APK (adb shell pm path <pkg> then adb pull) for hash analysis and sandbox detonation before removal, and preserve it as evidence if the vehicle is part of a fleet incident.

Remediation

There is no patch CVE to apply here — the fix is architectural and procedural. Prioritize in this order:

Immediate (24–72 hours)

1. Isolate the segment. Place all head units — fleet vehicles, showroom demos, service-loaner units — on a dedicated IoT VLAN with default-deny egress. Allowlist only the vendor's documented update CDNs and required navigation/streaming services. This single control neutralizes the proxy monetization model even on already-infected devices.
2. Run the ADB audit (script above) across your fleet, prioritizing aftermarket units and any device that received an update in the last 90 days.
3. Check egress IP reputation. Query your perimeter/abuse contacts for complaints against IP ranges used by vehicle or workshop networks. Proxy relay traffic frequently triggers abuse reports before internal detection does.
4. Block ADB-over-network (TCP/5555) fleet-wide. There is no legitimate reason for head units to expose ADB on the network in production.

Short term (1–4 weeks)

5. Rebuild, don't clean. For confirmed-infected head units, reflash with vendor-signed firmware obtained directly from the manufacturer — never reuse the update package that was on the device. Package removal alone is unreliable against payloads installed with elevated privileges through the update channel.
6. Establish a package baseline. Capture pm list packages -f from a known-good unit per model/firmware version. Diff every future audit against it. The malware's lack of disguise makes baseline diffing a near-perfect control.
7. Vendor engagement. Demand from your head unit suppliers: signed OTA packages with enforced signature verification, a published update-server domain list (for your allowlist), and an SBOM for the firmware. If the vendor cannot provide signed updates, that is a procurement finding.

Strategic

8. Treat update channels as supply chain. The infotainment update path is now a demonstrated attack vector. Include automotive/fleet IoT update mechanisms in your third-party risk assessments and require update-integrity controls (code signing, TLS-pinned update endpoints, staged rollout) in contracts.
9. Continuous egress monitoring. Deploy the Sigma/KQL content above with your actual segments. BADBOX has survived multiple disruption operations by migrating device classes — assume re-infection pressure persists.
10. Incorporate into IR playbooks. Add "compromised fleet/IoT device used as proxy infrastructure" as a scenario in your incident response runbooks, including evidence preservation (APK capture, netstat, install timeline) before reflashing.

Why this matters beyond vehicles

The Kaspersky finding is a proof point for a broader truth: any unmanaged Android device with internet egress is a candidate proxy node. The same update-channel abuse pattern applies to cheap Android TV boxes, digital signage, tablets, and point-of-sale adjuncts. If your segmentation strategy still treats these devices as benign appliances, this campaign is your justification to revisit it — this quarter, not next year.

Related Resources

Security Arsenal Incident Response Services AlertMonitor Platform Book a SOC Assessment incident-response Intel Hub