RASP que no deja fuera a los clientes reales

La protección en tiempo de ejecución, o RASP, ya se da por hecha en las apps bancarias y en otras apps que mueven dinero. Los bancos socios, los auditores y los equipos de fraude piden detección de root, detección de hooking y comprobaciones contra la manipulación.

Lo difícil no es detectar amenazas. Es detectarlas sin bloquear a clientes reales. Una comprobación que deja fuera a un usuario legítimo con un dispositivo poco habitual se traduce en un ticket de soporte, una mala reseña y, a veces, un cliente perdido.

En este artículo repasamos cómo construimos y verificamos la protección en tiempo de ejecución de la app Android de un banco minorista, y las decisiones de diseño que mantuvieron bajos los falsos positivos.

---

Qué tenía que detectar la app

• Frameworks de hooking como Frida, que pueden cambiar el comportamiento de la app en tiempo de ejecución.

• Dispositivos rooteados, en los que las protecciones del sistema operativo ya no se sostienen.

• Emuladores, utilizados a menudo para el abuso automatizado a gran escala.

• Apps reempaquetadas, modificadas y redistribuidas fuera de la tienda oficial.

• Abuso de superposiciones (overlays) y de la accesibilidad, una técnica habitual del malware bancario.

📌 Idea clave:

Todo detector puede fallar de dos maneras: dejar pasar un ataque o señalar a un usuario honesto. La mayoría de los debates sobre RASP solo hablan de la primera.

---

Decisiones de diseño que mantuvieron bajos los falsos positivos

1. Valores exactos, no heurísticas laxas

Muchas comprobaciones de emuladores buscan palabras sospechosas en las propiedades del dispositivo. Eso también atrapa hardware real con nombres poco habituales. Pasamos a una detección de emuladores por valores exactos, cubierta por 35 pruebas, y verificamos que no había ningún falso positivo en Chromebooks, que ejecutan apps Android y a menudo hacen saltar las comprobaciones ingenuas.

2. Clasificadores probados con apps reales

Para detectar autoclickers, creamos un clasificador y lo probamos con apps reales, no solo con muestras de laboratorio. Es en el comportamiento con software real donde un clasificador se gana la confianza o empieza a bloquear a usuarios honestos.

3. Comprobaciones de identidad que no dependen del dispositivo

La protección contra el reempaquetado usa una comprobación del certificado de firma y una comprobación del instalador. Ambas examinan la propia app, por lo que se comportan igual en todos los teléfonos.

4. Un kill-switch para cada detector

La detección en tiempo de ejecución está detrás de un kill-switch remoto. Si un nuevo modelo de teléfono empieza a activar una comprobación, el equipo no tiene que esperar a una nueva versión en la tienda para dejar de bloquear a la gente.

---

Cómo lo verificamos

La matriz de verificación ejecutó cada escenario en builds de prueba:

Escenario	Resultado esperado
Frida conectado a la app	Pantalla de bloqueo en menos de 5 segundos
App iniciada en un emulador	Bloqueada
App iniciada en un teléfono real	Funciona con normalidad

Probar las filas de «debe pasar» es tan importante como probar las de «debe bloquear». Ahí es donde se detectan los falsos positivos antes de que los encuentren los clientes.

---

Lo que RASP no hace

• No hace que una app sea invulnerable. Un atacante decidido puede eludir las comprobaciones del lado del cliente si dispone de tiempo suficiente.

• No sustituye a los controles del lado del servidor, como la validación de sesiones y la puntuación de fraude.

• No cubre requisitos específicos de cada sector, como la geolocalización certificada para las apuestas.

Lo que sí hace bien es encarecer los ataques habituales, frenar las herramientas listas para usar y el abuso automatizado, y dar al backend señales sobre las que actuar.

Cómo ayuda Mobian

En Mobian, estos controles en tiempo de ejecución formaron parte de la remediación de seguridad para un banco minorista que partió de una puntuación de MobSF de 48/100 y dio lugar a 124 correcciones con seguimiento. Diseñamos la detección pensando en los usuarios que usted tiene, no solo en los atacantes que teme, con pruebas para ambos y una forma de desactivar una comprobación si se comporta mal.

Conclusión

Un buen RASP se mide por dos lados: lo rápido que frena una herramienta de hooking y lo poco que molesta a un cliente real. Las comprobaciones por valores exactos, los clasificadores probados con apps legítimas, las comprobaciones de identidad independientes del dispositivo y un kill-switch remoto permiten bloquear Frida en segundos sin que un cliente con un Chromebook note absolutamente nada.

Preguntas frecuentes

¿Qué es RASP en una app móvil?

La autoprotección de aplicaciones en tiempo de ejecución (Runtime Application Self-Protection, RASP) es un conjunto de comprobaciones que una app realiza sobre sí misma mientras se usa: detectar root, herramientas de hooking como Frida, emuladores, depuradores y versiones reempaquetadas de la app. Cuando salta una comprobación, la app puede bloquear, limitar funciones o informar al servidor.

¿Por qué las comprobaciones de RASP provocan falsos positivos?

Muchas detecciones se basan en heurísticas laxas, como buscar en las propiedades del dispositivo palabras asociadas a emuladores. Los dispositivos reales, incluidos los Chromebooks que ejecutan apps Android, pueden coincidir con esos patrones. Un falso positivo deja a un cliente que paga sin acceso a su propia cuenta.

¿Qué es un kill-switch de RASP?

Un ajuste remoto que permite al equipo desactivar o relajar un detector concreto sin publicar una nueva versión de la app. Si una comprobación empieza a bloquear a usuarios reales en un dispositivo determinado, el equipo puede desactivarla en minutos mientras prepara una corrección.

¿Puede RASP detener a un atacante decidido?

No. Un atacante hábil con tiempo suficiente puede eludir las comprobaciones del lado del cliente. RASP encarece los ataques, frena las herramientas habituales y el abuso automatizado, y da al servidor señales sobre las que actuar. Complementa el diseño seguro y los controles del lado del servidor; no los sustituye.

¿Es útil RASP fuera de la banca?

Sí. Las granjas de emuladores, los autoclickers y las apps reempaquetadas alimentan el abuso de bonos en el gaming y el fraude en las apps de criptomonedas. Se aplican los mismos detectores, aunque cada sector tiene además requisitos propios, como la geolocalización certificada, que RASP no cubre.