Banking Trojans Móviles: Cerberus, TeaBot, Xenomorph y Vultur

El negocio de los banking trojans móviles

Los banking trojans móviles representan la categoría de malware Android con mayor impacto financiero directo. Estas familias han evolucionado desde herramientas simples de intercepción de SMS hasta plataformas sofisticadas de control remoto capaces de automatizar completamente el fraude bancario, desde la captura de credenciales hasta la ejecución de transferencias.

En 2026, el ecosistema de banking trojans móviles está dominado por el modelo Malware-as-a-Service: un número reducido de desarrolladores construye y mantiene las herramientas, y cientos de operadores las alquilan para ejecutar campañas contra instituciones financieras de todo el mundo.

Este artículo analiza las técnicas compartidas por las principales familias, los perfiles técnicos de cada una, y los métodos de detección disponibles.

Overlay attacks: el mecanismo central

El overlay attack es la técnica fundamental de los banking trojans móviles. Su funcionamiento:

Fase 1: Monitorización de apps

El troyano se registra como Accessibility Service y monitoriza constantemente qué aplicación está en primer plano. Mantiene una lista de paquetes objetivo (package names de apps bancarias) que recibe del C2.

// Paquetes objetivo típicos (ejemplos)
com.bankia.wallet
es.lacaixa.mobile.android.newwapicon
com.bbva.bbvacontigo
es.evobanco.bancamovil
com.cajasur.android
com.bankinter.launcher

Fase 2: Inyección del overlay

Cuando el usuario abre una app bancaria que está en la lista de targets, el troyano superpone una ventana (WebView o Activity) que imita la pantalla de login de esa app. El overlay cubre exactamente la app real.

El overlay puede implementarse de dos formas:

SYSTEM_ALERT_WINDOW: El troyano solicita el permiso SYSTEM_ALERT_WINDOW (dibujar sobre otras apps) y crea una ventana flotante posicionada a pantalla completa sobre la app bancaria. Este método funciona pero es más fácil de detectar.

Accessibility Service overlay: El troyano usa el Accessibility Service para detectar la app en primer plano y lanza una Activity propia a pantalla completa. Este método es más difícil de detectar porque no usa la API de ventanas flotantes.

Fase 3: Captura de credenciales

El usuario introduce sus credenciales en el formulario falso pensando que está interactuando con su banco. Las credenciales se exfiltran al C2 en tiempo real.

Fase 4: Bypass de MFA

Después de capturar las credenciales, el troyano necesita el segundo factor de autenticación:

• SMS OTP: Intercepta el SMS con el código mediante permisos de lectura de SMS o Notification Listener.
• Push notification OTP: Lee la notificación push de la app bancaria.
• Authenticator app: Via Accessibility Service, lee el código de Google Authenticator o similar cuando el usuario lo abre.

Fase 5: Automated Transfer System (ATS)

Las familias más avanzadas (Xenomorph v3+, Octo v2, Hook) implementan ATS: el malware puede ejecutar transferencias bancarias de forma automatizada usando el Accessibility Service para interactuar con la app bancaria real, sin intervención del atacante. El flujo completo (login, selección de destinatario, introducción de cantidad, confirmación) se ejecuta programáticamente.

Abuso de Accessibility Services en detalle

El Accessibility Service es el pilar de los banking trojans modernos. Un servicio de accesibilidad tiene acceso a:

AccessibilityNodeInfo: Estructura de árbol de la UI visible. El malware puede recorrer todos los elementos (botones, campos de texto, labels) de cualquier app.

AccessibilityEvent: Eventos de cambio en la UI. El malware detecta cuándo se abre una app, cuándo cambia el texto de un campo, cuándo aparece una notificación.

performAction(): Ejecutar acciones en la UI: hacer clic, escribir texto, desplazarse. Esto habilita el ATS.

getWindowContent(): Acceder al contenido de todas las ventanas visibles, incluyendo notificaciones expandidas.

El flujo de activación es crítico: el malware necesita que el usuario active manualmente el servicio en Configuración. Para lograrlo, utiliza ingeniería social agresiva:

1. Muestra diálogos persistentes que impiden el uso normal del teléfono hasta que el usuario acepta.
2. Los mensajes simulan ser del sistema: "Se requiere una actualización de seguridad", "Active el servicio para completar la instalación".
3. Algunos utilizan el propio Accessibility Service (si ya está activo) para navegar automáticamente a la pantalla de activación y activar un segundo servicio.

Intercepción de SMS para MFA

La intercepción de SMS fue históricamente el método principal para bypass de MFA. Las técnicas:

BroadcastReceiver para SMS_RECEIVED. El malware registra un receiver con prioridad alta para android.provider.Telephony.SMS_RECEIVED. Procesa el SMS antes que la app de mensajería del sistema y puede cancelar el broadcast para que el usuario no lo vea.

Restricciones recientes:

• Desde Android 10, solo la app de SMS por defecto puede recibir el broadcast SMS_RECEIVED en segundo plano.
• Google Play no permite apps que soliciten READ_SMS y RECEIVE_SMS a menos que sea la app de SMS por defecto.
• Por esta razón, los banking trojans modernos han migrado hacia Notification Listener y Accessibility Service como métodos alternativos de captura de OTP.

Screen recording: el enfoque Vultur

Vultur introdujo un cambio de paradigma en los banking trojans móviles al reemplazar los overlay attacks con screen recording y screen streaming.

Funcionamiento

1. Vultur usa la API MediaProjection de Android para grabar la pantalla del dispositivo. Esta API requiere consentimiento del usuario (un diálogo del sistema), que Vultur obtiene mediante el Accessibility Service (acepta el diálogo automáticamente).
2. Cuando el usuario abre una app bancaria o app objetivo, Vultur inicia la grabación/streaming.
3. El stream se transmite al servidor del atacante via VNC (Virtual Network Computing).
4. El atacante puede observar las credenciales en tiempo real mientras el usuario las introduce.

Ventajas sobre overlay

• Cobertura universal: No necesita un overlay específico para cada banco. Graba cualquier app.
• Captura de autenticación biométrica: Puede observar flujos de autenticación que no involucran texto (patrones, gestos).
• Menos detectable: No utiliza SYSTEM_ALERT_WINDOW ni lanza Activities sobre otras apps.
• Captura de apps de 2FA: Graba la pantalla de Google Authenticator cuando el usuario consulta un código.

Desventajas

• Mayor consumo de recursos: La grabación de pantalla es intensiva en CPU y red.
• Latencia: El atacante ve las credenciales con retraso, lo que dificulta la automatización.
• Detección por batería: El consumo anómalo de batería puede alertar al usuario.

Perfiles de familias

Cerberus

Característica	Detalle
Primera aparición	Junio 2019
Origen	Rusia/CIS
Modelo	MaaS (12.000 USD/año inicialmente)
Estado 2026	Inactivo como servicio, código fuente filtrado
Targets iniciales	Bancos europeos, apps de criptomonedas
Técnicas clave	Overlay, SMS interception, screen lock

Cerberus fue pionero en el modelo MaaS para banking trojans Android. Operó como servicio de alquiler desde junio 2019 hasta agosto 2020, cuando el desarrollador principal abandonó el proyecto y filtró el código fuente en foros clandestinos. Esta filtración generó docenas de variantes derivadas y sirvió como base para familias posteriores como Alien y Ermac.

Sus capacidades técnicas incluían: overlays para 30+ apps bancarias, intercepción de SMS, registro de pulsaciones, bloqueo de pantalla, robo de contactos, y abuso de Accessibility Service.

Anubis

Característica	Detalle
Primera aparición	Diciembre 2017
Origen	Turquía (atribuido)
Modelo	Open source (código filtrado 2019)
Estado 2026	Variantes activas
Targets	300+ apps bancarias globales
Técnicas clave	Overlay, keylogging, ransomware, RAT

Anubis es una de las familias más versátiles. Además de las funcionalidades de banking trojan, incluye módulo de ransomware (cifra archivos y pide rescate) y capacidades de RAT (control remoto del dispositivo). El código fuente se filtró en 2019, generando múltiples variantes que siguen activas.

TeaBot (Anatsa)

Característica	Detalle
Primera aparición	Enero 2021
Origen	Desconocido
Modelo	MaaS
Estado 2026	Activo, foco en Europa
Targets	400+ apps bancarias, foco en España, Italia, Alemania
Técnicas clave	Overlay, ATS, dropper en Google Play

TeaBot (también conocido como Anatsa en versiones posteriores) se ha centrado agresivamente en Europa. Sus campañas utilizan dropper apps en Google Play como vector de distribución, con apps de productividad (lectores de PDF, escáneres QR) que acumulan cientos de miles de descargas antes de ser eliminadas.

TeaBot implementa Automated Transfer System (ATS): puede ejecutar transferencias bancarias completas usando el Accessibility Service para interactuar con la app bancaria real. El operador solo necesita configurar la cuenta destino y el monto.

Campañas documentadas en España: suplantación de apps de Correos, BBVA y CaixaBank como vectores de distribución por smishing.

SharkBot

Característica	Detalle
Primera aparición	Octubre 2021
Origen	Desconocido
Modelo	MaaS
Estado 2026	Activo con evoluciones
Targets	Bancos europeos, foco UK, Italia, España
Técnicas clave	ATS, domain generation algorithm (DGA)

SharkBot se distingue por su uso de DGA (Domain Generation Algorithm) para la comunicación con el C2, dificultando el bloqueo por dominios. También fue de los primeros en implementar ATS completo para automatizar transferencias sin intervención humana.

Xenomorph

Característica	Detalle
Primera aparición	Febrero 2022
Origen	Desarrollador: Hadoken Security Group
Modelo	MaaS (suscripción mensual)
Estado 2026	Activo, v3+ con ATS avanzado
Targets	400+ apps bancarias y crypto, global
Técnicas clave	Overlay, ATS avanzado, anti-sandbox, C2 modular

Xenomorph es la familia más activa y sofisticada de 2024-2026. Su evolución:

• v1 (2022): Banking trojan básico con overlay y SMS interception. Distribuido como dropper en Google Play (app "Fast Cleaner" con 50.000+ descargas).
• v2 (2023): Mejoras en overlay, soporte para más bancos, sistema de configuración remota.
• v3 (2023): Introducción de ATS con motor de scripting propio. El operador puede definir flujos de fraude completos como scripts que el malware ejecuta automáticamente.
• v3.1+ (2024-2026): Anti-sandbox reforzado, soporte para apps de criptomonedas, C2 modular con fallback channels.

El motor ATS de Xenomorph v3 es el más avanzado del ecosistema. Permite definir flujos como:

// Ejemplo conceptual de flujo ATS Xenomorph v3
STEP 1: Abrir app bancaria (package: com.banco.app)
STEP 2: Esperar campo "Usuario" (AccessibilityNodeInfo con hint "usuario")
STEP 3: Introducir credenciales capturadas
STEP 4: Click botón "Entrar"
STEP 5: Navegar a "Transferencias"
STEP 6: Seleccionar cuenta origen
STEP 7: Introducir IBAN destino (mula)
STEP 8: Introducir cantidad
STEP 9: Confirmar transferencia
STEP 10: Interceptar OTP y completar verificación

Vultur

Característica	Detalle
Primera aparición	Marzo 2021
Origen	Desarrollador: Brunhilda (dropper)
Modelo	MaaS
Estado 2026	Activo, v4+ con screen recording mejorado
Targets	100+ apps bancarias y crypto
Técnicas clave	Screen recording/VNC, keylogging, no overlays

Vultur es único en el ecosistema por su enfoque de screen recording en lugar de overlays. Esto le permite capturar credenciales de cualquier aplicación sin necesidad de crear interfaces falsas específicas para cada banco.

En versiones recientes (v4+), Vultur ha añadido:

• Grabación selectiva (solo cuando apps objetivo están en primer plano).
• Compresión del stream para reducir consumo de datos.
• Capacidad de interacción remota (el atacante puede controlar el dispositivo en tiempo real).
• Exfiltración de archivos del dispositivo.

Tabla comparativa de familias

Familia	Overlay	ATS	Screen Record	SMS Intercept	DGA	Anti-Sandbox	Targets	Modelo
Cerberus	Si	No	No	Si	No	Basico	30+	MaaS (extinto)
Anubis	Si	No	No	Si	No	Basico	300+	Open source
TeaBot	Si	Si	No	Si	No	Medio	400+	MaaS
SharkBot	Si	Si	No	Si	Si	Medio	100+	MaaS
Xenomorph	Si	Avanzado	No	Si	No	Avanzado	400+	MaaS
Vultur	No	No	Si (VNC)	Si	No	Medio	100+	MaaS
Hook	Si	Si	Si	Si	No	Avanzado	300+	MaaS
Octo (Coper)	Si	Si	Si (VNC)	Si	No	Avanzado	200+	MaaS
Godfather	Si	No	No	Si	No	Avanzado	400+	MaaS

Protocolos C2

Los banking trojans utilizan diversos protocolos para la comunicación con sus servidores de comando y control:

HTTPS con API REST

El más común. El malware se comunica con el C2 mediante peticiones HTTPS a endpoints REST:

• POST /gate o /api/bot/register para registro inicial del bot.
• POST /api/bot/check para heartbeat y recepción de comandos.
• POST /api/bot/log para envío de datos capturados (credenciales, SMS).
• GET /api/injects/{package} para descarga de overlays específicos por app bancaria.

WebSocket

Familias como Vultur y Hook utilizan WebSocket para comunicación bidireccional en tiempo real, necesaria para el streaming de pantalla y el control remoto.

Telegram Bot API

Algunas variantes utilizan bots de Telegram como canal C2 secundario o para notificación de eventos al operador. Esto dificulta el bloqueo del C2 porque el tráfico se mezcla con el tráfico legítimo de Telegram.

Firebase Cloud Messaging (FCM)

FCM se usa como canal de push para enviar comandos desde el C2 al bot. Esto permite despertar al malware incluso cuando no tiene una conexión activa con el C2. El tráfico FCM es difícil de distinguir del tráfico legítimo de apps que usan notificaciones push de Google.

Domain Generation Algorithm (DGA)

SharkBot y algunas variantes de Godfather implementan DGA: el malware genera dominios C2 algorítmicamente basándose en la fecha actual. Si un dominio es bloqueado, el malware genera automáticamente el siguiente. Para defender contra DGA, es necesario reverse-engineer el algoritmo y registrar o bloquear proactivamente los dominios futuros.

Detección

Indicadores estáticos en APK

• Permisos excesivos: Combinación de RECEIVE_SMS, READ_SMS, BIND_ACCESSIBILITY_SERVICE, SYSTEM_ALERT_WINDOW.
• Receivers para BOOT_COMPLETED: Indica persistence al arranque.
• Services con BIND_ACCESSIBILITY_SERVICE: Indica potencial abuso de accesibilidad.
• Package names sospechosos: Variaciones de paquetes legítimos (ej: com.google.android.gms.update).
• Certificados de firma: Certificados debug o auto-firmados sin información del desarrollador.

Indicadores de comportamiento

• Solicitud de Accessibility Service: Especialmente si la app no tiene una función legítima de accesibilidad.
• Ventanas overlay sobre apps bancarias.
• Lecturas de SMS en segundo plano.
• Comunicaciones de red a IPs/dominios no asociados con la funcionalidad declarada de la app.
• Descarga de archivos DEX o APK adicionales post-instalación.

Detección en red

• Dominios recién registrados: C2 suelen usar dominios con antigüedad de menos de 30 días.
• Tráfico a IPs de hosting bulletproof: Rangos conocidos de proveedores tolerantes con actividades ilícitas.
• Beaconing: Peticiones periódicas al C2 con intervalos regulares.
• Exfiltración de datos tras interacción con app bancaria.

Reglas YARA para detección de APK

Las siguientes reglas YARA son ejemplos simplificados para ilustrar patrones de detección en archivos APK. En un entorno de producción, estas reglas deben refinarse para minimizar falsos positivos.

rule BankingTrojan_Overlay_Indicators
{
    meta:
        description = "Detecta indicadores comunes de banking trojans con overlay en APK"
        author = "MalwareIntel Research"
        date = "2026-06-06"
        reference = "https://malwareintel.es"

    strings:
        $perm1 = "android.permission.RECEIVE_SMS"
        $perm2 = "android.permission.READ_SMS"
        $perm3 = "android.permission.SYSTEM_ALERT_WINDOW"
        $perm4 = "BIND_ACCESSIBILITY_SERVICE"
        $perm5 = "android.permission.RECEIVE_BOOT_COMPLETED"

        $overlay1 = "TYPE_APPLICATION_OVERLAY"
        $overlay2 = "WindowManager$LayoutParams"

        $c2_1 = "/gate"
        $c2_2 = "/api/bot"
        $c2_3 = "register_bot"

    condition:
        // Archivo APK (ZIP con signature PK)
        uint16(0) == 0x4B50 and
        // Al menos 3 permisos sospechosos
        3 of ($perm*) and
        // Indicadores de overlay o C2
        (1 of ($overlay*) or 1 of ($c2*))
}

rule Vultur_ScreenRecording_Indicators
{
    meta:
        description = "Detecta indicadores de Vultur o banking trojans con screen recording"
        author = "MalwareIntel Research"
        date = "2026-06-06"

    strings:
        $media1 = "MediaProjectionManager"
        $media2 = "createScreenCaptureIntent"
        $media3 = "MediaProjection"
        $vnc1 = "VNCServer"
        $vnc2 = "RFBProtocol"
        $vnc3 = "framebuffer"
        $acc = "BIND_ACCESSIBILITY_SERVICE"
        $sms = "android.permission.READ_SMS"

    condition:
        uint16(0) == 0x4B50 and
        2 of ($media*) and
        (1 of ($vnc*) or $acc) and
        $sms
}

Mitigaciones recomendadas

Para usuarios

1. No instalar APKs desde enlaces SMS o WhatsApp. Ningún banco legítimo solicita instalar apps por SMS.
2. Verificar permisos. Rechazar apps que soliciten acceso a SMS, Accessibility Service o permisos de administrador sin justificación clara.
3. Mantener el dispositivo actualizado. Los parches de seguridad corrigen vulnerabilidades explotadas por banking trojans.
4. Usar apps bancarias oficiales. Descargar solo desde Google Play o la web oficial del banco.
5. Activar Google Play Protect. Verificar que está activo en Configuración.

Para organizaciones

1. Mobile Threat Defense (MTD). Desplegar soluciones que detecten overlay attacks, abuso de accesibilidad y comunicaciones C2.
2. MDM con políticas de seguridad. Restringir side-loading, forzar actualizaciones, monitorizar permisos.
3. Monitorización de transacciones. Sistemas anti-fraude que detecten patrones de ATS (transferencias automatizadas a cuentas mula).
4. Autenticación reforzada. Migrar de SMS OTP a push notifications in-app o tokens hardware (FIDO2).

Recursos

• ThreatFabric Research Blog (investigación de referencia sobre banking trojans Android)
• Cleafy Labs (análisis técnicos de TeaBot, SharkBot, Vultur)
• MITRE ATT&CK Mobile (TTPs de malware móvil)
• Zimperium zLabs (investigación de amenazas móviles)
• MalwareBazaar (repositorio de muestras de malware)
• VirusTotal (análisis de muestras sospechosas)
• MalwareIntel (plataforma de inteligencia sobre familias de malware)