Un nuevo caso de malware Android en coches ha encendido las alarmas en el sector de la seguridad. Según Kaspersky, la amenaza fue detectada en 2026 y está diseñada para comprometer el firmware de las unidades de cabina de vehículos con base Android, aprovechando herramientas de actualización integradas para distribuir la carga maliciosa.
El objetivo final no se limita a tomar el control: el malware se orienta a habilitar un descargador de varias etapas, facilitar el fraude publicitario y contribuir a la creación de una red proxy controlada por atacantes. Este enfoque convierte la unidad de cabina —un centro que combina funciones multimedia con ciertos aspectos de operación del vehículo— en un objetivo crítico.
Por qué las unidades de cabina Android atraen a los atacantes
La unidad de cabina actúa como un “hub” de funcionalidades. Puede venir de fábrica o instalarse en vehículos más antiguos mediante mejoras del mercado de accesorios. A medida que las opciones con Android ganan popularidad, también aumenta la superficie de ataque.
Un punto clave es la conectividad. Muchas unidades Android incorporan una ranura para SIM, lo que permite acceso a internet para navegación y para descargas de software y actualizaciones. Eso, que en principio es útil para el usuario, también puede ser aprovechado por atacantes si logran manipular el proceso de actualización.
Cómo se propaga: el abuso de actualizadores integrados
En este caso documentado, el malware se distribuye a través del mecanismo de actualización embebido en el firmware de modelos con base Android. Investigaciones señalan que el vector está relacionado con actualizadores de la plataforma de unidades de cabina desarrolladas por DoFun.
El primer componente opera como una aplicación de sistema legítima llamada TWCore (com.tw.core). Su finalidad es recopilar analíticas y actualizar el software de la unidad mediante la descarga de archivos APK. Para ello, hace uso de un broker MQTT publicado en un subdominio asociado a “cardoor”.
Cuando llega una actualización, el APK se descarga en una ruta de caché externa dentro de la unidad, preparada para que el sistema lo instale. El problema surge porque los atacantes “armaron” este canal confiable para entregar el malware.
JarService y la cadena de infección en varias etapas
La campaña identifica un componente tipo “dropper” llamado JarService. Su rol es arrancar un cargador que inicia comunicaciones con los servidores de los atacantes y, a partir de la respuesta recibida, obtiene la siguiente carga maliciosa.
El flujo reportado por Kaspersky incluye, primero, el envío de información del implante mediante una petición HTTP POST hacia un servidor controlado por los atacantes. Después, el servidor responde con un enlace para descargar el payload de la siguiente etapa.
El nombre del archivo de carga incluye un fragmento que referencia versiones (por ejemplo, “dex3.68”). Esto permite que el equipo de seguridad pueda recuperar distintos variantes probando otros números de versión, encontrando múltiples iteraciones que datan desde “3.57”.
El malware se comporta como una app “normal”, pero sin interfaz
Al finalizar la cadena, la amenaza se instala como una aplicación de usuario. Sin embargo, no muestra interfaz. En la práctica, funciona en segundo plano y está preparada para realizar tareas automatizadas orientadas a su objetivo.
Uno de los elementos centrales es su comunicación periódica con el servidor de mando y control (C2). De manera predeterminada, envía peticiones cada 90 minutos a un endpoint concreto (se menciona “/cpc/api/task”), incluyendo información del dispositivo comprometido y su versión de configuración.
Según Kaspersky, si el servidor determina que la configuración está desactualizada, devuelve una configuración nueva con direcciones C2 adicionales y rutas nuevas para las solicitudes HTTP. Si no hace falta cambiarla, el C2 retorna identificadores numéricos (descritos como “productId”), que la aplicación traduce a acciones.
Comandos para anuncios, fraude y ejecución de módulos
El malware implementa un conjunto de comandos que permiten actividades como mostrar anuncios no deseados, ejecutar fraude publicitario y descargar módulos adicionales. Para gestionar los comandos, el troyano mapea identificadores con información asociada, guardándola como un objeto JSON serializado usando la API SharedPreferences.
Entre las acciones descritas se encuentran:
- return: devolver un valor desde SharedPreferences.
- copy: establecer el contenido del portapapeles.
- http: realizar solicitudes HTTP (POST o GET) a un recurso especificado.
- web: abrir un enlace en WebView y ejecutar código JavaScript dentro de ese contexto.
- loadlib2: descargar y ejecutar código arbitrario desde una URL.
- deeplink: abrir una URL en el navegador.
- traceroute: verificar disponibilidad de recursos con un ping ICMP.
Se mencionan, además, comandos como loadlib y loadlib3 como no implementados completamente en el material analizado.
Conexión con redes proxy y módulos de reenvío
El análisis atribuye alta confianza a un grupo vinculado al esquema BADBOX, asociado anteriormente con fraudes publicitarios y redes residenciales de proxy. El informe también recuerda que, en el pasado, Google presentó una demanda relacionada con individuos o entidades no especificadas en China por operar la infraestructura de BADBOX.
Dentro del caso actual, se indica que los atacantes aprovechan comandos como loadlib2 y http para descargar un módulo llamado “zhima”. Ese componente actúa como un proxy inverso y aparece documentado por un equipo de respuesta ante emergencias de Nokia Deepfield. Además, se describe como un módulo que se entrega de forma selectiva en contextos donde ya existe software instalado en dispositivos de bajo costo con Android TV.
En resumen: la unidad de cabina funciona como puerta de entrada, pero la maquinaria final busca mantener el control, orquestar comunicaciones y habilitar los efectos deseados sobre publicidad y encaminamiento de tráfico.
El mensaje para la seguridad automotriz
Tras el proceso de divulgación responsable, el problema que impulsa el abuso del flujo de distribución de software se abordó. Aun así, los investigadores advierten sobre el riesgo que representan estos patrones: un canal de actualización legítimo puede transformarse en una vía de entrega de malware si un actor consigue manipularlo.
Kalinin subraya que este sería el primer caso documentado de malware con una cadena de infección específica para unidades de cabina de vehículos. Esto, en su lectura, funciona como una señal de alerta: las plataformas automotrices modernas necesitan mecanismos de protección robustos, especialmente en áreas como actualizaciones y comunicación remota.
Qué puedes hacer para reducir el riesgo
Aunque el caso descrito es específico, hay principios generales que ayudan a disminuir el impacto de este tipo de amenazas.
- Aplicar actualizaciones solo desde canales confiables del fabricante o proveedor.
- Desconfiar de instalaciones procedentes de fuentes no verificadas, especialmente archivos APK.
- Revisar permisos y comportamiento de aplicaciones del sistema cuando sea posible en el ecosistema del vehículo.
- Monitorizar conectividad: detectar actividad de red inusual puede ser una señal temprana.
Conclusión
El hallazgo muestra cómo el malware Android en coches puede aprovechar la confianza de los mecanismos integrados para entregarse y desplegarse en segundo plano, sin interacción visible. Al abusar de actualizadores del firmware y de aplicaciones de sistema legítimas, los atacantes logran una cadena de infección capaz de impulsar fraude publicitario y contribuir a botnets proxy.
La lección es clara: en el entorno automotriz conectado, proteger la ruta de actualización y las comunicaciones de la unidad de cabina es tan importante como endurecer el software del vehículo en sí.
Fuente: https://thehackernews.com/2026/08/android-car-malware-spreads-through.html
