Un ataque de superposición (overlay) coloca una ventana controlada por el atacante encima de una aplicación legítima, casi siempre la pantalla de acceso de un banco, para que la víctima escriba sus credenciales en el sitio equivocado. Es la técnica que define el fraude bancario en Android y corresponde en MITRE ATT&CK Mobile a T1417.002 — GUI Input Capture.
La técnica lleva una década en uso, y la plataforma ha dedicado buena parte de esa década a restringirla. Varias versiones de Android desde la 6 han cerrado una parte del camino. Los troyanos bancarios se han adaptado a cada cambio, y la generación actual depende menos del permiso clásico de superposición que del servicio de accesibilidad.
Quien defiende —los equipos de seguridad de aplicaciones de bancos, cooperativas y fintechs, y los analistas que hacen el triaje de las muestras que los atacan— necesita tres cosas: cómo limita hoy la plataforma las superposiciones, qué hacen los atacantes en su lugar y qué controles puede aplicar una app bancaria sobre sus propias pantallas.
Dos formas de poner una pantalla falsa delante de la víctima
La superposición clásica. La aplicación maliciosa tiene SYSTEM_ALERT_WINDOW, que el usuario ve como «Mostrar sobre otras apps», y dibuja una ventana por encima de lo que esté en primer plano. Cuando detecta que se abrió la app bancaria objetivo, pinta encima una copia de su pantalla de acceso.
La inyección guiada por accesibilidad. La aplicación maliciosa tiene un servicio de accesibilidad. El servicio recibe los eventos de cambio de ventana, así que sabe qué aplicación está en primer plano sin enumerar procesos. Cuando aparece el objetivo, el malware lanza su propia actividad —normalmente un WebView que carga una «inyección» HTML que imita al banco— sobre la aplicación real. Esta vía no necesita el permiso de superposición.
La diferencia importa en el triaje. Una muestra que declara SYSTEM_ALERT_WINDOW y nada más describe, en la mayoría de los casos, una burbuja de chat o un widget flotante. Una muestra que combina un servicio de accesibilidad, detección de primer plano y una lista de nombres de paquete de bancos describe un troyano bancario, pida o no el permiso de superposición.
Cómo ha restringido Android las superposiciones
| Versión de Android | Cambio | Efecto sobre los ataques |
|---|---|---|
| 6.0 (API 23) | SYSTEM_ALERT_WINDOW pasa a ser un permiso especial que se concede desde Ajustes |
El usuario tiene que activar «Mostrar sobre otras apps»; la ingeniería social pasa a guiar a la víctima por esa pantalla |
| 8.0 (API 26) | Las apps que apuntan a API 26+ deben usar TYPE_APPLICATION_OVERLAY; los tipos de ventana de sistema antiguos quedan obsoletos |
Las superposiciones se dibujan por debajo de ventanas críticas del sistema, como la barra de estado y el teclado |
| 10 (API 29) | Restricciones para iniciar actividades desde segundo plano | Lanzar una actividad de phishing en el momento justo se complica, salvo para apps con el permiso de superposición o con un servicio de accesibilidad vinculado, que quedan exentas |
| 11 (API 30) | El intent del permiso abre la lista general de Ajustes en lugar del interruptor de la app | Un paso más para la víctima y para la llamada guiada |
| 12 (API 31) | Se bloquean los toques que atraviesan ventanas de otras apps salvo que la ventana sea invisible, totalmente transparente o una superposición con opacidad combinada de 0,8 o menos; nuevo permiso HIDE_OVERLAY_WINDOWS |
Se recorta el tapjacking y una app puede ocultar las superposiciones de terceros sobre sus ventanas |
| 13 (API 33) | «Ajustes restringidos» para apps instaladas sin un instalador por sesión (por ejemplo, abriendo un APK descargado): la accesibilidad y el acceso a notificaciones piden una confirmación extra | Un troyano instalado así ya no obtiene la accesibilidad en un solo paso |
| 14 (API 34) | Atributo accessibilityDataSensitive para las vistas |
Una app puede limitar las vistas sensibles a los servicios declarados como herramientas de accesibilidad (isAccessibilityTool) |
Destacan dos patrones. Primero, unas restricciones dependen del nivel de API objetivo de la app y otras se aplican a todas las apps en una versión del sistema, así que un dispositivo con una versión antigua conserva el comportamiento antiguo, y en América Latina los equipos antiguos siguen siendo una parte importante del parque instalado. Segundo, las exenciones de Android 10 explican por qué la accesibilidad se convirtió en la vía preferida: una aplicación con un servicio de accesibilidad vinculado puede iniciar actividades desde segundo plano, que es exactamente lo que necesita una inyección.
Cómo se adaptaron los troyanos
Primero la accesibilidad. Las familias actuales tratan el servicio de accesibilidad como el núcleo del implante. Detecta la aplicación en primer plano, lanza la inyección, lee los códigos de un solo uso en pantalla, cierra los avisos y bloquea la pantalla de desinstalación. El permiso de superposición, cuando lo piden, pasa a ser secundario.
Instalación guiada por teléfono. Cada restricción que añade una pantalla de confirmación cae con más facilidad ante una persona al otro lado de la línea. En el fraude por llamada, quien llama se presenta como el área de fraude del banco y guía a la víctima para activar la instalación desde orígenes desconocidos, conceder la accesibilidad y, desde Android 13, permitir los ajustes restringidos.
Cambio de la vía de instalación. Los ajustes restringidos se aplican a las aplicaciones instaladas fuera de los instaladores por sesión. Los droppers han respondido instalando la segunda fase mediante la API de instalación por sesión, que la restricción de Android 13 no cubría; Android 15 extiende los ajustes restringidos a muchos de esos instaladores.
Objetivos remotos. La lista de aplicaciones objetivo y las plantillas de inyección suelen llegar del servidor de mando y control después de la instalación. El APK instalado contiene la maquinaria, no los objetivos. Por eso un informe estático de una muestra así puede mostrar todo el conjunto de capacidades sin nombrar a las entidades afectadas.
La cadena completa —abuso de accesibilidad, intercepción de SMS, entrega por fases— se describe en cómo funciona un troyano bancario Android.
Controles que puede aplicar una app bancaria
Una app bancaria no puede impedir que se instale malware en el dispositivo. Sí puede convertir sus propias pantallas en un objetivo más difícil y detectar condiciones que justifiquen un aviso.
Descartar toques cuando la ventana está tapada. Con android:filterTouchesWhenObscured="true" en las vistas sensibles, o llamando a setFilterTouchesWhenObscured(true), la vista ignora los toques recibidos mientras otra ventana visible la cubre. Para un control más fino, la aplicación puede revisar MotionEvent.FLAG_WINDOW_IS_OBSCURED y, desde API 29, FLAG_WINDOW_IS_PARTIALLY_OBSCURED, y decidir cómo responder. Es un control contra el tapjacking: ante una superposición que captura credenciales, lo que escribe la víctima va a la ventana del atacante, no a la vista del banco.
Ocultar las superposiciones de terceros. Desde Android 12, una aplicación que declara el permiso HIDE_OVERLAY_WINDOWS puede llamar a setHideOverlayWindows(true) en sus ventanas. Las superposiciones de otras apps quedan ocultas mientras esas ventanas se muestran. Es el control más directo contra la superposición clásica en las versiones compatibles.
Marcar las vistas sensibles para la accesibilidad. Desde Android 14, el atributo accessibilityDataSensitive limita el acceso a las vistas marcadas a los servicios de accesibilidad que se declaran como herramientas de accesibilidad. Esa declaración la hace cumplir la política de Google Play, no la plataforma, así que un servicio instalado fuera de la tienda puede atribuírsela; el atributo sube el listón sin cerrar la vía. Los campos de contraseña, de código de un solo uso y las pantallas de confirmación de transferencias son los candidatos naturales.
Proteger contra la captura de pantalla. FLAG_SECURE en las ventanas sensibles impide las capturas y que la ventana aparezca en grabaciones de pantalla y pantallas no seguras. No detiene las superposiciones ni la lectura por accesibilidad, pero cierra la vía de grabación de pantalla que algunas familias usan junto a ellas.
Revisar los servicios de accesibilidad activos. AccessibilityManager expone la lista de servicios habilitados. La aplicación puede avisar al usuario, o pedir verificación adicional en operaciones de alto riesgo, cuando hay un servicio desconocido activo. Conviene decidirlo con cuidado: las personas que usan tecnologías de asistencia dependen de estos servicios, y bloquear cualquier servicio activo las excluye.
Sacar la confirmación de la pantalla del dispositivo. Para firmar una transferencia, el control más fuerte es el que el malware no puede pintar: una confirmación por un canal separado o una firma criptográfica ligada a los datos de la operación, en lugar de un código que el troyano puede leer en pantalla o en la bandeja de SMS.
Estos controles pertenecen a la categoría MASVS-PLATFORM del estándar móvil de OWASP, que cubre cómo interactúa una aplicación con el sistema operativo y con su interfaz. Qué miden de verdad MASVS y MASTG explica cómo se evalúa esa categoría y por qué una nota alta no garantiza un dispositivo libre de amenazas.
Qué muestra el análisis estático en una muestra sospechosa
Ante una muestra sospechosa, el análisis estático establece el conjunto de capacidades sin ejecutar nada:
| Señal | Qué indica |
|---|---|
El permiso SYSTEM_ALERT_WINDOW por sí solo |
Débil: habitual en apps legítimas con interfaz flotante |
Un servicio protegido por BIND_ACCESSIBILITY_SERVICE cuya configuración recibe todos los eventos de ventana |
Detección de primer plano; fuerte combinada con lo siguiente |
QUERY_ALL_PACKAGES, paquetes de bancos listados en el elemento <queries> del manifiesto o una lista embebida de paquetes |
Selección de objetivos |
Actividades WebView sin propósito plausible, o plantillas HTML en assets/ |
Renderizado de inyecciones |
RECEIVE_SMS o un servicio de escucha de notificaciones |
Captura de códigos de un solo uso |
REQUEST_INSTALL_PACKAGES y carga dinámica de código |
Un dropper; la inyección puede llegar en una segunda fase |
Ninguna fila es concluyente por sí sola. La combinación es el hallazgo, y por eso Droidwatch puntúa combinaciones y no permisos aislados. Los hallazgos se mapean a técnicas de MITRE ATT&CK Mobile para que el resultado entre en el programa de detección existente; las relevantes para este patrón son T1417.002 para la superposición, T1516 para la inyección de entrada y T1582 para el control de SMS. El flujo de triaje del SOC explica cómo llegar a una clasificación con estas señales.
Cuando los objetivos los entrega el servidor, el análisis estático no puede nombrarlos. Ejecutar la muestra bajo instrumentación puede revelar la inyección cuando se carga, siempre que la infraestructura de mando y control siga respondiendo; los pros y contras están en análisis estático vs dinámico de malware Android. En Droidwatch, el análisis dinámico es sólo para Android, se ejecuta en el dispositivo o emulador del propio cliente mediante el agente de Droidwatch y está disponible desde el plan Pro. Ninguna muestra se ejecuta en infraestructura de Droidwatch.
Para la app propia del banco, la misma plataforma funciona en el pipeline de publicación: escanear APK en CI/CD explica cómo frenar una build según los hallazgos.
Preguntas frecuentes
¿Android todavía permite los ataques de superposición? Sí, con restricciones. El usuario tiene que conceder el permiso de forma explícita, las superposiciones quedan por debajo de las ventanas críticas del sistema y, desde Android 12, una aplicación puede ocultar las superposiciones de terceros sobre sus ventanas. Las inyecciones guiadas por accesibilidad siguen siendo la vía principal, sobre todo cuando se guía a la víctima por teléfono a través de las pantallas de permisos.
¿Qué diferencia hay entre un ataque de superposición y el tapjacking?
Un ataque de superposición captura lo que escribe la víctima mostrando una pantalla falsa. El tapjacking engaña al usuario para que toque un elemento oculto bajo una ventana engañosa. Android 12 bloquea la mayoría de los toques que atraviesan ventanas de otras apps, lo que recorta el tapjacking; filterTouchesWhenObscured cubre las versiones anteriores en las vistas que lo usan.
¿Puede una app bancaria detectar que tiene una superposición encima? En parte. Los eventos táctiles llevan indicadores de que la ventana estaba tapada y, desde Android 12, la aplicación puede ocultar directamente las superposiciones de terceros. Una actividad lanzada por el malware sobre la aplicación es otro caso: la actividad del banco simplemente pierde el foco.
¿SYSTEM_ALERT_WINDOW por sí solo indica malware?
No. Lo usan de forma legítima apps de mensajería, filtros de pantalla y ayudas de accesibilidad. Se vuelve relevante cuando aparece junto al abuso de accesibilidad, la selección de objetivos y el renderizado de inyecciones.
¿Qué técnica de MITRE ATT&CK cubre los ataques de superposición? T1417.002, GUI Input Capture, en MITRE ATT&CK Mobile.