En fintech, buena parte de las altas de clientes y de las operaciones diarias ocurre ya a través del móvil. Esa concentración lo ha convertido en el objetivo principal del fraude en aplicaciones móviles fintech.
Los atacantes ya no se limitan a robar contraseñas. Manipulan el dispositivo, falsean su identidad ante el sistema y ejecutan el fraude desde el propio terminal del usuario legítimo.
Este artículo repasa los vectores más relevantes (device spoofing, app tampering y las técnicas de device fingerprinting que ayudan a detectarlos) con datos verificados y ejemplos documentados del sector.
Qué son los vectores de ataque en apps móviles fintech
Un vector de ataque es el camino concreto que usa un atacante para comprometer una app fintech: desde la instalación de un troyano bancario hasta la manipulación del entorno de ejecución del dispositivo.
En la mayoría de los casos documentados, el fraude en aplicaciones móviles fintech sigue una secuencia reconocible. La tabla siguiente resume sus fases típicas.
| Fase | Qué ocurre | Objetivo del atacante |
| Infección | Malware bancario instalado vía sideloading, tiendas no oficiales o enlaces de phishing | Ganar persistencia en el dispositivo |
| Reconocimiento del entorno | La app maliciosa detecta root, jailbreak, emuladores o cámaras virtuales | Preparar la manipulación o la suplantación |
| Captura de señales | Overlays sobre la app legítima, keylogging, interceptación de SMS con códigos OTP | Robar credenciales y factores de autenticación |
| Ejecución del fraude | Transferencia o alta de producto ejecutada desde el propio dispositivo comprometido | Completar la operación sin activar alertas clásicas |
Tabla 1. Fases típicas del fraude en apps móviles fintech.
Según el informe Threat Landscape 2025 de ENISA, la agencia europea de ciberseguridad, las amenazas móviles son la categoría con mayor peso en la distribución de incidentes analizados entre julio de 2024 y junio de 2025: un 42,4%, lo que confirma que los dispositivos móviles siguen siendo una superficie de ataque principal a escala de toda la UE y de todos los sectores, no solo del financiero.
El fraude en apps móviles fintech, en cifras
Los datos oficiales disponibles no siempre hablan del mismo ámbito: unos cubren toda la UE y todos los sectores, otros se limitan a España, y otros son específicos del sector financiero. Conviene leerlos con esa referencia al lado.
| Dato | Cifra | Ámbito y fuente |
| Incidentes de ciberseguridad gestionados por INCIBE en 2025 | 122.223 (+26% vs. 2024) | España — Balance de Ciberseguridad 2025, INCIBE |
| Incidentes de malware (troyanos, infostealers, botnets, spyware y otras variantes; sin desglose bancario específico) | 55.411 (45% del total) | España — Balance de Ciberseguridad 2025, INCIBE |
| Incidentes de fraude online | 45.445 (4 de cada 10 incidentes, +19%) | España — Balance de Ciberseguridad 2025, INCIBE |
| Sector más afectado entre operadores esenciales (banca) | 34% | España — Balance de Ciberseguridad 2025, INCIBE |
| Incidentes de malware con impacto en entidades de crédito / particulares / proveedores de cripto | 36% / 24% / 15% | UE, sector financiero, ene. 2023-jun. 2024 — ENISA Threat Landscape: Finance Sector, sobre una base de 21 incidentes de malware (6% de los 488 incidentes totales del informe) |
| Incidentes de ciberseguridad analizados a nivel UE, todos los sectores | 4.875 (jul. 2024-jun. 2025) | UE, contexto general — ENISA Threat Landscape 2025 |
Tabla 2. Fraude en apps móviles fintech en cifras (fuentes oficiales; cada fila indica su ámbito geográfico y temporal).
Estas cifras describen el volumen del problema, pero no explican por qué buena parte de ese fraude está resultando más difícil de detectar que hace apenas dos años. Eso exige mirar el dato con más detalle.
Lo que las cifras agregadas no muestran
El titular habitual (aumentan los ataques a apps bancarias) esconde un cambio de fondo: buena parte del fraude ya no ocurre desde fuera del dispositivo, sino desde dentro de él.
ENISA documenta el resurgimiento del troyano Medusa con nuevas funcionalidades orientadas al On-Device Fraud mediante toma de control de la cuenta (Account Takeover), ampliando su victimología a Francia e Italia. La ampliación es relevante porque su predecesor, TangleBot, ya operaba en España, Turquía, Italia y Francia: el perímetro no es nuevo, se está reforzando. El mismo informe cita también BingoMod, que vacía las cuentas de la víctima y borra el dispositivo después para dificultar el análisis forense.
En el On-Device Fraud, el malware no exfiltra credenciales para operar desde otro equipo: ejecuta la transacción directamente en el teléfono de la víctima, usando su sesión ya autenticada. Ese cambio de patrón es lo que importa, porque redefine qué señales de fraude siguen sirviendo.
| Variable | Fraude a distancia clásico | On-Device Fraud |
| Origen de la sesión | Dispositivo o IP nuevos, geolocalización distinta | El mismo dispositivo y la misma sesión del usuario legítimo |
| Señal de riesgo típica | Dispositivo desconocido, salto geográfico, huella distinta | Prácticamente ninguna señal clásica salta |
| Vector habitual | Phishing y reutilización de credenciales robadas | Malware con control remoto o accesibilidad sobre el propio terminal |
| Dificultad de detección | Media: existen reglas de dispositivo e IP consolidadas | Alta: requiere análisis de comportamiento y del canal |
Tabla 3. Fraude a distancia clásico frente a On-Device Fraud.
El análisis de INCIBE sobre el troyano bancario TrickMo ilustra bien este patrón: el malware abusa de los servicios de accesibilidad de Android para superponer pantallas falsas y grabar la pantalla del dispositivo en tiempo real, y así intercepta los códigos de un solo uso, tanto los recibidos por SMS como los generados por aplicaciones autenticadoras. Ese matiz importa: desmonta la idea de que basta con migrar del SMS a una app de autenticación para cerrar este vector.
Esta es la razón por la que la biometría del comportamiento está ganando peso frente a los controles basados solo en reputación de dispositivo o IP: cuando el fraude ocurre dentro del propio terminal legítimo, hace falta observar cómo interactúa el usuario, no solo desde dónde lo hace.
El informe IOCTA 2025 de Europol confirma esta tendencia desde otro ángulo: la agencia europea documenta un mercado activo de compraventa de credenciales e infostealers, que alimenta precisamente este tipo de ataques ejecutados con sesiones y dispositivos legítimos ya comprometidos.
El propio informe añade un matiz incómodo para cualquier defensa basada solo en el dispositivo: los infostealers no solo roban contraseñas, también extraen tokens, cookies y huellas de dispositivo, lo que permite a los atacantes replicar la identidad digital de la víctima. La huella del dispositivo, usada sola, también puede convertirse en mercancía robada. Es el mejor argumento a favor de combinarla con biometría de comportamiento y verificación de origen de la captura, en lugar de depender de un único control.
Vectores específicos: device spoofing y app tampering
El device spoofing consiste en hacer que un sistema crea que una señal procede de un dispositivo o una cámara distintos de los reales. Incluye desde cámaras virtuales hasta emuladores que imitan un teléfono físico.
El app tampering, por su parte, es la manipulación del código o del entorno de ejecución de la propia aplicación: ingeniería inversa, inyección de código, ejecución en dispositivos rooteados o con jailbreak, o instalación de versiones repackaged de la app modificadas con frameworks de hooking en tiempo de ejecución, todo ello para desactivar controles de seguridad.
Conviene distinguir dos variantes que suelen confundirse bajo el término genérico «spoofing»: la diferencia entre ataque de presentación y ataque de inyección. El primero engaña a la cámara con una foto, máscara o vídeo. El segundo evita la cámara por completo e inyecta un vídeo fabricado directamente en el flujo de datos, típicamente mediante una cámara virtual.
Esta distinción explica por qué un proveedor evaluado frente a ataques de presentación puede seguir expuesto a la inyección: son controles distintos frente a preguntas distintas.
El device fingerprinting actúa como contramedida frente a ambos vectores. Analiza cientos de señales del hardware, el sistema operativo y la configuración del dispositivo para construir una huella única y detectar cuándo esa huella no encaja con el perfil habitual del usuario o con el de un dispositivo legítimo.
Las soluciones de defensa contra ataques de inyección combinan esta huella de dispositivo con verificación de origen de la captura y análisis forense de imagen, de forma que el sistema no solo pregunta «¿es una cara real?», sino también «¿esta señal llegó de verdad desde la cámara del dispositivo legítimo?».
Podemos diferenciar imágenes genuinas, con reflejos naturales en la piel, de aquellas manipuladas visualmente convincentes pero con artefactos imperceptibles. Sin embargo, solo un enfoque multicapa detecta ataques con muestras robadas no manipuladas.
— Javier Barrachina, R+D Director de Facephi
Retos del sector fintech frente a este tipo de fraude
Las fintech operan bajo una tensión constante entre onboarding sin fricción, cumplimiento normativo y una base de usuarios que incluye dispositivos rooteados o con jailbreak.
| Pain | Por qué importa | Qué exige resolverlo |
| Onboarding 100% remoto | Cualquier hueco en la verificación se explota a escala, sin presencia física que lo frene | Detección de inyección y de presentación integrada en el propio flujo de onboarding |
| Dispositivos rooteados o con jailbreak en la base de usuarios | Desactivan controles nativos del sistema operativo que la app da por hechos | Señales de entorno de ejecución combinadas con huella de dispositivo |
| Presión regulatoria creciente: PSD3 y el nuevo Reglamento de Servicios de Pago (PSR), DORA y equivalentes locales | El texto de compromiso de PSD3/PSR (abril de 2026, pendiente de adopción formal) traslada al proveedor de pagos la responsabilidad de reembolsar al cliente si no implementó mecanismos adecuados de prevención del fraude | Evidencia auditable de cada verificación y de cada señal analizada, no solo la existencia del control |
| Experiencia de usuario frente a fricción de seguridad | Añadir pasos de verificación reduce la conversión y el uso de la app | Autenticación multibiométrica continua que actúa en segundo plano |
Tabla 4. Retos del sector fintech frente al fraude en apps móviles.
Frente a estos retos, la combinación de biometría de comportamiento, verificación de origen de la captura y análisis forense de imagen permite mantener la fricción baja para el usuario legítimo y alta para el atacante, sin depender de un único control.
Preguntas frecuentes sobre fraude en apps móviles fintech
Es la técnica que hace pasar una señal falsa (una cámara virtual, un emulador o unos datos de localización manipulados) por la de un dispositivo real y legítimo. El objetivo es que el sistema de verificación crea que la operación viene de un teléfono físico y de una persona real.
Consiste en manipular el código o el entorno de ejecución de una aplicación, por ejemplo mediante ingeniería inversa, inyección de código o ejecución en dispositivos rooteados, para desactivar o esquivar sus controles de seguridad.
El device fingerprinting analiza cientos de señales de hardware, sistema operativo y configuración para construir una huella única del dispositivo. Cuando esa huella no coincide con el perfil habitual de un usuario o presenta rasgos de emulación, el sistema puede elevar la verificación antes de autorizar la operación.
Un ataque de presentación muestra algo falso delante de la cámara, como una foto o una máscara. Un ataque de inyección evita la cámara e inserta directamente un vídeo fabricado en el flujo de datos, normalmente mediante una cámara virtual o un emulador.
Porque ejecutar el fraude desde la sesión ya autenticada del usuario legítimo evita las señales clásicas de riesgo, como un dispositivo nuevo o una IP distinta. Esto obliga a los sistemas antifraude a analizar el comportamiento dentro de la sesión, no solo su origen.
La norma ISO/IEC 30107-3 define cómo se evalúa la detección de ataques de presentación; la certificación frente a ella la emiten laboratorios acreditados. Los ataques de inyección cuentan con una especificación más reciente, el CEN/TS 18099, aprobada por CEN en octubre de 2024 para aplicación provisional (validez inicial de tres años) y ratificada en España por UNE en enero de 2025. ISO ha iniciado además el desarrollo de una norma propia para inyección, ISO/IEC 25456, tomando CEN/TS 18099 como punto de partida.
