Cómo funciona un troyano bancario Android

Un troyano bancario Android no rompe el cifrado ni ataca al banco. Espera a que la víctima se autentique y toma las credenciales en el punto en que todavía están en claro: el teclado.

Todo lo demás en la familia —los permisos, la entrega por etapas, el antianálisis— existe para hacer posible ese instante y para mantenerlo funcionando después.

Entender la cadena de capacidades importa para el triaje, porque los componentes por separado son poco llamativos. El permiso de superposición lo usan aplicaciones de mensajería legítimas. Los servicios de accesibilidad existen para usuarios que los necesitan. Una señal aislada no prueba nada; la combinación es el hallazgo.

Las cuatro capacidades

1. Superposición

El ataque exige dibujar una ventana encima de la aplicación bancaria, idéntica píxel a píxel a su pantalla de acceso. La víctima teclea en la ventana del atacante.

En Android esto requiere SYSTEM_ALERT_WINDOW, y las variantes modernas lo combinan con una comprobación de qué aplicación está en primer plano, para que la pantalla falsa aparezca en el momento correcto y no al azar. Esa detección de primer plano exige a su vez enumerar los paquetes instalados, y así QUERY_ALL_PACKAGES entra en el conjunto: el malware necesita saber qué superposición bancaria mostrar.

En un informe esto aflora como dos hallazgos distintos: el permiso por sí solo, y el permiso junto a la detección de primer plano. El segundo es evidencia materialmente más fuerte que el primero, y Droidwatch los puntúa por separado por esa razón.

2. Abuso de accesibilidad

La API de accesibilidad de Android se creó para que el software de apoyo pueda leer la pantalla y actuar en nombre del usuario. Ésa es exactamente la capacidad que quiere un atacante.

Con un servicio de accesibilidad concedido, el malware puede leer el contenido de cualquier ventana —incluidos códigos de un solo uso—, descartar diálogos de permisos automáticamente, concederse más permisos sin intervención del usuario e impedir su propia desinstalación interceptando la pantalla de ajustes.

La distinción que importa en triaje es entre una aplicación que declara un servicio de accesibilidad y otra cuyo código demuestra que usa la API para pulsar, leer campos y navegar. La declaración por sí sola aparece en software legítimo. El patrón de uso no.

3. Intercepción de SMS

Si una transacción exige un código enviado por SMS, el troyano necesita leerlo antes que la víctima, o en lugar de la víctima.

Aquí aparecen dos capacidades: leer los mensajes entrantes y reenviarlos a un número o endpoint del operador. El reenvío es la señal más fuerte, porque no tiene explicación benigna plausible en una aplicación que no es un cliente de SMS.

Desde que Android restringió los permisos de SMS en Play, esta capacidad llega cada vez más acompañada de una petición para ser la aplicación de SMS por defecto, que la concede al completo. Una vía paralela evita el SMS por entero: un escucha de notificaciones lee el código desde la propia notificación, lo que cubre los códigos entregados por push.

4. Entrega por etapas

Las familias maduras no incluyen la carga útil en el APK instalado. La primera etapa es pequeña, pide poco y pasa la revisión. Una vez en ejecución, descarga la carga real y la carga en tiempo de ejecución.

Esto derrota a cualquier análisis limitado al fichero instalado, que es la mayoría del escaneo automatizado. Un informe estático aún puede cazarlo: carga dinámica de código mediante DexClassLoader o un PathClassLoader sobre un fichero descargado, una URL de descarga embebida, un blob de alta entropía en assets/ que el manifiesto no explica, y una petición para instalar paquetes de origen desconocido son todos visibles sin ejecutar nada.

Una señal de dropper en una aplicación que se presenta como producto bancario merece escalado por sí sola, independientemente de lo que haga la primera etapa.

El conjunto de permisos

Las capacidades anteriores se traducen en un grupo concreto y reconocible de declaraciones del manifiesto:

Ninguno es concluyente por separado. Todos tienen usuarios legítimos. El conjunto como grupo no tiene ninguna categoría de aplicación legítima.

Persistencia

Otras dos capacidades aparecen en muchas familias y conviene anotarlas porque cambian la respuesta al incidente, no sólo la clasificación.

Administrador de dispositivo. Una aplicación registrada como administrador resiste la desinstalación por la vía normal. Quitarla exige revocar antes ese permiso, que es justo lo que el servicio de accesibilidad se usa para impedir.

Combinación con accesibilidad. Administrador de dispositivo más abuso de accesibilidad es el par que convierte un hallazgo de malware en una decisión de reinstalar el dispositivo. El usuario no puede quitarlo de forma fiable por su cuenta, y una guía de soporte que asuma una desinstalación normal va a fallar delante del cliente.

Qué significa la combinación

Droidwatch sigue ocho señales bancarias distintas, y la puntuación refleja que el peso lo llevan las combinaciones:

Un informe que lista el permiso de superposición y nada más describe una aplicación de mensajería. Un informe que lista superposición con detección de primer plano, uso de accesibilidad, reenvío de SMS y un dropper describe un troyano bancario, y la confianza viene de la intersección y no de ningún elemento aislado.

Correspondencia con ATT&CK

Cada capacidad se corresponde con una técnica de MITRE ATT&CK Mobile, y Droidwatch mapea los hallazgos a técnicas para que el informe encaje en un programa de detección existente en lugar de quedarse al lado:

Ese mapeo es la diferencia entre un informe que dice esto es malo y uno sobre el que un ingeniero de detección puede actuar: el identificador de técnica es el vocabulario común entre el análisis y los controles que deberían cazarlo la próxima vez.

Dónde la identidad va primero

Antes que todo esto, hay una pregunta que se resuelve más rápido y de forma más concluyente: ¿es la aplicación lo que dice ser?

Un paquete que suplanta a un banco, firmado con un certificado que no coincide con el de Google Play, es un incidente de reempaquetado. Ese hallazgo no exige análisis de comportamiento y corresponde el mismo día a protección de marca, porque el canal de distribución sigue activo.

Droidwatch comprueba la identidad del paquete contra Play y examina el certificado de firma dentro del mismo análisis. La reutilización de certificados entre aplicaciones aparentemente sin relación es con frecuencia el pivote más productivo que se obtiene de una sola muestra, porque enlaza campañas que no comparten nada más.

Distribución

El conjunto de capacidades explica qué hace el malware una vez instalado. No explica cómo llega, y en los mercados de América Latina y la península ibérica las vías de entrega son lo bastante constantes como para enunciarlas:

• Smishing con pretexto de actualización. Un mensaje que afirma que la aplicación bancaria requiere una actualización obligatoria, con enlace a un paquete fuera de Play.
• Instalación guiada por teléfono. Alguien que dice llamar del departamento de fraudes de la entidad acompaña a la víctima mientras activa la instalación de orígenes desconocidos y concede el permiso de accesibilidad. Esta vía derrota a casi todos los avisos del dispositivo, porque alguien está guiando a la víctima para saltárselos en tiempo real.
• Tiendas alternativas y sitios agregadores. Versiones reempaquetadas de aplicaciones bancarias legítimas, con frecuencia con el nombre y el icono correctos y un certificado de firma incorrecto.

Las tres comparten una propiedad relevante para la defensa: el paquete malicioso nunca pasa por el pipeline de publicación de la entidad. Detectarlo es un problema de vigilancia, no de construcción.

Qué establece el análisis estático y qué no

Todo lo descrito es visible sin ejecutar la muestra. El análisis estático establece capacidad: lo que la aplicación es capaz de hacer.

No establece comportamiento. Una aplicación capaz de interceptar SMS puede no hacerlo nunca, o hacerlo sólo cuando se lo indique su servidor de mando y control. Cuando una decisión depende del comportamiento en ejecución hace falta análisis dinámico, y en Droidwatch eso es sólo Android, ejecutándose contra el dispositivo o emulador del propio cliente mediante el agente de Droidwatch, disponible desde el plan Pro. Ninguna muestra se ejecuta en infraestructura de Droidwatch.

A efectos de triaje esa distinción rara vez bloquea una decisión. Un paquete que reúne el conjunto completo de capacidades, firmado con un certificado que no coincide con el de la entidad que dice representar, no necesita confirmación en ejecución para justificar el escalado. El flujo de triaje establece los seis pasos que producen esa clasificación, y el recorrido del informe explica dónde aparece cada pieza de evidencia.

Los indicadores extraídos de las muestras analizadas en la plataforma se publican en el threat feed público bajo licencia CC BY 4.0.

¿Tienes una muestra? Sube un APK. No se requiere método de pago.