Autores
En junio de 2026, durante el monitoreo de amenazas para Android, identificamos un nuevo malware para Android. Nos pareció extraño que se instalara como una aplicación de usuario común, pero sin camuflarse como software legítimo (no tenía interfaz). Esto nos llevó a sospechar que esta aplicación podía aparecer en los dispositivos de los usuarios sin que se dieran cuenta. En la investigación posterior, confirmamos esta hipótesis y reconstruimos toda la cadena de infección.
Nuestras conclusiones, en resumen:
- Identificamos un nuevo malware para Android: un cargador multietapa cuyo objetivo final es el fraude publicitario y la creación de una botnet de proxy.
- El malware se propagaba mediante los mecanismos de actualización de software integrados en el firmware de las unidades centrales multimedia (Head Unit) Android. Este es el primer caso documentado de malware dirigido a la unidad central multimedia de un automóvil, con una cadena de infección diseñada de forma específica para este tipo de dispositivo.
- Atribuimos esta actividad, con alto grado de certeza, al actor MoYu Group, vinculado a la botnet BADBOX.
Las soluciones de Kaspersky detectan las amenazas descritas en este artículo y les asignan los siguientes veredictos:
- HEUR:Trojan-Dropper.AndroidOS.Agent.vu
- HEUR:Trojan-Downloader.AndroidOS.Agent.ov
- HEUR:Trojan-Proxy.AndroidOS.Zhima.*
- HEUR:Trojan.AndroidOS.Vo1d.*
¿Qué es una unidad central multimedia (Head Unit)?
La unidad central multimedia (Head Unit) es un sistema que integra funciones multimedia con algunas funciones de control del vehículo. Puede venir instalada de fábrica o incorporarse posteriormente. Los principales vectores de ataque contra estos sistemas son el acceso físico al dispositivo y la explotación de vulnerabilidades en el sistema operativo o en otros componentes, como ya explicamos en este artículo.
En algunos casos, las unidades centrales multimedia funcionan con el sistema operativo Android, lo cual se debe principalmente a la conveniencia para el fabricante (el código fuente de Android ya contempla escenarios de uso dentro de la unidad central multimedia de un automóvil). Además, durante el proceso de compilación, Android permite agregar aplicaciones de sistema propias, un recurso que los fabricantes pueden usar para diversos fines, como personalizar la interfaz o incluir componentes de sistema según las necesidades del distribuidor.
La mayoría de las aplicaciones desarrolladas para dispositivos Android también pueden ejecutarse en una unidad central multimedia que use Android. Esto también se cumple con las aplicaciones maliciosas. Sin embargo, es difícil imaginar que buena parte del malware dirigido a smartphones se use en ataques contra unidades centrales multimedia. Un ejemplo son los troyanos bancarios: la banca móvil se usa sobre todo desde el smartphone, por lo que infectar unidades centrales multimedia con este tipo de malware sería un desperdicio de recursos para el atacante.
Cabe destacar que muchas unidades centrales multimedia tienen ranuras para tarjeta SIM y pueden conectarse a internet, lo que permite, por ejemplo, usar el GPS o actualizar el software. Dado que, en la mayoría de los casos, la unidad central multimedia no contiene información valiosa para un atacante, uno de los escenarios de ataque más probables con malware “clásico” para Android es infectarla para conectarla a botnets, de forma similar a los ataques contra dispositivos IoT.
Durante nuestra investigación encontramos un malware de este tipo. El firmware de las unidades centrales multimedia del fabricante DoFun estaba diseñado de forma que permitía a los atacantes distribuir malware. Notificamos al proveedor sobre el esquema de distribución de malware, tras lo cual el fabricante informó que corrigió los problemas de seguridad.
El esquema completo de infección es el siguiente:
Esquema de infección de las unidades centrales multimedia
Veamos en detalle cómo se infectaban con malware las unidades centrales multimedia de este fabricante.
Aplicación TWCore
La aplicación TWCore es una aplicación de sistema legítima, responsable de recopilar datos analíticos y de actualizar el software de la unidad central multimedia. Profundicemos en la implementación de la función de actualización de software.
La actualización de software funciona de forma más o menos sencilla. Un bróker de mensajes con el protocolo MQTT, alojado en el subdominio cardoor[.]cn, envía un mensaje con información sobre los archivos APK que deben descargarse e instalarse en la unidad central multimedia. Cabe destacar que el objeto que describe ese mensaje incluye un campo installNotExists (una bandera que toma el valor true o false), que permite a TWCore instalar aplicaciones que al inicio no estaban presentes en el dispositivo.
TWCore verifica la presencia de la aplicación en el dispositivo solo cuando installNotExists = false
El archivo APK que se instalará se descarga en el directorio <TWCore external cache dir>/push/apk/.
Ruta que usa TWCore para descargar el APK
Nuestra telemetría detectó malware previamente desconocido en esas rutas. Además, los datos indican que, en todos los casos, el malware era instalado por la aplicación con nombre de paquete com.tw.core, que coincide con el de TWCore.
Analicemos el malware que instala TWCore (el dropper JarService).
Etapa 1: dropper JarService
Como ya se mencionó, JarService es una pequeña aplicación dropper sin interfaz. Descifra datos almacenados en el código del troyano como bloques cifrados. Cada bloque usa cifrado XOR con una clave de un byte que cambia linealmente de un bloque a otro. Los datos descifrados contienen información serializada sobre la versión de la carga útil, su punto de entrada, y el propio código del malware para su posterior carga.
Descifrado y deserialización de la información de la carga útil de la segunda etapa
En la versión de JarService que analizamos, el punto de entrada de la carga útil de la siguiente etapa era el método wa de la clase com.c.j.qbh.
Etapa 2: cargador
La carga útil de esta etapa es un cargador malicioso. Su código contiene cadenas cifradas que se usan después como nombres de clases para ejecutar la carga útil de la tercera etapa mediante reflexión. El cargador envía información sobre el implante mediante una solicitud POST a uno de los servidores de los atacantes. Ejemplo de solicitud al C2:
|
1 2 3 4 5 6 7 8 9 |
{ "userId": "REDACTED", "dexVersion": "1.7", "dexType": 1, "channelId": "2039", "packageName": "com.tw.jar1", "appVersion": 12, "appName": "JarService" } |
En respuesta a la solicitud POST, el servidor de comando y control devuelve un enlace para descargar la carga útil de la tercera etapa. A continuación, un ejemplo de esa respuesta del C2.
|
1 2 3 4 5 6 7 8 |
{ "code": 200, "data": { "dexUrl": " hxxp://144.217.243[.]201/vr34der34/dex3.68.png", "dexVersion": 3.680, "status": 0 } } |
Usando e enlace del campo dexUrl en el objeto data, el troyano descarga datos serializados para cargar la siguiente etapa. Al inicio de estos datos hay un número entero de un byte (la clave para descifrar las cadenas cifradas en el código del cargador). Justo después de ese número hay un número de punto flotante de cuatro bytes, que se usa para el descifrado XOR de la carga útil de la tercera etapa, la cual, a su vez, se ubica después de las claves mencionadas.
Descifrado de la carga útil de la tercera etapa
En la carga útil descifrada, el punto de entrada es el método init de la clase com.ast.sdk.BillingMain, que se muestra en la captura de pantalla a continuación.
Punto de entrada de la carga útil de la tercera etapa
Al analizar esta etapa, notamos que el enlace para descargar la carga útil de la siguiente etapa incluye el número de versión. Decidimos probar otras versiones para obtener distintas variantes de la carga útil, y logramos obtener siete versiones diferentes (la lista se incluye en la sección “Indicadores de compromiso”). La versión más antigua era la 3.57, pero utiliza un algoritmo de decodificación distinto al descrito antes, lo que podría indicar que antes existía otro cargador entre JarService y la carga útil de la tercera etapa.
Etapa 3: clicker/cargador de proxy inverso
En la tercera etapa, el malware envía, por defecto, una solicitud POST cada hora y media a la ruta /cpc/api/task con información sobre el dispositivo infectado (resolución de pantalla, modelo del dispositivo, SSID de la red Wi-Fi conectada, dirección MAC, etc.), además de la versión de configuración del troyano. Si la configuración está desactualizada, el servidor de comando y control devuelve una configuración actualizada con nuevas direcciones de C2 y nuevas rutas para el envío de solicitudes HTTP. A continuación se muestra un ejemplo de esa respuesta. Cabe señalar que, al momento de la investigación, la versión de configuración 3.82 era la más reciente.
|
1 2 3 4 5 6 7 8 9 10 11 12 13 |
{ "code": 100, "data": { "configVersion": 3.820, "hosts": [" hxxp://t2.kshahnd[.]sbs", " hxxp://t2.mdsjhd[.]sbs", " hxxp://t2.nmnsny[.]sbs", "hxxps://t2.nmnsny[.]sbs"], "interval": 5500000, "reportApi": "/cpc/api/report", "tagName": "config", "taskApi": "/cpc/api/task", "updates": [" hxxp://a2.kshahnd[.]sbs", " hxxp://a2.mdsjhd[.]sbs", " hxxp://a2.nmnsny[.]sbs", " hxxps://a2.nmnsny[.]sbs"], "vn": 1.010 } } |
Si la configuración no requiere actualización, el servidor de comando y control (C2) devuelve identificadores numéricos de comandos, denominados productId por los atacantes. El troyano asocia cada identificador con su información de comando, almacenada mediante SharedPreferences como objeto JSON serializado.
Cada productId incluye una versión representada por una marca de tiempo UNIX. Si la respuesta del C2 contiene un productId desconocido o con versión desactualizada, el malware envía una solicitud GET a /cpc/api/xml para recuperar el contenido de los comandos afectados. El C2 responde con la información correspondiente a cada identificador pendiente. A continuación se muestra un ejemplo de esta respuesta.
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 |
{ "code": 200, "data": [{ "productId": 979, "script": "{\n \"loadType\": 1,\n \"reload\": true,\n \"method\": \"start\",\n \"url2\": \" hxxp://144.217.243[.]201/vr34der34/sh65.io\",\n \"md52\": \"de77c3303e93c9450424759f1741441c\",\n \"name\": \"zhima\",\n \"className\": \"com.miyc.transfer.Client\",\n \"thread\": true,\n \"tagName\": \"loadlib2\",\n \"params\": [\n {\n \"type\": \"Context\"\n },\n {\n \"type\": \"String\",\n \"value\": \" 107.151.248[.]132\"\n },\n {\n \"type\": \"String\",\n \"value\": \"1002\"\n },\n {\n \"type\": \"int\",\n \"value\": 1337\n },\n {\n \"type\": \"int\",\n \"value\": 7777\n },\n {\n \"type\": \"int\",\n \"value\": 8888\n },\n {\n \"type\": \"int\",\n \"value\": 15000\n }\n ],\n \"url\": \" hxxp://144.217.243[.]201/vr34der34/sh65.io\",\n \"md5\": \"de77c3303e93c9450424759f1741441c\"\n}", "version": 1778650942 }, { "productId": 1019, "script": "{\n \"loadType\": 1,\n \"reload\": true,\n \"method\": \"start\",\n \"url2\": \" hxxp://144.217.243[.]201/vr34der34/sh65.io\",\n \"md52\": \"de77c3303e93c9450424759f1741441c\",\n \"name\": \"zhima\",\n \"className\": \"com.miyc.transfer.Client\",\n \"thread\": true,\n \"tagName\": \"loadlib2\",\n \"params\": [\n {\n \"type\": \"Context\"\n },\n {\n \"type\": \"String\",\n \"value\": \" 128.14.210[.]58\"\n },\n {\n \"type\": \"String\",\n \"value\": \"1002\"\n },\n {\n \"type\": \"int\",\n \"value\": 9999\n },\n {\n \"type\": \"int\",\n \"value\": 7777\n },\n {\n \"type\": \"int\",\n \"value\": 8888\n },\n {\n \"type\": \"int\",\n \"value\": 15000\n }\n ],\n \"url\": \" hxxp://144.217.243[.]201/vr34der34/sh65.io\",\n \"md5\": \"de77c3303e93c9450424759f1741441c\"\n}", "version": 1766001509 }, { "productId": 3505, "script": "{\n\"tagName\":\"http\",\n\"url\":\" hxxps://api.kookjar[.]com/sayhi?channel=daihai&uuid={get_uuid_10}\"\n}", "version": 1776656317 }], "msg": "" } |
La información del comando incluye el campo tagName, que corresponde a su nombre. En el código, cada nombre está asociado a las clases correspondientes para su ejecución.
Lista de comandos para ejecución
Al momento de la investigación, los atacantes habían implementado 9 comandos. Los nombres de los comandos, una breve descripción y sus argumentos se muestran en la tabla siguiente. A juzgar por la funcionalidad de los comandos implementados, el malware puede usarse para mostrar anuncios, cometer fraude publicitario (funcionalidad de clicker) y descargar código malicioso adicional.
| Nombre del comando | Descripción | Argumentos |
return |
Devuelve un valor de SharedPreferences. | key – clave cuyo valor se debe devolver |
copy |
Establece el contenido del portapapeles. | text – clave cuyo valor, guardado en SharedPreferences, se devuelve como contenido del portapapelesurl – enlace desde el que se descargan datos comprimidos con gzip (opcional). Estos datos se concatenan después con el valor de la clave text usando como separador |
http |
Realiza una solicitud HTTP POST/GET al recurso indicado y, si se especifica, guarda la respuesta en SharedPreferences bajo la clave indicada. | url – dirección del recursomethod – nombre del método HTTP (opcional)startLabel – marcador de inicio de los datos que se deben guardar del recurso (opcional)endLabel – marcador de fin de los datos que se deben guardar del recurso (opcional)valueLabel – clave bajo la cual se debe guardar el valor (opcional)header – diccionario con los encabezados de la solicitud HTTP (opcional)content – contenido de la solicitud POST (opcional) |
web |
Abre un enlace en WebView y ejecuta en él código JavaScript arbitrario. | url – enlace que se debe abrir con WebViewjs – código JavaScript codificado en base64 que se debe ejecutar en WebView, usado cuando el parámetro url está vacío o ausentecorejs – código JavaScript que se debe ejecutar al cargar el recurso en WebView (opcional)param – diccionario de cadenas con los parámetros para iniciar WebViewclient – si esta clave está presente, se usará WebViewClient para resolver manualmente la redireccióntime – tiempo límite (timeout) de la tarea |
loadlib |
Al momento de redactar este informe, el comando no estaba implementado por completo. | – |
loadlib2 |
Descarga y ejecuta código arbitrario. | url – dirección para descargar la carga útilname – nombre del módulo que se debe descargarmd5 – hash MD5 de la carga útilclear – lista de nombres de cargas útiles que se deben eliminar, separados por comas (opcional)params – arreglo de parámetros con los que se debe ejecutar la carga útilclassName – nombre de la clase del punto de entrada de la carga útilmethod – nombre del método virtual del punto de entrada de la carga útilcmethod – nombre del método estático para instanciar la clase del punto de entrada (opcional)thread – bandera: si no está definida, la carga útil se ejecuta en un hilo independientereload – bandera que, al estar definida, reinicia los módulos ya cargados |
loadlib3 |
Al momento de la publicación de este informe, el comando no estaba totalmente implementado. | – |
deeplink |
Abre un recurso usando el navegador. | url – enlace del recurso |
traceroute |
Verifica la disponibilidad de un recurso mediante ICMP ping. | host – recursos que se deben verificar, separados por comas |
Sin embargo, no todos los comandos son usados por los atacantes en ataques reales. Como se observa en el ejemplo de respuesta del C2 mostrado antes, al momento de la publicación de este informe los atacantes usaban los comandos loadlib2 y http. La carga útil que descarga el comando loadlib2 es el módulo de proxy inverso “zhima”, que investigadores del Nokia Deepfield Emergency Response Team identificaron de forma independiente en decodificadores de TV y describieron. Así, el objetivo final de los atacantes es crear una botnet de proxies.
Al analizar esta etapa de la cadena de ataque, notamos que el enlace para descargar zhima también tiene un número de versión. De forma similar a la etapa anterior, probamos otras versiones posibles y encontramos ocho variantes del módulo zhima, la más antigua de las cuales correspondía a la versión 57. La lista completa de los módulos zhima identificados se incluye en la sección “Indicadores de compromiso”.
Atribución
El análisis de la cadena de infección revela que el cargador de segunda etapa crea un hilo denominado mosdk-host-loader. Decidimos averiguar qué significaba mosdk en ese nombre. Así, identificamos una aplicación maliciosa con el nombre de paquete com.abc.nexus (3AD4BF5A86D26FFBF09CAE42AF330A98), instalada en varios decodificadores de TV. Consta de varios componentes (incluido un dropper similar a JarService), cada uno usado por los atacantes para monetizar de forma oculta la capacidad de cómputo del dispositivo. Cada componente malicioso de la aplicación corresponde a un servicio propio. El servicio que contiene el código para ejecutar el dropper similar a JarService se llama AdmoyuService. El nombre del hilo malicioso en la carga útil sugiere que moyu en el identificador del servicio hace referencia a MoYu Group, actor vinculado a la plataforma BADBOX, documentada por investigadores de HUMAN. Esta hipótesis también se confirma por la gran cantidad de coincidencias entre la infraestructura de red del malware y la infraestructura de red de MoYu Group, identificada de forma independiente por investigadores del Nokia Deepfield Emergency Response Team. La convergencia de patrones de nomenclatura e infraestructura permite atribuir esta actividad, con alto grado de certeza, a dicho actor.
Al analizar el malware descargado por TWCore, notamos que el dominio admin.uipoxy[.]com resolvía a la dirección IP 128.14.210[.]58, uno de los servidores de comando y control del módulo de proxy inverso “zhima”. Todo indica que el enlace hxxp://admin.uipoxy[.]com/proxy/u/login corresponde al panel de administración de zhima. Este panel permite que cualquier usuario se registre, siempre que tenga un código de invitación.
Página de registro del operador del malware
Durante el registro, también se invita al usuario a leer los términos de uso del servicio y la política de privacidad. Ambos documentos están en enlaces con el dominio pxyedge[.]com, perteneciente al proveedor PXYEDGE, especializado en la venta de proxies residenciales (residential proxy).
Además, en la página de registro alojada en el dominio admin.uipoxy[.]com, encontramos la cadena
copyright © 2020 proxyforu[.]com all rights reserved, que llevaba al sitio hxxps://proxyforu[.]com. Se trata del sitio del proveedor ProxyForU, que también ofrece servicios de proxies residenciales.
Identificamos algunas similitudes en la API de autorización de todos estos sitios:
- La página de autorización estaba en el subdominio
admin.* - La página de autorización estaba en la ruta
/proxy/u/login - La página de registro estaba en la ruta
/proxy/register?channelKey=<invitation code>
Con base en esto, consideramos que los servicios mencionados están asociados con MoYu Group.
Conclusión
A pesar de los esfuerzos de los especialistas en ciberseguridad y de las autoridades para detener las actividades de la botnet BADBOX, algunos actores asociados con ella siguen realizando actividades maliciosas e infectando dispositivos en todo el mundo. Los vectores de entrega de este tipo de malware pueden ser muy variados: desde descargas realizadas por puertas traseras preinstaladas en el sistema hasta la instalación de compilaciones infectadas de aplicaciones IPTV. El caso analizado demostró un método aún más sofisticado de entrega del malware, mediante la funcionalidad legítima de actualización de software de una aplicación de sistema. Además, los atacantes están explorando activamente nuevas plataformas. Es más, este malware es la primera aplicación maliciosa identificada para unidades centrales multimedia, lo que indica que ahora estas plataformas también requieren protección contra malware.
Indicadores de compromiso
Etapa 1: JarService
ba27951b4ee1c341f4415d033369ecd3
d63bacd6d6709dd68a10ef9d374c7835
6c2e34b30da42085240ede53ab6107d4
8b5e513144a6138a966ea59e68bf9da2
e119845877089d6f4b0a70dc7388f316
Etapa 2: cargador
e9f3a0dab6949ce2cddab9e0aa80ae1a
Etapa 3: cargador/clicker
0fbaa7092204f4b1494e0b840b014774
1dcf031c40ce456b6a36a00b0acf3d11
44b6b213a6a3f299eaf88e078de95ecb
67dc78e544ebce16b85dc7c195dfbc58
9642ae619b3165d23c6349002d1abe24
b067d5b0dbecbd6498bcdfba45dba77e
f0e3f7eba2cde91e2dedb921bab47422
Módulo zhima
412e9243f2981bbea3894254d105b3b8
71ab5517f71866279d0d87d37f2ae320
89ef78f716a75964539f2db6520be362
a4223ce4288a230d1e6c3ff2c7639045
bd4d81cd27125ad3d9a114922d468499
c6bfb1643ac7474ed8a7b4f96a187fdb
de77c3303e93c9450424759f1741441c
f8cf8c23ff597700d471fb7767df8bac
Dominios y direcciones IP
xmsae[.]sbs
ishano456[.]sbs
xshaon123[.]sbs
kshahnd[.]sbs
mdsjhd[.]sbs
nmnsny[.]sbs
kookjar[.]com
ty54fgd435[.]my
ue886578433[.]online
ty4523[.]space
144.217.243[.]201
107.151.248[.]132
128.14.210[.]58
Direcciones desde las que se descargó JarService
hxxp://ovcloudcontrol.cdn.cardoor[.]cn/upgrade/2026-06-08/bd80bd3c3d0e4bf6b5b4a825650d01f5.apk
hxxp://ovcloudcontrol.cdn.cardoor[.]cn/upgrade/2025-06-10/fe71af9ecf174de48d2b2ccc2c15fb04.apk
hxxp://ovcloudcontrol.cdn.cardoor[.]cn/upgrade/2024-11-07/fa831c3c23824b99871163387bcda7ad.apk
Hashes de TWCore (software legítimo utilizado para distribuir JarService)
2a64c3efc11bf224aa54f24e876446c9
7a4d3ba2dacccfdda55859a5dfee2671
ea24487996eb70c1780922fb3063bcc5
De los mismos autores
En la misma categoría
El pasajero invisible de su automóvil