El malware Android RatHat usa IA, pero la persistencia mediante ADB es la amenaza mayor
El malware Android RatHat ha incorporado control de pantalla guiado por IA, pero su amenaza más profunda proviene de una arquitectura de tres partes diseñada para sobrevivir a su eliminación. Investigadores de seguridad revelaron el malware el 16 de septiembre de 2026, tras analizar su navegación automatizada, robo de credenciales y mecanismos de persistencia inusuales. Según los informes, RatHat combina acceso a Android Accessibility, depuración inalámbrica local y dos agentes nativos que operan más allá de la aplicación maliciosa principal.
El componente de IA ayuda a RatHat a interpretar interfaces cambiantes, en lugar de depender por completo de instrucciones fijas. Esto proporciona a los operadores una forma más flexible de localizar botones, leer etiquetas y navegar por dispositivos comprometidos. Sin embargo, la IA no proporciona el acceso inicial. Las víctimas aún deben instalar un paquete Android fuera de Google Play y conceder los permisos necesarios para iniciar el ataque.
El cambio más importante es el intento de RatHat de conservar el control después de que la aplicación visible desaparezca. Malware anterior asistido por IA, incluido PromptSpy, mostró cómo un modelo de lenguaje podía navegar por interfaces específicas de distintos fabricantes. Según los informes, RatHat combina esa adaptabilidad con acceso a nivel de shell, superposiciones para robar credenciales, registro de pulsaciones y un túnel de red persistente.
El malware Android RatHat combina IA con control persistente
RatHat convierte una aplicación Android maliciosa en el punto de entrada de un sistema de control más amplio que puede sobrevivir a la propia aplicación.
El equipo zLabs de Zimperium reveló RatHat tras examinar una cadena de infección multietapa distribuida mediante smishing, malvertising, páginas de phishing y foros de terceros. Estos canales dirigen a los usuarios hacia archivos APK maliciosos, que son paquetes de aplicaciones Android instalados fuera del flujo habitual de Play Store.
La aplicación maliciosa primero solicita permisos de Accessibility. Los servicios Android Accessibility están diseñados para ayudar a las personas a interactuar con sus dispositivos, pero también pueden exponer contenido de la interfaz y permitir entradas automatizadas. Los operadores de malware abusan con frecuencia de estas capacidades para leer pantallas, pulsar botones y aprobar acciones sensibles.
Según los informes, RatHat utiliza ese acceso para habilitar Developer Options y Wireless Debugging. Luego extrae el código de emparejamiento de seis dígitos necesario para una conexión local de Android Debug Bridge. ADB es la interfaz legítima de comandos de Android para desarrollo, pruebas y administración de dispositivos.
Según el detallado análisis de RatHat, este proceso proporciona a un agente Go integrado ejecución a nivel de shell sin necesidad de un ordenador externo. El agente se almacena bajo el nombre engañoso de biblioteca liblocal-service.so.
Este agente puede ejecutar comandos, obtener exenciones de gestión de batería, recopilar entradas y facilitar la persistencia. Zimperium afirma que también puede comprobar si la aplicación maliciosa sigue instalada y restaurarla cuando sea necesario. La aplicación también puede restaurar el agente si dicho componente desaparece.
Un segundo componente nativo, denominado libmedia_codec.so, actúa como cliente Fast Reverse Proxy. Crea un túnel entre los servicios locales del teléfono y la infraestructura del atacante. Esta vía proporciona a los operadores un acceso que no depende exclusivamente del canal de comandos original de la aplicación.
RatHat puede mostrar superposiciones HTML que imitan aplicaciones bancarias, de pagos y de criptomonedas. Una superposición coloca una interfaz fraudulenta sobre una aplicación legítima, animando a los usuarios a introducir credenciales en campos controlados por los atacantes.
Los investigadores también encontraron funciones para interceptar mensajes SMS, notificaciones y contraseñas de un solo uso. El malware puede registrar cambios de texto, inspeccionar barras de direcciones del navegador, capturar pantallas y recopilar listas de aplicaciones instaladas.
Según los informes, su agente nativo también supervisa la entrada táctil de bajo nivel. Esta función puede ayudar a reconstruir toques en pantalla, PIN, contraseñas y patrones de desbloqueo a partir de los movimientos del usuario.
Estas capacidades convierten al subsistema de IA en solo una parte de la amenaza. RatHat utiliza IA para hacer que la navegación sea más adaptable, mientras que el acceso ADB y los agentes nativos proporcionan la base operativa duradera.
El motor de navegación con IA elimina un costoso paso manual
La IA de RatHat es relevante porque convierte pantallas Android cambiantes en decisiones de navegación estructuradas sin requerir una intervención constante del operador.
La automatización móvil tradicional depende en gran medida de diseños predecibles, identificadores de recursos o instrucciones cuidadosamente redactadas. Este enfoque deja de ser fiable cuando los fabricantes de dispositivos cambian los menús, traducen etiquetas o rediseñan diálogos del sistema.
Una instrucción que funciona en un Google Pixel puede fallar en un dispositivo Samsung, Oppo o Xiaomi. Incluso diferencias habituales en el tamaño de pantalla, la versión de software y la estructura de accesibilidad pueden romper una secuencia fija.
RatHat resuelve este problema serializando el árbol Accessibility actual en XML. Este árbol describe elementos visibles de la interfaz, etiquetas de texto, tipos de elementos y posiciones en pantalla. El malware envía esa instantánea estructurada a lo que Zimperium denomina un popular asistente de IA generativa.
Los investigadores no identificaron el servicio, el modelo, la cuenta ni el sistema de alojamiento. Por tanto, RatHat no debería describirse como usuario de ningún modelo comercial específico sin más pruebas.
Según los informes, el componente de IA responde a preguntas concretas sobre la interfaz. Puede devolver las coordenadas centrales de un elemento con nombre, determinar el texto mostrado por un elemento o proporcionar instrucciones como SCROLL_DOWN.
Se trata de un papel limitado, pero útil. El modelo no inventa de forma independiente el ataque ni concede nuevos permisos Android. Actúa como intérprete de interfaces entre el objetivo de un operador y la pantalla actual del dispositivo.
Esta distinción importa porque las descripciones sensacionalistas de malware autónomo pueden ocultar los mecanismos subyacentes. RatHat sigue dependiendo de ingeniería social, permisos peligrosos, acceso de depuración, código nativo malicioso e infraestructura controlada por atacantes.
No obstante, su capa de IA puede reducir la carga de trabajo. Un operador no necesita observar cada pantalla infectada ni mantener un script de automatización independiente para cada variante de interfaz. El modelo puede traducir datos de interfaz en tiempo real a la siguiente acción.
El informe sobre navegación con IA de BleepingComputer señala que esta adaptabilidad distingue a RatHat de la automatización basada enteramente en scripts estáticos. También ofrece a los operadores remotos otra forma de navegar sin interacción manual continua.
La técnica se parece al descubrimiento anterior de PromptSpy. Ese malware enviaba datos sobre el estado de la pantalla a Google Gemini y recibía instrucciones para fijarse en la interfaz de aplicaciones recientes de un dispositivo. El comportamiento de fijación difiere entre fabricantes Android, por lo que resulta un problema adecuado para la navegación guiada por modelos.
ESET no había observado PromptSpy en su telemetría cuando apareció la investigación anterior. Por tanto, su alcance en el mundo real seguía siendo incierto. RatHat amplía el concepto hacia una arquitectura más extensa, aunque su prevalencia tampoco se ha revelado.
La evolución es importante. La IA generativa está pasando de ser una ayuda para el desarrollo de ataques a formar parte del ciclo de ejecución de algunos malware. Su ventaja inmediata no es un razonamiento sobrehumano. Es su tolerancia a las variaciones de interfaz.
La persistencia, no la IA, crea el problema de seguridad más difícil
El conflicto central de RatHat es adaptabilidad frente a contención: la aplicación inicia el compromiso, mientras que agentes independientes intentan conservarlo.
El entorno aislado de aplicaciones de Android normalmente separa las aplicaciones de funciones sensibles del sistema y entre sí. Según los informes, RatHat utiliza el emparejamiento ADB local para trasladar parte de su operación a un contexto a nivel de shell con un acceso más amplio a comandos.
Esto no significa que el malware obtenga privilegios root ilimitados. El acceso shell y el acceso root son diferentes. Sin embargo, un shell ADB aún puede realizar acciones no disponibles para una aplicación convencional y puede facilitar la ejecución persistente de comandos.
El agente Go de RatHat expone un servicio HTTP en la interfaz de loopback del dispositivo. El componente de proxy inverso puede entonces hacer accesible ese servicio interno mediante un túnel controlado por el atacante. Esta disposición separa el acceso remoto de la interfaz visible de la aplicación maliciosa.
El diseño resultante tiene tres elementos que cooperan. La aplicación Android obtiene permisos y coordina la actividad. El agente Go ejecuta comandos y gestiona la persistencia. El proxy mantiene una ruta externa hacia los servicios locales.
Si una víctima elimina únicamente la aplicación, otro componente puede reinstalarla, según los informes. Si el agente nativo se detiene, la aplicación puede restaurarlo. Esta recuperación recíproca resulta más problemática que un único mecanismo de persistencia.
RatHat también interfiere con los intentos habituales de eliminación. Los investigadores indican que vigila la pantalla de confirmación de desinstalación de Android, cancela la acción y muestra un falso error de Google Play sobre la interfaz.
Un comportamiento similar contra la eliminación precede a RatHat. El malware Android lleva mucho tiempo abusando de los servicios Accessibility para pulsar botones de navegación o cubrir controles de seguridad. RatHat combina esa técnica conocida con un canal independiente de acceso shell.
Las defensas contra el análisis del malware añaden otra capa. Los investigadores identificaron manipulación de contenedores, atributos ZIP inusuales, cadenas cifradas, pseudoinstrucciones DEX no válidas y comprobaciones en tiempo de ejecución para herramientas de análisis.
Según los informes, su manifiesto Android ocupa 61 MB, y el 99 por ciento está compuesto por dos tipos de fragmentos no documentados. El tiempo de ejecución de Android omite esos fragmentos, mientras que algunas herramientas de análisis pueden fallar o agotar recursos al procesarlos.
La bomba de manifiesto no roba directamente credenciales ni controla un teléfono. Su propósito es ralentizar la inspección automatizada y dificultar la clasificación del paquete. Ese retraso puede dar a una campaña más tiempo antes de que circulen firmas e indicadores.
RatHat también busca depuradores, reempaquetado, emuladores, rastros de root, Frida y Xposed. Estas herramientas son habituales en entornos de análisis de malware. Detectarlas permite al código malicioso cambiar de comportamiento o dejar de ejecutarse bajo inspección.
La arquitectura combinada presiona a los defensores que se centran únicamente en archivos de aplicaciones. Eliminar un APK, identificar un hash conocido o bloquear un servidor de comandos puede no eliminar todos los componentes activos.
Las señales de comportamiento se vuelven más importantes. Los equipos de seguridad pueden buscar concesiones sospechosas de Accessibility, actividad inesperada de Wireless Debugging, emparejamiento ADB local, demonios nativos inusuales y túneles inversos persistentes.
Esto no vuelve inútil la detección mediante firmas. Los hashes de paquetes conocidos, dominios, certificados e indicadores de red siguen siendo valiosos. RatHat muestra por qué estas señales necesitan el respaldo de la supervisión en tiempo de ejecución y del estado del dispositivo.
Las aplicaciones bancarias se enfrentan a un adversario a nivel de interfaz
RatHat ataca la interacción de confianza entre un usuario y una aplicación financiera, no solo los datos almacenados dentro de esa aplicación.
Una aplicación bancaria puede cifrar su base de datos local y proteger el tráfico del servidor mientras el malware observa la pantalla del usuario. Si un servicio Accessibility hostil puede leer el contenido de la interfaz o inyectar toques, las protecciones de la capa de aplicación se enfrentan a un problema diferente.
Según los informes, RatHat muestra interfaces HTML falsas sobre aplicaciones bancarias y de criptomonedas seleccionadas. Una víctima puede creer que una solicitud de inicio de sesión pertenece al servicio auténtico mientras introduce sus datos en una superposición maliciosa.
El malware puede entonces interceptar mensajes SMS o contenido de notificaciones que contenga códigos de verificación. También puede recopilar texto introducido y supervisar direcciones del navegador, proporcionando a los operadores contexto sobre las credenciales capturadas.
Android ha añadido defensas contra estas técnicas. Android 15 limita cierta exposición de contraseñas de un solo uso durante el uso compartido de pantalla y ante los servicios de escucha de notificaciones. Android 16 introdujo una forma para que los desarrolladores marquen elementos sensibles de la interfaz.
La configuración accessibilityDataSensitive puede impedir que los servicios de Accessibility no verificados lean o interactúen con vistas protegidas. La guía de Android 16 de Google la recomienda para contraseñas, información financiera y otros campos sensibles.
Los desarrolladores también pueden utilizar las señales de entorno de Play Integrity. El veredicto de acceso a aplicaciones puede indicar si otra aplicación cuenta con permisos capaces de capturar la pantalla, mostrar superposiciones o controlar el dispositivo.
Estas defensas elevan el coste operativo de RatHat, pero no eliminan el problema. La protección depende de la versión de Android, la configuración del dispositivo, la adopción por parte de los desarrolladores y de si la aplicación maliciosa ya ha establecido otro canal de control.
Accessibility también plantea una difícil disyuntiva para la plataforma. Android debe admitir software de asistencia legítimo que lee contenido de la interfaz y realiza acciones para los usuarios. Bloquear toda interacción automatizada dañaría esas herramientas esenciales.
Google revisa las herramientas de Accessibility distribuidas a través de Play y advierte sobre usos engañosos. Su guía de Play Protect señala que un servicio sospechoso puede solicitar control total del dispositivo y acceso a información personal o financiera.
Según los informes, RatHat llega mediante descargas de APK fuera de Google Play. Esto limita la exposición directa a través de la tienda oficial, pero la instalación mediante sideloading sigue disponible a través de navegadores, mensajes, foros y mercados de terceros.
Google informó en marzo de 2026 que el malware aparecía más de 90 veces más a menudo en fuentes de sideloading que en Google Play. La empresa está ampliando la verificación de desarrolladores, con requisitos regionales de instalación programados para comenzar el 30 de septiembre de 2026.
El momento sitúa a RatHat junto a una respuesta más amplia de la plataforma frente a la distribución maliciosa. La verificación de desarrolladores puede aumentar la responsabilidad sobre el software instalado fuera de Play, aunque las vías de instalación avanzadas seguirán estando disponibles.
Las instituciones financieras también tienen trabajo por hacer. Las acciones de alto riesgo no deberían depender por completo de pruebas mostradas o introducidas en un teléfono potencialmente comprometido.
La confirmación de transacciones puede incorporar puntuación de riesgo del lado del servidor, historial de dispositivos de confianza, cambios de comportamiento y límites para destinatarios añadidos recientemente. Los bancos también pueden cuestionar sesiones cuando las señales de integridad del dispositivo o de acceso a aplicaciones indiquen un riesgo elevado.
Para los equipos empresariales, los dispositivos móviles merecen la misma profundidad de respuesta ante incidentes que los portátiles. Un teléfono con aplicaciones de autenticación, mensajes de trabajo, sesiones en la nube y acceso bancario puede convertirse en un puente hacia varios sistemas.
El alcance y la atribución de RatHat siguen sin estar claros
Las capacidades del malware están documentadas en detalle, pero su número de víctimas, la escala de la campaña y la identidad de sus operadores siguen sin resolverse.
Zimperium vincula RatHat con actores que parecen operar desde China. Las pruebas públicas incluyen mensajes en chino hallados en el malware y la infraestructura de campaña observada.
El idioma no constituye una atribución definitiva. Los desarrolladores de malware pueden reutilizar código, sembrar pistas engañosas, trabajar a través de fronteras o vender herramientas a operadores no relacionados. Los informes disponibles no identifican a un grupo concreto ni a un patrocinador gubernamental.
La investigación pública tampoco proporciona un número confirmado de infecciones. No enumera los países afectados, los bancos objetivo, la duración de la campaña ni el número de servidores de mando activos.
Esa información ausente limita las conclusiones sobre la exposición inmediata. RatHat podría respaldar una campaña muy dirigida, un servicio criminal en desarrollo o una operación más amplia que los investigadores solo han observado parcialmente.
El servicio de IA no identificado crea otra incertidumbre. Los investigadores no han explicado públicamente cómo se autentica el malware ante el asistente, con qué frecuencia envía solicitudes ni qué ocurre cuando falla la conectividad.
Las solicitudes de IA basadas en la nube pueden generar actividad de red detectable. Los proveedores también pueden suspender cuentas abusivas, filtrar prompts sospechosos o cooperar con investigaciones. Los atacantes pueden responder rotando cuentas, utilizando servicios proxy o trasladándose a modelos alojados localmente.
La fiabilidad del modelo también merece escrutinio. La automatización de interfaces puede fallar cuando los datos XML están incompletos, las etiquetas son ambiguas o las pantallas contienen diálogos inesperados. Un toque equivocado puede revelar el malware, interrumpir un ataque o dejar a los operadores sin acceso.
Estas limitaciones no neutralizan la amenaza. Demuestran que el malware asistido por IA sigue dependiendo de infraestructura, credenciales, conectividad y una lógica de respaldo cuidadosamente diseñada.
El caso anterior de PromptSpy ofrece una referencia útil. Su función asistida por modelos abordaba una tarea limitada de persistencia, mientras que un módulo VNC independiente permitía el control remoto. Los investigadores no pudieron confirmar si sus muestras representaban una campaña activa o una prueba de concepto.
RatHat parece más completo desde el punto de vista operativo. Sus canales de distribución, superposiciones para capturar credenciales, sistema de mando, servicios nativos y componente de túnel forman una cadena de ataque coherente.
Sin embargo, la integridad técnica no equivale a un despliegue a gran escala. Los lectores deberían evitar tratar cada capacidad documentada como prueba de que ha afectado a una gran población.
Zimperium también vende productos de seguridad móvil y afirma que sus productos detectan RatHat. Ese contexto comercial no invalida los hallazgos técnicos, pero la replicación independiente sigue siendo valiosa.
Un segundo análisis técnico de The Hacker News corrobora la arquitectura basándose en la divulgación de Zimperium. No representa un análisis independiente del malware con muestras separadas.
La conclusión actual más sólida es más acotada. Los investigadores analizaron malware que combina interpretación de interfaces guiada por IA con técnicas consolidadas de toma de control de Android y una arquitectura basada en ADB inusualmente persistente.
Tres señales mostrarán si RatHat transforma el malware móvil
La próxima prueba es si las técnicas de RatHat se extienden más allá de una familia reportada y fuerzan cambios medibles por parte de defensores, aplicaciones financieras y Android.
La primera señal es la evidencia independiente de campañas. Investigadores adicionales deberían buscar muestras coincidentes, infraestructura de mando, certificados de firma, páginas de distribución e infecciones en la telemetría de clientes.
La geografía confirmada de las víctimas aclararía si RatHat se dirige a determinados bancos o regiones. Un aumento del número de muestras sugeriría desarrollo o distribución activos, en lugar de un experimento técnico aislado.
La ausencia de telemetría amplia debilitaría las afirmaciones de que RatHat representa una ola global inmediata. No eliminaría la lección arquitectónica, pero cambiaría la urgencia.
La segunda señal es la reutilización de la cadena de persistencia local basada en ADB. Los autores de malware copian con frecuencia técnicas que demuestran ser fiables, especialmente cuando la investigación pública revela suficiente detalle de implementación como para inspirar imitaciones.
Los defensores deberían vigilar nuevas familias que habiliten Wireless Debugging, recuperen códigos de emparejamiento, desplieguen agentes a nivel de shell y mantengan el acceso tras eliminar la aplicación. Una adopción repetida haría que este mecanismo fuera más relevante que la marca RatHat.
Android y los fabricantes de dispositivos pueden responder endureciendo las transiciones entre Accessibility, Developer Options, el emparejamiento inalámbrico y los procesos de shell en segundo plano. Mejores advertencias para los usuarios también podrían revelar combinaciones sospechosas de estas acciones.
La tercera señal es la expansión de la IA en tiempo de ejecución más allá de la consulta de interfaces. Según los informes, RatHat pide a un modelo coordenadas, texto visible y comandos de navegación. Las futuras muestras podrían usar modelos para clasificar pantallas financieras, adaptar prompts fraudulentos o seleccionar acciones a partir de objetivos más amplios.
Ese desarrollo reforzaría la necesidad de supervisar el tráfico de servicios de IA en las investigaciones de malware. También presionaría a los proveedores de modelos para identificar abusos automatizados sin bloquear flujos de trabajo legítimos de accesibilidad y pruebas.
Si la IA sigue limitada a unas pocas tareas de navegación frágiles, RatHat parecerá una mejora incremental de automatización. Si varias familias de malware adoptan bucles de decisión, los defensores afrontarán un comportamiento más variable entre dispositivos.
Los usuarios pueden reducir el riesgo actual sin esperar esas señales. Eviten archivos APK recibidos mediante mensajes no solicitados, anuncios o páginas de descarga desconocidas. Consideren las solicitudes inesperadas de Accessibility como una advertencia grave, especialmente cuando provengan de aplicaciones no relacionadas con funciones de asistencia.
Mantengan Play Protect activado y permitan que analice aplicaciones desconocidas. Revisen los servicios de Accessibility habilitados, el acceso a notificaciones, las aplicaciones de administrador del dispositivo, Developer Options y Wireless Debugging cuando se sospeche un compromiso.
Un dispositivo que bloquea la desinstalación o restaura una aplicación eliminada necesita más que otro intento ordinario de eliminación. Desconéctenlo de cuentas y redes sensibles, y busquen después apoyo cualificado de respuesta ante incidentes.
Las organizaciones deberían revocar las sesiones activas, rotar las credenciales expuestas y revisar la actividad financiera desde un dispositivo independiente de confianza. Puede ser necesario un restablecimiento de fábrica, pero los equipos de respuesta deberían preservar pruebas cuando una investigación sea importante.
El malware Android RatHat merece atención porque combina navegación adaptable con un control duradero del dispositivo. La cuestión decisiva es si los defensores pueden contener cada componente, no si su IA puede pulsar el siguiente botón.
