¿Por qué el banco no detecta un Device Takeover?

Porque las transacciones se ejecutan desde el dispositivo habitual del cliente, con su IP, geolocalización y fingerprint de dispositivo, lo que las hace parecer legítimas.

¿Cómo demuestro que fui víctima de un Device Takeover?

Un perito informático puede extraer del móvil evidencia del malware, logs de acceso remoto y correlacionar los timestamps de la actividad maliciosa con las transacciones fraudulentas.

Device Takeover Fraud (DTO)

El 97% de los fraudes bancarios móviles en Europa durante 2025 se ejecutaron directamente desde el dispositivo de la víctima, según el informe anual de ThreatFabric. No hubo login sospechoso desde otra IP, ni acceso desde un navegador desconocido, ni geolocalización anómala. El banco vio una operación normal, ejecutada desde el teléfono habitual del cliente, con su huella digital de dispositivo y su conexión WiFi de siempre. Solo que quien movía los hilos no era el titular, sino un troyano bancario con control remoto total.

Qué es Device Takeover Fraud

Device Takeover Fraud (DTO) es una técnica avanzada de fraude bancario en la que el atacante toma el control remoto del dispositivo móvil de la víctima para ejecutar transferencias y operaciones financieras directamente desde el terminal del titular. A diferencia del Account Takeover (ATO) clásico, donde el atacante accede a la cuenta bancaria desde su propio dispositivo con credenciales robadas, en un DTO el malware opera dentro del teléfono del usuario legítimo, manipulando la app bancaria en tiempo real.

Diferencia fundamental:

Account Takeover (ATO): Atacante usa credenciales robadas desde SU dispositivo. El banco detecta IP, geolocalización y fingerprint distintos
Device Takeover (DTO): Atacante ejecuta operaciones desde el dispositivo DE LA VÍCTIMA. El banco ve IP, geolocalización y fingerprint habituales

Esta distinción es crítica porque los sistemas antifraude bancarios modernos basan gran parte de su detección en el análisis del dispositivo. Si la transacción proviene del mismo teléfono que el cliente usa habitualmente, los motores de riesgo le asignan una puntuación baja y la operación se aprueba automáticamente.

Por qué el banco no lo detecta

Los sistemas antifraude bancarios verifican factores como la IP de origen, la geolocalización GPS, el fingerprint del dispositivo (modelo, sistema operativo, resolución de pantalla), la red WiFi y los patrones de uso habituales. En un Device Takeover, todos estos factores coinciden con el perfil legítimo del cliente porque la transacción se ejecuta literalmente desde su teléfono. El motor de riesgo del banco califica la operación como “de confianza” y la aprueba sin intervención humana. Según Cleafy, los DTO evaden el 95% de los controles antifraude basados en dispositivo.

DTO frente a otros tipos de fraude bancario

Tipo de fraude	Dispositivo usado	IP de origen	Fingerprint	Detección bancaria	Complejidad
Device Takeover (DTO)	Móvil de la víctima	IP habitual del cliente	Coincide 100%	Muy baja (menos del 5%)	Muy alta
Account Takeover (ATO)	Dispositivo del atacante	IP distinta	No coincide	Media-alta (60-80%)	Media
SIM Swapping	Dispositivo del atacante	IP distinta	No coincide	Media (50-70%)	Media
Phishing bancario	Dispositivo del atacante	IP distinta	No coincide	Alta (70-90%)	Baja
Ingeniería social (vishing)	Víctima ejecuta voluntariamente	IP habitual	Coincide	Muy baja	Baja-media

El DTO representa la evolución natural de los troyanos bancarios: en lugar de robar credenciales y usarlas desde otro dispositivo (lo que los bancos ya detectan eficazmente), el malware ejecuta las operaciones directamente en el terminal del cliente, donde resulta prácticamente invisible para los sistemas de monitorización.

Cómo funciona un ataque DTO

Un Device Takeover sigue una cadena de ataque con fases técnicas bien diferenciadas. La sofisticación radica en que todo ocurre dentro del dispositivo de la víctima, a menudo mientras esta duerme o no está usando el teléfono.

Fase 1: Distribución e infección

El troyano llega al dispositivo de la víctima a través de vectores comunes:

Vector 1: Google Play Store (dropper)
─────────────────────────────────────
App legítima en apariencia (lector PDF, limpiador, QR)
→ Pasa revisión de Google Play Protect
→ Tras instalación, descarga payload malicioso
→ Solicita permisos de Accesibilidad

Vector 2: Sideloading (APK directo)
────────────────────────────────────
SMS/WhatsApp phishing: "Actualización de seguridad banco"
→ Usuario descarga APK desde enlace
→ Instala desde "Orígenes desconocidos"
→ App solicita permisos de Accesibilidad

Vector 3: Smishing + redirección
─────────────────────────────────
SMS simulando ser el banco o Correos
→ Enlace a web falsa con descarga de APK
→ Ingeniería social para conceder permisos

Fase 2: Obtención de permisos críticos

El malware necesita dos permisos fundamentales para ejecutar un DTO:

Accessibility Services: Permite leer pantalla, simular toques, capturar texto y navegar entre apps (ver Accessibility Services Android)
SYSTEM_ALERT_WINDOW: Permite mostrar ventanas sobre otras apps para overlay attacks

Con estos dos permisos, el troyano obtiene capacidad de control total del dispositivo: puede leer credenciales, interceptar OTPs, ejecutar transferencias y ocultar la actividad al usuario.

Fase 3: Reconocimiento y espera

Malware en modo pasivo:
→ Monitoriza apps bancarias instaladas
→ Identifica entidad bancaria (BBVA, Santander, CaixaBank...)
→ Descarga configuración específica del servidor C2
→ Registra patrones de uso: horarios de actividad del usuario
→ Detecta saldo disponible (lectura de pantalla)
→ Espera momento óptimo (noche o madrugada)

Fase 4: Ejecución del Device Takeover

Esta es la fase crítica donde se materializa el fraude:

Atacante activa control remoto vía C2:
→ Activa "black screen overlay" (pantalla negra falsa)
→ Usuario cree que el teléfono está apagado o en reposo
→ En segundo plano, malware abre app bancaria
→ Usa credenciales previamente capturadas para login
→ Si el banco pide OTP por SMS: intercepta notificación
→ Si el banco pide biometría: espera a que usuario desbloquee
→ Navega al apartado de transferencias
→ Rellena IBAN de cuenta mula + importe
→ Confirma operación
→ Borra notificaciones de confirmación del banco
→ Desactiva overlay negro
→ Usuario no percibe nada anómalo

Fase 5: Ocultación

Tras ejecutar la transferencia, el troyano:

Borra las notificaciones push del banco
Elimina SMS de confirmación de la operación
Borra registros del historial de transferencias en la app (si es posible)
En algunos casos, desinstala la propia app maliciosa para eliminar evidencia

Troyanos que ejecutan Device Takeover

Anatsa (TeaBot)

Activo: 2021-2026, con actualizaciones constantes
Distribución: Google Play Store via apps dropper (lectores PDF, apps de limpieza)
Target: Mas de 650 apps bancarias en Europa, incluyendo BBVA, Santander, CaixaBank, Bankinter, ING, Sabadell
Técnica DTO: ATS (Automated Transfer System) que ejecuta transferencias automáticas via Accessibility Services sin intervención humana
Peculiaridad: Capaz de ejecutar toda la cadena de fraude de forma completamente automática, desde el login hasta la confirmación de la transferencia
Cifras 2025: Mas de 220.000 instalaciones detectadas solo en Google Play (ThreatFabric)
Referencia: ThreatFabric, Cleafy Labs

Vultur

Activo: 2021-2026
Distribución: Smishing + llamada telefónica (el atacante llama simulando ser el banco y guía a la víctima para instalar la “app de seguridad”)
Target: Apps bancarias europeas y australianas
Técnica DTO: VNC (Virtual Network Computing) para control remoto en tiempo real + grabación de pantalla + keylogging
Peculiaridad: En la versión 2.0 (2024), incorporó la capacidad de descargar, instalar y eliminar apps remotamente, además de impedir que el usuario desinstale el malware
Referencia: NCC Group, ThreatFabric

SharkBot (Mako)

Activo: 2021-2025
Distribución: Google Play Store via apps dropper (antivirus falsos, gestores de archivos)
Target: Bancos en España, Italia, Reino Unido y EE.UU.
Técnica DTO: ATS via Accessibility Services + overlay attacks para captura de credenciales
Peculiaridad: Geofencing avanzado (solo se activa si el dispositivo está en países objetivo) + evasión de análisis en emuladores y sandboxes
Referencia: Cleafy Labs, NCC Group

BianLian

Activo: 2018-2026
Distribución: Sideloading via phishing SMS y Telegram
Target: Apps bancarias turcas, europeas y norteamericanas
Técnica DTO: Screen casting + inyección de código en apps bancarias + intercepción SMS
Peculiaridad: Capacidad de registrar la pantalla del dispositivo y retransmitirla en streaming al atacante en tiempo real
Referencia: Fortinet, ThreatFabric

Automated Transfer System (ATS)

ATS es el mecanismo que permite a troyanos como Anatsa y SharkBot ejecutar transferencias bancarias de forma completamente automatizada, sin que el atacante tenga que operar manualmente. El malware navega la app bancaria paso a paso (abrir app, login, transferencias, rellenar datos, confirmar), todo mediante Accessibility Services. El proceso completo dura entre 30 segundos y 3 minutos, y puede ejecutarse mientras el usuario duerme con la pantalla aparentemente apagada.

Proceso forense para demostrar un Device Takeover

Preservación del dispositivo
Es imprescindible no restaurar de fábrica el teléfono antes de la extracción forense. El dispositivo debe ponerse en modo avión inmediatamente para evitar que el malware reciba instrucciones de borrado desde el servidor C2. Se documenta el estado del dispositivo con fotografías y se calcula hash del almacenamiento si es posible.
Extracción forense completa
Utilizando herramientas certificadas (Cellebrite UFED, Oxygen Forensics o AXIOM), se realiza extracción física o lógica avanzada del dispositivo. Se priorizan: apps instaladas con timestamps, permisos concedidos (especialmente Accessibility y Overlay), APKs sospechosos, bases de datos de SMS y notificaciones, logs del sistema.
Identificación del malware
Análisis estático del APK sospechoso con Androguard, Jadx y APKTool. Se verifican permisos solicitados (BIND_ACCESSIBILITY_SERVICE, SYSTEM_ALERT_WINDOW, READ_SMS, RECEIVE_SMS), se extraen strings con URLs de servidores C2, se identifica la familia de malware y se confirma con VirusTotal y MalwareBazaar.
Reconstrucción del timeline del ataque
Se correlacionan cronológicamente los siguientes eventos: instalación del APK malicioso (timestamp en packages.list), concesión de permisos de accesibilidad (appops.xml), conexiones salientes al servidor C2 (logs de red), actividad de la app bancaria durante el fraude (logcat, ActivityManager), la transacción fraudulenta (extracto bancario del titular), y el borrado de notificaciones y SMS por el malware.
Análisis de conexiones de red
Se examinan las conexiones establecidas por el malware con el servidor C2: direcciones IP, puertos, protocolos, frecuencia de comunicación y volumen de datos transmitidos. Se geolocalizan las IPs del C2 y se cruzan con bases de datos de amenazas conocidas (AbuseIPDB, OTX AlienVault).
Demostración de automatización (ATS)
El elemento clave del informe pericial es demostrar que la transacción fue ejecutada por el malware y no por el usuario. Se acredita analizando la velocidad de ejecución (las operaciones ATS se completan en segundos, un humano tarda minutos), la ausencia de interacción táctil del usuario durante la operación (logs de InputDispatcher), la coincidencia temporal entre actividad del malware y la transacción, y la presencia de código ATS en el APK decompilado.
Emisión del informe pericial
El informe documenta la cadena completa: vector de infección, capacidades del malware, timeline del ataque, evidencia de automatización y conclusión de que la transacción no fue autorizada ni ejecutada por el titular. Se adjuntan hashes SHA-256 de toda la evidencia para garantizar la integridad de la cadena de custodia.

Caso práctico: DTO mediante Anatsa en app bancaria

Nota: El siguiente caso es un ejemplo compuesto y anonimizado basado en tipologías reales de peritaje informático forense. Los datos técnicos reflejan el comportamiento documentado de Anatsa/TeaBot por investigadores de seguridad. Los detalles personales y financieros son ficticios y no representan un caso específico real.

Contexto

Un profesional autónomo de Sevilla descubrió al revisar su extracto bancario que se habían ejecutado tres transferencias por un total de 14.200 EUR durante la madrugada, a una cuenta de un neobanco lituano que nunca había utilizado. Las transferencias se realizaron entre las 03:15 y las 03:42 de la madrugada, mientras el titular dormía con el teléfono cargándose en la mesilla. El banco rechazó la reclamación, argumentando que las operaciones fueron ejecutadas desde el dispositivo habitual del cliente y autenticadas correctamente.

Investigación forense

Paso 1: Extracción del dispositivo

Se extrajo el contenido del teléfono Android mediante Cellebrite UFED (extracción lógica avanzada). Se identificaron 127 apps instaladas, de las cuales una resultó ser un dropper de Anatsa.

Paso 2: Identificación del malware

App sospechosa: "PDF Reader Pro" (com.pdftools.reader)
Instalada: 28 enero 2026 (Google Play Store)
Permisos concedidos:
  - BIND_ACCESSIBILITY_SERVICE (activado 28 enero, 19:47h)
  - SYSTEM_ALERT_WINDOW (activado 28 enero, 19:48h)
  - READ_SMS, RECEIVE_SMS, SEND_SMS
  - INTERNET, ACCESS_NETWORK_STATE
Hash SHA-256: e7f4a2c9d1b3...
Detección VirusTotal: 38/72 motores (Anatsa/TeaBot)

Paso 3: Reconstrucción del timeline

Timestamp	Evento	Evidencia
28 ene, 19:45	App “PDF Reader Pro” instalada desde Play Store	packages.list
28 ene, 19:47	Accesibilidad concedida por el usuario	appops.xml
28 ene, 20:15	Primera conexión C2: 91.215.85.xxx (Moldavia)	logs de red
29 ene - 4 feb	Malware en modo pasivo, monitoriza app bancaria	logcat
5 feb, 03:12	Conexión C2 activa, recibe instrucciones	logs de red
5 feb, 03:14	Black screen overlay activado	logcat, WindowManager
5 feb, 03:15	App bancaria abierta en segundo plano	ActivityManager
5 feb, 03:16	Login automático con credenciales capturadas	AccessibilityService logs
5 feb, 03:18	Primera transferencia: 5.000 EUR	Extracto bancario
5 feb, 03:27	Segunda transferencia: 5.000 EUR	Extracto bancario
5 feb, 03:38	Tercera transferencia: 4.200 EUR	Extracto bancario
5 feb, 03:42	Notificaciones SMS del banco borradas	telephony.db (deleted_at)
5 feb, 03:43	Black screen overlay desactivado	logcat

Paso 4: Evidencia de automatización ATS

El análisis del código decompilado del APK reveló módulos ATS específicos para la entidad bancaria del afectado, incluyendo scripts de navegación automatizada (abrir transferencias, rellenar campos, confirmar) y código de interceptación de OTP por SMS.

Los logs de InputDispatcher del sistema Android confirmaron que no hubo interacción táctil del usuario durante las 03:12 y las 03:43, período en el que se ejecutaron las tres transferencias. La pantalla no registró ningún toque humano.

Resultado

El informe pericial demostró que:

Las transferencias fueron ejecutadas por el troyano Anatsa (TeaBot) mediante ATS
El titular no participó activamente en las operaciones (ausencia de interacción táctil)
El malware llegó al dispositivo via Google Play Store (app aparentemente legítima)
El banco no detectó la anomalía porque la operación se ejecutó desde el dispositivo habitual

El juzgado estimó la reclamación y condenó al banco a reembolsar los 14.200 EUR, aplicando el Art. 44 del RDL 19/2018 (responsabilidad del proveedor de servicios de pago por operaciones no autorizadas).

Reclamación bancaria bajo PSD2

La Directiva PSD2 y su transposición española (RDL 19/2018) proporcionan el marco legal para reclamar el reembolso de fondos sustraídos mediante Device Takeover.

Marco normativo aplicable

RDL 19/2018 (transposición PSD2 en España):

Art. 44: El proveedor de servicios de pago (banco) es responsable de las operaciones de pago no autorizadas. Debe devolver el importe inmediatamente, y como máximo al final del siguiente día hábil, salvo que tenga motivos razonables para sospechar fraude del propio usuario
Art. 36: El usuario debe notificar sin demora indebida las operaciones no autorizadas. Plazo máximo: 13 meses desde la fecha de cargo
Art. 41: La autenticación reforzada del cliente (SCA) debe basarse en dos o mas factores independientes. Si uno de los factores fue comprometido por el malware, la entidad no puede alegar cumplimiento de SCA
Art. 46: La carga de la prueba recae sobre el proveedor de servicios de pago. Es el banco quien debe demostrar que la operación fue autenticada, registrada y contabilizada correctamente

Código Penal

Art. 248.2 CP (Estafa informática): “También se consideran reos de estafa los que, con ánimo de lucro y valiéndose de alguna manipulación informática o artificio semejante, consigan una transferencia no consentida de cualquier activo patrimonial”. Pena: 6 meses a 3 años de prisión; si supera 50.000 EUR: 1 a 6 años
Art. 197.1 CP (Descubrimiento y revelación de secretos): El acceso a datos personales y bancarios mediante malware constituye delito contra la intimidad. Pena: 1 a 4 años de prisión; agravante si datos bancarios: 2 a 6 años
Art. 264 CP (Daños informáticos): El malware que altera el funcionamiento del dispositivo puede constituir delito de daños. Pena: 6 meses a 3 años

Estrategia de reclamación

Notificación inmediata al banco
Comunicar por escrito (burofax o formulario oficial) las operaciones no autorizadas dentro del plazo del Art. 36 RDL 19/2018. Solicitar el bloqueo de la cuenta y la devolución provisional del importe.
Denuncia policial
Presentar denuncia ante la Policía Nacional (Grupo de Delitos Telemáticos) o Guardia Civil. Aportar extractos bancarios con las operaciones fraudulentas y cualquier evidencia inicial disponible.
Peritaje informático forense
Contratar un perito informático para la extracción y análisis del dispositivo. El informe pericial es la pieza fundamental de la reclamación, ya que demuestra que la transacción fue ejecutada por malware (no por el titular) y que el usuario no incurrió en negligencia grave.
Reclamación formal al banco
Presentar reclamación con el informe pericial adjunto. El banco tiene 15 días hábiles para resolver. Si no hay respuesta o es negativa, acudir al Servicio de Reclamaciones del Banco de España.
Vía judicial si es necesario
Si el banco no restituye el importe, presentar demanda invocando el Art. 44 RDL 19/2018. La jurisprudencia española es favorable al usuario en casos de DTO con informe pericial que acredite el malware.

Carga de la prueba invertida

Bajo la PSD2 (Art. 46 RDL 19/2018), la carga de la prueba recae sobre el banco, no sobre el usuario. Es la entidad financiera quien debe demostrar que el cliente autorizó la operación o actuó con negligencia grave. En un Device Takeover, el informe pericial que acredite la presencia de malware ATS generalmente desplaza cualquier argumento de negligencia, ya que el usuario no pudo razonablemente detectar ni impedir la actividad del troyano.

Conceptos relacionados

Troyano bancario: Familias de malware (ERMAC, Godfather, Octo) que ejecutan Device Takeover mediante control remoto y ATS
Overlay attack: Técnica de superposición de pantalla utilizada durante la fase de captura de credenciales previa al DTO
Accessibility Services Android: API del sistema operativo que los troyanos explotan para obtener control total del dispositivo
SIM swapping: Técnica alternativa de fraude que, a diferencia del DTO, opera desde el dispositivo del atacante

Preguntas frecuentes

¿Qué es exactamente un Device Takeover Fraud?

Es un fraude bancario donde el atacante instala malware en el móvil de la víctima y, mediante técnicas de control remoto o automatización (ATS), ejecuta transferencias bancarias directamente desde el dispositivo del titular. La particularidad es que, al operar desde el teléfono habitual del cliente, los sistemas antifraude del banco no detectan anomalías y aprueban la operación como legítima.

¿En qué se diferencia un DTO de un Account Takeover clásico?

En un Account Takeover (ATO), el atacante roba las credenciales y accede a la banca online desde su propio dispositivo, lo que genera alertas por IP desconocida, fingerprint nuevo y geolocalización distinta. En un DTO, el malware ejecuta la operación desde el propio móvil de la víctima, por lo que todos los indicadores de dispositivo coinciden con el perfil legítimo del cliente y la transacción pasa desapercibida.

¿Puede mi banco negarme el reembolso si fui víctima de un DTO?

El banco puede intentar argumentar negligencia del usuario, pero bajo el RDL 19/2018 (PSD2), la carga de la prueba recae sobre la entidad. Con un informe pericial que demuestre la presencia de malware ATS y la ausencia de interacción del usuario durante las transacciones, la jurisprudencia española tiende a resolver a favor del cliente. El banco debe reembolsar el importe salvo que demuestre fraude o negligencia grave imputable al titular.

¿Cómo puedo protegerme de un Device Takeover?

Las medidas mas efectivas son: no instalar apps fuera de Google Play Store, no conceder nunca permisos de Accesibilidad a apps que no sean lectores de pantalla oficiales, activar alertas bancarias por cada operación, establecer límites diarios de transferencia bajos, y mantener el sistema operativo y las apps actualizados. Si sospechas que tu dispositivo está comprometido, no lo restaures de fábrica antes de consultar con un perito forense, ya que destruirías la evidencia.

¿Cuánto cuesta un peritaje forense de Device Takeover?

El coste típico de un peritaje forense completo de DTO oscila entre 2.000 y 4.000 EUR, dependiendo de la complejidad del caso. Incluye extracción del dispositivo (800-1.200 EUR), análisis del malware (600-1.000 EUR), reconstrucción del timeline e informe pericial (400-800 EUR) y ratificación judicial si es necesaria (300-600 EUR). El retorno es significativo: con informe pericial favorable, los tribunales suelen condenar al banco a restituir el 100% del importe defraudado.

Prevención y detección

Señales de alarma para usuarios

Señal	Descripción	Acción inmediata
App solicita Accesibilidad	Cualquier app (que no sea lector de pantalla) pide activar Accessibility Services	No conceder el permiso y desinstalar la app
Batería se agota rápidamente	El malware en segundo plano consume recursos	Revisar apps con consumo anómalo
Teléfono se enciende solo	La pantalla se activa sin interacción del usuario	Podría ser control remoto activo
Notificaciones bancarias desaparecen	El malware borra notificaciones de transacciones	Comprobar extracto bancario inmediatamente
App bancaria se abre sola	El usuario no inició la app pero aparece abierta	Bloquear acceso bancario y contactar al banco

Verificación rápida del dispositivo

# Verificar Accessibility Services activos
adb shell settings get secure enabled_accessibility_services
# Solo deberían estar: TalkBack, Switch Access o similares del fabricante
# Cualquier otro servicio activo es SOSPECHOSO

# Verificar apps con permiso overlay
adb shell appops query-op SYSTEM_ALERT_WINDOW allow

# Comprobar conexiones de red activas
adb shell cat /proc/net/tcp | grep "ESTABLISHED"

Referencias y fuentes

ThreatFabric. (2025). “On-Device Fraud: How Banking Trojans Are Stealing Right From Your Phone”. Disponible en: threatfabric.com
- El 97% de los fraudes bancarios móviles en Europa se ejecutaron via on-device fraud (DTO) en 2025
Cleafy Labs. (2025). “Anatsa Banking Trojan: Expanding Reach and Evolving Tactics”. Disponible en: cleafy.com
- Anatsa: ATS completo para transferencias automatizadas, mas de 650 apps bancarias target
ThreatFabric. (2025). “Exposing Crocodilus: New Device Takeover Malware Targeting Android Devices”. Disponible en: threatfabric.com
- Crocodilus: DTO dirigido a España y Turquía via Accessibility Services
NCC Group. (2024). “Vultur Banking Trojan: Analysis of Version 2.0 Capabilities”. Disponible en: nccgroup.com
- Vultur v2: VNC remoto + capacidad de instalar/eliminar apps remotamente
Cleafy Labs. (2024). “SharkBot: A New Generation Android Banking Trojan Being Distributed on Google Play Store”. Disponible en: cleafy.com
- SharkBot: ATS + geofencing avanzado en apps de Play Store
INCIBE. (2026). “Balance de ciberseguridad 2025”. Disponible en: incibe.es
- 122.223 ciberincidentes en España en 2025 (+26% respecto a 2024)
RDL 19/2018 - Real Decreto-ley 19/2018, de 23 de noviembre, de servicios de pago (transposición PSD2). Disponible en: boe.es
Directiva (UE) 2015/2366 (PSD2) - Directiva sobre servicios de pago en el mercado interior. Disponible en: eur-lex.europa.eu
Código Penal español - Arts. 197 (descubrimiento de secretos), 248 (estafa informática), 264 (daños informáticos)
Kaspersky. (2025). “The mobile malware threat landscape in 2024”. Disponible en: kaspersky.com
- 1.242.000 ataques de troyanos bancarios en Android (2024), aumento del 196%
Appdome. (2025). “How to Protect Android Banking Apps from On-Device Fraud”. Disponible en: appdome.com
- Estrategias de defensa contra DTO para desarrolladores de apps bancarias
Fortinet. (2024). “BianLian Banking Trojan Analysis”. Disponible en: fortinet.com
- BianLian: screen casting + inyección en apps bancarias

Aviso legal: Este artículo tiene finalidad exclusivamente educativa e informativa. Los datos estadísticos provienen de fuentes públicas citadas y pueden estar sujetos a actualización. El caso práctico es un ejemplo compuesto y anonimizado basado en tipologías reales; no representa un caso específico. Para asesoramiento legal sobre un caso concreto de fraude bancario, consulte con un abogado especializado en derecho tecnológico.

Sobre el autor: Jonathan Izquierdo es perito informático forense, ex-CTO y 5x AWS Certified, con especialización en análisis forense de dispositivos móviles y fraude bancario digital. Metodología de trabajo basada en ISO 27037 para preservación de evidencia digital.

Última actualización: 16 de febrero de 2026 Categoría: Ciberataques (ATK-025) Nivel técnico: Avanzado Relevancia: Muy Alta (principal vector fraude bancario móvil 2025-2026)