Kaspersky detecta malware en head units Android de coches: primer caso automotriz

El primer malware documentado en un head unit de coche

Kaspersky ha revelado el primer caso documentado de malware con una cadena de infección específica para head units Android de vehículos. El hallazgo, atribuido con alta confianza al MoYu Group —uno de los actores vinculados al botnet BADBOX—, se descubrió en junio de 2026 mientras el equipo de la investigadora Dmitry Kalinin monitorizaba amenazas Android. Lo inusual: el troyano se instalaba como una app de usuario cualquiera, sin interfaz visible, lo que delataba un mecanismo de propagación sin intervención del usuario.

El vector de ataque es el TWCore (com.tw.core), una app legítima preinstalada en head units del fabricante DoFun, responsable de收集 analítica y推送 actualizaciones. TWCore se conecta a un broker MQTT en cardoor[.]cn y descarga APKs a <TWCore external cache dir>/push/apk/. Un campo booleano llamado installNotExists permite instalar paquetes que no estaban previamente en el dispositivo —y es justo lo que explotaron los atacantes.

Cómo es la cadena de infección JarService → Zhima

Kaspersky descompuso la cadena en tres etapas:

👥 ¿Quieres ir más allá de la noticia?

En nuestra comunidad discutimos las tendencias, compartimos oportunidades y nos ayudamos entre emprendedores. Sin humo, solo acción.

👥 Unirme a la comunidad

Etapa 1 — JarService: un dropper sin UI que descifra bloques XOR con clave lineal, serializando la versión del payload y el entry point (com.c.j.qbh.wa).
Etapa 2 — Loader: envía información del implante al C2 vía POST (userId, dexVersion, packageName: com.tw.jar1) y recibe un enlace para descargar la etapa 3. Kaspersky probó distintos números de versión y recuperó siete variantes distintas del payload, la más antigua la 3.57.
Etapa 3 — Clicker / Reverse proxy loader: envía un POST cada 90 minutos a /cpc/api/task con datos del dispositivo (resolución, SSID, MAC) y descarga el módulo Zhima, un reverse proxy que también fue identificado en TV boxes Android por Nokia Deepfield Emergency Response Team según The Hacker News.

El malware soporta nueve comandos (return, copy, http, web, loadlib, loadlib2, loadlib3, deeplink, traceroute); los atacantes usaban principalmente loadlib2 y http para desplegar Zhima y para cometer ad fraud. Los dominios y hashes de la cadena aparecen al final del reporte de Kaspersky como IoCs.

¿Quién está detrás? La pista MoYu y el rastro BADBOX

La atribución llega por una pista casi artesanal: el loader de la etapa 2 crea un hilo con el nombre mosdk-host-loader. Investigando, los analistas encontraron en TV boxes una app maliciosa con paquete com.abc.nexus cuyo servicio de descarga se llama AdmoyuService. La cadena apunta al MoYu Group, uno de los operadores detrás de BADBOX, la plataforma descrita por HUMAN Security y demandada por Google en julio de 2025.

The Hacker News recuerda que Google demandó en Nueva York a 25 entidades chinas sin identificar por operar la infraestructura de BADBOX 2.0 y un esquema de residential proxy que compromete a más de 10 millones de dispositivos Android no certificados. En la misma línea, un análisis de Cloud Security Alliance documenta que BADBOX 2.0 y la operación paralela Kimwolf llegaron a controlar entre 1,8 y 2 millones de dispositivos, con C2 en dominios como catmore88[.]com e ipmoyu[.]com, y que cerca del 25% de los clientes empresariales de Infoblox consultaron dominios C2 de Kimwolf desde octubre de 2025.

La infraestructura del nuevo ataque —el panel de administración en admin.uipoxy[.]com y los Términos de Servicio en pxyedge[.]com— vincula al actor con ProxyForU, un vendor chino de residential proxies comercial. No es un actor nuevo: es una rama de un ecosistema criminal que sobrevive a los takedowns.

¿Por qué importa este caso al ecosistema startup?

Tres lecturas que cualquier founder tech debería llevarse:

El head unit ya es un endpoint IoT de primera clase. Con SIM, conexión a internet y un stack Android sobre el que corre "casi cualquier malware de smartphone", el coche se ha convertido en un objetivo rentable para ad fraud y proxy abuse. No lo es para banking trojans, pero sí para redes residenciales y fraude publicitario.
El firmware y los canales de update son el nuevo perímetro. Si tu producto tiene actualizaciones OTA, cualquier error en la firma, transporte o lógica de instalación se convierte en vector de ataque. La regla installNotExists del firmware DoFun es el ejemplo perfecto de cómo un atajo de fabricante abre la puerta a un dropper.
El fraude publicitario y el residential proxy son negocios criminales escalables. Zhima convierte un dispositivo comprometido en un nodo de tráfico revendible. Para un atacante, monetizar 1 millón de dispositivos cabe en una hoja de cálculo.

Qué significa esto para tu startup

Si estás construyendo o integrando hardware conectado —ya sea un head unit, una TV box, una cerradura inteligente o un datalogger industrial—, este caso redefine el suelo mínimo de seguridad:

Audita el canal de update de tu dispositivo. Cualquier app del sistema con permiso para instalar APKs debe verificar la firma del paquete, validar el origen del manifiesto y exigir confirmación out-of-band para apps nuevas. Lo que hizo TWCore —aceptar un APK enviado por un broker MQTT si installNotExists=true— es exactamente lo que tu equipo de firmware no debe hacer.
Aísla los componentes críticos del subsistema multimedia. Aunque hoy el malware de un head unit robe ancho de banda para ad fraud, mañana podría abrir un WebView con JavaScript arbitrario (web), copiar al portapapeles (copy) o ejecutar código arbitrario (loadlib2). Separar la red del infoentretenimiento de la red crítica del vehículo no es opcional.
Exige certifiación y provenance a tus fabricantes. El FBI ya advirtió en junio de 2025 que BADBOX se distribuye por dispositivos comprados en retail sin certificación de Google. Si integras un OEM chino barato, asume que podrías estar revendiendo malware preinstalado. Pide SBOMs, attestation de firmware y auditorías de fábrica.

El tamaño del problema

El mercado global de cibersecguridad para coches se estimó en USD 4.750 millones en 2026 y proyecta alcanzar USD 10.030 millones en 2031, con una CAGR del 16,12%, según ResearchAndMarkets. El dato relevante para founders: el 95% de los ciberataques automotrices son remotos y el 43% de los incidentes reportados involucran servidores backend. UNECE R155 obliga a los fabricantes a gestionar 69 vectores de ataque a lo largo del ciclo de vida del vehículo, lo que abre una oportunidad de USD 2.100 millones en servicios de cumplimiento hasta 2030.

Para founders hispanos, la lectura es directa: hay mercado real y compliance obligatorio en Europa. Si tu startup sabe asegurar firmware, automatizar pentests de componentes automotrices o auditar supply chains de IoT chino, el volumen de demanda ya está en el reporte de ResearchAndMarkets.

Lecciones del lado defensivo

La cadena de infección de DoFun no es sofisticada desde el punto de vista técnico —XOR con clave lineal, loaders por etapas, C2 con POST cada 90 minutos—. Lo que la hace dañina es operacional: escala, monetización probada y la pasividad del usuario. Un head unit comprometido no muestra síntomas visibles, no aparece en antivirus porque el malware se ejecuta sin UI, y se beneficia de la SIM integrada del vehículo.

La respuesta de la industria no puede seguir siendo la del smartphone. Como advierte el propio Kalinin: "esto sirve como advertencia de que las plataformas automotrices modernas requieren urgentemente protección robusta contra el malware". Si construyes para automoción o IoT, asume que tu próximo CVE también será un vector de distribución de malware, no solo una nota en un changelog.