MAST es la práctica de probar una aplicación móvil desde dos ángulos a la vez: su binario compilado y su comportamiento mientras se ejecuta en un dispositivo. MAST cubre lo que un archivo .apk, .aab o .ipa revela al descompilarlo, lo que la aplicación escribe en el teléfono y cómo se comunica con el backend del que depende. El objeto de estudio es software que una empresa publica y deja de controlar.
En septiembre de 2026, nuestro Offensive Team divulgó tres vulnerabilidades en aplicaciones Android publicadas en Google Play. Una de ellas, CVE-2026-84283, afectaba a una aplicación que ofrecía una bóveda protegida con PIN y escribía esos archivos, sin cifrar, en el almacenamiento compartido de Android. Cualquier gestor de archivos del dispositivo podía abrirlos. El PIN nunca fue vulnerado, porque nunca estuvo en el camino.
Esta página cubre qué es MAST, por qué no es lo mismo que OWASP MASVS o MASTG, cómo ejecutamos MAST en Fluid Attacks, qué controles debe alcanzar una evaluación móvil y en qué punto la técnica deja de ser evidencia por sí sola.
¿Qué es MAST?
MAST o Pruebas de Seguridad de Aplicaciones Móviles (Mobile Application Security Testing), es la práctica de encontrar vulnerabilidades, errores de configuración y defectos de privacidad en aplicaciones móviles a lo largo de su ciclo de vida. No es una sola herramienta. MAST combina análisis estático del código descompilado, análisis dinámico de la aplicación en ejecución, inspección de lo que la aplicación almacena en el dispositivo y pruebas de las API que hay detrás.
La técnica se diferencia de las pruebas de aplicaciones web por la forma en que se entrega el software. Una aplicación web corre sobre infraestructura que la organización administra. Una aplicación móvil se entrega al usuario como un archivo y se instala en un dispositivo que puede estar rooteado, con jailbreak o instrumentado. El atacante tiene el binario, tiempo ilimitado y un depurador. Ese escenario de “Man-at-the-End” es el supuesto del que debería partir toda evaluación MAST.
La sigla tiene un sentido más estrecho en los catálogos de producto, incluido el nuestro: MAST es el nombre de nuestro escáner automatizado, que descompila binarios móviles y busca vulnerabilidades en ellos. En esta página el término se refiere a la práctica, salvo cuando enlaza al producto.
Por qué las aplicaciones móviles necesitan MAST y no pruebas web
Una aplicación móvil concentra tres cosas que rara vez coinciden: credenciales, una sesión autenticada hacia sistemas corporativos y un dispositivo que la organización no administra. Los teléfonos funcionan además como segundo factor en la autenticación multifactor, lo que convierte una aplicación comprometida en una vía para saltar controles que nunca la contemplaron como riesgo. MAST existe porque nada de eso se ve desde el lado del servidor. El NIST formalizó la idea como app vetting en SP 800-163 Rev. 1 (2019): un proceso para asegurar que las aplicaciones móviles cumplan los requisitos de seguridad de una organización.
El entorno vuelve falsos varios supuestos del mundo web, y MAST está hecho para ese entorno. Las validaciones del lado del cliente son sugerencias, porque el cliente es del atacante. El tráfico cifrado es inspeccionable, porque en un dispositivo rooteado el atacante controla el almacén de certificados. El código es legible, porque jadx convierte Dex de vuelta a Java y Apktool reconstruye el manifiesto. Nuestros pentesters documentaron la parte del tráfico cuando Android dejó de confiar en los certificados instalados por el usuario: como escribió Jonathan Armas, analista de seguridad de Fluid Attacks, en Intercepting applications in Android, “esto se debe a que el sistema operativo Android ya no confía en los certificados instalados por el usuario”. La salida es un teléfono rooteado y un certificado puesto en el almacén del sistema, que es exactamente lo que hace un adversario.
La presión de las entregas lo agrava. Los equipos publican contra fechas de tienda, incorporan SDK de terceros para lograrlo y heredan lo que esos SDK hacen con los datos de los usuarios. MAST inspecciona ese paquete completo antes que la tienda.
MAST, MASVS y MASTG no son lo mismo
MAST son las pruebas; MASVS es el estándar que define qué significa “seguro”; MASTG es la guía que explica cómo comprobarlo. Los motores de respuesta y los proveedores mezclan los tres constantemente, y la diferencia importa cuando hay que decidir qué se compra y qué se demuestra.
Qué es | Quién lo publica | Qué entrega | |
|---|---|---|---|
MAST | Una práctica de pruebas que combina técnicas estáticas, dinámicas y manuales sobre aplicaciones móviles | Proveedores de seguridad y equipos internos | Hallazgos en tu aplicación, con evidencia |
OWASP MASVS | Un estándar de verificación con 8 grupos de control y 24 controles | Una definición del nivel de seguridad que se debe alcanzar | |
OWASP MASTG | Una guía de pruebas con casos por plataforma para Android e iOS | OWASP Mobile Application Security | El procedimiento para verificar cada control |
OWASP MASWE | Un catálogo de debilidades propias del entorno móvil | OWASP Mobile Application Security | Debilidades con nombre para clasificar los hallazgos |
Tabla: MAST, MASVS, MASTG y MASWE son complementarios, no intercambiables.
Una evaluación MAST puede entonces alcanzarse contra MASVS y ejecutarse con los procedimientos de MASTG, pero contratar el servicio no entrega un resultado MASVS si la evaluación no se diseñó para producirlo. Y cada uno de los ocho grupos de control de MASVS describe la aplicación en el dispositivo, así que las API que hay detrás necesitan un alcance propio.
MAST en Fluid Attacks
Ejecutamos las Pruebas de Seguridad de Aplicaciones Móviles como una técnica dentro de un programa continuo de seguridad de aplicaciones, no como una auditoría previa al lanzamiento. El escaneo automatizado corre con cada nueva build, nuestros pentesters trabajan la misma aplicación a mano y ambos alimentan una sola lista de vulnerabilidades con una sola escala de severidad.
Qué evaluamos y bajo qué reglas
El alcance es el binario más el entorno con el que se emparejó. Según nuestra documentación de entornos, aceptamos archivos .aab, .ipa y .apk de hasta 4,88 GB, cargados directamente o tomados de la plataforma de distribución que ya usa la aplicación: TestFlight, Firebase, App Store Connect o Google Play Store. Cada nueva versión entra a pruebas automáticamente.
Todo lo que reportamos en una evaluación MAST sale de una build que nos entregaste, contra un alcance que registraste. Los advisories que publicamos sobre software de terceros siguen divulgación coordinada.
Dos builds: con y sin controles RASP
Este es el requisito que casi nadie espera: para MAST pedimos dos versiones de la aplicación, una con controles RASP y otra sin ellos. Los controles en cuestión son detección de root, detección de emuladores y certificate pinning.
La autoprotección en tiempo de ejecución cambia lo que una prueba puede ver, no lo que un atacante puede hacer. Una build endurecida nos dice si las defensas aguantan. Una build sin endurecer nos dice qué hay detrás de ellas: el token en texto plano en SharedPreferences, el componente exportado, la API que nunca verifica la propiedad del objeto. Un atacante que vence la detección de root con Frida llega a esa segunda capa, así que un informe que solo cubre la primera está describiendo la cerradura y no la habitación.
Cómo se ve una evaluación MAST en la práctica
Capa evaluada | Qué instrumentamos | Evidencia que queda | Herramientas de nuestro stack |
|---|---|---|---|
Binario y código | Descompilación de APK, manifiesto, ofuscación, secretos embebidos | Código descompilado, ID de debilidad, archivo afectado | jadx, Apktool, APKLab, Ghidra |
Almacenamiento local | Archivos, bases de datos, preferencias, cachés, respaldos | Artefactos extraídos con los datos que contenían | MobSF, shell del dispositivo |
Comportamiento en ejecución | Hooks sobre llamadas criptográficas, chequeos de root, pinning | Scripts de instrumentación y registro del bypass | Frida, Objection |
Capa de red | TLS, validación de certificados, flujos de petición y respuesta | Tráfico interceptado, registros del proxy | mitmproxy, Burp Suite Professional |
Builds multiplataforma | Snapshots AOT de Flutter y librerías reempaquetadas | Build parcheada, estructura de llamadas recuperada | reFlutter, Uber Apk Signer |
Backend y API | Autorización, manejo de sesión, lógica de negocio | Peticiones reproducibles y respuestas del servidor | Pruebas manuales, nuestro escáner DAST |
Tabla: cada capa de una evaluación MAST, su evidencia y las herramientas que usan nuestros pentesters.
La parte automatizada corre como contenedor Docker. Nuestro escáner MAST, fluidattacks/mast, descompila archivos APK y busca vulnerabilidades en ellos; ocupa 553 MiB de instalación y 877 MiB de disco, según nuestra documentación de escáneres.
Qué encuentra la automatización y qué se le escapa
Lo medimos sobre nosotros mismos. En el benchmark de Fluid Attacks de 36 herramientas de AppSec de terceros contra una aplicación con 1.201 vulnerabilidades sembradas, un pentester alcanzó 89,6 % de recall con 100 % de precisión, mientras que la herramienta automatizada de mejor desempeño —nuestro propio escáner— llegó a 22,7 % de recall, equivalente a 8,8 % de la exposición al riesgo total de la aplicación medida en CVSSF.
El patrón se repite en producción. En nuestro reporte State of Attacks 2026, sobre 1.119.396 vulnerabilidades reportadas durante 2025, el 87 % de las vulnerabilidades de severidad crítica se identificó mediante revisión manual, aunque las herramientas automatizadas aportaron el 88,4 % del total por conteo. Los escáneres encuentran volumen. Las personas encuentran las que importan.
Un escáner puede marcar un archivo legible por cualquiera; no puede razonar si el token que hay dentro todavía autoriza una transferencia. Por eso nuestro trabajo en móviles combina el escáner con pentesting de aplicaciones móviles, entregado como Pentesting as a Service (PTaaS) y, cuando el binario se resiste, como Reverse Engineering.
Dónde un escaneo limpio deja de ser prueba
Un escaneo que no devuelve nada no es una aplicación segura, y preferimos decirlo. Nuestro propio recall automatizado de 22,7 % es el techo que se le puede acreditar a cualquier escáner por sí solo, y las tres aplicaciones que nuestro equipo rompió en 2026 estaban publicadas en Google Play.
Vale la pena nombrar dos límites. Las builds multiplataforma derrotan el flujo estándar: una release de Flutter compila Dart anticipadamente a un snapshot, así que descompilar el APK a Java con jadx no devuelve casi nada de la lógica de negocio, y el trabajo se mueve a reFlutter y a una build reempaquetada. Y una aplicación puede cumplir todos los controles del lado del cliente mientras su API le entrega a cualquier usuario autenticado los registros de otro, porque ese defecto no está en el binario.
La pregunta útil frente a un proveedor no es cuántas vulnerabilidades reportó el escáner. Es qué hizo la evaluación MAST después de que el escáner se detuvo.
Qué debe cubrir una evaluación MAST
Una evaluación MAST completa debería alcanzar los ocho grupos de control de MASVS, porque cada uno falla por separado. Nuestro catálogo de debilidades mapea 39 requisitos de seguridad a OWASP MASVS v2.0, y los grupos que siguen respetan ese mapeo.
Los 39 requisitos de Fluid Attacks mapeados a OWASP MASVS v2.0 en nuestra base de datos pública.
Almacenamiento y criptografía
Qué deja la aplicación en el dispositivo y cómo lo protege. El análisis estático cubre bases de datos, preferencias, cachés, registros y respaldos, además del manejo de llaves y la elección de algoritmos. Nuestra debilidad 020, información confidencial no cifrada, enuncia el control de forma directa: “en móviles, usa el almacenamiento seguro de la plataforma (iOS Keychain, Android Keystore) en lugar del almacenamiento local o compartido”. Codificar no es cifrar, y un Base64 en un archivo de preferencias cuenta como texto plano.
Autenticación y comunicación en red
Si las verificaciones de identidad ocurren donde no se pueden saltar, y si el tráfico sobrevive a un atacante en el camino. Este grupo cubre verificación biométrica, manejo de sesión, vinculación de factores múltiples, versiones de TLS y consistencia de certificados. El certificate pinning entra aquí, y también la prueba que importa más en MAST: qué hace la aplicación una vez que el pinning se evade.
Interacción con la plataforma: IPC, WebViews y deep links
La superficie de ataque de Android que los escáneres subreportan, y la que produjo dos de nuestros tres advisories de 2026. Las actividades exportadas, los broadcast receivers y los content providers exponen el interior de una aplicación a cualquier otra del dispositivo. Nuestra debilidad 075, acceso no autorizado a archivos - APK Content Provider, prescribe android:exported=false y android:grantUriPermissions=false, con un permiso personalizado de nivel Signature cuando compartir es realmente necesario. Los WebViews con interfaces JavaScript habilitadas y los deep links que aceptan parámetros no confiables caen en la misma categoría.
Resiliencia, calidad de código y privacidad
Resistencia a la manipulación, manejo de entradas y qué hace la aplicación con los datos personales. La debilidad 046, ofuscación segura ausente - APK, cubre lo primero: sin ofuscación al desplegar, “es posible obtener el código fuente de la aplicación”. La privacidad cubre consentimiento, propósito de la recolección y revocación. Los marcos de las tiendas se apoyan en el mismo estándar: MASA, de la App Defense Alliance, valida que las aplicaciones tengan los controles de seguridad definidos en MASVS, y nuestra propia CLI fue aceptada para validar requisitos de tier 2 del marco CASA, dentro de sus procedimientos de escaneo estático.
El OWASP Mobile Top 10 sigue siendo útil para comunicar el riesgo a los desarrolladores, pero es una lista de categorías de riesgo, no un plan de pruebas. MASVS es contra lo que MAST verifica.
Qué encontró MAST: tres vulnerabilidades móviles que reportamos en 2026
Aplicación | CVE | CVSS v4.0 | Nuestra debilidad | Qué la encontró |
|---|---|---|---|---|
CVE-2026-84283 | 6.8 | 020, información confidencial no cifrada | Inspeccionar el almacenamiento compartido después de usar la bóveda | |
CVE-2026-81301 | 8.5 | 075, acceso no autorizado a archivos - APK Content Provider | Leer el manifiesto y luego invocar el provider exportado desde una segunda aplicación | |
CVE-2026-85082 | 8.5 | 404, inyección de comandos de sistema operativo | Seguir la ruta de un archivo hasta un comando de shell |
Tabla: tres vulnerabilidades de Android divulgadas por nuestro Offensive Team en septiembre de 2026, con la actividad MAST que destapó cada una.
Nuestro advisory para CVE-2026-84283: una bóveda protegida con PIN que guardaba sus archivos sin cifrar.
Leídas en conjunto, describen tres pasos MAST distintos. La primera salió de revisar el sistema de archivos después de usar la función, no de leer código. La segunda salió del manifiesto: OpenFileProvider estaba exportado sin exigir permisos y convertía la ruta de un URI suministrado por quien llamaba en una ruta del sistema de archivos, de modo que cualquier aplicación local podía hacerle leer, sobrescribir o borrar archivos en su nombre. La tercera salió de seguir una entrada no confiable hasta un shell, donde un nombre de archivo SQLite con $(...) ejecutaba comandos al tocarlo la víctima.
Ninguna de las tres necesitó un día cero en Android. Cada una necesitó un paso MAST que alguien tiene que ejecutar de verdad.
Dónde no termina la superficie de ataque móvil
Una aplicación móvil es un cliente, y su backend es parte de la misma superficie de ataque, así que MAST no puede detenerse en el binario. Quita la aplicación y la API sigue ahí, alcanzable con curl, con la lógica de autorización que tenga.
La seguridad de las API móviles es donde viven la autorización rota a nivel de objeto, las peticiones repetibles y los tokens con permisos excesivos; ninguno aparece en un binario descompilado. Por eso nuestro alcance MAST incluye los entornos de API emparejados con la aplicación, probados con Pruebas de Seguridad de Aplicaciones Dinámicas y a mano.
Lo contrario también se cumple: una API endurecida no excusa un hallazgo MAST como tokens de sesión guardados en texto plano, porque el dispositivo se puede perder, prestar o infectar.
Ejecutar MAST de forma continua
Las nuevas builds salen cada semana, así que una evaluación anual reporta sobre una aplicación que ya no existe. Tres cosas hacen que MAST sea continuo.
Escanear cada build: nuestro escáner MAST corre como contenedor Docker, así que encaja en cualquier proveedor de CI/CD que soporte imágenes Docker.
Conectar la plataforma de distribución: con TestFlight, Firebase, App Store Connect o Google Play Store enlazados, cada nueva versión entra al alcance automáticamente.
Mantener a las personas en un calendario, no en un evento: el pentesting que sigue el ritmo de las entregas encuentra las fallas de lógica que la build anterior no tenía.
Combina MAST con el resto del programa — SAST, AI SAST, SCA sobre los SDK que la aplicación empaqueta y un flujo DevSecOps que rompe la build ante violaciones de política. Nuestros planes separan el nivel automatizado del que incluye pentesters, cuyas credenciales en móviles incluyen eMAPT, GMOB y CMPen-iOS/Android, entre otras certificaciones.
Conclusiones
MAST trata una aplicación móvil como lo que es: software que compilaste, firmaste y luego entregaste a alguien cuyo dispositivo no controlas. Ejecutar MAST como corresponde significa descompilar el binario, observar la aplicación en ejecución, alcanzar los ocho grupos de control de MASVS y seguir al cliente hasta las API que hay detrás.
Nuestras propias mediciones dicen que la automatización sola no llega. Nuestro escáner MAST alcanzó 22,7 % de recall en un benchmark con vulnerabilidades sembradas donde un pentester alcanzó 89,6 %, y el 87 % de las vulnerabilidades de severidad crítica en nuestros datos de clientes de 2025 salió de revisión manual. Los tres CVE de Android que nuestro equipo divulgó en 2026 estaban en aplicaciones ya publicadas en Google Play. El escaneo automatizado es el piso de un programa MAST, y tomarlo por techo es como terminan publicándose bóvedas sin cifrado.
Preguntas frecuentes
¿MAST es lo mismo que OWASP MASVS?
No. MAST es la actividad de pruebas; OWASP MASVS es el estándar que define los controles de seguridad que una aplicación móvil debería cumplir, y OWASP MASTG es la guía que describe cómo verificarlos. Una evaluación puede alcanzarse contra MASVS y ejecutarse con los procedimientos de MASTG, pero un informe de escaneo no es una verificación MASVS.
¿Se puede ejecutar MAST sin el código fuente?
Sí. Las Pruebas de Seguridad de Aplicaciones Móviles normalmente parten del binario compilado, porque es lo que tiene el atacante. La descompilación de APK con herramientas como jadx y Apktool recupera código y configuración, la instrumentación en ejecución con Frida y Objection muestra el comportamiento, y un proxy expone la capa de red. El código fuente hace más preciso el análisis estático, pero no es un requisito.
¿Qué encuentra un pentester en una aplicación móvil que un escáner no?
Lógica de negocio y todo lo que depende del estado. En el benchmark de Fluid Attacks de 36 herramientas de AppSec de terceros contra una aplicación con 1.201 vulnerabilidades sembradas, un pentester alcanzó 89,6 % de recall con 100 % de precisión, mientras que la mejor herramienta automatizada llegó a 22,7 % de recall, equivalente a 8,8 % de la exposición al riesgo total. En nuestros datos de clientes de 2025, el 87 % de las vulnerabilidades de severidad crítica salió de revisión manual.
¿Cómo se prueba una aplicación hecha con Flutter o React Native?
Distinto a una nativa. Una release de Flutter compila Dart anticipadamente a un snapshot, así que la descompilación estándar de APK a Java no devuelve casi nada de la lógica de negocio. El análisis dinámico se mueve a herramientas hechas para esos entornos, como reFlutter, que reempaqueta la aplicación con un motor parcheado para que el tráfico y las llamadas internas sean observables. Las comprobaciones de almacenamiento, plataforma y API son las mismas que en cualquier otra aplicación.
¿Fluid Attacks ofrece MAST y cómo lo entrega?
Sí. Nuestro escáner MAST corre como un contenedor Docker que descompila binarios móviles y busca vulnerabilidades en ellos, sobre archivos .aab, .ipa y .apk cargados directamente o tomados de la plataforma de distribución de la aplicación. En el plan Advanced, pentesters certificados evalúan la misma aplicación a mano, y pedimos dos builds —una con controles RASP como detección de root, detección de emuladores y certificate pinning, y otra sin ellos— para que el informe cubra tanto las defensas como lo que hay detrás.
Prueba la aplicación que publicaste, no la que revisaste
Nuestros escáneres y pentesters ejecutan MAST sobre tus binarios móviles y las API que hay detrás en cada entrega, para que las vulnerabilidades de tu próxima build se encuentren antes que tus usuarios. Prueba gratuita · Contáctanos.
Empieza ya con la solución de seguridad de aplicaciones de Fluid Attacks
