Malware en las radios Android para automóviles: las actualizaciones se convierten en un canal para el fraude publicitario y las botnets proxy

Una nueva cadena de infección para las head units de DoFun

Los investigadores de Kaspersky identificaron en junio de 2026 una familia de malware diseñada para atacar el firmware de las head units Android desarrolladas por DoFun. Según el análisis publicado, se trata del primer caso documentado de una cadena de infección creada específicamente para sistemas multimedia de automóviles.

El objetivo no es controlar directamente las funciones de conducción, sino convertir la unidad Android en una plataforma para el fraude publicitario y las actividades de proxy. Una vez comprometido el dispositivo, los atacantes pueden instalar módulos adicionales, mostrar contenido no deseado, ejecutar código de forma remota y utilizar la conexión del vehículo para reenviar tráfico.

La amenaza afecta a un área que a menudo se considera simple infotainment. Sin embargo, las head units son ordenadores Android con conectividad, aplicaciones, almacenamiento persistente y, en muchos casos, acceso a Internet mediante una SIM integrada.

El punto débil es la aplicación de actualización

El componente central del ataque es TWCore, una aplicación del sistema con el package com.tw.core. El software desempeña funciones legítimas: recopila datos analíticos y actualiza la head unit mediante la descarga de archivos APK.

Los operadores de MoYu aprovecharon precisamente este mecanismo para distribuir directamente un programa malicioso en las unidades. La comunicación con la infraestructura de actualización se realiza mediante MQTT, utilizando el subdominio cardoor[.]cn. Los paquetes APK se guardan en el directorio:

<TWCore external cache dir>/push/apk/

El abuso se notificó de forma responsable y se corrigió el problema que permitía distribuir software no autorizado. Sin embargo, no se conocen las versiones exactas que contienen la corrección ni un procedimiento público completo para verificar todos los modelos afectados.

El riesgo aumenta porque las head units Android pueden instalarse directamente por los fabricantes o añadirse posteriormente como sistemas aftermarket. Por tanto, la misma superficie de ataque puede abarcar tanto vehículos nuevos como automóviles antiguos actualizados con componentes retrofit.

JarService inicia un downloader de varias etapas

El primer malware identificado en la cadena es un dropper denominado JarService. Su función es evadir los controles iniciales e iniciar un loader encargado de recuperar el payload siguiente.

La secuencia observada por los investigadores funciona de la siguiente manera:

1. el loader recopila información sobre la head unit comprometida;
2. envía los datos a un servidor remoto mediante una solicitud HTTP POST;
3. recibe un enlace al componente siguiente;
4. descarga el payload desde 144.217.243[.]201/vr34der34/dex3.68.png.

La extensión .png no indica necesariamente que se trate de una imagen. El archivo se utiliza como contenedor del código que se instalará. La referencia dex3.68 identifica una versión del payload: al modificar el número en la URL, Kaspersky recuperó siete variantes, incluidas versiones anteriores como 3.57.

Al final de la cadena, el malware se instala como una aplicación de usuario normal. No muestra ventanas ni una interfaz visible y continúa funcionando en segundo plano, lo que reduce las posibilidades de que el propietario del vehículo detecte la infección.

Una infraestructura C2 actualizada a distancia

El componente instalado contacta periódicamente con la infraestructura de mando y control. De forma predeterminada, cada 90 minutos envía una solicitud POST al endpoint /cpc/api/task.

La comunicación incluye datos del dispositivo y de la versión de la configuración local. Si dicha configuración está desactualizada, el servidor proporciona nuevas direcciones C2 y nuevas rutas HTTP. En caso contrario, la respuesta contiene identificadores numéricos de comandos, denominados productId por los operadores.

El troyano asocia cada identificador con los parámetros necesarios y almacena la información en formato JSON serializado mediante SharedPreferences, el mecanismo de Android utilizado normalmente para guardar preferencias de las aplicaciones.

Esta arquitectura permite a los operadores cambiar rápidamente de servidor, rutas e instrucciones sin tener que reinstalar cada vez el componente principal. Por tanto, la intrusión no depende de una infraestructura fija y fácil de bloquear.

Nueve comandos para publicidad, descargas y control remoto

El malware implementa nueve funciones operativas:

• return, para leer y devolver valores presentes en SharedPreferences;
• copy, para modificar el contenido del portapapeles;
• http, para enviar solicitudes HTTP GET o POST;
• web, para abrir contenido en una WebView y ejecutar JavaScript;
• loadlib, preparado para cargar bibliotecas, aunque no está completamente implementado;
• loadlib2, para descargar y ejecutar código desde una URL;
• loadlib3, una segunda función de carga sin terminar;
• deeplink, para abrir direcciones en el navegador;
• traceroute, para comprobar la accesibilidad de un recurso mediante ping ICMP.

Estas capacidades bastan para mostrar anuncios sin consentimiento, generar tráfico publicitario fraudulento e instalar módulos adicionales. La ejecución de JavaScript en WebView amplía aún más el control sobre el contenido cargado.

El malware también recopila información técnica del entorno, como la resolución de pantalla, el modelo de la head unit, el identificador de la red Wi-Fi y la dirección MAC. Estos datos pueden ayudar a los operadores a clasificar los dispositivos y distribuir comandos específicos.

Del fraude publicitario a la red proxy

Uno de los aspectos más relevantes es el uso de los comandos loadlib2 y http para instalar zhima, un módulo reverse proxy asociado anteriormente a campañas realizadas mediante aplicaciones IPTV presentes en económicos Android TV box.

De este modo, una head unit comprometida puede convertirse en un nodo para reenviar tráfico de terceros. La conexión móvil o Wi-Fi del vehículo se utiliza como si perteneciera a un usuario legítimo, mientras el operador mantiene el control del flujo.

La infección cumple, por tanto, dos objetivos relacionados: monetizar el dispositivo mediante ad fraud e incorporarlo a una infraestructura proxy. El propietario podría detectar un consumo anómalo de datos, ralentizaciones o tráfico de red inesperado, pero el malware no muestra señales visibles fiables.

MoYu y el contexto de BADBOX

Kaspersky atribuye la campaña con un alto nivel de confianza a MoYu, un grupo vinculado al esquema BADBOX. Las actividades del grupo ya habían sido expuestas públicamente por el equipo HUMAN Satori Threat Intelligence and Research.

En julio de 2025, Google inició acciones legales contra 25 personas o entidades no identificadas en China, acusándolas de gestionar la botnet BADBOX y su infraestructura asociada. El caso de las head units indica que la operación no se limita a los dispositivos Android económicos comercializados como TV box.

No se sabe si esta campaña concreta afectó a un número determinado de vehículos ni qué mercados fueron los más perjudicados. Tampoco se han indicado identificadores CVE para la vulnerabilidad explotada. Según la información disponible, no hay elementos que sitúen el fallo en el catálogo KEV de CISA.

Qué comprobar en las unidades afectadas

El problema del canal de actualización ya se ha corregido, pero no se conocen las versiones exactas que incluyen la solución. Quienes gestionen vehículos equipados con head units de DoFun deberían comprobar la integridad del firmware y de las aplicaciones del sistema, instalando únicamente actualizaciones proporcionadas por el fabricante o por un distribuidor autorizado.

En materia de monitorización, son indicadores útiles:

• tráfico hacia cardoor[.]cn;
• conexiones con 144.217.243[.]201;
• solicitudes periódicas a /cpc/api/task;
• APK o archivos con referencias de dex3.57 a dex3.68;
• aplicaciones sin interfaz gráfica activas en segundo plano;
• uso anómalo de WebView o descargas de código mediante loadlib2;
• tráfico compatible con un reverse proxy.

La presencia de uno de estos indicadores no demuestra por sí sola que exista una infección. Sin embargo, puede justificar un análisis forense del firmware y de las aplicaciones instaladas. Como no se ha publicado un procedimiento operativo detallado de limpieza, la reinstalación del software debe realizarse únicamente con imágenes oficiales y siguiendo los procedimientos del fabricante.