RatHat convierte las herramientas de depuración propias de Android y la IA generativa en un canal de control persistente

Una nueva familia de malware para Android, denominada RatHat, combina el abuso de los servicios de accesibilidad, el emparejamiento autónomo mediante ADB, superposiciones para robar credenciales, servicios nativos en segundo plano y navegación de la interfaz guiada por IA. Los investigadores informaron sobre este malware el 17 de septiembre de 2026 y atribuyeron su operación a actores de amenazas con base en China.

RatHat llega a las víctimas a través de anuncios maliciosos, campañas de phishing por SMS, páginas de descarga engañosas, portales de terceros y foros. Estas campañas convencen a los usuarios para que instalen paquetes APK alojados fuera de Google Play.

Una vez instalado y después de obtener permisos de accesibilidad, RatHat puede activar la depuración inalámbrica, emparejarse con el servicio local de Android Debug Bridge del dispositivo y obtener ejecución a nivel de shell. Sus componentes pueden mantener el acceso incluso si la víctima elimina la aplicación de Android visible.

Los APK instalados fuera de Google Play abren la puerta al abuso de la accesibilidad

El APK inicial actúa como un dropper del payload principal de RatHat. También incluye protecciones diseñadas para interferir con la inspección automatizada, la depuración y la ingeniería inversa.

La infección depende en gran medida de la ingeniería social. Los usuarios de Android deben instalar el paquete desde fuera de Google Play y después conceder permisos que proporcionan a la aplicación un control considerable sobre la interfaz.

Los servicios de accesibilidad son fundamentales para el ataque. Aunque están diseñados para ayudar a los usuarios a interactuar con los dispositivos, también pueden permitir que una aplicación observe los elementos de la interfaz y ejecute acciones sintéticas cuando se utilizan de forma indebida.

Tras obtener este acceso, RatHat puede navegar por los ajustes de Android, activar las Opciones de desarrollador, habilitar la Depuración inalámbrica y obtener el código de seis dígitos utilizado para el emparejamiento mediante ADB. De este modo, puede establecer una conexión de depuración local sin necesidad de conectar físicamente un equipo controlado por el atacante.

Esta técnica de autoemparejamiento proporciona a RatHat acceso a un shell de ADB y capacidades que van más allá de las implementadas directamente en la aplicación maliciosa. Mecanismos similares ya habían aparecido en las familias de malware para Android ToxicPanda y RedHook.

No se han revelado las versiones de Android afectadas. Por el momento tampoco hay disponibles nombres de paquetes maliciosos, hashes, dominios, direcciones IP ni otros indicadores específicos de la campaña.

Tres componentes crean una persistencia redundante

RatHat utiliza tres capas que cooperan entre sí, en lugar de depender de un único paquete de Android.

La primera es la propia aplicación maliciosa. Gestiona el acceso a la accesibilidad, activa funciones de depuración, despliega otros componentes, muestra superposiciones de phishing, intercepta comunicaciones, graba la pantalla e impide su eliminación.

El segundo componente es un agente local basado en Go, camuflado o empaquetado como liblocal-service.so. Al ejecutarse con el acceso obtenido a través del demonio ADB local, el agente puede ejecutar comandos proporcionados por el atacante, solicitar excepciones a la gestión de batería, establecer persistencia y recopilar pulsaciones de teclas o toques en la pantalla.

El agente también comprueba si el malware para Android continúa instalado. Si la aplicación se ha eliminado, puede volver a instalarla.

La tercera capa es un cliente proxy inverso de FRP. Un informe sobre la arquitectura de RatHat identifica su biblioteca como libmedia_codec.so. El componente recibe la configuración del túnel a través del agente Go y crea una conexión inversa persistente con la infraestructura de comando y control.

Ese túnel proporciona a los operadores una vía de uso general hasta el demonio ADB del dispositivo, independiente de los comandos integrados de RatHat. Puede mantener el acceso incluso cuando se interrumpen funciones concretas del malware.

La persistencia funciona en ambas direcciones. La aplicación de Android puede restaurar el agente local si este se detiene o desaparece, mientras que el agente puede volver a instalar la aplicación. Por tanto, eliminar únicamente el icono de la aplicación o el paquete visible puede dejar el dispositivo comprometido.

RatHat también interfiere activamente con la desinstalación. Cancela el flujo de confirmación de Android y muestra una pantalla de error falsa con el estilo de Google Play, lo que induce a la víctima a creer que la eliminación ha fallado por un motivo legítimo del sistema.

La IA generativa interpreta las pantallas de Android en tiempo real

La característica distintiva de RatHat es un mecanismo de control asistido por IA que interpreta la interfaz de usuario actual en lugar de depender por completo de coordenadas fijas y scripts predefinidos.

El malware serializa en XML la jerarquía de accesibilidad de Android en tiempo real. Después envía esa representación a un asistente de IA generativa de uso extendido cuyo nombre no se ha revelado.

Según los informes, el sistema de IA se utiliza para tres tareas:

• Encontrar un elemento de la interfaz por su nombre y devolver sus coordenadas centrales en formato JSON.
• Extraer el texto que muestra en ese momento un elemento seleccionado.
• Generar instrucciones de navegación como SCROLL_DOWN.

Esto crea un ciclo de decisión dinámico. Si un botón cambia de posición, una aplicación muestra un texto diferente o una pantalla requiere desplazamiento, la IA puede interpretar el árbol de accesibilidad actualizado y sugerir la siguiente acción.

La automatización rígida suele fallar cuando las aplicaciones cambian de diseño, idioma o estado de la interfaz. El enfoque de RatHat permite, en cambio, que los operadores describan un elemento objetivo y deleguen parte del proceso de navegación en el servicio de IA.

Se desconoce la identidad del asistente. Los investigadores no han revelado el modelo, el proveedor, el protocolo de comunicación, la modalidad de cuenta ni si se accede al servicio directamente o a través de una infraestructura controlada por los atacantes.

Esta función no convierte al malware en autónomo en todos los sentidos. RatHat sigue dependiendo de una arquitectura de control extensa, instrucciones de comando y control, acceso a la accesibilidad y ejecución local mediante ADB. Sin embargo, la IA reduce la necesidad de que los operadores naveguen manualmente por cada pantalla o mantengan scripts para cada variación de la interfaz.

El robo bancario es solo una parte de la amenaza

RatHat puede colocar superposiciones HTML sobre aplicaciones bancarias y de criptomonedas para capturar credenciales de las cuentas. También puede interceptar mensajes SMS y notificaciones, lo que podría exponer contraseñas de un solo uso utilizadas durante la autenticación.

Sus funciones de vigilancia abarcan todo el dispositivo. Entre ellas se incluyen:

• Capturar PIN, contraseñas y patrones de desbloqueo de la pantalla de bloqueo.
• Grabar las credenciales introducidas en las aplicaciones.
• Supervisar eventos de cambio de texto y pulsaciones de teclas.
• Recopilar las URL introducidas en las barras de direcciones de los navegadores.
• Grabar los toques en la pantalla mediante el agente Go.
• Crear capturas y grabaciones de pantalla mediante la API MediaProjection de Android.
• Recopilar archivos y el inventario de aplicaciones instaladas.
• Navegar de forma remota por aplicaciones y ajustes del sistema.
• Ejecutar comandos arbitrarios a través del shell de ADB.

El túnel inverso aumenta el impacto porque proporciona un acceso continuado que va más allá de un conjunto fijo de funciones del malware. Un operador con una vía de acceso al demonio ADB puede utilizar las funciones de shell expuestas por el dispositivo comprometido.

Por tanto, RatHat supone un riesgo para cuentas bancarias, servicios de criptomonedas, mensajes privados, archivos almacenados, códigos de autenticación y secretos de desbloqueo del dispositivo. La grabación de pantalla y la supervisión de los toques también pueden revelar información que no se capturaría mediante las superposiciones convencionales para robar credenciales.

La campaña sigue una tendencia más amplia de amenazas para Android que utilizan paquetes instalados fuera de Google Play para realizar vigilancia intrusiva. Otro ejemplo reciente, el malware Mantax Otax, también se distribuyó mediante APK alojados fuera de Google Play, aunque sus capacidades y arquitectura difieren de las de RatHat.

Las estructuras de APK malformadas complican la inspección

Los desarrolladores de RatHat utilizan varias técnicas contra el análisis para provocar comportamientos diferentes en los propios analizadores de Android y en las herramientas habituales de ingeniería inversa.

Algunos archivos se declaran como directorios o se marcan con el indicador de cifrado de propósito general de ZIP. libziparchive de Android puede ignorar esas entradas, mientras que utilidades como unzip y apktool las procesan de otra forma.

El archivo AndroidManifest.xml contiene encabezados de bloque no documentados 0x9999. El entorno de ejecución nativo de Android omite estas estructuras, pero los sistemas de análisis automatizado pueden bloquearse, agotar el tiempo de espera o no conseguir analizar el paquete. También se ha informado de que el manifiesto alcanza 61 MB, un tamaño anómalo que somete a una carga adicional a los sistemas de análisis.

RatHat también inserta pseudoinstrucciones DEX no válidas con un atributo element_width incorrecto, lo que puede romper los desensambladores. Un mecanismo doble de protección de cadenas identificado como StringCrypto: Base64 dificulta aún más el análisis estático.

Estas defensas no proporcionan directamente el control del dispositivo. Su objetivo es retrasar la clasificación, generar resultados incoherentes entre herramientas y reducir la fiabilidad de los flujos automatizados de análisis de malware.

Los investigadores consideran que RatHat está operado por actores con base en China. Las instrucciones en chino enviadas al subsistema de IA respaldan esa evaluación, pero no se ha confirmado ningún grupo de amenazas concreto. La atribución sigue siendo provisional.

La detección debe ir más allá de la aplicación visible

Los usuarios deben evitar los APK promocionados mediante mensajes de texto no solicitados, anuncios, foros, páginas de phishing o portales de descarga desconocidos. No deben conceder acceso a la accesibilidad a las aplicaciones salvo que su función legítima lo requiera claramente.

La activación inesperada de las Opciones de desarrollador o de la Depuración inalámbrica es una señal de alerta importante. Los usuarios también deben investigar solicitudes de emparejamiento mediante ADB que no puedan explicar, peticiones de excepciones de batería, permisos sospechosos para grabar la pantalla y aplicaciones que muestren errores con la apariencia de Google Play durante la eliminación.

Los análisis de Google Play Protect pueden ayudar a identificar aplicaciones dañinas, pero los servicios independientes de RatHat complican la respuesta más que la simple eliminación de un APK.

Los equipos de seguridad empresarial y móvil deben buscar:

• Servicios de accesibilidad no autorizados.
• Activación inesperada de la Depuración inalámbrica.
• Eventos de emparejamiento local mediante ADB que no reconozcan.
• Bibliotecas nativas con los nombres liblocal-service.so o libmedia_codec.so.
• Tráfico inusual de un proxy inverso de FRP.
• Procesos persistentes que sobrevivan a la eliminación de la aplicación.
• Instalaciones repetidas de un paquete eliminado anteriormente.
• Pantallas falsas de Google Play que informen de un fallo durante la desinstalación.

Los nombres de las bibliotecas, por sí solos, no bastan para demostrar una infección y deben evaluarse junto con la actividad de los procesos, los paquetes, la red y ADB.

No se ha publicado ningún procedimiento completo de remediación por parte de los proveedores. Dado que el agente Go de RatHat puede sobrevivir a la eliminación de la aplicación principal y volver a instalarla posteriormente, los equipos de respuesta deben verificar que también hayan desaparecido el servicio accesible mediante ADB y el túnel inverso. De lo contrario, la eliminación aparente podría limitarse a borrar la parte más visible del compromiso.