Pentesting de aplicaciones móviles iOS y Android: guía técnica para empresas

Un pentesting móvil es una auditoría ofensiva sobre la app que tu organización publica en App Store y Google Play (o distribuye internamente como MDM) y sobre la conversación que esa app mantiene con sus servidores. La superficie de ataque no es sólo la pantalla del usuario: incluye el binario instalado, los datos en disco, las claves en Keychain o Keystore, los esquemas de URL que invocan otras apps, los servicios expuestos por broadcast en Android y la API que sirve los datos. Un atacante con un teléfono rooteado, un AVD modificado y media tarde tiene acceso a lo mismo que ve tu equipo de QA, y a bastante más.

Esta guía cubre qué audita un pentesting móvil moderno, en qué se diferencian iOS y Android desde la perspectiva ofensiva, los bugs más explotados según el OWASP MASVS vigente, los bypass que ningún equipo de desarrollo logra cerrar a la primera y cómo encaja la auditoría móvil en NIS2, DORA, PCI DSS e ISO 27001.

Qué es un pentesting móvil

Un pentesting móvil es un ejercicio ofensivo autorizado y acotado sobre el binario IPA o APK/AAB que tu empresa distribuye, sobre los datos que esa app almacena en el dispositivo y sobre los endpoints backend que consume. El alcance va de la propia app al ecosistema que la rodea: SDKs de terceros embebidos, configuraciones de red (App Transport Security en iOS, Network Security Config en Android), credenciales hardcodeadas, lógica de actualización forzada, mecanismos de jailbreak/root detection y la API que sirve datos sensibles.

A diferencia de un análisis automático con escáner SAST tipo MobSF, un pentesting móvil profesional:

• Realiza análisis estático e instrumentación dinámica en paralelo. El estático extrae secrets, endpoints ocultos, dependencias y permisos abusivos. El dinámico hooks la app en runtime con Frida u Objection y manipula su comportamiento real.
• Audita el backend con la app como cliente legítimo. La app firma peticiones, añade tokens y aplica certificate pinning; un pentest web tradicional contra el mismo dominio no detecta los bugs que sólo emergen cuando la app se comporta como cliente.
• Prueba todos los canales fuera del HTTP estándar: deep links, universal links, push notifications, IPC interprocess (broadcast receivers, content providers, service intents en Android; URL schemes y XPC en iOS).
• Comprueba seguridad en reposo en el dispositivo: dónde quedan tokens al cerrar sesión, qué se vuelca en logs de sistema, qué viaja a iCloud o Google Backup, qué se filtra en screenshots del task switcher.
• Verifica jailbreak/root detection y obfuscación realmente, no como casilla de cumplimiento. Si tarda 10 minutos saltarse la detección con Frida y un script público, el control no protege.

La duración típica varía por complejidad: una app que sólo consume una API REST y muestra datos se cubre en 5-7 días laborables; una app fintech o de salud con SDK propio, módulo offline, criptografía custom y antifraude (RASP) puede pedir 15-25 días y un equipo con perfil iOS y Android específicos.

Por qué hacer pentesting de apps móviles

Tres razones operativas que están moviendo el pentesting móvil de la zona "nice to have" a la zona "exigido":

1. El binario está fuera de tu perímetro. Una vez publicada en App Store o Play, la app vive en un dispositivo que tú no controlas. Un atacante puede descomprimir el IPA o APK, leer recursos, extraer claves embebidas y observar el tráfico TLS desde dentro del dispositivo. El WAF que protege tu web no aplica.
2. Las apps móviles concentran datos personales y financieros. Banca, salud, identidad, tokens de pago, geolocalización continua, biometría. La superficie de impacto regulatorio (RGPD, PSD2 SCA, PCI DSS móvil) es mayor que la de la mayoría de apps web equivalentes.
3. NIS2, DORA, PCI DSS v4.0 e ISO 27001:2022 cubren explícitamente apps móviles. PCI DSS 6.4.6 obliga a pruebas técnicas tras cambios significativos en cualquier código que toque datos de tarjeta, incluido el cliente móvil. NIS2 artículo 21 exige eficacia probada de medidas técnicas en servicios esenciales que se entreguen vía app.

Bien hecho, un pentesting móvil entrega:

• Inventario real de SDKs embebidos y de los datos que cada uno envía a su proveedor (publicidad, analytics, attribution).
• Lista de bugs con prueba de concepto reproducible: petición HTTP capturada, script Frida, captura del filesystem.
• Recomendaciones priorizadas por riesgo de explotación y esfuerzo de fix, no por severidad CVSS aislada.
• Evidencia auditable para PCI DSS QSA, auditor NIS2 o auditor ISO 27001:2022.

iOS y Android: por qué se auditan distinto

iOS y Android comparten patrones de bug pero su superficie técnica difiere lo suficiente como para que un equipo que sólo audita uno se deje cosas en el otro.

iOS

Apple cierra mucho del entorno: app sandbox por defecto, distribución obligatoria por App Store o MDM empresarial, code signing forzado, ATS (App Transport Security) que exige TLS 1.2+ con cert pinning recomendado, Keychain como almacén de secrets respaldado por Secure Enclave en hardware.

Esa rigidez hace que los bugs típicos en iOS estén en otra capa:

• Almacenamiento inseguro fuera de Keychain. La app guarda tokens en UserDefaults, en archivos planos del sandbox o en Core Data sin cifrar. Suficiente con un dispositivo jailbroken para extraerlos.
• ATS deshabilitado en exceptions. El Info.plist tiene NSAllowsArbitraryLoads o exceptions por dominio que permiten HTTP plano. Cualquier intermediario lee el tráfico.
• Universal links mal validados. La app abre cualquier URL del dominio en lugar de validar el path concreto, y un atacante invoca acciones internas vía link.
• Bypass de jailbreak detection. La app usa una librería pública o checks triviales (existencia de /Applications/Cydia.app) que se saltan con Liberty Lite o Shadow.
• WKWebView con JavaScript bridge inseguro. La app expone funciones nativas a JavaScript sin validación de origen y un MITM las llama con argumentos arbitrarios.
• Logging excesivo a os_log o NSLog. Tokens, headers de autorización y respuestas API quedan en los logs unificados de iOS y se exfiltran con un cable USB.

Android

Android es más abierto y la superficie crece: APK firmado con clave del desarrollador, permisos granulares, IPC vía Intents y Content Providers, sideloading habitual, fragmentación de versiones que mantiene parches viejos en producción, opción real de root accesible al usuario.

Bugs típicos en Android:

• Exported components inseguros. activities, services, broadcast receivers o content providers declarados con android:exported="true" sin permission, accesibles desde otra app maliciosa instalada en el mismo dispositivo.
• WebView con setJavaScriptEnabled(true) y addJavascriptInterface. Riesgo de RCE en versiones antiguas de Android y de exfiltración de datos en cualquiera.
• Backup ABIerto. android:allowBackup="true" en AndroidManifest.xml permite extraer toda la base de datos local con adb backup desde un dispositivo conectado.
• Cleartext traffic permitido. android:usesCleartextTraffic="true" o un Network Security Config laxo deja que tráfico HTTP plano salga sin que el desarrollador lo note.
• Deeplinks con android:autoVerify="false". Otra app del dispositivo registra el mismo intent filter, intercepta el callback OAuth y se queda con el token.
• Root detection débil. Checks por archivo (/system/bin/su) que se saltan con Magisk Hide; la app sigue funcionando como si fuera un dispositivo limpio.

Apps híbridas: React Native, Flutter, Cordova

Las híbridas añaden capa: el JavaScript bundle (RN, Cordova) o el snapshot Dart compilado (Flutter) viaja en el binario y se reverséa con relativa facilidad. Lo que hay que vigilar:

• Bundle JS sin minificar que filtra endpoints, claves y lógica completa.
• Plugins de terceros del marketplace correspondiente con permisos excesivos o vulnerabilidades conocidas.
• Bridge entre JS y nativo mal expuesto: una vista web carga contenido externo y llama código nativo a través del bridge.

Flutter tiene la ventaja de compilar Dart a binario nativo (más caro de revertir) pero los strings y endpoints siguen ahí.

OWASP MASVS y MASTG: el estándar de la industria

OWASP mantiene dos artefactos imprescindibles que cualquier auditor móvil serio sigue:

• MASVS (Mobile Application Security Verification Standard). Define controles agrupados en 7 categorías: arquitectura, almacenamiento, criptografía, autenticación, comunicaciones, plataforma e integridad. Cada control tiene niveles L1 (mínimo), L2 (apps con datos sensibles) y MASVS-R (resistencia a reverse engineering, sólo cuando el modelo de amenazas lo justifica).
• MASTG (Mobile Application Security Testing Guide). La guía técnica que detalla cómo probar cada control de MASVS en iOS y Android con herramientas concretas (Frida, Objection, MobSF, Drozer, Radare2, Hopper).

Un informe profesional mapea cada hallazgo a un control MASVS y referencia el test concreto del MASTG. Eso es lo que un auditor PCI o NIS2 quiere ver.

Bugs más explotados en apps móviles auditadas

El 80% de los hallazgos críticos en apps móviles caen en este patrón:

1. Almacenamiento inseguro de tokens y datos sensibles. Tokens JWT en UserDefaults/SharedPreferences planos, ficheros SQLite sin cifrar, capturas de cache que quedan en disco al ir al task switcher.
2. Cert pinning ausente o trivialmente bypaseable. La app no valida el certificado del backend o usa una implementación custom que un script Frida de cinco líneas anula.
3. Bugs en backend que sólo se ven con la app como cliente. La app firma cada petición con un HMAC; reproducir esa firma desde Postman es complicado, así que el backend nunca ha sido auditado de verdad. Resultado: BOLA, mass assignment y lógica de negocio rota a discreción.
4. Logs con datos sensibles. Headers de autorización, payloads completos de respuesta y stacks con secrets aparecen en logs de sistema accesibles a otras apps con permisos de logs (Android viejo) o vía cable USB.
5. Deep links sin validación de estado. La app procesa un link sin comprobar que el usuario está autenticado o que el flujo es legítimo. Un atacante manda al usuario a un link que dispara una acción peligrosa.
6. Root/jailbreak detection cosmético. Detecta el dispositivo modificado, muestra un warning, pero deja que la app siga corriendo. Vale para checkbox PCI, no para defensa real.
7. WebViews con configuración relajada. JavaScript habilitado, file:// permitido, content:// permitido y bridge nativo expuesto. Cualquier XSS en el contenido cargado se convierte en acceso a APIs nativas.
8. SDKs de terceros con permisos abusivos. Un SDK de analytics que pide acceso a contactos o ubicación continua sin que el equipo de producto sea consciente del traffic real que genera.

Bypass técnicos que el equipo de desarrollo no espera

Tres categorías que en informes reales se ejecutan en horas:

Cert pinning

La defensa estándar es pinear el cert del backend para evitar MITM. Bypass habituales:

• Frida + script de comunidad (frida-multiple-unpinning, objection). Hookea las funciones de validación TLS de la app y devuelve siempre OK.
• Reempaquetado del APK con SmaliPatcher o herramientas Frida-gadget para introducir el bypass sin necesidad de root.
• iOS con SSL Kill Switch 3 sobre dispositivo jailbroken, o con un proxy que reemplaza el binario en runtime.

El pinning bien hecho hace dinámico el matching y rota certificados con server-driven config. La mayoría de pinning en producción es un único cert hardcodeado.

Root/jailbreak detection

Las técnicas comunes (existencia de /system/bin/su, presencia de Cydia, comprobación de getprop ro.debuggable, llamada a Runtime.exec) se enumeran y se hookean en bloque. Magisk Hide para Android y Shadow para iOS son herramientas mantenidas por la comunidad que automatizan el ocultamiento.

Defensa razonable: combinar varias señales, usar attestation de Google Play Integrity API o Apple DeviceCheck/AppAttest contra un servidor backend que decida si dejar pasar la sesión, y degradar funcionalidad sensible (por ejemplo, no permitir transferencias) en lugar de cerrar la app.

Anti-debugging y RASP

Las apps reguladas (banca, salud) suelen incorporar RASP comercial (Promon SHIELD, Talsec, Verimatrix). Un equipo de pentesting profesional dedica una fracción del esfuerzo a evaluar resistencia, pero conviene saber que el RASP eleva el coste del atacante, no lo bloquea. Los CTFs de móvil llevan años demostrando bypass para todos los productos comerciales.

Metodología de un pentesting móvil profesional

La que aplicamos en Secra y la que cualquier equipo serio sigue (alineada al MASTG):

1. Onboarding técnico: entrega del IPA/APK, credenciales de cuentas de prueba, documentación de arquitectura, listado de SDKs. Si hay backend dedicado, accesos para tráfico legítimo.
2. Análisis estático. Decompilación con jadx o apktool (Android) y class-dump/Hopper/Ghidra (iOS). MobSF como primer pase automatizado. Extracción de strings, secrets, endpoints, dependencias.
3. Configuración del laboratorio. Dispositivo físico jailbroken/rooted o emulador (AVD para Android, simulador iOS sólo para algunas pruebas). Burp Suite + cert custom o mitmproxy para tráfico interceptado. Frida server activo en el dispositivo.
4. Análisis dinámico. Recorrido funcional completo de la app con tráfico capturado. Hooking con Objection para volcar Keychain/SharedPreferences, leer SQLite locales y extraer tokens.
5. Auditoría del backend con la app como cliente. BOLA, mass assignment, lógica de negocio, rate limiting. Aquí coincide con un pentesting de APIs clásico.
6. Auditoría de IPC y deep links. En Android con Drozer enumerando exported components; en iOS analizando URL schemes registrados y universal links.
7. Bypass de defensas. Cert pinning, root/jailbreak detection, RASP si aplica. Documentación del esfuerzo necesario, no sólo del resultado.
8. Reporting y retest. Informe ejecutivo, técnico con PoC reproducible y debrief con el equipo de desarrollo. Retest cuando los fixes están listos.

Pentesting móvil y compliance: NIS2, DORA, PCI DSS, ISO 27001

• PCI DSS v4.0 (6.4.6). Cualquier cambio significativo en código que toque datos de tarjeta requiere prueba técnica. Si tu app móvil procesa pagos directamente, es ámbito PCI y el pentesting debe cubrirla. Frecuencia mínima anual.
• NIS2 (artículo 21). Eficacia de medidas técnicas en servicios esenciales. Si el servicio se entrega vía app móvil (banca, telco, sanidad), el pentesting móvil es la prueba de eficacia que el organismo competente espera ver.
• DORA (artículo 25). Pruebas de resistencia operativa digital. Las entidades financieras significativas deben someter a pentesting sus aplicaciones críticas con frecuencia mínima anual e incluir TLPT (TIBER-EU) cada tres años para apps consideradas críticas.
• ISO 27001:2022 (control 8.29). Pruebas de seguridad en el ciclo de vida del software. La auditoría móvil documentada cubre este control para SGSIs que incluyan apps en su alcance.

Cómo elegir un proveedor de pentesting móvil

Cinco criterios que separan al equipo serio del que sólo pasa MobSF:

1. Mapeo explícito a OWASP MASVS y MASTG. Cada hallazgo referenciado al control concreto. Si el informe no lo trae, el equipo no se ha leído el estándar.
2. Equipo con perfil iOS y Android dedicados. Iguala el nivel del equipo del cliente. Un pentester sólo Android se pierde detalles de Keychain, ATS, App Groups y entitlements.
3. Capacidad real de instrumentación dinámica con Frida y Objection, no únicamente análisis estático con MobSF. Pídelo expresamente al evaluar propuestas.
4. Auditoría conjunta del backend con la app como cliente. Sin esa parte, los bugs de autorización a nivel de objeto no aparecen.
5. PoC reproducible y retest incluido en el alcance original.

Preguntas frecuentes

¿En qué se diferencia el pentesting móvil del pentesting web?

El pentesting móvil cubre tres frentes: el binario instalado en el dispositivo (que puede leerse, modificarse y reinstalarse), los datos en reposo en disco y en almacenes nativos como Keychain/Keystore, y la comunicación con el backend (igual que un pentesting web, pero con la app como cliente legítimo que firma peticiones y aplica pinning). Un pentest web tradicional sobre la misma API se pierde los bugs que sólo emergen cuando la app actúa como cliente.

¿Cuánto tiempo lleva un pentesting móvil?

Depende del scope. Una app que consume una API REST sencilla y muestra datos se cubre en 5-7 días laborables. Una app fintech con módulo offline, criptografía custom, RASP comercial y SDK propio puede pedir 15-25 días con perfiles iOS y Android específicos. Para servicios bajo DORA o PCI con TLPT, el alcance se extiende varias semanas.

¿Hace falta el código fuente para auditar la app?

No, aunque ayuda. Un pentesting black-box sobre el binario IPA o APK ya descubre la mayoría de bugs críticos: el decompilador devuelve código legible y el análisis dinámico llega a casi todo. El acceso a código fuente acelera la auditoría y permite revisar lógica difícil de alcanzar dinámicamente, pero no es un requisito previo.

¿Por qué la app "que no se puede rootear" sí se rootea en pentest?

Porque la detección de root o jailbreak suele basarse en checks que un atacante con Frida o Magisk Hide neutraliza en minutos. El estándar moderno es no confiar el control al dispositivo: usar attestation servidor (Google Play Integrity, Apple AppAttest) para que el backend decida si la sesión es legítima.

¿Es necesario auditar también el backend si ya audité la web?

Sí. Las apps móviles consumen rutas, parámetros y flujos que el frontend web no toca. La firma HMAC, los headers custom y el pinning hacen que esos endpoints rara vez aparezcan en un pentest web tradicional. Los bugs de BOLA, mass assignment y lógica de negocio frecuentes en backend móvil no se descubren sin un cliente móvil legítimo manipulado.

¿Conviene auditar la app antes de subirla a la store o después?

Antes de la primera publicación y después de cualquier release con cambios estructurales (refactor de auth, integración de un SDK nuevo, lógica de pago, módulo offline). Para apps con compliance recurrente (PCI, DORA, NIS2), pentesting anual mínimo y revisión técnica menor por release.

Recursos relacionados

• Qué es un pentesting: el pillar del cluster, con metodología y comparativas con red team y bug bounty.
• Pentesting de aplicaciones web: la disciplina hermana en frontend web. Comparte parte del backend cuando hay app y web sobre la misma API.
• Pentesting de APIs REST y GraphQL: la auditoría del backend que sirve la app, con OWASP API Top 10 detallado.
• Rootear AVD Android para pentesting con Burp Suite: tutorial técnico para montar el laboratorio Android.
• OWASP Top 10 2025 explicado para empresas: contexto del Top 10 web aplicable a la API que consume la app móvil.

El pentesting móvil en Secra

En Secra cubrimos pentesting iOS y Android con perfiles dedicados a cada plataforma, mapeo MASVS/MASTG en informe, instrumentación con Frida y Objection, auditoría conjunta del backend con la app como cliente y retest incluido en el alcance. Si tu organización publica apps reguladas (banca, salud, sector público) o tiene compliance PCI DSS, NIS2 o DORA, escríbenos a través de contacto o consulta nuestro servicio de auditoría web y móvil.