Seguridad móvil: guía completa de Android, iOS y pentesting (2026)

Los teléfonos inteligentes han dejado de ser simples herramientas de comunicación para convertirse en el centro digital de nuestra vida: banca, trabajo, salud, identidad y relaciones personales pasan por la pantalla que llevamos en el bolsillo. Esa concentración de valor los convierte en el objetivo más codiciado por atacantes, desde script kiddies hasta grupos de espionaje patrocinados por estados. Comprender la seguridad móvil —qué protege, qué falla y cómo auditarla— ya no es optativo para quien trabaja en ciberseguridad: es una competencia básica.

Esta guía cubre los dos ecosistemas dominantes (Android e iOS), las amenazas reales con ejemplos documentados, el marco técnico de referencia de OWASP, las técnicas y herramientas de pentesting móvil profesional, la seguridad empresarial de dispositivos, la privacidad del usuario y las rutas de certificación. Todo con fuentes verificables, sin relleno.

Por qué la seguridad móvil es crítica en 2026

En 2025 hay más de 6.000 millones de usuarios de smartphones a nivel global, una cifra que supera con amplitud el número de ordenadores de escritorio y portátiles combinados. Esa masa crítica tiene consecuencias directas sobre la superficie de ataque que los equipos de seguridad deben gestionar.

El primer factor es la concentración de datos sensibles. Una app bancaria, el correo corporativo, la VPN de empresa, las fotos con geolocalización, los mensajes cifrados y las claves de autenticación multifactor coexisten en el mismo dispositivo. Comprometer un teléfono es a menudo más lucrativo que comprometer un servidor bien monitorizado.

El segundo factor es la fragmentación de plataformas y versiones. En el ecosistema Android conviven cientos de fabricantes con ciclos de actualización dispares: una parte significativa de los dispositivos Android activos sigue ejecutando versiones con vulnerabilidades conocidas para las que el fabricante ya no publica parches. iOS presenta un panorama más uniforme, pero la aparición de exploits de zero-click (sin interacción del usuario) ha demostrado que la homogeneidad no equivale a invulnerabilidad.

El tercer factor es la mezcla de uso personal y profesional. Las políticas BYOD (Bring Your Own Device) extienden el perímetro corporativo hasta dispositivos que el equipo de TI no controla directamente. Un malware que llega por WhatsApp personal puede saltar a la VPN corporativa si el dispositivo no está correctamente segmentado.

Por todo ello, el pentesting móvil, el desarrollo seguro de apps y la gestión de dispositivos móviles se han convertido en disciplinas con demanda propia en el mercado laboral de la ciberseguridad.

Arquitectura de seguridad de Android

Android es un sistema operativo de código abierto basado en el kernel de Linux. Su arquitectura de seguridad combina mecanismos del propio kernel, capas de middleware y un modelo de aplicaciones diseñado para el aislamiento.

Sandbox de aplicaciones y modelo de permisos

Cada aplicación Android se ejecuta en su propio proceso con un UID (User ID) único asignado por el sistema. Este mecanismo, heredado directamente de Linux, garantiza que dos aplicaciones distintas no puedan acceder a los datos de la otra salvo que compartan explícitamente un UID (mediante el atributo android:sharedUserId, desaconsejado desde Android 10).

Sobre ese aislamiento a nivel de proceso, Android impone un modelo de permisos declarativo. Desde Android 6.0 (Marshmallow, API 23), los permisos sensibles —cámara, micrófono, localización, contactos, almacenamiento— se solicitan en tiempo de ejecución y el usuario puede revocarlos individualmente. A partir de Android 11, los permisos de localización admiten tres granularidades: precisa, aproximada y solo mientras la app está en primer plano. Android 12 añadió el indicador verde en la barra de estado cuando una app accede al micrófono o la cámara.

Para el análisis de seguridad, los permisos declarados en el AndroidManifest.xml son el primer punto de revisión en el análisis estático: una app de linterna que solicita READ_CONTACTS o SEND_SMS es una señal de alerta inmediata.

Firma de código y verificación de aplicaciones

Todas las APK deben estar firmadas criptográficamente antes de su instalación. Android soporta tres esquemas de firma (v1 basado en JAR, v2 y v3 basados en APK Signing Block, y v4 introducido en Android 11 para instalación incremental). Play Store exige APK Signing Scheme v2 o superior; las apps de sideloading pueden usar v1, lo que históricamente permitió ataques de Janus (CVE-2017-13156) que añadían código malicioso sin invalidar la firma.

La verificación de integridad en tiempo de ejecución la proporciona Google Play Protect, el servicio antimalware integrado en dispositivos con Google Play Services. Analiza las apps instaladas y las APK descargadas, tanto en el dispositivo como en la nube. Según los informes de Android Security, Play Protect detecta y bloquea miles de millones de instalaciones de aplicaciones potencialmente dañinas cada año.

SELinux en Android

Desde Android 5.0, SELinux (Security-Enhanced Linux) se ejecuta en modo enforcing en todos los dispositivos certificados. SELinux implementa MAC (Mandatory Access Control): incluso si un proceso escala privilegios, las políticas SELinux limitan qué recursos puede acceder. Cada proceso, archivo y socket tiene una etiqueta de contexto de seguridad, y el kernel denota las operaciones no explícitamente permitidas en la política.

Para un pentester, SELinux supone que obtener una shell con privilegios de root mediante un exploit del kernel no garantiza acceso irrestricto: la política SELinux puede seguir bloqueando operaciones críticas. Los dispositivos rooteados suelen desactivar o debilitar SELinux (modo permissive), lo que explica por qué el análisis dinámico en dispositivos rooteados no refleja fielmente el comportamiento en producción.

Trusted Execution Environment y hardware de seguridad

Android soporta TEE (Trusted Execution Environment) mediante el estándar ARM TrustZone. El almacén de claves del sistema (Android Keystore) puede vincular claves criptográficas al hardware, de modo que nunca abandonen el TEE aunque el sistema operativo esté comprometido. Las operaciones criptográficas se realizan dentro del enclave seguro; la clave privada en sí nunca es accesible para el código de usuario.

Desde Android 9, el sistema requiere que las claves de desbloqueo de pantalla se almacenen en el Strongbox Keymaster, un chip de seguridad dedicado separado del SoC principal (presente en dispositivos Pixel 3 en adelante y en los Samsung con chip S3K250AF). Esta arquitectura eleva el coste de ataques de fuerza bruta sobre el PIN incluso con acceso físico al dispositivo.

Arquitectura de seguridad de iOS

Apple diseñó iOS con un modelo de seguridad centralizado en hardware desde el principio, sin la fragmentación de fabricantes que caracteriza a Android. Esto permite garantías más uniformes, pero también significa que los fallos en la capa de Apple afectan a todos los dispositivos simultáneamente.

Sandbox de aplicaciones en iOS

En iOS, cada app vive en su propio contenedor de datos (sandbox) creado en el momento de la instalación. El contenedor incluye directorios predefinidos (Documents, Library, tmp) a los que solo esa app puede acceder. A diferencia de Android, donde las apps pueden compartir datos mediante Content Providers o intents, en iOS el intercambio de datos entre apps requiere mecanismos explícitos y controlados: App Groups (grupos de apps del mismo desarrollador), URL schemes, Universal Links o las extensiones de sistema.

El modelo de permisos de iOS es similar al de Android moderno: los recursos sensibles (cámara, micrófono, localización, contactos, fotos, Bluetooth) requieren autorización explícita del usuario. Desde iOS 14, el sistema muestra un indicador naranja cuando el micrófono está activo y verde cuando la cámara lo está, e iOS 16 añadió una pantalla de Privacy Report que muestra qué apps accedieron a qué datos en los últimos 7 días.

Secure Enclave

El Secure Enclave es un coprocesador dedicado presente en todos los dispositivos Apple con chip A7 o posterior (iPhone 5s en adelante). Funciona como un HSM (Hardware Security Module) embebido con su propio firmware, memoria cifrada y generador de números aleatorios verdadero. El Secure Enclave gestiona:

• Las claves de cifrado del almacenamiento (Data Protection)
• Las claves biométricas de Touch ID y Face ID
• El almacén de claves del Keychain con nivel de protección hardware
• El cifrado de las copias de seguridad

La arquitectura garantiza que ni siquiera iOS en modo kernel pueda acceder directamente al material de clave del Secure Enclave. Apple publica la Apple Platform Security Guide (actualizada anualmente) con el diseño detallado de estos mecanismos; es lectura obligatoria para cualquier auditor de seguridad móvil.

Firma de código y revisión de App Store

iOS implementa firma de código obligatoria a tres niveles. Primero, todas las apps deben estar firmadas por un certificado de Apple (desarrollador o distribución). Segundo, el kernel verifica la firma en tiempo de carga: cualquier página de código ejecutable que no tenga firma válida es rechazada. Tercero, desde iOS 9.0, el sistema obliga a que todas las librerías dinámicas estén firmadas con el mismo equipo que la app (o ser librerías del sistema), cerrando el vector de inyección de dylibos.

El proceso de revisión de App Store añade una capa de detección de malware y de conformidad con las directrices de Apple. Aunque no es infalible (han existido apps maliciosas que superaron la revisión, como el caso de XcodeGhost en 2015, donde más de 4.000 apps fueron recompiladas con un IDE de Xcode troyanizado), el proceso reduce significativamente la superficie de distribución de malware comparado con ecosistemas sin revisión centralizada.

Data Protection y cifrado

iOS utiliza un sistema de cifrado por clases (Data Protection) que vincula el cifrado de cada archivo al estado del dispositivo (bloqueado/desbloqueado) y, opcionalmente, a la biometría o al código de acceso. Las cuatro clases son: Complete Protection (la clave de cifrado del archivo se destruye cuando el dispositivo se bloquea), Protected Unless Open, Protected Until First User Authentication y No Protection. Los datos bancarios y de salud deberían usar siempre Complete Protection; muchas apps, sin embargo, usan clases menos restrictivas por comodidad de uso.

Amenazas reales en el ecosistema móvil

Malware y troyanos bancarios

El malware móvil ha evolucionado desde el adware simple hasta sofisticados troyanos bancarios con capacidades de overlay (superponer pantallas falsas sobre apps reales), interceptación de SMS y autenticación de dos factores, y accesibilidad abusada para realizar operaciones sin intervención del usuario.

Anatsa (también llamado TeaBot) es un troyano bancario para Android que desde 2021 ha atacado a más de 650 aplicaciones bancarias en Europa, Norteamérica y Asia-Pacífico. Su método de distribución incluye apps dropper en Google Play que superan la revisión inicial sin código malicioso y lo descargan en una segunda fase. Anatsa usa el Accessibility Service para grabar pantallas, robar credenciales y realizar transferencias bancarias en segundo plano.

Goldoson es otro ejemplo significativo: en 2023, la empresa de seguridad McAfee descubrió una librería maliciosa integrada en 60 aplicaciones legítimas de Google Play (con más de 100 millones de descargas combinadas) que recopilaba listas de apps instaladas, historial de localización y redes WiFi cercanas.

En iOS, el malware distribuido fuera de la App Store (mediante perfiles MDM o certificados empresariales abusados) ha permitido la distribución de apps espía. El caso más documentado es el de aplicaciones de seguimiento disfrazadas de herramientas para padres que abusan del programa de distribución empresarial de Apple.

Apps maliciosas y repackaging

El repackaging consiste en descompilar una app legítima, inyectarle código malicioso (malware, adware, spyware) y redistribuirla en tiendas de terceros o mediante sideloading. En Android, herramientas como apktool permiten decompilar y recompilar APKs con relativa facilidad; basta con reemplazar la firma original por una nueva para que el sistema la acepte como nueva instalación.

Los mercados alternativos de aplicaciones (APK Mirror, sitios de descarga directa) son el principal vector de distribución de APKs repackageadas. Buena parte de los archivos maliciosos para Android que circulan son variantes repackageadas de apps populares: la app original modificada para incluir código malicioso.

Smishing y phishing móvil

El smishing (SMS phishing) aprovecha la mayor tasa de apertura de los mensajes de texto frente al correo electrónico para distribuir enlaces maliciosos. Las campañas modernas combinan smishing con vishing (llamadas fraudulentas) en ataques de múltiples fases: un SMS simula ser un banco o servicio de paquetería, la víctima llama al número indicado y un operador humano (o una IA generativa) la guía para instalar una app de control remoto.

El phishing móvil también explota la limitada visibilidad de las URLs en navegadores móviles: en Chrome para Android, la barra de direcciones muestra solo el dominio raíz cuando la página está desplazada, ocultando la estructura completa de la URL que delataría el dominio falso.

Ataques MITM en redes WiFi

Los dispositivos móviles se conectan constantemente a redes WiFi desconocidas en hoteles, aeropuertos, cafeterías y centros comerciales. Los ataques de evil twin (punto de acceso falso con el mismo SSID que una red legítima) y las técnicas de deauthentication (desconectar al cliente de la red real para forzar la reconexión a la falsa) siguen siendo efectivos contra clientes sin VPN.

En redes comprometidas, el tráfico HTTP no cifrado es trivialmente interceptable. El tráfico HTTPS es resistente al MITM pasivo, pero si la app no valida correctamente el certificado del servidor (o implementa SSL pinning de forma incorrecta, usando solo el dominio sin anclar el hash del certificado), un atacante con un certificado de CA confiada puede interceptar el tráfico incluso en HTTPS.

Spyware mercenario: el caso Pegasus

Pegasus es el spyware más documentado y técnicamente sofisticado conocido públicamente. Desarrollado por la empresa israelí NSO Group, Pegasus fue identificado por primera vez en 2016 por el Citizen Lab de la Universidad de Toronto y la empresa Lookout, cuando el activista emiratí Ahmed Mansoor recibió un SMS con un enlace que intentaba explotar tres vulnerabilidades de zero-day en iOS (la cadena de exploits fue bautizada Trident; CVE-2016-4655, CVE-2016-4656, CVE-2016-4657).

En 2021, el consorcio de medios Forbidden Stories y Amnesty International publicaron el Pegasus Project: un análisis forense de más de 50.000 números de teléfono seleccionados como objetivos potenciales por clientes de NSO Group, entre los que se encontraban periodistas, activistas, jefes de Estado y empresarios. El análisis técnico de Amnesty International (publicado en el repositorio github.com/AmnestyTech/investigations) describió los indicadores de compromiso y la metodología forense. Apple publicó actualizaciones de seguridad de emergencia en respuesta a los exploits de Pegasus (notablemente FORCEDENTRY, CVE-2021-30860, una vulnerabilidad en el parseador de imágenes CoreGraphics que permitía ejecución de código sin ninguna interacción del usuario).

NSO Group afirma que solo vende Pegasus a gobiernos para combatir el crimen y el terrorismo, pero la investigación independiente ha documentado su uso contra periodistas y disidentes en México, Arabia Saudí, India, Azerbaiyán, Rwanda y otros países. En noviembre de 2021, el Departamento de Comercio de Estados Unidos incluyó a NSO Group en su lista de entidades restringidas.

La metodología forense de Amnesty International para detectar Pegasus, basada en la herramienta MVT (Mobile Verification Toolkit, disponible en github.com/mvt-project/mvt), permite analizar copias de seguridad de iPhone y volcados de Android en busca de indicadores de compromiso conocidos.

Ataques a la cadena de suministro de apps

Los ataques a la cadena de suministro apuntan a las librerías y herramientas de desarrollo que los propios desarrolladores integran en sus apps, comprometiendo el código antes de que llegue a la tienda. El caso XcodeGhost (2015) es el ejemplo canónico en iOS: versiones no oficiales del IDE Xcode de Apple, distribuidas en servidores chinos para acelerar la descarga, incluían código malicioso que se inyectaba en las apps compiladas con ellas. Más de 4.000 apps en la App Store resultaron afectadas, incluyendo WeChat.

En Android, los SDKs de publicidad y analíticas de terceros son un vector frecuente: el SDK integra código que los desarrolladores de la app no han auditado y que puede incluir comportamientos no declarados. El caso Goldoson mencionado anteriormente es un ejemplo de SDK malicioso integrado en apps legítimas.

El marco OWASP Mobile: MASVS, MASTG y Mobile Top 10

OWASP (Open Web Application Security Project) mantiene el marco de referencia más utilizado en la industria para la seguridad de aplicaciones móviles. El marco consta de tres documentos complementarios.

OWASP MASVS (Mobile Application Security Verification Standard)

El MASVS es el estándar de requisitos de seguridad para aplicaciones móviles. En su versión actual (MASVS v2.0, publicada en marzo de 2023 en mas.owasp.org/MASVS/), el estándar se organiza en cinco categorías de controles:

• MASVS-STORAGE: almacenamiento seguro de datos sensibles en el dispositivo.
• MASVS-CRYPTO: uso correcto de criptografía.
• MASVS-AUTH: autenticación y gestión de sesiones.
• MASVS-NETWORK: comunicaciones de red seguras.
• MASVS-PLATFORM: uso seguro de las APIs de la plataforma.
• MASVS-CODE: calidad y resiliencia del código.
• MASVS-RESILIENCE: resistencia a la ingeniería inversa y manipulación.

La v2.0 simplificó la estructura respecto a la v1.x (que definía tres niveles L1/L2/R) al enfocarse en controles concretos y verificables, mejorando la trazabilidad con el MASTG.

OWASP MASTG (Mobile Application Security Testing Guide)

El MASTG (anteriormente MSTG, Mobile Security Testing Guide) es la guía técnica de pruebas que complementa el MASVS. Disponible en mas.owasp.org/MASTG/, el MASTG describe cómo verificar cada control del MASVS con técnicas de análisis estático y dinámico para Android e iOS. Incluye casos de prueba concretos con comandos y herramientas específicas (Frida, objection, apktool, jadx, MobSF, Burp Suite, entre otras).

Desde 2024, el MASTG ha migrado a un formato modular donde cada «test» es un documento independiente enlazado a uno o más controles del MASVS, facilitando su uso como referencia puntual sin tener que leer el documento completo. La comunidad OWASP MAS (Mobile Application Security) mantiene activamente ambos documentos.

OWASP Mobile Top 10

El OWASP Mobile Top 10 lista los riesgos de seguridad más críticos en aplicaciones móviles. La versión actual es la de 2024 (owasp.org/www-project-mobile-top-10/), una actualización significativa respecto a la lista de 2016 que refleja la evolución del panorama de amenazas:

1. M1 – Uso inadecuado de credenciales: claves de API, contraseñas y tokens embebidos en código o recursos.
2. M2 – Fallos en la cadena de suministro: SDKs, librerías y dependencias maliciosas o desactualizadas.
3. M3 – Autenticación/Autorización insegura: lógica de autenticación defectuosa, tokens sin expiración, ausencia de controles de autorización en el backend.
4. M4 – Validación de entrada/salida insuficiente: inyecciones SQL, XSS en WebViews, deserialización insegura.
5. M5 – Comunicación insegura: tráfico en claro, validación de certificados incorrecta, SSL pinning ausente en datos críticos.
6. M6 – Controles de privacidad inadecuados: recopilación excesiva de datos, registro en logs de datos sensibles.
7. M7 – Protecciones binarias insuficientes: ausencia de ofuscación, detección de root/jailbreak o anti-tampering.
8. M8 – Fallos de configuración de seguridad: permisos Android excesivos, configuración de red insegura, backups habilitados para datos sensibles.
9. M9 – Almacenamiento de datos inseguro: datos sensibles en SharedPreferences sin cifrar, bases de datos SQLite accesibles, archivos en almacenamiento externo.
10. M10 – Criptografía insuficiente: algoritmos débiles (MD5, SHA-1, DES), claves hardcodeadas, IVs estáticos.

La lista 2024 refleja el creciente peso de los riesgos de cadena de suministro (ahora en el segundo puesto) y de privacidad (nuevo en la lista), alineándose con regulaciones como el RGPD y la ePrivacy Directive.

Pentesting de aplicaciones móviles: técnicas y herramientas

El pentesting de apps móviles combina análisis estático (sin ejecutar el código) y dinámico (con la app en ejecución). Ambas técnicas son complementarias: el análisis estático revela problemas estructurales que el análisis dinámico puede no exponer, mientras que el análisis dinámico detecta comportamientos en tiempo real que el código ofuscado ocultaría al análisis estático.

Análisis estático de APKs e IPAs

El análisis estático comienza con la obtención del binario de la app. En Android, la APK puede extraerse del dispositivo mediante adb pull o descargarse de servicios como APKPure (para testing en laboratorio). Una APK es un archivo ZIP que contiene el bytecode Dalvik (classes.dex), los recursos, el manifiesto y las firmas.

La herramienta jadx (Java Decompiler for Android) convierte el bytecode Dalvik a código Java legible, permitiendo revisar la lógica de la aplicación. apktool permite decompilar los recursos y el manifiesto a formato legible y recompilar la APK tras modificaciones.

En iOS, el binario de una IPA (iPhone Package Archive) es un ejecutable Mach-O compilado para ARM. La herramienta class-dump extrae las interfaces de clases de Objective-C; para Swift, swift-demangle decodifica los nombres mangleados. El análisis de binarios iOS requiere un entorno macOS o herramientas como jtool2 en Linux.

Los puntos clave del análisis estático son:

• Permisos en AndroidManifest.xml (Android) o Info.plist (iOS)
• Claves de API, credenciales y secretos hardcodeados (grep por patrones como password, secret, api_key, Bearer)
• URLs de endpoints (identifican la superficie de ataque del backend)
• Uso de algoritmos criptográficos débiles
• Validación de certificados (búsqueda de onReceivedSslError en Android, NSURLSession con NSURLConnectionDelegate inseguro en iOS)
• Exportación de componentes Android (android:exported="true" sin protección de permisos)
• Configuración de red (Network Security Config en Android; ATS en iOS)

MobSF: análisis automatizado

MobSF (Mobile Security Framework, disponible en github.com/MobSF/Mobile-Security-Framework-MobSF) es un framework de código abierto que automatiza el análisis estático y dinámico de APKs, IPAs y APPXs (Windows). Proporciona una interfaz web donde se sube el binario y recibe un informe detallado con:

• Puntuación de seguridad global
• Análisis del manifiesto (Android) o Info.plist (iOS)
• Búsqueda de patrones de código inseguros
• Análisis de librerías de terceros
• Resultados de VirusTotal (opcional)
• Flujo de análisis dinámico con Frida (en la instalación completa con emulador)

MobSF es la herramienta de entrada estándar en auditorías de apps móviles: su informe automatizado identifica los problemas más comunes en minutos y orienta el análisis manual posterior.

Frida: instrumentación dinámica

Frida (frida.re) es el framework de instrumentación dinámica de referencia en pentesting móvil. Permite inyectar código JavaScript en procesos en ejecución para interceptar llamadas a funciones, modificar el comportamiento de la app y extraer datos en tiempo real, sin necesidad de modificar el binario.

Frida opera en varios modos: injected (requiere root en Android o jailbreak en iOS), embedded (el servidor de Frida se compila dentro de la app, útil para testing sin root), y gadget (librería inyectada mediante repackaging). El uso típico en pentesting:

• Hooking de métodos criptográficos para capturar claves en memoria
• Bypass de detección de root/jailbreak
• Bypass de SSL pinning
• Enumeración de clases y métodos en tiempo de ejecución
• Modificación de valores de retorno para bypass de controles

Un ejemplo de script Frida para bypass de SSL pinning en Android con OkHttp:

Java.perform(function() {
  var OkHttpClient = Java.use('okhttp3.OkHttpClient$Builder');
  OkHttpClient.hostnameVerifier.overload(
    'javax.net.ssl.HostnameVerifier'
  ).implementation = function(verifier) {
    return this.hostnameVerifier(new AlwaysAllowHostnameVerifier());
  };
});

Objection: shell de pentesting basada en Frida

Objection (github.com/sensepost/objection) es una herramienta de pentesting móvil construida sobre Frida que proporciona una shell interactiva con comandos de alto nivel para las operaciones más comunes en auditorías:

• android sslpinning disable / ios sslpinning disable: bypass automático de SSL pinning
• android root disable: bypass de detección de root
• android hooking list classes: enumerar clases cargadas
• android hooking watch class_method: interceptar un método específico
• ios keychain dump: volcar el contenido del Keychain de iOS
• ios filesystem ls: explorar el sandbox de la app en iOS

Objection reduce significativamente el tiempo de configuración en auditorías repetitivas, aunque para casos avanzados o apps con detección de instrumentación, se requiere scripting directo con Frida.

Dispositivos rooteados/con jailbreak para análisis dinámico

El análisis dinámico avanzado requiere acceso privilegiado al dispositivo. En Android, el rooting proporciona acceso de superusuario al sistema operativo; en iOS, el jailbreak elimina las restricciones de firma de código y acceso al sistema de archivos.

Para Android, las opciones más utilizadas en laboratorio son Magisk (permite root sin modificar la partición del sistema, con soporte para MagiskHide para evadir la detección de root) en dispositivos físicos, o el Android Emulator de AOSP (con Google Play Edition para apps que requieren GMS). Genymotion es otra opción popular de emulación.

Para iOS, los jailbreaks actuales más utilizados en pentesting son checkra1n (basado en el exploit checkm8, permanente en hardware A5-A11, disponible hasta iPhone X) y palera1n (sucesor de checkra1n, compatible hasta A17). Para dispositivos con chip A12 o superior sin exploit de bootrom permanente, los jailbreaks modernos como Dopamine requieren una versión específica de iOS.

Importante: el análisis en dispositivos rooteados no debe utilizarse como representativo del entorno de usuario final para todas las pruebas, especialmente las relacionadas con MASVS-RESILIENCE (controles anti-tampering). Las pruebas de robustez deben realizarse en dispositivos no modificados siempre que sea posible.

Interceptación de tráfico con Burp Suite y bypass de SSL pinning

La interceptación del tráfico de red entre la app y su backend es fundamental en cualquier auditoría. El flujo estándar es:

1. Configurar Burp Suite (o mitmproxy, ZAP) como proxy HTTP/HTTPS.
2. Instalar el certificado de CA del proxy en el dispositivo o emulador.
3. Configurar el proxy del dispositivo para apuntar a Burp.
4. Observar y manipular el tráfico en Burp.

El obstáculo principal es el SSL pinning: la app valida que el certificado del servidor coincide con un certificado o clave pública embebidos, rechazando el certificado del proxy aunque esté instalado como CA de confianza en el sistema. Las técnicas de bypass incluyen:

• Frida/objection: hooking de las funciones de validación de certificados en tiempo de ejecución (el método más universal y menos intrusivo).
• Repackaging: decompilar la APK, modificar el código que implementa el pinning y recompilar. Requiere habilidades de reversing.
• Patches del sistema: en Android ≥7.0, la Network Security Config permite añadir CAs de usuario para apps específicas si se modifica el network_security_config.xml.
• Patches de librería: para apps que usan TrustKit (iOS/Android) o certificate pinning mediante la Android Keystore, se requieren técnicas específicas.

Para el análisis de tráfico no HTTP (protocolos binarios, WebSocket, gRPC), herramientas como tcpdump en el dispositivo rooteado y Wireshark en el PC analizador son más apropiadas.

Seguridad móvil en la empresa

MDM y MAM: gestión de dispositivos y aplicaciones

Las organizaciones gestionan la seguridad de dispositivos móviles corporativos y BYOD mediante dos capas complementarias: MDM (Mobile Device Management) y MAM (Mobile Application Management).

MDM gestiona el dispositivo completo. Permite al equipo de TI aplicar políticas de configuración (PIN mínimo, cifrado obligatorio, restricción de cámara), distribuir apps corporativas, enviar comandos remotos (bloqueo, borrado completo) y supervisar el inventario de dispositivos. Los protocolos MDM más comunes son el protocolo MDM de Apple (para iOS/macOS), el Android Management API de Google (para Android Enterprise), y estándares como OMA-DM.

Las plataformas MDM más extendidas en el mercado empresarial son Microsoft Intune, VMware Workspace ONE (anteriormente AirWatch), Jamf Pro (especializado en Apple) y MobileIron (ahora parte de Ivanti). Todas permiten integración con Azure AD / Entra ID para el modelo Zero Trust.

MAM opera a nivel de aplicación en lugar del dispositivo. Es particularmente útil en escenarios BYOD donde la organización no tiene (ni quiere tener) control total del dispositivo personal del empleado. Con MAM, solo las apps corporativas están gestionadas: se pueden aplicar políticas de acceso, cifrado a nivel de app, prevención de copiar/pegar entre apps corporativas y personales, y borrado selectivo de solo los datos corporativos (en lugar de un borrado completo del dispositivo).

BYOD y contenedorización

El modelo BYOD plantea un equilibrio delicado entre la seguridad corporativa y la privacidad del empleado. La solución técnica estándar es la contenedorización: separar el espacio de trabajo corporativo del personal dentro del mismo dispositivo.

En Android, Android Enterprise Work Profile proporciona esta separación a nivel de sistema operativo: las apps corporativas viven en un perfil separado con su propio sandbox, iconos con insignia (badge), almacenamiento independiente y políticas gestionadas por MDM. El usuario puede ver las notificaciones de ambos perfiles, pero las apps del perfil personal no pueden acceder a los datos del perfil corporativo y viceversa. El empleado puede desactivar el perfil de trabajo sin perder datos personales; la empresa puede borrarlo sin tocar lo personal.

En iOS, la separación no es tan nativa a nivel de sistema operativo, pero las capacidades de gestión de iOS 16 y posteriores permiten a MDM gestionar cuentas gestionadas separadas. Apps de contenedores de terceros como VMware Boxer o Microsoft Outlook (con políticas Intune MAM) implementan su propio sandbox a nivel de aplicación.

Zero Trust en dispositivos móviles

El modelo Zero Trust («nunca confíes, siempre verifica») es especialmente relevante en contextos de dispositivos móviles, donde el perímetro de red corporativo es inexistente. Los pilares de Zero Trust aplicados a dispositivos móviles son:

• Identidad: autenticación multifactor obligatoria para acceder a recursos corporativos. La biometría del dispositivo puede usarse como primer factor si la política MDM la valida.
• Dispositivo: el estado del dispositivo (cumplimiento de políticas, ausencia de jailbreak/root, versión de SO actualizada) determina el nivel de acceso. Un dispositivo no conforme puede ser bloqueado o redirigido a recursos de remediación.
• Red: el acceso a recursos corporativos se realiza mediante VPN de aplicación (per-app VPN) o acceso a aplicaciones de red (ZTNA, Zero Trust Network Access) sin exponer la red interna completa.
• Sesión: el acceso se reevalúa continuamente, no solo en el momento de la autenticación inicial.

Microsoft Entra ID con Intune y Conditional Access, y Google BeyondCorp Enterprise, son las implementaciones de referencia de Zero Trust que incluyen soporte nativo para dispositivos móviles.

Privacidad y buenas prácticas para el usuario

La seguridad móvil no es solo responsabilidad de los desarrolladores y equipos de TI. Los usuarios también tienen un papel activo en la reducción de su superficie de ataque.

Actualizaciones del sistema operativo y aplicaciones

La recomendación más impactante y menos costosa es mantener el sistema operativo y las aplicaciones actualizados. La mayoría de los exploits utilizados por malware real atacan vulnerabilidades con parche disponible: el tiempo entre la publicación del parche y su explotación activa se ha reducido significativamente, en algunos casos a días o incluso horas (un fenómeno documentado por Google Project Zero en su análisis de in-the-wild exploits). En iOS, las actualizaciones se instalan directamente desde Apple; en Android, la fragmentación del ecosistema hace que muchos dispositivos tarden semanas o meses en recibir actualizaciones de seguridad del fabricante.

Gestión de permisos

Los usuarios deben revisar periódicamente qué permisos han concedido a cada app. En iOS, esto se hace en Ajustes → Privacidad y seguridad; en Android, en Ajustes → Privacidad → Gestor de permisos. La regla práctica: si no entiendes por qué una app necesita un permiso concreto, no lo concedas. Una app de calculadora no necesita acceso a la ubicación.

Tanto Android como iOS permiten conceder acceso a la ubicación solo mientras la app está en primer plano (While using), o incluso solo una vez (Ask each time). Esta opción debe preferirse siempre que sea compatible con el uso legítimo de la app.

Instalación de apps: tiendas oficiales y fuentes de confianza

Instalar apps únicamente desde Google Play Store y App Store (iOS) reduce significativamente el riesgo de malware. En Android, la opción «Instalar apps de fuentes desconocidas» debe estar deshabilitada salvo para casos de uso muy específicos en los que el usuario entiende el riesgo. Las APKs descargadas de sitios de terceros (aunque sean versiones de apps conocidas) pueden haber sido repackageadas con malware.

Redes WiFi y VPN

Evitar conectarse a redes WiFi abiertas sin VPN. Si es inevitable, usar siempre una VPN de confianza (proveedores como Mullvad, ProtonVPN o una VPN corporativa) que cifre todo el tráfico antes de que salga del dispositivo. Los dispositivos iOS y Android soportan nativa o mediante configuración MDM la activación automática de VPN al conectarse a redes no confiables.

Autenticación multifactor y gestores de contraseñas

Habilitar la autenticación multifactor (MFA) en todas las cuentas importantes. Para el factor TOTP (Time-based One-Time Password), usar una app de autenticación (Google Authenticator, Authy, Microsoft Authenticator) en lugar de SMS, que es vulnerable a ataques de SIM swapping. Los gestores de contraseñas (Bitwarden, 1Password, el Keychain nativo de iOS, Autofill de Google) reducen el riesgo de reutilización de contraseñas y el phishing de credenciales.

Cifrado y copias de seguridad

Activar el cifrado del dispositivo (habilitado por defecto en iOS desde el iPhone 3GS con código de acceso; en Android desde la versión 5.0 en adelante en dispositivos nuevos) y protegerlo con un PIN o contraseña de al menos 6 dígitos. Evitar patrones de desbloqueo (son predecibles y dejan rastros visibles en la pantalla). Cifrar las copias de seguridad en iCloud o Google Drive: en iOS, la opción de «Advanced Data Protection» (disponible desde iOS 16.2 en países soportados) cifra end-to-end la mayoría de los datos de iCloud, de modo que ni Apple puede acceder a ellos.

Herramientas del auditor: resumen de toolkit

Un pentester de apps móviles necesita un conjunto de herramientas bien integradas. El toolkit estándar incluye:

Entorno de análisis

• Android Studio + Emulador: entorno de desarrollo y emulación para Android (la imagen del emulador de Google APIs soporta root y Frida sin dispositivo físico).
• Xcode + Simulador de iOS: disponible solo en macOS; el simulador no tiene Secure Enclave real pero permite análisis de comportamiento de apps.
• Genymotion: emulador Android de pago con mejores capacidades de red que el emulador de stock.

Análisis estático

• jadx: decompilador de APK a Java/Kotlin.
• apktool: disassembler/reassembler de APKs.
• dex2jar: conversión de .dex a .jar para su análisis con jd-gui.
• class-dump / jtool2: extracción de interfaces en iOS Mach-O.
• MobSF: análisis automatizado estático y dinámico.
• semgrep: análisis estático de código fuente con reglas para Android/iOS.

Análisis dinámico

• Frida: instrumentación dinámica, hooking de funciones.
• Objection: shell de pentesting sobre Frida.
• Burp Suite / mitmproxy: intercepción de tráfico HTTP/HTTPS.
• adb (Android Debug Bridge): acceso a dispositivos/emuladores Android (logcat, shell, file transfer, port forwarding).
• db Browser for SQLite: inspección de bases de datos de apps.
• strings / rabin2 (radare2): extracción de cadenas y análisis de binarios.

Forense e IOC

• MVT (Mobile Verification Toolkit): detección de indicadores de compromiso de spyware (Pegasus, Predator).
• Autopsy / Cellebrite UFED: análisis forense de dispositivos móviles.
• iLEAP: análisis de copias de seguridad de iOS.

Laboratorio de práctica recomendado

Para desarrollar habilidades de pentesting móvil sin necesidad de apps reales de terceros, existen aplicaciones vulnerables diseñadas para el aprendizaje:

• DVIA-v2 (Damn Vulnerable iOS Application v2): app iOS con vulnerabilidades intencionadas cubriendo la mayoría de los controles del MASVS.
• InsecureShop: app Android de tienda online intencionalmente insegura.
• DVSA (Damn Vulnerable Android App): Android equivalente de DVWA para web.
• GoatDroid y HackMe Bank: apps bancarias vulnerables para Android.
• InjuredAndroid: app de CTF con 18 vulnerabilidades en nivel progresivo.

Las plataformas de entrenamiento como las mejores plataformas para practicar hacking incluyen retos de pentesting móvil en entornos controlados.

Seguridad móvil en el ciclo de desarrollo (DevSecOps)

Integrar la seguridad desde las primeras fases del desarrollo de apps móviles reduce drásticamente el coste de corrección de vulnerabilidades. Los principios clave son:

Threat modeling en el diseño

Antes de escribir una línea de código, identificar qué datos maneja la app, quién los accede, cuáles son los flujos de datos y qué ocurre si un atacante compromete cada componente. El marco STRIDE (Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, Elevation of Privilege) es aplicable a componentes móviles.

Seguridad en el almacenamiento de datos

Una de las vulnerabilidades más frecuentes en apps móviles es el almacenamiento de datos sensibles en ubicaciones inseguras. En Android, las opciones seguras son el Android Keystore (para claves criptográficas), EncryptedSharedPreferences (para preferencias sensibles, disponible en Jetpack Security) y Room con cifrado SQLCipher (para bases de datos). Los datos en almacenamiento externo, logs de sistema o archivos de caché son accesibles para otras apps y no deben contener información sensible.

En iOS, el Keychain es el almacén seguro recomendado para credenciales, tokens y claves. La clase de protección debe ser kSecAttrAccessibleWhenUnlockedThisDeviceOnly para datos que no deben sincronizarse ni sobrevivir a restauraciones. Los datos en NSUserDefaults no están cifrados y no son apropiados para información sensible.

Seguridad de la comunicación de red

Las apps deben usar TLS 1.2 o superior para todas las comunicaciones de red. Android 9.0 y superiores bloquean tráfico HTTP en claro por defecto (Network Security Config). iOS aplica App Transport Security (ATS) que requiere HTTPS con TLS 1.2 o superior desde iOS 9.

El SSL pinning debe implementarse para apps de alto riesgo (bancarias, gubernamentales, de salud), anclando el hash de la clave pública del certificado del servidor (más robusto que anclar el certificado completo, que requiere actualizar el pin con cada renovación del certificado). La implementación debe incluir un pin de respaldo y un mecanismo de actualización out-of-band.

Integración en CI/CD

El análisis estático automatizado puede integrarse en pipelines de CI/CD mediante herramientas como MobSF en modo CLI, semgrep con reglas para Android/iOS o Checkmarx SAST Mobile. Estos análisis automáticos detectan problemas comunes sin interrumpir el flujo de desarrollo; las vulnerabilidades más complejas requieren revisión manual.

Cómo formarse y certificarse en seguridad móvil

La demanda de profesionales con habilidades de pentesting móvil y desarrollo seguro de apps supera la oferta. Las certificaciones especializadas validan competencias en este dominio.

eMAPT (eLearnSecurity Mobile Application Penetration Tester)

La certificación eMAPT, ofrecida por INE Security (anteriormente eLearnSecurity), es una de las pocas certificaciones prácticas de pentesting móvil disponibles. Evalúa al candidato mediante un examen completamente práctico de 7 días en el que debe auditar aplicaciones Android e iOS en un entorno de laboratorio controlado y redactar un informe profesional.

El temario cubre análisis estático y dinámico de APKs e IPAs, uso de Frida/objection para bypass de controles de seguridad, interceptación de tráfico, bypass de SSL pinning, ingeniería inversa de apps Android, y exploración de vulnerabilidades del OWASP Mobile Top 10. La certificación no requiere experiencia previa formal, pero se recomienda conocimiento sólido de Android/iOS antes de intentarla. Más información en ine.com/certifications/emapt-certification.

En el sitio encontrarás también nuestra guía de recursos para preparar certificaciones de pentesting con contexto adicional para estructurar tu preparación.

GMOB (GIAC Mobile Device Security Analyst)

La certificación GMOB de GIAC (Global Information Assurance Certification) es la certificación de seguridad móvil del catálogo GIAC/SANS. Cubre seguridad de plataformas Android e iOS, análisis forense de dispositivos móviles, gestión corporativa de dispositivos (MDM/MAM), análisis de aplicaciones y respuesta a incidentes en entornos móviles.

El examen GMOB es un examen de libro abierto de 75 preguntas en 2 horas, con una puntuación de aprobado de 70 %. La preparación recomendada es el curso SANS SEC575 (Mobile Device Security and Ethical Hacking), aunque no es obligatorio. La certificación es especialmente valiosa para perfiles defensivos (blue team, forense móvil, gestión de MDM corporativo). Más información en giac.org/certifications/mobile-device-security-analyst-gmob/.

Puedes complementar tu ruta con nuestra comparativa de las mejores certificaciones GIAC y el mapa de certificaciones de seguridad para ver dónde encajan eMAPT y GMOB en tu itinerario.

Otras rutas de formación

El punto de partida en ciberseguridad para quien quiere especializarse en seguridad móvil debería incluir:

1. Fundamentos de redes y sistemas operativos (preferiblemente con Security+ o eJPT).
2. Desarrollo básico en Java/Kotlin (para entender el código Android) y Swift/Objective-C o al menos capacidad de leer código iOS.
3. Familiaridad con el shell de Linux y herramientas de red (Wireshark, tcpdump).
4. El MASTG de OWASP como referencia técnica de lecturas.
5. Práctica con apps vulnerables (DVIA, InjuredAndroid, InsecureShop) antes de intentar la eMAPT.

Recursos de aprendizaje online: el curso Android Application Penetration Testing de TCM Security (accesible desde la plataforma de The Cyber Mentor) y el curso gratuito de MASTG preparado por la propia OWASP MAS Community son excelentes puntos de entrada sin coste. Las técnicas de hacking web son también relevantes, ya que muchas apps móviles son wrappers de APIs web que comparten las mismas vulnerabilidades de backend.

Análisis forense de dispositivos móviles

La respuesta a incidentes que involucran dispositivos móviles requiere técnicas de forense específicas, distintas al forense tradicional de sistemas de escritorio. Las consideraciones principales son:

Preservación de la evidencia

El primer principio del forense móvil es evitar la modificación del dispositivo. Esto implica aislar el dispositivo de redes móviles y WiFi (para prevenir borrado remoto o actualizaciones) mediante una jaula de Faraday o poniendo el dispositivo en modo avión. Conectar el dispositivo a un equipo de extracción antes de que la batería se agote: algunos dispositivos con biometría de iOS solo permiten acceso por PIN tras un reinicio, un período prolongado sin uso o múltiples intentos fallidos.

Tipos de adquisición

Existen cuatro niveles de adquisición de datos de un dispositivo móvil, de menor a mayor profundidad:

• Forense de backup: análisis de la copia de seguridad del dispositivo (iTunes/iCloud para iOS, adb backup para Android). No requiere acceso físico al dispositivo desbloqueado, pero es incompleto: no incluye todos los archivos del sistema.
• Adquisición lógica: acceso a los datos del sistema de archivos del dispositivo mediante protocolos de sincronización (AFC en iOS, MTP/ADB en Android). Más completa que el backup, pero limitada al sistema de archivos accesible sin privilegios.
• Adquisición del sistema de archivos: copia completa del sistema de archivos, requiere acceso root o jailbreak. Incluye bases de datos de apps, caches, archivos de preferencias y datos del sistema.
• Adquisición física: imagen bit a bit del almacenamiento flash del dispositivo. Permite recuperar archivos eliminados mediante análisis de espacio no asignado. Requiere herramientas especializadas como Cellebrite UFED o Magnet AXIOM, o técnicas de JTAG/chip-off en casos extremos.

En iOS, el cifrado por hardware (Data Protection) hace que la adquisición física de un dispositivo bloqueado con código de acceso desconocido sea prácticamente inútil: los datos cifrados son ilegibles sin las claves derivadas del PIN. Este es el mismo fundamento técnico del debate legal entre Apple y el FBI en el caso del iPhone 5C del tirador de San Bernardino (2015-2016).

Herramientas forenses

Las herramientas forenses de referencia para dispositivos móviles son Cellebrite UFED (hardware y software, con soporte para miles de modelos de dispositivos) y Magnet AXIOM Cyber (análisis de artefactos de iOS, Android, y nube). Ambas son herramientas comerciales de alto coste usadas principalmente en entornos gubernamentales y de grandes corporaciones.

En el ámbito open-source, Autopsy con módulos móviles y MVT (para IOC de spyware) cubren casos de uso más específicos. La guía de análisis forense digital cubre el marco metodológico completo que aplica también al forense móvil.

Tendencias emergentes en seguridad móvil

IA en el dispositivo y sus riesgos

La ejecución de modelos de lenguaje y visión directamente en los dispositivos (Apple Intelligence en iOS 18, Google Gemini Nano en Pixel 9) introduce nuevas superficies de ataque. Los ataques de prompt injection a través de imágenes o documentos que la IA procesa, la extracción de datos sensibles del contexto de la IA (que accede a correos, mensajes y calendarios), y el riesgo de que la IA ejecute acciones no deseadas (auto-fill de formularios, borrado de archivos por instrucción de contenido malicioso) son vectores que la industria está comenzando a estudiar.

Spyware comercial más allá de Pegasus

Pegasus no es el único spyware mercenario documentado. Predator (desarrollado por el consorcio Intellexa, que incluye a la empresa griega Cytrox) fue analizado por Citizen Lab en 2022 y 2023, revelando capacidades similares a Pegasus con explotación de vulnerabilidades zero-day en iOS y Android. Hermit, documentado por Lookout y Google TAG en 2022, fue utilizado por actores gubernamentales en Italia y Kazajistán. El ecosistema de spyware mercenario es más amplio y activo de lo que los titulares sobre Pegasus sugieren.

Ataques a eSIM y SIM Swapping

La migración masiva a eSIM (SIM embebida, sin tarjeta física) introduce nuevos vectores: el proceso de activación de eSIM a través de QR codes o portales web de operadoras puede ser vulnerado mediante phishing a empleados de la operadora o explotación de APIs de gestión de eSIM. El SIM swapping (convencer a un agente de la operadora de transferir el número a una SIM del atacante) sigue siendo un vector efectivo para comprometer cuentas protegidas solo con SMS-OTP.

Preguntas frecuentes sobre seguridad móvil

¿Es iOS más seguro que Android?

iOS tiene un modelo de seguridad más uniforme gracias al control vertical de Apple sobre hardware y software, y la App Store reduce significativamente la distribución de malware. Sin embargo, iOS no es inmune: los exploits de zero-click para iOS (como FORCEDENTRY de Pegasus) han demostrado que un sistema unificado y de alto valor es un objetivo atractivo para atacantes con recursos. En la práctica, para usuarios promedio, iOS presenta menos riesgo de malware; para objetivos de alto valor de grupos de espionaje estatal, ambas plataformas son vulnerables si el atacante tiene recursos suficientes.

¿Qué es el SSL pinning y por qué es importante?

El SSL pinning (también llamado certificate pinning o public key pinning) es una técnica por la que la app verifica que el certificado del servidor con el que se comunica coincide con un certificado o clave pública previamente conocida y embebida en la app. Sin pinning, cualquier CA del sistema confiada (incluyendo la de un proxy de auditoría o de un atacante MITM) puede interceptar el tráfico HTTPS. Con pinning, aunque el atacante tenga una CA confiada por el sistema, no puede presentar un certificado válido para el servidor que pase la validación de la app.

¿Qué significa rootear un dispositivo Android y qué riesgos tiene?

Rootear un dispositivo Android consiste en obtener acceso de superusuario (root) al sistema operativo, permitiendo acciones que el sistema normalmente bloquea. En dispositivos rooteados, las protecciones de seguridad del sistema se debilitan: SELinux puede pasar a modo permissive, las particiones del sistema son modificables, y las apps con permisos de root pueden acceder a los datos de cualquier otra app. En términos prácticos, rootear un dispositivo personal anula casi todas las garantías de seguridad del modelo de sandbox de Android y puede invalidar la garantía del fabricante. Solo se recomienda en dispositivos dedicados a laboratorio de seguridad.

¿Qué es MASVS y en qué se diferencia del MASTG?

MASVS (Mobile Application Security Verification Standard) es el estándar de requisitos: define QUÉ controles de seguridad debe tener una app móvil. MASTG (Mobile Application Security Testing Guide) es la guía de pruebas: describe CÓMO verificar que esos controles están implementados correctamente, con técnicas concretas, herramientas y comandos de ejemplo. MASVS se usa para definir el alcance de una auditoría; MASTG se usa durante la ejecución de la auditoría. Ambos son documentos gratuitos y de código abierto mantenidos por la comunidad OWASP MAS.

¿Cómo se protege una empresa cuyo modelo es BYOD?

La estrategia más efectiva para BYOD combina: MDM/MAM (para gestionar y aislar las apps corporativas del resto del dispositivo), Zero Trust Network Access (para que el acceso a sistemas internos no dependa de la red ni de la confianza implícita en el dispositivo), MFA robusto (no SMS-OTP, sino TOTP o FIDO2) para acceder a cualquier recurso corporativo, y políticas claras de uso aceptable que el empleado comprenda. El MDM solo debe aplicar políticas sobre el perfil corporativo (Work Profile en Android), nunca sobre los datos personales del empleado.

¿Qué herramienta uso si sospecho que mi teléfono tiene spyware tipo Pegasus?

La herramienta más accesible para un análisis inicial es MVT (Mobile Verification Toolkit) de Amnesty International (github.com/mvt-project/mvt). Para iOS, analiza copias de seguridad de iTunes o el sistema de archivos completo (requiere jailbreak) en busca de IOCs de Pegasus y otros spywares conocidos. Para Android, analiza el APK instalado y los logs del dispositivo. Es importante entender que MVT detecta IOCs conocidos; el spyware nuevo sin IOCs documentados no será detectado por ninguna herramienta automatizada. Ante sospecha seria, la consulta con un laboratorio forense especializado como Citizen Lab o Access Now es la recomendación más sólida.

¿Es necesario un antivirus en el móvil?

En iOS, los antivirus son en gran medida inefectivos porque el sandbox impide que una app de terceros analice otras apps. En Android con apps solo de Google Play, las capacidades de Play Protect son comparables o superiores a la mayoría de antivirus de terceros para la detección de malware convencional. Los antivirus móviles aportan valor principalmente como capas adicionales de detección en entornos corporativos con MDM, o en dispositivos que instalan apps de fuentes no controladas. Para el usuario doméstico con buenos hábitos de instalación, su impacto es marginal.

¿Qué diferencia hay entre MDM y MAM?

MDM (Mobile Device Management) gestiona el dispositivo completo: puede borrar, bloquear, configurar y supervisar todo el teléfono. Es apropiado para dispositivos propiedad de la empresa. MAM (Mobile Application Management) gestiona solo las aplicaciones corporativas: aplica políticas de acceso, cifrado y prevención de fugas de datos a nivel de app, sin necesidad de controlar el dispositivo completo. Es la solución apropiada para BYOD, donde el empleado retiene el control de su dispositivo personal mientras la empresa gestiona sus propias apps.

¿Qué hace un pentester de apps móviles en un día de trabajo?

Un día típico de auditoría de seguridad de una app móvil comienza con la instalación y primer análisis con MobSF para obtener un panorama rápido. Continúa con la revisión manual del manifiesto (Android) o Info.plist (iOS), la decompilación con jadx/class-dump para buscar secretos hardcodeados y lógica de autenticación, la configuración del proxy Burp con bypass de SSL pinning mediante Frida/objection, y la revisión del tráfico de red en busca de datos sensibles en tránsito. A mitad de jornada, el pentester suele dedicar tiempo a probar la lógica de autenticación y autorización tanto en la app como en el backend. El día termina documentando los hallazgos con capturas de pantalla y evidencias para el informe.

Recursos adicionales y lectura recomendada

Para profundizar en los temas tratados en esta guía, estos son los recursos de referencia:

• OWASP Mobile Application Security (mas.owasp.org): portal central del MASVS y MASTG, con todos los documentos actualizados.
• Apple Platform Security Guide: documentación oficial de Apple sobre la arquitectura de seguridad de iOS/iPadOS/macOS.
• Android Security: documentación oficial de Google sobre el modelo de seguridad de Android.
• Citizen Lab Targeted Threats Research: informes técnicos sobre spyware mercenario y vigilancia digital.
• NIST SP 800-124: Guidelines for Managing the Security of Mobile Devices in the Enterprise.

Si tu objetivo es el trabajo en seguridad móvil como profesión, el catálogo completo de cursos y certificaciones del sitio incluye las rutas más rentables del sector. Para un análisis comparativo de todas las opciones de carrera, el mapa de certificaciones de seguridad es el punto de referencia visual que te permite ver de un vistazo las opciones según nivel y especialidad.