Pentesting de Aplicaciones Android

Tip

Aprende y practica Hacking en AWS:HackTricks Training AWS Red Team Expert (ARTE)
Aprende y practica Hacking en GCP: HackTricks Training GCP Red Team Expert (GRTE) Aprende y practica Hacking en Azure: HackTricks Training Azure Red Team Expert (AzRTE)

Apoya a HackTricks

Conceptos básicos de aplicaciones Android

Se recomienda encarecidamente empezar leyendo esta página para conocer las partes más importantes relacionadas con la seguridad de Android y los componentes más peligrosos en una aplicación Android:

Android Applications Basics

ADB (Android Debug Bridge)

Esta es la herramienta principal que necesitas para conectar con un dispositivo Android (emulado o físico).
ADB permite controlar dispositivos ya sea por USB o por red desde un ordenador. Esta utilidad permite el copiado de archivos en ambas direcciones, la instalación y desinstalación de apps, la ejecución de comandos de shell, el respaldo de datos, la lectura de logs, entre otras funciones.

Consulta la siguiente lista de Comandos ADB para aprender a usar adb.

Smali

A veces es interesante modificar el código de la aplicación para acceder a información oculta (quizá contraseñas muy ofuscadas o flags). Entonces, puede ser interesante decompilar el apk, modificar el código y recompilarlo.
En este tutorial puedes aprender cómo decompilar un APK, modificar código Smali y recompilar el APK con la nueva funcionalidad. Esto puede ser muy útil como alternativa para varias pruebas durante el análisis dinámico que se van a presentar. Por lo tanto, ten siempre en cuenta esta posibilidad.

Otros trucos interesantes

Adquisición automatizada de APKs desde múltiples fuentes (justapk)

pip install justapk (Python 3.11+). La CLI envía JSON a stdout y el progreso a stderr (compatible con pipes). Intenta una cadena de fallback determinista a través de APK20 → F-Droid → APKPure (mobile API) → APKMirror (HTML scrape) → Uptodown (mobile API) → APKCombo (HTML scrape). Las fuentes protegidas por Cloudflare usan curl_cffi con impersonación de huella TLS para imitar clientes reales y reducir los bloqueos por detección de bots.

justapk download <package>              # auto fallback
justapk download <package> -s apkpure   # pin a source / version / output dir
justapk search telegram
justapk info org.telegram.messenger
justapk convert app.xapk -o output/      # merges splits, re-signs with debug key

convert fusiona XAPK/split APKs y los firma con una debug key, por lo que la firma/procedencia del APK resultante difiere de la original (usar para pruebas/análisis, no para instalaciones en producción).

  • Extraer APK del dispositivo:
adb shell pm list packages
com.android.insecurebankv2

adb shell pm path com.android.insecurebankv2
package:/data/app/com.android.insecurebankv2-Jnf8pNgwy3QA_U5f-n_4jQ==/base.apk

adb pull /data/app/com.android.insecurebankv2-Jnf8pNgwy3QA_U5f-n_4jQ==/base.apk
  • Fusiona todos los splits y los APKs base con APKEditor:
mkdir splits
adb shell pm path com.android.insecurebankv2 | cut -d ':' -f 2 | xargs -n1 -i adb pull {} splits
java -jar ../APKEditor.jar m -i splits/ -o merged.apk

# after merging, you will need to align and sign the apk, personally, I like to use the uberapksigner
java -jar uber-apk-signer.jar -a merged.apk --allowResign -o merged_signed

Android malware tradecraft (loaders, fileless DEX, persistence)

Native staging + fileless DEX loaders

Algunos Android droppers incrustan una librería nativa (lib*.so) que descifra y escribe un segundo ELF (p. ej., l.so) en una ruta temporal, la carga vía JNI, y luego carga la lógica real como DEX solo en memoria usando dalvik.system.InMemoryDexClassLoader. Esto reduce la visibilidad estática del payload y evita escribir classes*.dex en disco.

Puntos prácticos de triaje:

  • Busca librerías nativas que llamen a dlopen o a System.loadLibrary muy temprano, y que luego resuelvan métodos Java mediante strings en la pila ofuscadas (p. ej., decodificadas con XOR en la pila).
  • Fíjate en InMemoryDexClassLoader en logs/strings o hooks, lo que indica ejecución de fileless DEX.

Gancho rápido de Frida para volcar el buffer DEX en memoria:

Java.perform(() => {
const IM = Java.use('dalvik.system.InMemoryDexClassLoader');
IM.$init.overload('java.nio.ByteBuffer','java.lang.ClassLoader').implementation = function(buf, parent){
const arr = Java.array('byte', buf.array());
const fos = Java.use('java.io.FileOutputStream').$new("/sdcard/memdex.dex");
fos.write(arr); fos.close();
return this.$init(buf, parent);
};
});

Anti-analysis kill-switch

Loaders empaquetados a menudo se auto-terminan cuando las comprobaciones de emulador o de análisis fallan (p. ej., validación de CPU_ABI) llamando a:

android.os.Process.killProcess(android.os.Process.myPid());

Persistencia mediante foreground service + bucle de MediaPlayer

Un patrón de persistencia ligero consiste en mantener un foreground service activo con una notificación fijada y reproducir continuamente un bucle de audio casi inaudible vía MediaPlayer. Esto mantiene el proceso “activo” y reduce las terminaciones por inactividad del sistema operativo. Busca el uso de ForegroundService + MediaPlayer que repita un asset pequeño (a menudo de pocos segundos).

Superposición Accessibility + ACTION_SET_TEXT hijacking

Después de que un usuario concede Accessibility, los troyanos bancarios pueden monitorizar la foreground app, renderizar una superposición realista (a menudo HTML para WebView almacenado como Base64) y reemplazar campos de transacción usando AccessibilityNodeInfo.ACTION_SET_TEXT. Esto permite la sustitución silenciosa de la dirección del destinatario mientras la víctima ve una UI plausible.

Ejemplo mínimo de reemplazo de texto:

Bundle args = new Bundle();
args.putCharSequence(AccessibilityNodeInfo.ACTION_ARGUMENT_SET_TEXT_CHARSEQUENCE,
"ATTACKER_USDT_ADDRESS");
node.performAction(AccessibilityNodeInfo.ACTION_SET_TEXT, args);

Legitimate push infrastructure as C2 gating

Instead of custom sockets, some malware uses Firebase Cloud Messaging (FCM) as the C2 channel. FCM messages can trigger telemetry checks (charging state, battery %, temperature, user inactivity) and gate actions like mining or fraud for stealth.

Encrypted native payload staging with filename‑derived keys

Native payloads can be delivered as encrypted ELF blobs and decrypted with CipherInputStream(), using a key derived from SHA‑1 of the downloaded filename. Each filename/version yields a distinct key, hindering static IOC reuse.

Jezail rooted Android pentesting toolkit (REST API + web UI)

  • Runs on a rooted device (Magisk/rootAVD) and starts an HTTP server on tcp/8080 with a Flutter web UI and REST API.
  • Install the release APK with perms: adb install -g -r jezail.apk, then launch the app (server auto-starts).
  • Endpoints: http://<device-ip>:8080/ (UI), http://<device-ip>:8080/api/json (API listing), http://<device-ip>:8080/api/swagger (Swagger).
  • Emulator port-forward to reach UI/API from the host: adb forward tcp:8080 tcp:8080 then browse http://localhost:8080.

Android Enterprise & Work Profile Attacks

Android Enterprise Work Profile Bypass

Case Studies & Vulnerabilities

Air Keyboard Remote Input Injection

Android Rooting Frameworks Manager Auth Bypass Syscall Hook

Abusing Android Media Pipelines Image Parsers

Firmware Level Zygote Backdoor Libandroid Runtime

Static Analysis

First of all, for analysing an APK you should take a look to the to the Java code using a decompiler.
Please, read here to find information about different available decompilers.

Looking for interesting Info

Just taking a look to the strings of the APK you can search for passwords, URLs (https://github.com/ndelphit/apkurlgrep), api keys, encryption, bluetooth uuids, tokens and anything interesting… look even for code execution backdoors or authentication backdoors (hardcoded admin credentials to the app).

Firebase

Pay special attention to firebase URLs and check if it is bad configured. More information about whats is FIrebase and how to exploit it here.

Basic understanding of the application - Manifest.xml, strings.xml

The examination of an application’s Manifest.xml and strings.xml files can reveal potential security vulnerabilities. These files can be accessed using decompilers or by renaming the APK file extension to .zip and then unzipping it.

Vulnerabilities identified from the Manifest.xml include:

  • Debuggable Applications: Applications set as debuggable (debuggable="true") in the Manifest.xml file pose a risk as they allow connections that can lead to exploitation. For further understanding on how to exploit debuggable applications, refer to a tutorial on finding and exploiting debuggable applications on a device.
  • Backup Settings: The android:allowBackup="false" attribute should be explicitly set for applications dealing with sensitive information to prevent unauthorized data backups via adb, especially when usb debugging is enabled.
  • Network Security: Custom network security configurations (android:networkSecurityConfig="@xml/network_security_config") in res/xml/ can specify security details like certificate pins and HTTP traffic settings. An example is allowing HTTP traffic for specific domains.
  • Exported Activities and Services: Identifying exported activities and services in the manifest can highlight components that might be misused. Further analysis during dynamic testing can reveal how to exploit these components.
  • Content Providers and FileProviders: Exposed content providers could allow unauthorized access or modification of data. The configuration of FileProviders should also be scrutinized.
  • Broadcast Receivers and URL Schemes: These components could be leveraged for exploitation, with particular attention to how URL schemes are managed for input vulnerabilities.
  • SDK Versions: The minSdkVersion, targetSDKVersion, and maxSdkVersion attributes indicate the supported Android versions, highlighting the importance of not supporting outdated, vulnerable Android versions for security reasons.

From the strings.xml file, sensitive information such as API keys, custom schemas, and other developer notes can be discovered, underscoring the need for careful review of these resources.

Tapjacking

Tapjacking is an attack where a malicious application is launched and positions itself on top of a victim application. Once it visibly obscures the victim app, its user interface is designed in such a way as to trick the user to interact with it, while it is passing the interaction along to the victim app.
In effect, it is blinding the user from knowing they are actually performing actions on the victim app.

Find more information in:

Tapjacking

Task Hijacking

An activity with the launchMode set to singleTask without any taskAffinity defined is vulnerable to task Hijacking. This means, that an application can be installed and if launched before the real application it could hijack the task of the real application (so the user will be interacting with the malicious application thinking he is using the real one).

More info in:

Android Task Hijacking

Insecure data storage

Internal Storage

In Android, files stored in internal storage are designed to be accessible exclusively by the app that created them. This security measure is enforced by the Android operating system and is generally adequate for the security needs of most applications. However, developers sometimes utilize modes such as MODE_WORLD_READABLE and MODE_WORLD_WRITABLE to allow files to be shared between different applications. Yet, these modes do not restrict access to these files by other applications, including potentially malicious ones.

  1. Static Analysis:
  • Ensure that the use of MODE_WORLD_READABLE and MODE_WORLD_WRITABLE is carefully scrutinized. These modes can potentially expose files to unintended or unauthorized access.
  1. Dynamic Analysis:
  • Verify the permissions set on files created by the app. Specifically, check if any files are set to be readable or writable worldwide. This can pose a significant security risk, as it would allow any application installed on the device, regardless of its origin or intent, to read or modify these files.

External Storage

When dealing with files on external storage, such as SD Cards, certain precautions should be taken:

  1. Accessibility:
  • Files on external storage are globally readable and writable. This means any application or user can access these files.
  1. Security Concerns:
  • Given the ease of access, it’s advised not to store sensitive information on external storage.
  • External storage can be removed or accessed by any application, making it less secure.
  1. Handling Data from External Storage:
  • Always perform input validation on data retrieved from external storage. This is crucial because the data is from an untrusted source.
  • Storing executables or class files on external storage for dynamic loading is strongly discouraged.
  • If your application must retrieve executable files from external storage, ensure these files are signed and cryptographically verified before they are dynamically loaded. This step is vital for maintaining the security integrity of your application.

External storage can be accessed in /storage/emulated/0 , /sdcard , /mnt/sdcard

Tip

Starting with Android 4.4 (API 17), the SD card has a directory structure which limits access from an app to the directory which is specifically for that app. This prevents malicious application from gaining read or write access to another app’s files.

Sensitive data stored in clear-text

  • Shared preferences: Android allow to each application to easily save xml files in the path /data/data/<packagename>/shared_prefs/ and sometimes it’s possible to find sensitive information in clear-text in that folder.
  • Databases: Android allow to each application to easily save sqlite databases in the path /data/data/<packagename>/databases/ and sometimes it’s possible to find sensitive information in clear-text in that folder.

Broken TLS

Accept All Certificates

For some reason sometimes developers accept all the certificates even if for example the hostname does not match with lines of code like the following one:

SSLSocketFactory sf = new cc(trustStore);
sf.setHostnameVerifier(SSLSocketFactory.ALLOW_ALL_HOSTNAME_VERIFIER);

Una buena manera de probar esto es intentar capturar el tráfico usando algún proxy como Burp sin autorizar Burp CA dentro del dispositivo. También, puedes generar con Burp un certificado para un hostname diferente y usarlo.

Criptografía débil

Procesos pobres de gestión de claves

Algunos desarrolladores guardan datos sensibles en el almacenamiento local y los cifran con una clave hardcoded/predictible en el código. Esto no debería hacerse, ya que algo de reversing podría permitir a atacantes extraer la información confidencial.

Uso de algoritmos inseguros y/o obsoletos

Los desarrolladores no deberían usar algoritmos obsoletos para realizar checks de autorización, almacenar o enviar datos. Algunos de estos algoritmos son: RC4, MD4, MD5, SHA1… Si se usan hashes para almacenar contraseñas por ejemplo, deberían usarse hashes resistentes a brute-force con salt.

Otras comprobaciones

  • Se recomienda ofuscar el APK para dificultar el trabajo de reverse engineer a los atacantes.
  • Si la app es sensible (como apps bancarias), debería realizar sus propias comprobaciones para ver si el móvil está rooteado y actuar en consecuencia.
  • Si la app es sensible (como apps bancarias), debería comprobar si se está usando un emulador.
  • Si la app es sensible (como apps bancarias), debería comprobar su propia integridad antes de ejecutarse para verificar si fue modificada.
  • Usa APKiD para comprobar qué compiler/packer/obfuscator se usó para construir el APK

React Native Application

Lee la siguiente página para aprender cómo acceder fácilmente al código javascript de aplicaciones React:

React Native Application

Xamarin Applications

Lee la siguiente página para aprender cómo acceder fácilmente al código C# de una aplicación xamarin:

Xamarin Apps

Superpacked Applications

Según este blog post superpacked es un algoritmo de Meta que comprime el contenido de una aplicación en un único archivo. El blog habla sobre la posibilidad de crear una app que descomprima este tipo de apps… y una forma más rápida que implica ejecutar la aplicación y recopilar los archivos descomprimidos desde el sistema de archivos.

Análisis estático de código automatizado

La herramienta mariana-trench es capaz de encontrar vulnerabilidades escaneando el código de la aplicación. Esta herramienta contiene una serie de known sources (que indica a la herramienta los lugares donde la entrada está controlada por el usuario), sinks (que indica a la herramienta lugares peligrosos donde la entrada maliciosa del usuario podría causar daños) y rules. Estas reglas indican la combinación de sources-sinks que representan una vulnerabilidad.

Con este conocimiento, mariana-trench revisará el código y encontrará posibles vulnerabilidades en él.

Secrets leaked

Una aplicación puede contener secretos (API keys, contraseñas, urls ocultas, subdominios…) dentro de ella que podrías ser capaz de descubrir. Podrías usar una herramienta como https://github.com/dwisiswant0/apkleaks

Bypass Biometric Authentication

Bypass Biometric Authentication (Android)

Otras funciones interesantes

  • Code execution: Runtime.exec(), ProcessBuilder(), native code:system()
  • Send SMSs: sendTextMessage, sendMultipartTestMessage
  • Native functions declaradas como native: public native, System.loadLibrary, System.load
  • Read this to learn how to reverse native functions
  • In-memory native code execution via JNI (downloaded shellcode → mmap/mprotect → call):

In Memory Jni Shellcode Execution

Other tricks

content:// protocol

Análisis dinámico

Primero que nada, necesitas un entorno donde puedas instalar la aplicación y todo el entorno (Burp CA cert, Drozer and Frida principalmente). Por lo tanto, se recomienda encarecidamente un dispositivo rooteado (emulado o no).

Análisis dinámico online

Puedes crear una cuenta gratuita en: https://appetize.io/. Esta plataforma te permite subir y ejecutar APKs, por lo que es útil para ver cómo se comporta un apk.

Incluso puedes ver los logs de tu aplicación en la web y conectarte mediante adb.

Gracias a la conexión ADB puedes usar Drozer y Frida dentro de los emuladores.

Análisis dinámico local

Usando un emulador

  • Android Studio (Puedes crear dispositivos x86 y arm, y según esto las últimas versiones x86 soportan librerías ARM sin necesitar un emulador arm lento).
  • Aprende a configurarlo en esta página:

AVD - Android Virtual Device

  • Genymotion (versión gratuita: Personal Edition, necesitas crear una cuenta. Se recomienda descargar la versión CON VirtualBox para evitar errores potenciales.)
  • Nox (Gratis, pero no soporta Frida ni Drozer).

Tip

Al crear un nuevo emulador en cualquier plataforma recuerda que cuanto más grande sea la pantalla, más lento funcionará el emulador. Así que selecciona pantallas pequeñas si es posible.

Para instalar google services (como AppStore) en Genymotion necesitas hacer clic en el botón marcado en rojo de la siguiente imagen:

Además, fíjate que en la configuración de la VM Android en Genymotion puedes seleccionar Bridge Network mode (esto será útil si te vas a conectar a la VM Android desde una VM diferente con las herramientas).

Usar un dispositivo físico

Necesitas activar las opciones de debugging y sería ideal si puedes rootear el dispositivo:

  1. Settings.
  2. (FromAndroid 8.0) Selecciona System.
  3. Selecciona About phone.
  4. Pulsa Build number 7 veces.
  5. Vuelve atrás y encontrarás las Developer options.

Una vez que hayas instalado la aplicación, lo primero que deberías hacer es probarla e investigar qué hace, cómo funciona y familiarizarte con ella.
Sugiero realizar este análisis dinámico inicial usando MobSF dynamic analysis + pidcat, de modo que podamos aprender cómo funciona la aplicación mientras MobSF captura muchos datos interesantes que podrás revisar más tarde.

Notas rápidas sobre Magisk/Zygisk (recomendado en dispositivos Pixel)

  • Parchea boot.img con la app Magisk y flashea vía fastboot para obtener root sin modificar la partición system
  • Activa Zygisk + DenyList para ocultar root; considera LSPosed/Shamiko cuando se requiera un ocultamiento más fuerte
  • Conserva el boot.img original para recuperarte de actualizaciones OTA; vuelve a parchear después de cada OTA
  • Para mirror de pantalla, usa scrcpy en el host

Filtración de datos no intencionada

Logging

Los desarrolladores deben tener cuidado de no exponer información de debugging públicamente, ya que puede conducir a leaks de datos sensibles. Se recomiendan las herramientas pidcat y adb logcat para monitorizar los logs de la aplicación y así identificar y proteger información sensible. Pidcat es preferida por su facilidad de uso y legibilidad.

Warning

Ten en cuenta que desde versiones posteriores a Android 4.0, las aplicaciones solo pueden acceder a sus propios logs. Por tanto, las aplicaciones no pueden acceder a los logs de otras apps.
Aun así, se sigue recomendando no registrar información sensible.

Caché del portapapeles (Copy/Paste Buffer Caching)

El framework basado en clipboard de Android habilita la funcionalidad de copiar/pegar en las apps, pero representa un riesgo ya que otras aplicaciones pueden acceder al portapapeles, exponiendo potencialmente datos sensibles. Es crucial desactivar las funciones de copiar/pegar en secciones sensibles de una aplicación, como los datos de tarjetas de crédito, para prevenir leaks de datos.

Crash Logs

Si una aplicación crashea y guarda logs, esos logs pueden ayudar a atacantes, especialmente cuando la aplicación no puede ser reverse-engineered. Para mitigar este riesgo, evita registrar en crashes y, si los logs deben transmitirse por la red, asegúrate de enviarlos vía un canal SSL para mayor seguridad.

Como pentester, intenta revisar estos logs.

Datos de analítica enviados a terceros

Las aplicaciones a menudo integran servicios como Google Adsense, lo que puede inadvertidamente provocar leaks de datos sensibles debido a una implementación incorrecta por parte de los desarrolladores. Para identificar posibles leaks, es aconsejable interceptar el tráfico de la aplicación y comprobar si se está enviando información sensible a servicios de terceros.

SQLite DBs

La mayoría de las aplicaciones usarán bases de datos SQLite internas para guardar información. Durante el pentest echa un vistazo a las bases de datos creadas, los nombres de tablas y columnas y todos los datos guardados porque podrías encontrar información sensible (lo que sería una vulnerabilidad).
Las bases de datos deberían estar ubicadas en /data/data/the.package.name/databases como /data/data/com.mwr.example.sieve/databases

Si la base de datos guarda información confidencial y está encrypted pero puedes encontrar la password dentro de la aplicación, sigue siendo una vulnerabilidad.

Enumera las tablas usando .tables y enumera las columnas de las tablas con .schema <table_name>

Drozer (Exploit Activities, Content Providers and Services)

From Drozer Docs: Drozer permite que asumas el rol de una app Android e interactúes con otras apps. Puede hacer todo lo que una aplicación instalada puede hacer, como hacer uso del mecanismo de Inter-Process Communication (IPC) de Android e interactuar con el sistema operativo subyacente. .
Drozer es una herramienta útil para explotar exported activities, exported services and Content Providers como aprenderás en las siguientes secciones.

Explotando Activities exportadas

Read this if you want to refresh what is an Android Activity.
Recuerda también que el código de una activity empieza en el método onCreate.

Bypass de autorización

Cuando una Activity está exportada puedes invocar su pantalla desde una app externa. Por lo tanto, si una activity con información sensible está exported podrías bypassear los mecanismos de autenticación para acceder a ella.

Learn how to exploit exported activities with Drozer.

También puedes iniciar una activity exportada desde adb:

  • PackageName is com.example.demo
  • Exported ActivityName is com.example.test.MainActivity
adb shell am start -n com.example.demo/com.example.test.MainActivity

NOTA: MobSF detectará como malicioso el uso de singleTask/singleInstance como android:launchMode en una Activity, pero debido a this, aparentemente esto solo es peligroso en versiones antiguas (API versions < 21).

Tip

Ten en cuenta que un authorisation bypass no siempre es una vulnerabilidad; dependerá de cómo funcione el bypass y qué información se exponga.

Exposición de información sensible

Activities can also return results. Si consigues encontrar una Activity exportada y sin protección que llame al método setResult y devuelva información sensible, existe una exposición de información sensible.

Tapjacking

Si Tapjacking no se previene, podrías abusar de la Activity exportada para hacer que el usuario realice acciones inesperadas. For more info about what is Tapjacking follow the link.

Exploiting Content Providers - Accessing and manipulating sensitive information

Read this if you want to refresh what is a Content Provider.
Content providers se usan básicamente para compartir datos. Si una app tiene Content providers disponibles, puede que puedas extraer datos sensibles de ellos. También es interesante probar posibles SQL injections y Path Traversals, ya que podrían ser vulnerables.

Learn how to exploit Content Providers with Drozer.

Exploiting Services

Read this if you want to refresh what is a Service.
Recuerda que las acciones de un Service comienzan en el método onStartCommand.

Un Service es básicamente algo que puede recibir datos, procesarlos y devolver (o no) una respuesta. Entonces, si una aplicación exporta Services deberías revisar el código para entender qué hace y probarlo dinámicamente para extraer información confidencial, eludir medidas de autenticación…

Learn how to exploit Services with Drozer.

Exploiting Broadcast Receivers

Read this if you want to refresh what is a Broadcast Receiver.
Recuerda que las acciones de un Broadcast Receiver comienzan en el método onReceive.

Un Broadcast Receiver estará esperando un tipo de mensaje. Dependiendo de cómo el Broadcast Receiver maneje el mensaje, podría ser vulnerable.
Learn how to exploit Broadcast Receivers with Drozer.

Exploiting Schemes / Deep links

You can look for deep links manually, using tools like MobSF or scripts like this one.
Puedes abrir un declarado scheme usando adb o un browser:

adb shell am start -a android.intent.action.VIEW -d "scheme://hostname/path?param=value" [your.package.name]

Ten en cuenta que puedes omit the package name y el móvil llamará automáticamente a la app que debería abrir ese enlace.

<!-- Browser regular link -->
<a href="scheme://hostname/path?param=value">Click me</a>
<!-- fallback in your url you could try the intent url -->
<a href="intent://hostname#Intent;scheme=scheme;package=your.package.name;S.browser_fallback_url=http%3A%2F%2Fwww.example.com;end">with alternative</a>

Código ejecutado

Para encontrar el código que se ejecutará en la App, ve a la activity llamada por el deep link y busca la función onNewIntent.

Información sensible

Cada vez que encuentres un deep link verifica que no reciba datos sensibles (como contraseñas) mediante parámetros de URL, porque cualquier otra aplicación podría suplantar el deep link y robar esos datos!

Parámetros en la ruta

También debes comprobar si algún deep link está usando un parámetro dentro de la ruta de la URL como: https://api.example.com/v1/users/{username}, en ese caso puedes forzar un path traversal accediendo a algo como: example://app/users?username=../../unwanted-endpoint%3fparam=value.
Nota que si encuentras los endpoints correctos dentro de la aplicación podrías provocar un Open Redirect (si parte de la ruta se usa como nombre de dominio), account takeover (si puedes modificar detalles de usuarios sin token CSRF y el endpoint vulnerable usó el método correcto) y cualquier otra vulnerabilidad. Más info about this here.

Más ejemplos

Un interesante informe de bug bounty sobre links (/.well-known/assetlinks.json).

Inspección de la capa de transporte y fallos de verificación

  • Los certificados no siempre se inspeccionan correctamente por las aplicaciones Android. Es común que estas aplicaciones ignoren las advertencias y acepten certificados self-signed o, en algunos casos, vuelvan a usar conexiones HTTP.
  • Las negociaciones durante el handshake SSL/TLS a veces son débiles, empleando conjuntos de cifrado inseguros. Esta vulnerabilidad hace que la conexión sea susceptible a ataques man-in-the-middle (MITM), permitiendo a los atacantes descifrar los datos.
  • Leakage of private information es un riesgo cuando las aplicaciones se autentican usando canales seguros pero luego se comunican por canales no seguros para otras transacciones. Este enfoque no protege datos sensibles, como cookies de sesión o detalles de usuario, de la intercepción por entidades maliciosas.

Verificación de certificados

Nos centraremos en verificación de certificados. La integridad del certificado del servidor debe verificarse para mejorar la seguridad. Esto es crucial porque las configuraciones TLS inseguras y la transmisión de datos sensibles por canales no cifrados pueden suponer riesgos significativos. Para pasos detallados sobre cómo verificar certificados de servidor y abordar vulnerabilidades, this resource ofrece una guía completa.

SSL Pinning

SSL Pinning es una medida de seguridad donde la aplicación verifica el certificado del servidor contra una copia conocida almacenada dentro de la propia aplicación. Este método es esencial para prevenir ataques MITM. Se recomienda encarecidamente implementar SSL Pinning en aplicaciones que manejen información sensible.

Inspección de tráfico

Para inspeccionar tráfico HTTP, es necesario instalar el certificado de la herramienta proxy (p. ej., Burp). Sin instalar este certificado, el tráfico cifrado podría no ser visible a través del proxy. Para una guía sobre cómo instalar un certificado CA personalizado, click here.

Las aplicaciones dirigidas a API Level 24 and above requieren modificaciones en el Network Security Config para aceptar el certificado CA del proxy. Este paso es crítico para inspeccionar tráfico cifrado. Para instrucciones sobre cómo modificar el Network Security Config, refer to this tutorial.

Si se está usando Flutter debes seguir las instrucciones en this page. Esto se debe a que, simplemente añadir el certificado al store no funcionará ya que Flutter tiene su propia lista de CAs válidas.

Detección estática de SSL/TLS pinning

Antes de intentar bypasses en tiempo de ejecución, mapea rápidamente dónde se aplica el pinning en el APK. El descubrimiento estático te ayuda a planear hooks/patches y a centrarte en las rutas de código correctas.

Herramienta: SSLPinDetect

  • Utilidad de análisis estático open-source que decompila el APK a Smali (vía apktool) y busca patrones regex curados de implementaciones de SSL/TLS pinning.
  • Reporta la ruta exacta del archivo, número de línea y un fragmento de código por cada coincidencia.
  • Cubre frameworks comunes y rutas de código personalizadas: OkHttp CertificatePinner, custom javax.net.ssl.X509TrustManager.checkServerTrusted, SSLContext.init with custom TrustManagers/KeyManagers, y pins en Network Security Config XML.

Instalar

  • Requisitos previos: Python >= 3.8, Java en PATH, apktool
git clone https://github.com/aancw/SSLPinDetect
cd SSLPinDetect
pip install -r requirements.txt

Uso

# Basic
python sslpindetect.py -f app.apk -a apktool.jar

# Verbose (timings + per-match path:line + snippet)
python sslpindetect.py -a apktool_2.11.0.jar -f sample/app-release.apk -v

Ejemplo de reglas de patrones (JSON) Usa o extiende firmas para detectar estilos de pinning propietarios/personalizados. Puedes cargar tu propio JSON y escanear a gran escala.

{
"OkHttp Certificate Pinning": [
"Lcom/squareup/okhttp/CertificatePinner;",
"Lokhttp3/CertificatePinner;",
"setCertificatePinner"
],
"TrustManager Override": [
"Ljavax/net/ssl/X509TrustManager;",
"checkServerTrusted"
]
}

Notas y consejos

  • Escaneo rápido en aplicaciones grandes mediante multi-threading y memory-mapped I/O; regex precompiladas reducen overhead/falsos positivos.
  • Pattern collection: https://github.com/aancw/smali-sslpin-patterns
  • Objetivos típicos de detección para priorizar a continuación:
  • OkHttp: CertificatePinner usage, setCertificatePinner, okhttp3/okhttp package references
  • Custom TrustManagers: javax.net.ssl.X509TrustManager, checkServerTrusted overrides
  • Custom SSL contexts: SSLContext.getInstance + SSLContext.init with custom managers
  • Declarative pins en res/xml network security config y referencias en el manifest
  • Usa las ubicaciones encontradas para planificar hooks de Frida, parches estáticos o revisiones de configuración antes de las pruebas dinámicas.

Bypass de SSL Pinning

Cuando SSL Pinning está implementado, es necesario bypassearlo para inspeccionar el tráfico HTTPS. Existen varios métodos para este propósito:

Buscando vulnerabilidades web comunes

También es importante buscar vulnerabilidades web comunes dentro de la aplicación. La información detallada sobre cómo identificar y mitigar estas vulnerabilidades queda fuera del alcance de este resumen, pero está ampliamente cubierta en otros lugares.

Frida

Frida es un toolkit de instrumentación dinámica para developers, reverse-engineers y security researchers.
Puedes acceder a la aplicación en ejecución y hookear métodos en tiempo de ejecución para cambiar el comportamiento, modificar valores, extraer valores, ejecutar código distinto…
Si quieres pentestear aplicaciones Android necesitas saber cómo usar Frida.

Anti-instrumentation & SSL pinning bypass workflow

Android Anti Instrumentation And Ssl Pinning Bypass

Dump Memory - Fridump

Comprueba si la aplicación está almacenando información sensible en memoria que no debería, como passwords o mnemonics.

Usando Fridump3 puedes volcar la memoria de la app con:

# With PID
python3 fridump3.py -u <PID>

# With name
frida-ps -Uai
python3 fridump3.py -u "<Name>"

Esto volcará la memoria en la carpeta ./dump, y allí podrías usar grep con algo como:

strings * | grep -E "^[a-z]+ [a-z]+ [a-z]+ [a-z]+ [a-z]+ [a-z]+ [a-z]+ [a-z]+ [a-z]+ [a-z]+ [a-z]+ [a-z]+$"

Datos sensibles en Keystore

En Android el Keystore es el mejor lugar para almacenar datos sensibles; sin embargo, con suficientes privilegios todavía es posible acceder a él. Como las aplicaciones tienden a almacenar aquí datos sensibles in clear text, los pentests deberían comprobarlo, ya que un root user o alguien con acceso físico al dispositivo podría robar estos datos.

Incluso si una app almacenó datos en el Keystore, los datos deberían estar cifrados.

Para acceder a los datos dentro del Keystore puedes usar este Frida script: https://github.com/WithSecureLabs/android-keystore-audit/blob/master/frida-scripts/tracer-cipher.js

frida -U -f com.example.app -l frida-scripts/tracer-cipher.js

Fingerprint/Biometrics Bypass

Usando el siguiente script de Frida, podría ser posible bypass fingerprint authentication que las aplicaciones Android podrían estar realizando para protect certain sensitive areas:

frida --codeshare krapgras/android-biometric-bypass-update-android-11 -U -f <app.package>

Imágenes de fondo

Cuando pones una aplicación en segundo plano, Android almacena una snapshot of the application para que cuando se recupere al primer plano empiece a cargar la imagen antes que la app, de modo que parezca que la aplicación se cargó más rápido.

Sin embargo, si ese snapshot contiene información sensible, alguien con acceso al snapshot podría robar esa información (nota: necesitas root para acceder a ella).

Los snapshots suelen almacenarse en: /data/system_ce/0/snapshots

Android proporciona una forma de evitar la captura de pantalla estableciendo el parámetro de layout FLAG_SECURE. Al usar este flag, el contenido de la ventana se trata como seguro, impidiendo que aparezca en capturas de pantalla o que pueda verse en pantallas no seguras.

getWindow().setFlags(LayoutParams.FLAG_SECURE, LayoutParams.FLAG_SECURE);

Android Application Analyzer

Esta herramienta puede ayudarte a gestionar diferentes herramientas durante el análisis dinámico: https://github.com/NotSoSecure/android_application_analyzer

Inyección de Intent

Los desarrolladores a menudo crean componentes proxy como activities, services y broadcast receivers que manejan estos Intents y los pasan a métodos como startActivity(...) o sendBroadcast(...), lo cual puede ser arriesgado.

El peligro radica en permitir que un atacante dispare componentes de la app no exportados o acceda a content providers sensibles desviando estos Intents. Un ejemplo notable es el componente WebView que convierte URLs en objetos Intent vía Intent.parseUri(...) y luego los ejecuta, lo que puede llevar a inyecciones maliciosas de Intent.

Conclusiones esenciales

  • Intent Injection es similar al problema web de Open Redirect.
  • Los exploits implican pasar objetos Intent como extras, que pueden ser redirigidos para ejecutar operaciones inseguras.
  • Puede exponer componentes no exportados y content providers a atacantes.
  • La conversión de URL a Intent de WebView puede facilitar acciones no intencionadas.

Android Client Side Injections and others

Probablemente conozcas este tipo de vulnerabilidades por la Web. Debes tener especial cuidado con estas vulnerabilidades en una aplicación Android:

  • SQL Injection: Cuando trabajes con queries dinámicas o Content-Providers asegúrate de usar consultas parametrizadas.
  • JavaScript Injection (XSS): Verifica que JavaScript y el soporte de Plugins estén deshabilitados para cualquier WebViews (deshabilitado por defecto). More info here.
  • Local File Inclusion: Los WebViews deberían tener el acceso al sistema de archivos deshabilitado (habilitado por defecto) - (webview.getSettings().setAllowFileAccess(false);). More info here.
  • Eternal cookies: En varios casos, cuando la aplicación Android finaliza la sesión la cookie no se revoca o incluso puede guardarse en disco.
  • Secure Flag in cookies

Automatic Analysis

MobSF

Static analysis

Vulnerability assessment of the application using a nice web-based frontend. You can also perform dynamic analysis (but you need to prepare the environment).

docker pull opensecurity/mobile-security-framework-mobsf
docker run -it -p 8000:8000 opensecurity/mobile-security-framework-mobsf:latest

Ten en cuenta que MobSF puede analizar Android(apk), IOS(ipa) and Windows(apx) applications (Windows applications must be analyzed from a MobSF installed in a Windows host).
Además, si creas un archivo ZIP con el código fuente de una app Android o una IOS app (ve a la carpeta raíz de la aplicación, selecciona todo y crea un ZIPfile), también podrá analizarlo.

MobSF también te permite hacer diff/Compare de análisis e integrar VirusTotal (necesitarás configurar tu API key en MobSF/settings.py y habilitarlo: VT_ENABLED = TRUE VT_API_KEY = <Your API key> VT_UPLOAD = TRUE). También puedes poner VT_UPLOAD en False, entonces el hash será upload en lugar del archivo.

Análisis dinámico asistido con MobSF

MobSF también puede ser muy útil para el análisis dinámico en Android, pero en ese caso necesitarás instalar MobSF y genymotion en tu host (una VM o Docker no funcionarán). Nota: Necesitas start first a VM in genymotion y then MobSF.
El analizador dinámico de MobSF puede:

  • Dump application data (URLs, logs, clipboard, capturas de pantalla realizadas por ti, capturas realizadas por “Exported Activity Tester”, emails, SQLite databases, XML files, y otros archivos creados). Todo esto se hace automáticamente excepto las capturas de pantalla; necesitas pulsar cuando quieras una captura o necesitas pulsar “Exported Activity Tester” para obtener capturas de todas las exported activities.
  • Capturar tráfico HTTPS
  • Usar Frida para obtener runtime information

A partir de Android versions > 5, iniciará automáticamente Frida y configurará los ajustes globales de proxy para capture traffic. Sólo capturará tráfico de la aplicación probada.

Frida

Por defecto, también usará algunos Frida Scripts para bypass SSL pinning, root detection y debugger detection y para monitor interesting APIs.
MobSF también puede invoke exported activities, capturar screenshots de ellas y guardar para el reporte.

Para start las pruebas dinámicas pulsa el botón verde: “Start Instrumentation”. Pulsa “Frida Live Logs” para ver los logs generados por los Frida scripts y “Live API Monitor” para ver todas las invocaciones a métodos hookeados, argumentos pasados y valores devueltos (esto aparecerá después de pulsar “Start Instrumentation”).
MobSF también te permite cargar tus propios Frida scripts (para enviar los resultados de tus Frida scripts a MobSF usa la función send()). También tiene varios scripts pre-escritos que puedes cargar (puedes añadir más en MobSF/DynamicAnalyzer/tools/frida_scripts/others/), simplemente selecciónalos, pulsa “Load” y pulsa “Start Instrumentation” (podrás ver los logs de esos scripts dentro de “Frida Live Logs”).

Además, tienes algunas funcionalidades auxiliares de Frida:

  • Enumerate Loaded Classes: Imprimirá todas las clases cargadas
  • Capture Strings: Imprimirá todas las cadenas capturadas mientras usas la aplicación (muy ruidoso)
  • Capture String Comparisons: Puede ser muy útil. Mostrará las 2 strings que se comparan y si el resultado fue True o False.
  • Enumerate Class Methods: Introduce el nombre de la clase (como “java.io.File”) y mostrará todos los métodos de la clase.
  • Search Class Pattern: Buscar clases por patrón
  • Trace Class Methods: Trace a whole class (ver entradas y salidas de todos los métodos de la clase). Recuerda que por defecto MobSF traza varios métodos interesantes de la Android Api.

Una vez que hayas seleccionado el módulo auxiliar que quieras usar necesitas pulsar “Start Intrumentation” y verás todas las salidas en “Frida Live Logs”.

Shell

MobSF también te ofrece una shell con algunos comandos adb, MobSF commands, y comandos comunes de shell en la parte inferior de la página de análisis dinámico. Algunos comandos interesantes:

help
shell ls
activities
exported_activities
services
receivers

Herramientas HTTP

Cuando se captura tráfico HTTP puedes ver una vista poco amigable del tráfico capturado en el botón “HTTP(S) Traffic” o una vista más agradable en el botón verde “Start HTTPTools”. Desde la segunda opción, puedes enviar las captured requests a proxies como Burp o Owasp ZAP.
Para ello: power on Burp –> turn off Intercept –> en MobSB HTTPTools selecciona la request –> pulsa “Send to Fuzzer” –> selecciona la proxy address (http://127.0.0.1:8080\).

Una vez que termines el dynamic analysis con MobSF puedes pulsar “Start Web API Fuzzer” para fuzz http requests y buscar vulnerabilidades.

Tip

Después de realizar un dynamic analysis con MobSF la configuración del proxy puede quedar mal y no podrás arreglarla desde la GUI. Puedes arreglar la configuración del proxy ejecutando:

adb shell settings put global http_proxy :0

Análisis dinámico asistido con Inspeckage

Puedes obtener la herramienta en Inspeckage.
Esta herramienta usa algunos Hooks para informarte qué está pasando en la aplicación mientras realizas un dynamic analysis.

Yaazhini

Esta es una excelente herramienta para realizar static analysis con una GUI

Qark

Esta herramienta está diseñada para buscar varias vulnerabilidades relacionadas con security en aplicaciones Android, ya sea en source code o en packaged APKs. La herramienta también es capaz de crear un APK desplegable tipo “Proof-of-Concept” y ADB commands, para explotar algunas de las vulnerabilidades encontradas (Exposed activities, intents, tapjacking…). Al igual que con Drozer, no es necesario rootear el dispositivo de prueba.

pip3 install --user qark  # --user is only needed if not using a virtualenv
qark --apk path/to/my.apk
qark --java path/to/parent/java/folder
qark --java path/to/specific/java/file.java

ReverseAPK

  • Muestra todos los archivos extraídos para referencia rápida
  • Descompila automáticamente archivos APK a formato Java y Smali
  • Analiza AndroidManifest.xml en busca de vulnerabilidades comunes y comportamiento
  • Análisis estático del código fuente para vulnerabilidades comunes y comportamiento
  • Información del dispositivo
  • y más
reverse-apk relative/path/to/APP.apk

SUPER Android Analyzer

SUPER es una aplicación de línea de comandos que puede utilizarse en Windows, MacOS X y Linux, y que analiza archivos .apk en busca de vulnerabilidades. Hace esto descomprimiendo APKs y aplicando una serie de reglas para detectar esas vulnerabilidades.

Todas las reglas están centradas en un archivo rules.json, y cada empresa o tester puede crear sus propias reglas para analizar lo que necesiten.

Descarga los últimos binarios desde la download page

super-analyzer {apk_file}

StaCoAn

StaCoAn es una herramienta crossplatform que ayuda a desarrolladores, bugbounty hunters y ethical hackers a realizar static code analysis en aplicaciones móviles.

El concepto es que arrastres y sueltes el archivo de tu aplicación móvil (un archivo .apk o .ipa) sobre la aplicación StaCoAn y ésta generará un informe visual y portátil para ti. Puedes ajustar la configuración y las wordlists para obtener una experiencia personalizada.

Descargar latest release:

./stacoan

AndroBugs

AndroBugs Framework es un sistema de análisis de vulnerabilidades de Android que ayuda a desarrolladores o hackers a encontrar posibles vulnerabilidades de seguridad en aplicaciones Android.
Windows releases

python androbugs.py -f [APK file]
androbugs.exe -f [APK file]

Androwarn

Androwarn es una herramienta cuyo objetivo principal es detectar y advertir al usuario sobre posibles comportamientos maliciosos desarrollados por una aplicación Android.

La detección se realiza mediante la static analysis del Dalvik bytecode de la aplicación, representado como Smali, con la biblioteca androguard.

Esta herramienta busca el comportamiento común de las aplicaciones “malas” como: Telephony identifiers exfiltration, Audio/video flow interception, PIM data modification, Arbitrary code execution…

python androwarn.py -i my_application_to_be_analyzed.apk -r html -v 3

MARA Framework

MARA is a Mobile Application Reverse engineering and Analysis Framework. Es una herramienta que reúne herramientas comúnmente usadas para reverse engineering y análisis de aplicaciones móviles, para ayudar a probar aplicaciones móviles frente a las amenazas de seguridad móvil de OWASP. Su objetivo es facilitar esta tarea y hacerla más accesible para desarrolladores de aplicaciones móviles y profesionales de seguridad.

It is able to:

Koodous

Útil para detectar malware: https://koodous.com/

Obfuscating/Deobfuscating code

Ten en cuenta que, dependiendo del servicio y la configuración que uses para ofuscar el código, los secretos pueden o no quedar ofuscados.

ProGuard

From Wikipedia: ProGuard is an open source command-line tool that shrinks, optimizes and obfuscates Java code. Es capaz de optimizar bytecode así como detectar y eliminar instrucciones no usadas. ProGuard es software libre y se distribuye bajo la GNU General Public License, version 2.

ProGuard se distribuye como parte del Android SDK y se ejecuta al compilar la aplicación en release mode.

DexGuard

Encuentra una guía paso a paso para deobfuscar el apk en https://blog.lexfo.fr/dexguard.html

(From that guide) La última vez que lo comprobamos, el modo de operación de Dexguard era:

  • load a resource as an InputStream;
  • feed the result to a class inheriting from FilterInputStream to decrypt it;
  • do some useless obfuscation to waste a few minutes of time from a reverser;
  • feed the decrypted result to a ZipInputStream to get a DEX file;
  • finally load the resulting DEX as a Resource using the loadDex method.

DeGuard

DeGuard reverses the process of obfuscation performed by Android obfuscation tools. This enables numerous security analyses, including code inspection and predicting libraries.

Puedes subir un APK ofuscado a su plataforma.

[Deobfuscate android App]https://github.com/In3tinct/deobfuscate-android-app

Esta es una herramienta LLM para encontrar posibles vulnerabilidades de seguridad en apps Android y desofuscar el código de aplicaciones Android. Usa la API pública de Google Gemini.

Simplify

It is a generic android deobfuscator. Simplify virtually executes an app to understand its behavior and then tries to optimize the code so it behaves identically but is easier for a human to understand. Cada tipo de optimización es simple y genérico, por lo que no importa qué tipo específico de ofuscación se haya usado.

APKiD

APKiD te da información sobre cómo se hizo un APK. Identifica muchos compiladores, packers, obfuscators, y otras cosas raras. Es el PEiD para Android.

Manual

Lee este tutorial para aprender algunos trucos sobre cómo revertir ofuscación personalizada

Labs

Androl4b

AndroL4b es una máquina virtual de seguridad Android basada en ubuntu-mate que incluye la colección de los últimos frameworks, tutoriales y labs de diferentes geeks e investigadores de seguridad para reverse engineering y análisis de malware.

References

Tip

Aprende y practica Hacking en AWS:HackTricks Training AWS Red Team Expert (ARTE)
Aprende y practica Hacking en GCP: HackTricks Training GCP Red Team Expert (GRTE) Aprende y practica Hacking en Azure: HackTricks Training Azure Red Team Expert (AzRTE)

Apoya a HackTricks