Divide y vencerás: cómo el nuevo backdoor Keenadu ayudó a revelar conexiones entre grandes botnets de Android

En abril de 2025 describimos una versión, nueva en aquel momento, del backdoor Triada, que infectaba los firmwares de dispositivos Android falsificados distribuidos a través de marketplaces populares. El malware se ubicaba en las particiones del sistema de los firmwares y penetraba en Zygote (el proceso padre de todas las aplicaciones en el sistema), lo que provocaba la infección de cualquier aplicación en el dispositivo. Esto permitía que el troyano pudiera robar credenciales de mensajeros y redes sociales, entre otras cosas.

El hallazgo nos motivó a realizar una investigación y buscar otras amenazas en los firmwares de dispositivos Android. Así descubrimos el nuevo backdoor Keenadu, que, al igual que Triada, se incrustaba en los firmwares e infectaba cada aplicación que se ejecutase en el dispositivo. El backdoor ya estaba muy expandido: cuando se lo descubrió, nuestros usuarios comenzaron a contactar en masa al servicio de soporte para obtener información sobre esta amenaza. El objetivo de este informe es disipar dudas y describir la nueva amenaza.
Estas son nuestras conclusiones:

• Descubrimos una nueva puerta trasera, denominada Keenadu, en el firmware de dispositivos de varias marcas. Fue introducida durante el proceso de compilación: una biblioteca estática maliciosa se vinculaba con libandroid_runtime.so. Una vez en el dispositivo, al igual que Triada, infectaba el proceso Zygote. En algunos casos, el firmware malicioso se instalaba mediante una actualización OTA.
• Una copia del backdoor se inyectaba en el espacio de direcciones de cada aplicación al ejecutarse en el dispositivo. El malware es un cargador multinivel que otorga a los atacantes control casi ilimitado sobre el dispositivo de la víctima.
• Logramos obtener las cargas útiles que descarga Keenadu. Según la aplicación infectada, sustituyen búsquedas en el navegador, monetizan instalaciones de apps y manipulan en secreto elementos publicitarios.
• Una de las cargas útiles obtenidas durante la investigación también se encontró en múltiples aplicaciones que se distribuían tanto a través de fuentes no oficiales como a través de Google Play y Xiaomi GetApps.
• En los firmwares de algunos dispositivos, Keenadu estaba integrado en aplicaciones clave del sistema: servicio de reconocimiento facial, aplicación de escritorio, etc.
• Durante la investigación logramos establecer que existía una conexión entre las botnets de Android más grandes: Triada, BADBOX, Vo1d y Ke

La cadena completa de infección de Keenadu es la siguiente:

Las soluciones de Kaspersky detectan las amenazas descritas abajo con los siguientes veredictos:

HEUR:Backdoor.AndroidOS.Keenadu.*
HEUR:Trojan-Downloader.AndroidOS.Keenadu.*
HEUR:Trojan-Clicker.AndroidOS.Keenadu.*
HEUR:Trojan-Spy.AndroidOS.Keenadu.*
HEUR:Trojan.AndroidOS.Keenadu.*
HEUR:Trojan-Dropper.AndroidOS.Gegu.*

Dropper malicioso en libandroid_runtime.so

Al inicio de la investigación, nos llamaron la atención bibliotecas sospechosas ubicadas en las rutas /system/lib/libandroid_runtime.so y /system/lib64/libandroid_runtime.so (en adelante, para abreviar, usaremos la representación /system/lib[64]/ para designar estos dos directorios). Tal biblioteca existe en la plataforma legítima de Android. En particular, en ella se define el método nativo println_native para la clase android.util.Log. Las aplicaciones lo usan para escribir en el registro logcat. En las bibliotecas sospechosas, la implementación de este método llamaba a una función adicional, a diferencia de las bibliotecas legítimas.

La función sospechosa descifraba datos del cuerpo de la biblioteca usando RC4 y los escribía en la ruta /data/dalvik-cache/arm[64]/system@framework@vndx_10x.jar@classes.jar. Estos datos son la carga útil que se introduce mediante DexClassLoader. El punto de entrada en ella es el método main de la clase com.ak.test.Main, donde es probable que ak haga referencia al nombre del malware que le dio el autor, considerando que esta combinación de letras también se usa en otros lugares del código. En particular, los desarrolladores dejaron mucho código que registra mensajes de error del malware en logcat durante su ejecución. Para estos mensajes se usa la etiqueta AK_CPP.

La carga útil verifica si no se está ejecutando en aplicaciones del sistema del conjunto de servicios de Google, así como en aplicaciones del sistema de los operadores Sprint y T-Mobile. Estas versiones suelen corresponder a dispositivos que los operadores venden a bajo costo a cambio de que el usuario firme un contrato de servicios de telecomunicaciones. Si el malware se ejecuta en tales procesos, detiene sus operaciones. También tiene implementado un mecanismo para dejar de funcionar si en los directorios del sistema hay archivos con determinados nombres.

Luego, el troyano verifica si se está ejecutando en el proceso system_server. Este proceso gestiona todo el sistema y tiene privilegios máximos. Lo inicia el proceso Zygote al comienzo de su trabajo. Si el resultado de la verificación es positivo, el troyano crea una instancia de la clase AKServer; pero si el código funciona en cualquier otro proceso, se crea una instancia de la clase AKClient. En el objeto creado se invoca un método al que se le pasa el nombre del proceso de la aplicación. Los nombres de las clases sugieren que el troyano se basa en una arquitectura cliente-servidor.

El proceso system_server crea e inicia diversos servicios del sistema mediante la clase SystemServiceManager. En la base de estos servicios está la arquitectura cliente-servidor, y los clientes se solicitan en el código de las aplicaciones mediante la llamada al método Context.getSystemService. La comunicación con el servidor se realiza mediante binder, el mecanismo nativo de comunicación entre procesos (IPC) de Android. Este enfoque tiene múltiples ventajas, incluso desde el punto de vista de la seguridad. Entre ellas está la posibilidad de restringir a algunas aplicaciones el acceso a diversos servicios del sistema y sus funciones. Otra ventaja es la presencia de abstracciones que permiten simplificar el uso de este acceso para los desarrolladores y al mismo tiempo proteger el sistema de posibles vulnerabilidades en las aplicaciones.

Los autores de Keenadu adoptaron un enfoque similar. La lógica principal se encuentra en la clase AKServer, que funciona en el proceso system_server. AKServer funciona como un servicio del sistema malicioso, mientras que <>codeAKClient actúa como stub (proxy) que permite invocar métodos remotos en AKServer a través de binder. A continuación presentamos un diagrama del funcionamiento del backdoor:

Aquí cabe resaltar que Keenadu vuelve a comprometer los principios básicos de seguridad de Android. En primer lugar, dado que está integrado en libandroid_runtime.so, funciona en el contexto de cada aplicación en el dispositivo, obteniendo así acceso a todos sus datos y haciendo que el aislamiento de aplicaciones entre sí previsto por el sistema carezca de sentido. En segundo lugar, proporciona interfaces para burlar los permisos (de los que hablaremos más adelante) que regulan los derechos de las aplicaciones en el sistema. De esta forma, estamos ante un backdoor de pleno derecho, que permite a los atacantes obtener control casi ilimitado sobre el dispositivo de la víctima.

Arquitectura de AKClient

AKClient está estructurado de forma bastante simple. Se integra en todas las aplicaciones que se ejecutan en el dispositivo y obtiene una instancia de la interfaz para comunicarse con el servidor mediante un mensaje de difusión protegido (protected broadcast) com.action.SystemOptimizeService. Mediante binder, este stub invoca el método attach en AKServer, pasando como parámetro un objeto IBinder que encapsula la lógica para cargar DEX arbitrarios en el contexto de la aplicación infectada. Esto permite a AKServer ejecutar cargas útiles maliciosas según la aplicación afectada.

Arquitectura de AKServer

AKServer, al inicio de su trabajo, envía dos mensajes de difusión protegidos (protected broadcast): com.action.SystemOptimizeService y com.action.SystemProtectService. El primer mensaje, como ya hemos mencionado, transmite a otros procesos infectados con AKClient una instancia de la interfaz para interactuar con AKServer. Junto con el mensaje com.action.SystemProtectService también se transmite una instancia de otra interfaz para interactuar con AKServer. Mediante esta interfaz, los módulos maliciosos descargados en los contextos de otras aplicaciones pueden:

• otorgar cualquier permiso a cualquier aplicación en el dispositivo;
• revocar cualquier permiso de cualquier aplicación en el dispositivo;
• obtener la geolocalización del dispositivo;
• obtener información sobre el dispositivo.

Después de que se configura la interacción entre la parte del servidor y del cliente, AKServer inicia la tarea maliciosa principal llamada MainWorker. En su primer inicio, MainWorker guarda la hora actual. Después, el malware verifica el idioma del dispositivo y su zona horaria. Si el idioma de la interfaz es uno de los dialectos del chino y el dispositivo mismo está ubicado en una de las zonas horarias chinas, termina su trabajo. Tampoco funcionará si su dispositivo no tiene la tienda de aplicaciones Google Play o los servicios de Google Play. Si el dispositivo pasa las verificaciones, el troyano inicia la tarea PluginTask. PluginTask descifra las direcciones de los servidores de comando y control del código de la siguiente manera:

1. La cadena con la dirección cifrada se decodifica mediante Base64.
2. Los datos obtenidos (un búfer comprimido con gzip) se descomprimen.
3. Los datos descomprimidos se descifran mediante AES-128 en modo CFB. La clave para el descifrado es el MD5 de la cadena ota.host.ba60d29da7fd4794b5c5f732916f7d5c, el vector de inicialización es la cadena 0102030405060708.

Después de descifrar las direcciones de los servidores de comando y control, el troyano recopila datos sobre el dispositivo de la víctima: modelo, IMEI, dirección MAC, versión del SO, etc., y los cifra de la misma manera que las direcciones de los servidores, solo que como clave AES se usa el MD5 de la cadena ota.api.bbf6e0a947a5f41d7f5226affcfd858c. Los datos cifrados se envían al servidor de comando y control mediante una solicitud POST a la ruta /ak/api/pts/v4. Se transmiten dos valores a los parámetros de la solicitud:

• m: MD5 del IMEI del dispositivo;
• n: tipo de conexión a la red (w: Wi-Fi, m: internet móvil).

La respuesta del servidor de comando y control contiene el campo code, en el que puede haber un código de error devuelto por el servidor. Si el valor de este campo es igual a cero, no hay error. En este caso, en la respuesta habrá un campo data: un JSON cifrado de forma análoga a los datos de la solicitud con información sobre las cargas útiles.

Cómo Keenadu llegó a libandroid_runtime.so

Después del análisis de las primeras etapas de infección, decidimos averiguar de qué forma exacta el backdoor llegaba a los firmwares de dispositivos Android. Casi de inmediato descubrimos en fuentes abiertas en la red quejas de usuarios de tabletas del fabricante Alldocube sobre consultas DNS sospechosas desde los dispositivos. Este proveedor ya había reconocido la presencia de software malicioso en uno de los modelos de tabletas. Pero en la declaración publicada por la compañía no había ningún detalle sobre cuál era el malware específico que llegó a los dispositivos y cómo había sucedido esto. Intentaremos responder a estas preguntas.

Las consultas DNS descritas por el autor del reclamo también nos parecieron extrañas. Según nuestros datos, los dominios C2 de Keenadu obtenidos en ese momento se resolvían en las direcciones IP que se presentan a continuación.

• 67.198.232[.]4
• 67.198.232[.]187

En estas mismas direcciones se resolvían los dominios keepgo123[.]com y gsonx[.]com, lo que puede indicar que la tableta del autor del reclamo también está infectada con Keenadu. Sin embargo, una sola coincidencia de direcciones IP no es suficiente para afirmarlo con certeza. Para verificar la hipótesis, es necesario estudiar el dispositivo mismo. Consideramos la opción de adquirir el mismo modelo de tableta, pero no fue necesario: Alldocube publica archivos con firmware para sus dispositivos en acceso abierto, por lo que cualquier interesado puede verificarlos en busca de software malicioso.

Para analizar el firmware, primero es necesario estudiar en qué formato se almacena el contenido. Los firmwares para dispositivos Alldocube son archivos RAR que contienen diversas imágenes y otros archivos, así como una utilidad para flashear en formato de archivo ejecutable para Windows. El mayor valor desde el punto de vista del análisis lo representa el sistema de archivos de Android. Sus particiones principales, incluida la del sistema, se encuentran en una de las imágenes llamada super.img. Este es un archivo Android Sparse Image. Para abreviar la exposición, omitiremos describir formato (se lo puede, por ejemplo, recuperar del código de libsparse); solo señalaremos que existen utilidades con código abierto para extraer particiones de tales archivos en forma de imagen del sistema de archivos.

Extrajimos libandroid_runtime.so del firmware para Alldocube iPlay 50 mini Pro (T811M) del 18 de agosto de 2023. Al estudiar la biblioteca, descubrimos en ella el backdoor Keenadu. Además, desciframos la carga útil y extrajimos de allí las direcciones de los servidores de comando y control, que se ubicaban en los dominios keepgo123[.]com y gsonx[.]com, lo que confirma las sospechas del usuario: sus dispositivos están infectados con este mismo backdoor. Además, todas las versiones posteriores de firmwares para este modelo también resultaron infectadas, incluidas las que salieron después de la publicación de la declaración del proveedor.

Se debe prestar atención especial a los firmwares para el modelo Alldocube iPlay 50 mini Pro NFE. La abreviatura NFE (Netflix Enabled) en su nombre significa que tales dispositivos tienen un módulo DRM adicional que permite usar servicios de streaming en alta calidad. Para ello, deben cumplir con el estándar Widevine L1 del sistema de protección de medios premium Google Widevine DRM. En consecuencia, procesan medios en TEE (Trusted Execution Environment), lo que reduce el riesgo de acceso a la película o serie por parte de código no confiable y, como consecuencia, no permite copiar medios sin autorización. Aunque la certificación por Widevine no protegió estos dispositivos de la infección, a diferencia de otros modelos, el primer firmware de Alldocube iPlay 50 mini Pro NFE, lanzado el 7 de noviembre de 2023, estaba limpio. Al mismo tiempo, todos los demás, incluida la versión más reciente del 20 de mayo de 2024, contenían Keenadu.

Durante el análisis de firmware para dispositivos Alldocube, descubrimos que todos tienen una firma válida. Esto significa que, para integrar el backdoor en libandroid_runtime.so, no fue suficiente que el atacante hackease el servidor de actualizaciones OTA. Además, era necesario darse modos para apoderarse de las claves para su firma, que en condiciones normales no deberían ser accesibles desde el servidor OTA. Lo más probable es que el troyano haya llegado al firmware durante la etapa de compilación.

También logramos descubrir la biblioteca estática libVndxUtils.a (ca98ae7ab25ce144927a46b7fee6bd21), que contiene el código de Keenadu, lo que confirma nuestra hipótesis. Esta biblioteca maliciosa está escrita en lenguaje C++ y compilada mediante el sistema de compilación CMake. Es interesante que en la biblioteca también quedaron las rutas a los archivos con código fuente en la computadora del desarrollador.

• D:\work\git\zh\os\ak-client\ak-client\loader\src\main\cpp\__log_native_load.cpp: en este archivo se encuentra el código del dropper.
• D:\work\git\zh\os\ak-client\ak-client\loader\src\main\cpp\__log_native_data.cpp: en este archivo se encuentra la carga útil cifrada mediante RC4, así como su tamaño.

El punto de entrada del dropper es la función __log_check_tag_count. El atacante insertó la llamada de esta función en la implementación del método println_native.

Según nuestros datos, la dependencia maliciosa se ubicaba en el repositorio con el código fuente del firmware en las siguientes rutas:

• vendor/mediatek/proprietary/external/libutils/arm/libVndxUtils.a
• vendor/mediatek/proprietary/external/libutils/arm64/libVndxUtils.a

Es interesante que el troyano en libandroid_runtime.so descifra y escribe en el disco la carga útil en la ruta /data/dalvik-cache/arm[64]/system@framework@vndx_10x.jar@classes.jar. Lo más probable es que el atacante estuviese intentando disfrazar la dependencia maliciosa libandroid_runtime.so como un componente vndx que se supone que es legítimo, con código propietario del proveedor MediaTek. En realidad, tal componente no existe en los productos de MediaTek.

Por último, según los datos de nuestra telemetría, el troyano se encuentra no solo en dispositivos Alldocube, sino también en dispositivos de otros fabricantes. En todos los casos, el backdoor está integrado en firmwares para tabletas. A los proveedores mencionados les advertimos de la infección.

Basándonos en todo lo anterior, consideramos que Keenadu llegó a los firmwares de dispositivos Android como resultado de un ataque a la cadena de suministro: una de las etapas de la cadena de suministro del firmware resultó comprometida, lo que introdujo una dependencia maliciosa en sus códigos fuente. De esta forma, los proveedores podrían no sospechar que sus dispositivos ya estaban infectados antes de ponerlos en venta.

Módulos del backdoor Keenadu

Como ya señalamos, Keenadu, debido a su arquitectura, permite a los atacantes obtener un control casi ilimitado sobre el dispositivo de la víctima. Para entender de qué forma exacta aprovecharon esta característica del backdoor, decidimos analizar las cargas útiles que descarga. Para ello, creamos una solicitud en nombre de un dispositivo infectado para el servidor de comando y control. El servidor C2 no envió ningún archivo como respuesta a nuestra primera solicitud. En su lugar, devolvió la hora y fecha para la siguiente solicitud: 2.5 meses después de la primera. Durante el análisis del servidor de comando y control mediante el método de “caja negra”, logramos establecer que la solicitud contiene la hora y fecha de activación del backdoor, y si desde su momento no han pasado 2.5 meses, el C2 no devuelve cargas útiles. Es probable que esto se haya hecho para dificultar el análisis y disminuir la probabilidad de detección de estas cargas. Después de que cambiamos en la solicitud el momento de la activación a uno más antiguo, el servidor de comando y control nos devolvió una lista de cargas útiles para análisis.

El servidor de los atacantes envía información sobre las cargas útiles en forma de array de objetos. Cada uno de estos objetos contiene un enlace para descargar la carga útil, así como su MD5, nombres de paquetes de aplicaciones objetivo, nombres de procesos objetivo, etc. A continuación se presenta un ejemplo de tal objeto. Los atacantes eligieran Alibaba Cloud para construir la CDN.

Los archivos descargados por Keenadu tienen su propio formato, en el que se almacena la carga útil cifrada y su configuración. La descripción del formato del archivo en pseudocódigo se presenta a continuación (struct KeenaduPayload):

Después de la descarga, Keenadu verifica la integridad del archivo mediante MD5. Además, los autores del troyano implementaron un mecanismo de firma de código mediante el algoritmo DSA, que se verifica antes del descifrado y ejecución de la carga útil. Esto significa que solo el atacante que posee la clave privada puede crear cargas útiles maliciosas. Si la verificación de la firma es exitosa, la configuración y el módulo malicioso se descifran mediante AES-128 en modo CFB. La clave para el descifrado es el hash MD5 calculado de la concatenación de la cadena 37d9a33df833c0d6f11f1b8079aaa2dc con la “sal” (salt), y el vector de inicialización es la cadena 0102030405060708.

La configuración contiene información sobre los puntos de entrada y salida del módulo, su nombre y versión. A continuación, se presenta un ejemplo de configuración de uno de los módulos.

Ahora que ya hemos descrito el algoritmo de carga de módulos maliciosos por el backdoor, pasemos a analizarlo.

Cargador de Keenadu

Este módulo (MD5: 4c4ca7a2a25dbe15a4a39c11cfef2fb2) está dirigido a reconocidas tiendas en línea, con los siguientes nombres de paquetes:

• com.amazon.mShop.android.shopping (Amazon)
• com.zzkko (SHEIN)
• com.einnovation.temu (Temu)

Su punto de entrada es el método start de la clase com.ak.p.d.MainApi. Esta clase inicia la tarea maliciosa llamada HsTask. Es un cargador cuyo concepto es similar a AKServer. Al inicio de su trabajo, el cargador recopila datos sobre el dispositivo infectado (modelo del dispositivo, IMEI, dirección MAC, versión del SO, etc.), así como información sobre la aplicación en la que funciona. Los datos obtenidos se codifican de la misma manera que las solicitudes de AKServer en la ruta /ak/api/pts/v4. Después de codificarlos, el cargador envía los datos mediante una solicitud POST al servidor C2 en la ruta /ota/api/tasks/v3.

En respuesta, el servidor de los atacantes devuelve una lista de módulos que descargar y ejecutar, así como una lista de archivos APK para instalar en el dispositivo de la víctima. Es interesante que, en las nuevas versiones de Android, la entrega de estos APK se implementa a través de sesiones de instalación. Es probable que sea la forma en que el malware intenta eludir las restricciones introducidas en las últimas versiones del SO: las aplicaciones provenientes de terceros no pueden obtener en ellas acceso a permisos peligrosos, en particular a Accesibilidad.

Por desgracia, durante la investigación no logramos obtener ejemplos de los módulos y archivos APK que descarga este cargador. Sin embargo, los usuarios en la red reclamaron que las tabletas infectadas agregaban productos a los carritos de las tiendas sin informar al usuario.

Cargador de clickers

Estos módulos (ejemplo: ad60f46e724d88af6bcacb8c269ac3c1) se integran en las siguientes aplicaciones:

• Administrador de fondos de pantalla del sistema (com.android.wallpaper)
• YouTube (com.google.android.youtube)
• Facebook (com.facebook.katana)
• Bienestar digital (com.google.android.apps.wellbeing)
• Lanzador del sistema (com.android.launcher3)

El módulo malicioso comienza sus operaciones obtieniendo datos sobre la ubicación y la dirección IP del dispositivo mediante el servicio GeoIP desplegado en el servidor de comando y control de los atacantes. Los datos conseguidos, así como el tipo de conexión a la red y la versión del SO, se envían al servidor de comando y control. Este, en respuesta, devuelve un archivo de formato especial, que contiene un JSON cifrado con información sobre las cargas útiles y la clave para descifrarlo mediante XOR. La estructura de este archivo se describe a continuación, usando pseudocódigo.

El JSON obtenido después del descifrado representa un array de objetos con enlaces para descargar cargas útiles, así como información sobre los puntos de entrada. A continuación se presenta un ejemplo de tal objeto. Las cargas útiles están cifradas según el mismo principio que el JSON con información sobre ellas.

Durante la investigación obtuvimos varias cargas útiles, cuyo objetivo principal es la interacción con elementos publicitarios en sitios de diversa temática (sitios de juegos, sitios de recetas, sitios de noticias). El módulo interactúa con un sitio concreto, cuya dirección está codificada en su código.

Módulo para el navegador Chrome

El módulo (MD5: 912bc4f756f18049b241934f62bfb06c) está dirigido al navegador Google Chrome (com.android.chrome). Lo primero que hace es registrar un manejador (handler) de eventos del ciclo de vida de las actividades de la aplicación (Activity Lifecycle Callbacks). Al iniciar cada actividad en la aplicación objetivo, este manejador verifica su nombre. Si coincide con ChromeTabbedActivity, el troyano busca el campo de entrada de texto (consultas de búsqueda y direcciones de sitios web) llamado url_bar.

Si se encuentra tal elemento, el malware rastrea los cambios de texto en él. Todas las consultas de búsqueda ingresadas por el usuario en url_bar se envían al servidor de los atacantes. Además, tras terminar de ingresar la consulta, el troyano también puede sustituir el motor de búsqueda del usuario dependiendo de la configuración obtenida del servidor del atacante.

Vale la pena mencionar que la sustitución del buscador podría no funcionar si el usuario selecciona una solicitud desde las sugerencias, ya que en ese caso no se presiona la tecla Intro o el botón de búsqueda en la barra de direcciones (url_bar), que es el encargado de señalar al malware que se está iniciando una búsqueda. Sin embargo, los atacantes también estaban preparados para esto. El troyano intenta encontrar en la actividad actual el elemento omnibox_suggestions_dropdown, que representa un grupo de elementos gráficos (ViewGroup): sugerencias del motor de búsqueda. El troyano rastrea las pulsaciones en las sugerencias y sustituye el motor de búsqueda.

Clicker Nova (Phantom)

El módulo al inicio (MD5: f0184f6955479d631ea4b1ea0f38a35d) era un clicker que se integraba en el gestor de fondos de pantalla del sistema (com.android.wallpaper). En paralelo con nosotros, lo descubrieron investigadores de Dr.Web, quienes, sin embargo, no mencionaron en su informe el vector de distribución del clicker mediante el backdoor Keenadu. El módulo usa tecnologías de aprendizaje automático y WebRTC para interactuar con elementos publicitarios. Los colegas de Dr.Web lo llamaron Phantom, pero en la respuesta del servidor de comando y control se llama Nova. Además, la tarea ejecutada en el código también se llama NovaTask. Basándonos en esto, consideramos que el nombre original del clicker es Nova.

Señalemos también que algún tiempo después de la publicación del informe sobre este clicker, el servidor de comando y control de Keenadu comenzó a eliminarlo de los dispositivos infectados. Lo más probable es que los atacantes lo hayan hecho para evitar la detección.

Asimismo, en la solicitud de descarga, el módulo Nova tenía un nombre algo diferente. Consideramos que bajo el nuevo nombre se oculta la última versión del módulo, que es un cargador y puede descargar los siguientes módulos:

• Clicker Nova.
• Módulo espía que carga información sobre el dispositivo de la víctima al servidor de los atacantes.
• Dropper Gegu SDK. Este módulo, según nuestros datos, es un dropper multinivel que ejecuta otros dos clickers.

Monetización de instalaciones

El módulo con hash MD5 3dae1f297098fa9d9d4ee0335f0aeed3 se integra en la aplicación del sistema para escritorio (com.android.launcher3). Al inicio de su trabajo, verifica el entorno en busca de artefactos de máquina virtual. Si no los encuentra, el malware registra un manejador de eventos de sesión de instalación de aplicaciones.

A la vez, el módulo solicita la configuración del servidor de comando y control. A continuación se presenta un ejemplo de tal configuración.

Cuando en el dispositivo se inicia la instalación de una aplicación, el troyano envía información sobre esta aplicación al servidor de comando y control. En respuesta, el servidor de comando y control proporciona información sobre el anuncio publicitario que la promociona.

Para cada sesión de instalación completada con éxito, el troyano ejecuta solicitudes GET en el enlace del campo tracking_link en la respuesta, así como en el primer enlace del array click. Los enlaces del array click, a juzgar por el código, son plantillas en las que se sustituyen varios identificadores publicitarios. Es posible que este sea un intento de monetizar las instalaciones de aplicaciones. Para esto, el troyano finge el tráfico desde el dispositivo de la víctima, convenciendo así a las plataformas publicitarias de que la aplicación fue instalada a partir de un anuncio.

Módulo para Google Play

Aunque AKClient finaliza la ejecución si se detecta a sí mismo en el proceso de Google Play, pudimos obtener la carga útil para este proceso desde el servidor C2. Este módulo (MD5: 529632abf8246dfe555153de6ae2a9df) recibe el identificador publicitario de Google Ads y lo guarda mediante la instancia global de la clase Settings con la clave S_GA_ID3. En adelante, otros módulos lo pueden usar como identificador de la víctima.

Otros vectores de distribución de Keenadu

Durante la investigación decidimos buscar otras fuentes de infección de Keenadu. Como resultado, descubrimos que algunos módulos descritos arriba figuraban en ataques no relacionados con la infección de libandroid_runtime.so. Hablaremos de ellos con más detalle.

Aplicaciones del sistema

Según los datos de nuestra telemetría, el cargador de Keenadu se encontraba en diversas aplicaciones del sistema, en los firmwares de algunos dispositivos. Una de tales aplicaciones (MD5: d840a70f2610b78493c41b1a344b6893) resultó ser el servicio de reconocimiento facial con nombre de paquete com.aiworks.faceidservice. La aplicación contiene un conjunto de modelos de aprendizaje automático entrenados para reconocer rostros y permitir, en particular, la autenticación. Para esto, la aplicación define el servicio com.aiworks.lock.face.service.FaceLockService, que es usado por la interfaz del sistema (com.android.systemui) para desbloquear el dispositivo mediante reconocimiento facial.

En el método onCreate del servicio com.aiworks.lock.face.service.FaceLockService, que será llamado al crear el servicio, se registran tres receptores que rastrean eventos de encendido y apagado de la pantalla, inicio de carga y disponibilidad de conexión de red. Cada uno de los receptores llama al método startMars, cuyo objetivo principal es inicializar el cargador malicioso mediante la llamada al método init de la clase com.hs.client.TEUtils.

El cargador es una versión muy parecida al de Keenadu. Esta versión usa la biblioteca nativa libhshelper.so para cargar módulos y para instalar APK. Para estos fines, la biblioteca define los métodos nativos correspondientes de la clase com.hs.helper.NativeMain.

Este vector de ataque (integración del cargador en aplicaciones del sistema) en sí mismo no es una novedad. Ya hemos descrito casos similares, por ejemplo, el cargador Dwphon, que se integraba en aplicaciones del sistema para actualizaciones OTA. Sin embargo, es la primera vez que nos encontramos con un troyano en un servicio de reconocimiento facial.

Además del servicio de reconocimiento facial, descubrimos otras aplicaciones del sistema infectadas con el cargador de Keenadu. Entre ellas está la aplicación de escritorio (launcher) en algunos dispositivos (MD5: 382764921919868d810a5cf0391ea193). En tales aplicaciones estaba integrado el servicio malicioso com.pri.appcenter.service.RemoteService, que inicia la ejecución del troyano.

También encontramos el cargador Keenadu en una aplicación cuyo paquete se llama com.tct.contentcenter (d07eb2db2621c425bda0f046b736e372). La app incluye el SDK publicitario fwtec, que obtiene su configuración mediante una solicitud HTTP GET a hxxps://trends.search-hub[.]cn/vuGs8 con follow-redirects desactivado. En respuesta, el troyano esperaba el código 302 (redirección) con URL en el encabezado Location, en cuyos parámetros se contenía la configuración del SDK. El parámetro hsby_search_switch actúa como switch de activación: cuando su valor es 1, el SDK fwtec inicia el cargador de Keenadu dentro del proceso de la aplicación.

Carga por otros backdoors

Al analizar nuestra telemetría, descubrimos una versión inusual del cargador de Keenadu (MD5: f53c6ee141df2083e0200a514ba19e32) en los directorios de diversas aplicaciones en el almacenamiento externo, ubicados en la ruta del tipo /storage/emulated/0/Android/data/%PACKAGE%/files/.dx/. A juzgar por el código, el cargador estaba diseñado para funcionar en un sistema con proceso system_server comprometido. Al mismo tiempo, los nombres de las interfaces binder que contenía diferían de las interfaces de AKServer. El cargador usaba las siguientes interfaces:

• com.androidextlib.sloth.api.IPServiceM
• com.androidextlib.sloth.api.IPermissionsM

Otro backdoor, con una estructura similar y también hallado en libandroid_runtime.so, usaba las mismas interfaces binder. El inicio de este backdoor en dispositivos infectados ocurre de la siguiente manera: libandroid_runtime.so importa la función maliciosa __android_log_check_loggable de la biblioteca liblog.so (MD5: 3d185f30b00270e7e30fc4e29a68237f). Esta función se llama en la implementación del método nativo println_native de la clase android.util.Log. Descifra mediante XOR de un byte la carga útil codificada en el cuerpo de la biblioteca y la ejecuta en el contexto de todas las aplicaciones en el dispositivo.

La carga útil tiene muchas similitudes con el backdoor BADBOX, una plataforma maliciosa compleja que fue descrita por primera vez por investigadores de HUMAN Security. En particular, coinciden las rutas en los servidores C2 a las que el troyano envía solicitudes HTTP. Por lo tanto, consideramos que esta es una de las versiones de BADBOX.

En este backdoor también descubrimos las interfaces binder que utilizaba el cargador Keenadu que mencionamos antes. Esto indica que las instancias correspondientes de Keenadu fueron instaladas por BADBOX.

Modificaciones de aplicaciones populares

Por desgracia, que no se detecte Keenadu u otro backdoor preinstalado en el firmware de un dispositivo, no significa que el troyano no sea una amenaza. Así, el clicker Nova (Phantom) fue descubierto en paralelo con nosotros por los investigadores de Dr.Web. En su informe se describe otro vector de distribución: mediante modificaciones de programas populares que se entregan, en su gran mayoría, desde orígenes no oficiales, así como diversas aplicaciones en la tienda GetApps.

Google Play

Las aplicaciones infectadas penetraron también en Google Play. Durante la investigación identificamos apps de cámaras IP troyanizadas que se distribuían en la tienda oficial Google Play. El volumen combinado de descargas superaba las 300 000.

Todas incluían el servicio com.arcsoft.closeli.service.KucopdInitService, responsable de inicializar el clicker Nova. Alertamos a Google sobre la presencia de aplicaciones infectadas en la tienda y los desarrolladores las eliminaron. El servicio malicioso estaba presente en todas las apps, pero su activación dependía del nombre del paquete: solo se ejecutaba cuando este coincidía con com.taismart.global.

Los Cuatro Fantásticos: los vínculos que existen entre Triada, BADBOX, Vo1d y Keenadu

Al descubrir que BADBOX descarga uno de los módulos de Keenadu, decidimos realizar una investigación adicional para averiguar si no hay más señales de conexión entre estos troyanos. Como resultado, descubrimos que BADBOX y Keenadu tienen similitudes en el código de la carga útil que descifra y ejecuta el código malicioso en libandroid_runtime.so. También descubrimos similitudes entre el cargador de Keenadu y el módulo BB2DOOR del troyano BADBOX. Considerando que en el código hay diferencias evidentes, así como el hecho de que BADBOX descargaba el cargador de Keenadu, suponemos que son botnets diferentes, y los desarrolladores de Keenadu quizá se hayan inspirado en el código de BADBOX. Además, los autores de Keenadu dirigen sus esfuerzos ante todo a las tabletas Android.

En nuestro último informe sobre el backdoor Triada mencionamos que el servidor de comando y control de uno de los módulos descargados por él se ubicaba en el mismo dominio que uno de los servidores de comando y control de la botnet Vo1d, lo que puede indicar la conexión entre estos dos troyanos. Sin embargo, durante la investigación, logramos descubrir una conexión entre Triada y la botnet BADBOX. En los directorios donde BADBOX descargaba el cargador de Keenadu también se encontraban otras cargas útiles para diversas aplicaciones. Su descripción merece un informe aparte, y para resumir no entraremos en detalles en este artículo, limitándonos al análisis de la carga útil para clientes de Telegram e Instagram (MD5: 8900f5737e92a69712481d7a809fcfaa). El punto de entrada de esta carga útil es la clase com.extlib.apps.InsTGEnter. Está destinada al robo de credenciales de las cuentas de las víctimas en los servicios infectados. Es interesante que en ella también hay código para el robo de credenciales del cliente de WhatsApp, que, sin embargo, no se usa de ninguna manera.

Las direcciones de los servidores C2 a los que el troyano exfiltra datos se almacenan cifradas en el código del malware. Para descifrarlas, primero se decodifica el string en base64 y luego se aplica XOR con la clave xiwljfowkgs.

Tras descifrar las direcciones C2, identificamos el dominio zcnewy[.]com, que se asociaba con campañas de Triada. Encontramos ese dominio en 2022 en modificaciones maliciosas de WhatsApp que contenían Triada. En ese momento suponíamos que el fragmento de código destinado al robo de credenciales del cliente de WhatsApp y el dropper malicioso pertenecían a Triada. Tomando en cuenta que hemos mostrado que el dominio zcnewy[.]com está relacionado con BADBOX, consideramos que en 2022 las modificaciones infectadas de WhatsApp que describimos contenían dos troyanos diferentes: Triada y BADBOX. Para confirmar esta hipótesis, volvimos a estudiar una de estas modificaciones (caa640824b0e216fab86402b14447953) y descubrimos que en ella estaba integrado el código del dropper de Triada y del módulo de BADBOX, similar en funcionalidad al descrito arriba. Los troyanos, aunque se iniciaban desde un mismo punto de entrada, no interactuaban entre sí de ninguna manera y su estructura era muy diferente. Esto nos hace pensar que en 2022 observamos un ataque conjunto de BADBOX y Triada.

Por lo tanto, podemos concluir que varias de las mayores botnets de Android interactúan entre sí. Por el momento, logramos confirmar la conexión de Triada con Vo1d y BADBOX, así como la conexión de Keenadu con BADBOX. Los investigadores de HUMAN Security también señalaron la conexión entre Vo1d y BADBOX. Vale decir que las conexiones descritas no son transitivas. Por ejemplo, de la conexión de Triada y Keenadu con BADBOX no se deduce que Triada y Keenadu estén conectados entre sí; esta última afirmación requiere una prueba aparte. Sin embargo, no nos sorprendería si dentro de poco aparecieran informes que permitan demostrar que esta conexión sí existe.

Las víctimas

Según los datos de nuestra telemetría, 13 715 usuarios en todo el mundo se toparon con Keenadu o sus módulos. Nuestras soluciones de seguridad registraron el mayor número de usuarios atacados por malware en Rusia, Japón, Alemania, Brasil y los Países Bajos.

Nuestras recomendaciones

Nuestro servicio de soporte técnico recibe con frecuencia preguntas sobre las acciones a realizar si la solución de seguridad detecta Keenadu en el dispositivo. En esta sección veremos todos los escenarios posibles de lucha contra el troyano.

Si la biblioteca libandroid_runtime.so está infectada

En las versiones modernas de Android, la partición del sistema, en la que entre otras cosas se encuentra libandroid_runtime.so, está montada en modo “solo lectura”. Incluso si se admite la posibilidad teórica de modificar esta partición, la biblioteca infectada libandroid_runtime.so no se podrá eliminar sin dañar el firmware: el dispositivo dejará de arrancar. Por lo tanto, no será posible eliminar la amenaza con medios estándar del SO Android. El uso de un dispositivo infectado con el backdoor Keenadu puede acarrear múltiples inconvenientes. Por ejemplo, en las reseñas de dispositivos infectados, los compradores se quejan de publicidad molesta, así como de la aparición de diversos sonidos cuya fuente no logran establecer.

Si su dispositivo está infectado con el backdoor Keenadu, recomendamos:

1. Verificar la disponibilidad de actualizaciones de software. Es posible que para el dispositivo ya haya salido un firmware limpio. Después de la actualización, es necesario verificar con ayuda de una solución de protección confiable que el problema se haya solucionado.
2. Si no existe una actualización de firmware limpia del fabricante para tu dispositivo, puede instalar un firmware limpio de forma independiente. Es importante recordar que instalar firmware de forma manual puede dejar el dispositivo inoperante.
3. Hasta el reemplazo o actualización del firmware, recomendamos abstenerse de usar el dispositivo infectado.

Si una de las aplicaciones del sistema está infectada

Por desgracia, como en el caso anterior, no será posible eliminar tal aplicación del dispositivo, ya que se encuentra en la partición del sistema. Si encontró el cargador de Keenadu en una aplicación del sistema, le recomendamos:

1. De ser posible, encontrar un reemplazo para la aplicación. Por ejemplo, si la aplicación de escritorio está infectada, se puede descargar cualquier análogo que no contenga software malicioso. Si no existen alternativas para la aplicación (por ejemplo, el servicio de reconocimiento facial está infectado), recomendamos en la medida de lo posible no usar la función correspondiente.
2. Deshabilitar la aplicación infectada mediante ADB si se encontró un análogo para ella o se puede renunciar a su funcionalidad. Esto se puede hacer con el comando adb shell pm disable --user 0 %PACKAGE%.

Si en el dispositivo se instaló una aplicación infectada

Este es uno de los casos más simples de infección. Si la solución de protección descubrió en su dispositivo una aplicación infectada con Keenadu, basta con eliminar la aplicación siguiendo las indicaciones de la solución de protección.

Conclusión

Los desarrolladores de backdoors preinstalados en firmwares de dispositivos Android siempre se han distinguido por su alta calificación. En el caso de Keenadu, también es así: los autores del malware comprenden bien la estructura de Android y el proceso de inicio de aplicaciones, así como los principios básicos de seguridad del sistema operativo. Durante la investigación nos sorprendió el alcance de las campañas de Keenadu: además del backdoor principal en los firmwares, sus módulos se encontraban en aplicaciones del sistema e incluso en aplicaciones de Google Play. Esto coloca al troyano en la misma escala que otros malware como Triada o BADBOX. La aparición de un nuevo backdoor preinstalado de tal escala significa que esta categoría de malware es un mercado aparte donde existe una gran competencia.

Keenadu es una plataforma maliciosa amplia y compleja que proporciona a los atacantes un control ilimitado sobre el dispositivo de la víctima. Aunque por el momento logramos mostrar que el backdoor se usa para diversos tipos de fraude publicitario, no descartamos que en el futuro el malware pueda seguir, por ejemplo, el camino de Triada y comenzar a robar credenciales.

Indicadores de compromiso

Los clientes del servicio Threat Intelligence disponen de indicadores adicionales de compromiso, detalles técnicos y una regla YARA para detectar la actividad de Keenadu. Para más información, escríbanos a crimewareintel@kaspersky.com.

Bibliotecas maliciosas libandroid_runtime.so
bccd56a6b6c9496ff1acd40628edd25e
c4c0e65a5c56038034555ec4a09d3a37
cb9f86c02f756fb9afdb2fe1ad0184ee
f59ad0c8e47228b603efc0ff790d4a0c
f9b740dd08df6c66009b27c618f1e086
02c4c7209b82bbed19b962fb61ad2de3
185220652fbbc266d4fdf3e668c26e59
36db58957342024f9bc1cdecf2f163d6
4964743c742bb899527017b8d06d4eaa
58f282540ab1bd5ccfb632ef0d273654
59aee75ece46962c4eb09de78edaa3fa
8d493346cb84fbbfdb5187ae046ab8d3
9d16a10031cddd222d26fcb5aa88a009
a191b683a9307276f0fc68a2a9253da1
65f290dd99f9113592fba90ea10cb9b3
68990fbc668b3d2cfbefed874bb24711
6d93fb8897bf94b62a56aca31961756a

Cargas útiles de Keenadu
2922df6713f865c9cba3de1fe56849d7
3dae1f297098fa9d9d4ee0335f0aeed3
462a23bc22d06e5662d379b9011d89ff
4c4ca7a2a25dbe15a4a39c11cfef2fb2
5048406d8d0affa80c18f8b1d6d76e21
529632abf8246dfe555153de6ae2a9df
7ceccea499cfd3f9f9981104fc05bcbd
912bc4f756f18049b241934f62bfb06c
98ff5a3b5f2cdf2e8f58f96d70db2875
aa5bf06f0cc5a8a3400e90570fb081b0
ad60f46e724d88af6bcacb8c269ac3c1
dc3d454a7edb683bec75a6a1e28a4877
f0184f6955479d631ea4b1ea0f38a35d

Aplicaciones del sistema infectadas con el descargador Keenadu
07546413bdcb0e28eadead4e2b0db59d
0c1f61eeebc4176d533b4fc0a36b9d61
10d8e8765adb1cbe485cb7d7f4df21e4
11eaf02f41b9c93e9b3189aa39059419
19df24591b3d76ad3d0a6f548e608a43
1bfb3edb394d7c018e06ed31c7eea937
1c52e14095f23132719145cf24a2f9dc
21846f602bcabccb00de35d994f153c9
2419583128d7c75e9f0627614c2aa73f
28e6936302f2d290c2fec63ca647f8a6
382764921919868d810a5cf0391ea193
45bf58973111e00e378ee9b7b43b7d2d
56036c2490e63a3e55df4558f7ecf893
64947d3a929e1bb860bf748a15dba57c
69225f41dcae6ddb78a6aa6a3caa82e1
6df8284a4acee337078a6a62a8b65210
6f6e14b4449c0518258beb5a40ad7203
7882796fdae0043153aa75576e5d0b35
7c3e70937da7721dd1243638b467cff1
9ddd621daab4c4bc811b7c1990d7e9ea
a0f775dd99108cb3b76953e25f5cdae4
b841debc5307afc8a4592ea60d64de14
c57de69b401eb58c0aad786531c02c28
ca59e49878bcf2c72b99d15c98323bcd
d07eb2db2621c425bda0f046b736e372
d4be9b2b73e565b1181118cb7f44a102
d9aecc9d4bf1d4b39aa551f3a1bcc6b7
e9bed47953986f90e814ed5ed25b010c

Aplicaciones infectadas con el clicker Nova
0bc94bc4bc4d69705e4f08aaf0e976b3
1276480838340dcbc699d1f32f30a5e9
15fb99660dbd52d66f074eaa4cf1366d
2dca15e9e83bca37817f46b24b00d197
350313656502388947c7cbcd08dc5a95
3e36ffda0a946009cb9059b69c6a6f0d
5b0726d66422f76d8ba4fbb9765c68f6
68b64bf1dea3eb314ce273923b8df510
9195454da9e2cb22a3d58dbbf7982be8
a4a6ff86413b3b2a893627c4cff34399
b163fa76bde53cd80d727d88b7b1d94f
ba0a349f177ffb3e398f8c780d911580
bba23f4b66a0e07f837f2832a8cd3bd4
d6ebc5526e957866c02c938fc01349ee
ec7ab99beb846eec4ecee232ac0b3246
ef119626a3b07f46386e65de312cf151
fcaeadbee39fddc907a3ae0315d86178

CDN para entregar cargas útiles
ubkt1x.oss-us-west-1.aliyuncs[.]com
m-file-us.oss-us-west-1.aliyuncs[.]com
pkg-czu.istaticfiles[.]com
pkgu.istaticfiles[.]com
app-download.cn-wlcb.ufileos[.]com

Servidores C2
110.34.191[.]81
110.34.191[.]82
67.198.232[.]4
67.198.232[.]187
fbsimg[.]com
tmgstatic[.]com
gbugreport[.]com
aifacecloud[.]com
goaimb[.]com
proczone[.]com
gvvt1[.]com
dllpgd[.]click
fbgraph[.]com
newsroomlabss[.]com
sliidee[.]com
keepgo123[.]com
gsonx[.]com
gmsstatic[.]com
ytimg2[.]com
glogstatic[.]com
gstatic2[.]com
uscelluliar[.]com
playstations[.]click