Quartz 4

Ejemplo: La Liga 2018

17 min read

Las muestras analizadas son de tipo Pegasus, un conocido software espía que aprovecha vulnerabilidades avanzadas para obtener acceso privilegiado en dispositivos móviles.

La aplicación mencionada utiliza técnicas de “stemming” probablemente debido a que servicios como Spotify ofrecen versiones gratuitas con funcionalidades limitadas, y estas técnicas podrían relacionarse con mecanismos internos para optimizar búsquedas o recomendaciones.

Nuestro sistema operativo Android se basa en Linux. Linux actúa como kernel, es decir, es la interfaz fundamental entre el hardware y los demás programas del sistema operativo. Encima del kernel Linux existe una capa adicional que gestiona el entorno gráfico o de escritorio; en Android, esta capa corresponde al entorno de usuario específico denominado Android Framework.

En lugar de permitir acceso directo al kernel Linux, Android implementa una capa de abstracción propia. Esta abstracción reduce la superficie de ataque del sistema, ya que limita los puntos de acceso directo al kernel y minimiza la cantidad de controles necesarios. Gracias a esta estructura, cuando se produce un fallo, es más sencillo identificar y aislar la causa del problema.

Además, Android permite funcionalidades nativas escritas en lenguajes como C++. Estas funcionalidades, aunque potentes y rápidas, presentan mayores riesgos de seguridad debido al acceso directo a memoria y hardware. Por esta razón, su uso se limita y se controla estrictamente a través de interfaces gestionadas por la API de Java.

El procesamiento de señales, aunque a menudo no es muy eficiente en Java, puede beneficiarse de estas funcionalidades nativas en C++. Sin embargo, Android limita estrictamente su alcance y uso, precisamente para equilibrar rendimiento y seguridad.

Android utiliza un sistema llamado “Binder” para facilitar la comunicación entre procesos (IPC), permitiendo así la interacción controlada entre diferentes aplicaciones y servicios del sistema.

Las API de Android gestionan diversas funcionalidades del dispositivo, como el acceso a la cámara, las notificaciones, el acceso a telefonía y tareas similares a cron (tareas programadas).

El componente Android Runtime (ART) es una máquina virtual que cumple una función similar a la JVM de Java o la máquina virtual de .NET. ART traduce en tiempo de ejecución las instrucciones Java a instrucciones de bajo nivel que pueden ejecutarse directamente en el hardware del dispositivo.

Históricamente, la máquina virtual de Java (JVM) era software propietario, lo que complicaba la distribución y empaquetado completo para sistemas abiertos. Para solucionar esta limitación, Android introdujo Dalvik, una máquina virtual alternativa que utiliza su propio bytecode. Este bytecode Dalvik permite evitar directamente el uso de la JVM.

Inicialmente, Android empleaba la máquina virtual Dalvik, pero esto resultaba ineficiente. Por ello, se desarrolló la técnica de precompilación Ahead-of-Time (AOT) para que las aplicaciones se compilen anticipadamente, optimizando así el rendimiento en el Android Runtime actual (ART).

¿Qué es un APK?

Relacionado: VirusTotal. SSRF. owasp. Alcance. Controles.

Un APK (Android Package Kit) es el formato estándar para distribuir aplicaciones Android. Al igual que los archivos JAR o WAR en Java, un APK es esencialmente un archivo ZIP comprimido que contiene el código compilado (clases .dex), recursos gráficos, layouts, y activos necesarios para la aplicación.

En Android, las aplicaciones tienen interfaces gráficas avanzadas desarrolladas usando assets y recursos específicos, como layouts en XML, imágenes, audios, etc. El archivo AndroidManifest.xml incluido en cada APK define las configuraciones esenciales de la aplicación: permisos requeridos, orientación y configuración de pantalla, componentes de la app, entre otros aspectos clave.

Android es un sistema operativo multiusuario, donde cada aplicación ejecuta bajo un usuario Linux propio, aislado mediante un sistema de sandboxing gestionado por Linux. El control de acceso, por tanto, es estrictamente regulado por permisos específicos definidos en el manifest, los cuales la API de Android gestiona. Recientemente, los permisos más sensibles son solicitados al usuario en tiempo de ejecución para mejorar la seguridad y la privacidad.

Herramientas importantes:

  • jadx: Herramienta para descompilar APKs y visualizar el código fuente de manera legible en Java.

  • JavaDecompiler (específico para Android): Permite abrir un APK y visualizarlo como un proyecto Java tradicional, facilitando la comprensión del código.

  • MobSF: Plataforma integral para análisis estático y ocasionalmente dinámico de aplicaciones Android, ideal para pentesting y auditoría inicial de aplicaciones, especialmente útil en el análisis preliminar de malware.

  • CyberChef: Aplicación web desarrollada por GCHQ que proporciona numerosas funciones para codificar, decodificar, analizar y manipular cadenas cifradas o textos ofuscados, especialmente valiosa en análisis de malware.

  • Dex2jar: Convierte archivos .dex de Android en archivos .jar, facilitando así el análisis mediante herramientas tradicionales de Java.

  • apktool: Herramienta ampliamente utilizada para descompilar y reconstruir APKs, permitiendo extraer recursos, modificar aplicaciones y analizar internamente la estructura del archivo.

Android Pentesting

Para realizar pruebas de penetración (pentesting) en Android, la guía OWASP Mobile Application Security Testing Guide (MASTG) proporciona herramientas recomendadas y prácticas óptimas: OWASP MASTG Tools.

Malware en Android

Muestras famosas:

  • xHelper

  • Cerberus

  • Oscorp

Origen del malware:

Las infecciones suelen proceder de mercados alternativos (tiendas no oficiales), pero también se encuentran ocasionalmente en Google Play debido a técnicas avanzadas de evasión. La falta de voluntad de pagar por servicios legítimos (como Spotify) puede llevar a usuarios a descargar aplicaciones maliciosas.

Una vez infectado y superado el sandbox (entorno aislado) de Android, el malware puede controlar todo el teléfono. Casos como Pegasus emplean binarios Linux que no necesitan interactuar con la API estándar de Android, representando así una amenaza particularmente peligrosa.

Para realizar una atribución efectiva del malware es necesario entender claramente sus vectores de entrada, puntos de infección e indicadores de compromiso (IOCs).

El objetivo típico de muchos malwares de Android son troyanos bancarios. Sin embargo, algunos, como Pegasus, actúan como Remote Access Trojans (RAT), permitiendo un control remoto total del dispositivo comprometido.

Metodología REM

La metodología REM consta de las siguientes fases:

  • Adquisición

  • Clasificación

  • Análisis estático:

    • Parámetros básicos del archivo

    • Análisis avanzado del código

  • Análisis dinámico:

    • Métricas básicas de interacción

    • Depuración avanzada y análisis de memoria

  • Iteración: Repetición del proceso con nuevas muestras

El teléfono puede “rootearse” mediante un binario que solicita autorización al usuario para romper el aislamiento (sandbox) de Android. Esto facilita un análisis más profundo.

Las aplicaciones multiplataforma, en su mayoría páginas web embebidas, son frecuentemente vulnerables a ataques web típicos (XSS, SSRF). Por eso se recomiendan metodologías OWASP al analizar estas aplicaciones.

La biblioteca usada para gestionar subtítulos suele ser común tanto en aplicaciones móviles como en navegadores, lo que supone un vector adicional de ataque que no depende del APK directamente.

Cuando se analiza una muestra de malware, es esencial realizar una evaluación continua y ajustar las medidas de mitigación y respuesta conforme aparecen nuevos hallazgos.

Android REM Lab

Se recomienda usar un entorno controlado como una máquina virtual dedicada con herramientas como MobSF para análisis estático y dinámico. Las máquinas virtuales permiten tomar snapshots del sistema, algo fundamental para revertir rápidamente cambios durante pruebas avanzadas.

Adquisición mediante ADB

El protocolo ADB (Android Debug Bridge) permite depurar aplicaciones y obtener acceso directo al sistema del dispositivo, facilitando tareas como:

  • Obtener una shell interactiva.

  • Extraer (adb pull) o insertar (adb push) archivos fácilmente.

Esto permite recuperar muestras de malware directamente desde dispositivos reales.

Mercados alternativos ofrecen acceso directo a archivos APK, lo que facilita obtener muestras. Plataformas como Koodous (similar a VirusTotal) y Malware Bazaar son útiles para descargar y analizar muestras conocidas.

El número mágico (magic number) para identificar formatos ZIP, EXE, APK y JAR es común y corresponde a los bytes iniciales que identifican estos tipos de archivo. Aquí tienes tu texto corregido y ampliado, manteniendo el enfoque claro y organizado:

Ejemplo: La Liga 2018

En 2018, La Liga permitió habilitar el micrófono y la ubicación en sus aplicaciones móviles para detectar si algún bar estaba retransmitiendo fútbol de forma pirata. Utilizando el micrófono, la aplicación podía reconocer el sonido ambiental para verificar si se estaba emitiendo fútbol en directo, mientras que con la ubicación GPS se comprobaba si el local tenía licencia o no para realizar la retransmisión. Un juez consideró que estas prácticas eran legales, a pesar de las preocupaciones sobre privacidad.

Para analizar una aplicación específica de esta época, se puede descargar una muestra desde la plataforma APKPure. El desafío radica en identificar correctamente la versión de 2018, tarea que se facilita buscando la fecha específica de lanzamiento de la APK.

Actividad propuesta: Análisis de APK para detección de malware

El entorno donde se analizará la aplicación debe configurarse de manera aislada, es decir, la máquina utilizada para el análisis no debe tener acceso al entorno productivo ni a redes críticas (por ejemplo, un entorno separado y aislado sin acceso al servidor de remux o cualquier infraestructura sensible). Esto se realiza para prevenir posibles riesgos derivados del análisis de software potencialmente malicioso.

Para llevar a cabo el análisis estático, se utilizará la herramienta apktool, especialmente diseñada para descompilar y recompilar archivos APK. El uso de esta herramienta permite examinar el contenido de la aplicación Android en detalle.

Por ejemplo, para verificar el tamaño de la muestra antes y después de modificaciones o posibles infecciones, se usa el comando:

du -sh *

Esto facilita visualizar cambios en el binario analizado y detectar si la muestra podría estar infectada o modificada por terceros.

A continuación, se descompila la APK con:

apktool d nombre_app.apk

Una vulnerabilidad, en este contexto, es un fallo o debilidad en la aplicación que podría permitir ataques o ejecución maliciosa de código.

En cuanto a los servicios en Android, éstos suelen ejecutarse en segundo plano para proporcionar funcionalidad continua a la aplicación, y generalmente se manifiestan en forma de notificaciones persistentes para indicar que están activos. Sin embargo, en versiones anteriores de Android, existían servicios que podían ejecutarse sin mostrar notificaciones explícitas al usuario, dificultando la detección de comportamientos no deseados.

Los receivers (receptores de eventos en Android) reaccionan según ciertos eventos específicos del sistema operativo, como el arranque del dispositivo o cambios de estado en la red, ejecutando código automáticamente ante estos eventos.

Respecto a los permisos, algunos se declaran explícitamente en el archivo AndroidManifest.xml (permisos estáticos), mientras que otros requieren la autorización directa del usuario en tiempo de ejecución (permisos dinámicos, introducidos a partir de Android 6.0).

En el caso de malware, una técnica frecuente es no incluir iconos visibles para el usuario. Esto permite que la aplicación maliciosa se ejecute sigilosamente mediante servicios en segundo plano al iniciarse automáticamente con eventos del sistema, reduciendo así la probabilidad de que sea detectada por un usuario casual.

Al descompilar una APK, se obtiene código Smali (.smali). Este código es intermedio y se asemeja a un lenguaje ensamblador orientado a Dalvik/ART. Smali es menos intuitivo que Java, aunque mantiene similitudes básicas como métodos, constructores y tipos de retorno. Aun así, no es ideal para búsquedas rápidas de cadenas de texto; por ello, una estrategia eficiente es realizar búsquedas directas usando comandos como grep, por ejemplo:

grep -r 'microphone'

Cabe destacar que la búsqueda únicamente basada en permisos puede ser poco efectiva o engañosa. Muchas aplicaciones legítimas incluyen código de terceros (SDKs, bibliotecas), lo cual hace que ciertos permisos parezcan sospechosos sin necesariamente indicar actividad maliciosa. Por ello, la búsqueda debe ser más específica, buscando también en funciones internas y acciones específicas (“Intents”).

Otra forma de identificar posibles modificaciones o inserción de malware es comparando dos versiones diferentes de la aplicación usando el comando diff:

diff -r --color paquete_original paquete_sospechoso

Esto permite identificar rápidamente cambios sospechosos que podrían indicar manipulación malintencionada.

Finalmente, una estrategia utilizada por los atacantes contra técnicas de reversing es dificultar el análisis mediante la ofuscación del bytecode de la aplicación. Estas técnicas complican la lectura y el entendimiento del código, consumiendo más tiempo en la investigación. Por ello, el analista debe estar preparado y utilizar técnicas avanzadas y herramientas complementarias para manejar aplicaciones altamente ofuscadas o protegidas.

Análisis de TeaTV

TeaTV es una aplicación de streaming que se presentaba como una especie de Netflix Premium gratuito. Aunque aparentaba ser gratuita, en realidad ofrecía contenido protegido por derechos de autor de forma ilegal. En este ejercicio, vamos a analizar esta aplicación dentro de un entorno seguro.

1. Entorno de análisis con MobSF

Para comenzar, nos dirigimos a la ruta:

tools/android/Mobile-Security-Framework-MobSF/

Ejecutamos MobSF con el siguiente comando:

./run.sh

Este script levanta un entorno web desde donde podemos subir y analizar archivos APK. MobSF es una herramienta muy útil para análisis estático y dinámico de aplicaciones móviles, especialmente en el contexto de esta asignatura.

Desde otra consola, también podemos utilizar herramientas como jadx para descompilar el APK y comparar manualmente partes del código, lo cual permite realizar un análisis diferencial si tenemos varias versiones del mismo APK.

2. Certificado de la aplicación

Uno de los aspectos clave para determinar si una muestra es sospechosa es revisar su certificado digital. Si la aplicación está firmada con un certificado autofirmado, es decir, no verificado por una entidad de confianza, esto puede ser un indicador de riesgo. Los desarrolladores legítimos suelen firmar sus aplicaciones con certificados emitidos por entidades certificadoras reconocidas.

3. Indicadores de malware

MobSF nos proporciona múltiples indicadores que pueden revelar comportamientos maliciosos. En el caso de TeaTV, se observa que el malware se implementa en etapas, una técnica común para evadir la detección. El código malicioso no se ejecuta todo de golpe, sino que se activa progresivamente a medida que se cumplen ciertas condiciones o eventos.

4. Inseguridad en la API

Otro punto crítico es que la API de TeaTV muestra un diseño altamente inseguro, lo cual representa un riesgo tanto para los usuarios como para la red a la que se conectan. Las APIs mal protegidas permiten filtraciones de datos, modificación de contenido o incluso ejecución de código arbitrario.

5. Permisos peligrosos

Al analizar los permisos solicitados por la aplicación, es importante identificar cuál se repite con mayor frecuencia y cuál representa mayor riesgo. En este caso, destaca el uso del permiso de accesibilidad (AccessibilityService), uno de los más peligrosos del ecosistema Android.

Este permiso permite a la aplicación observar y controlar otras aplicaciones, detectar cuándo se abre un campo de contraseña y simular interacciones del usuario. Un desarrollador malicioso puede explotar este permiso para robar credenciales, leer mensajes o manipular la interfaz de otras apps.

6. Conclusión del análisis estático

Una vez identificado el uso indebido del permiso de accesibilidad y confirmada la firma autofirmada, junto con otros indicadores proporcionados por MobSF, se puede concluir el análisis estático. La evidencia sugiere que TeaTV presenta comportamientos típicos de aplicaciones maliciosas, con estructura por etapas, API insegura, permisos intrusivos y firma no verificada.

Por supuesto, aquí tienes el texto reescrito sin iconos y en un estilo claro y técnico:

Análisis dinámico

El análisis dinámico consiste en ejecutar la aplicación en un entorno controlado para observar su comportamiento en tiempo real. Durante este proceso, se analizan:

  • Conexiones de red: para identificar a qué servidores se conecta, si envía datos sensibles o si interactúa con dominios maliciosos.

  • Procesos: para detectar procesos secundarios que podrían estar relacionados con comportamiento oculto o malicioso.

  • Archivos: para observar qué archivos se crean, modifican o eliminan, y en qué rutas del sistema.

  • Comportamiento del código: se analiza cómo interactúa la aplicación con el sistema operativo, si lanza servicios, ejecuta código oculto o realiza acciones inesperadas.

Requisitos previos: virtualización

Para que el análisis dinámico funcione correctamente, es necesario habilitar la virtualización a nivel de hardware y de la máquina anfitriona.

Habilitar VT-x o AMD-V

Debes asegurarte de que la opción de virtualización esté habilitada en la BIOS o UEFI del equipo físico. En procesadores Intel se llama VT-x, y en AMD, AMD-V. Esta funcionalidad permite que las máquinas virtuales tengan acceso directo a instrucciones del procesador para tareas de virtualización.

Además, si estás trabajando dentro de una máquina virtual (como Kali o Ubuntu en VirtualBox o VMware), debes habilitar también la virtualización anidada. Esto permite ejecutar una segunda máquina virtual (como un emulador de Android) dentro de la primera. Si no se habilita, el rendimiento será muy bajo y muchas funciones, como la emulación de Android, simplemente no funcionarán.

Configuración de red: adaptador Host-only

Para aislar el entorno de análisis y evitar que la aplicación se conecte libremente a Internet, se recomienda usar un adaptador de red en modo Host-only. Este tipo de configuración permite que la máquina virtual se comunique únicamente con el equipo anfitrión o con otras máquinas virtuales conectadas a esa misma red, evitando el acceso a redes externas.

La arquitectura ideal para el análisis dinámico incluye dos máquinas virtuales:

  1. Una máquina virtual con el emulador de Android donde se ejecuta la aplicación sospechosa.

  2. Otra máquina virtual de análisis (por ejemplo, con Kali Linux) equipada con herramientas como tcpdump, Wireshark o mitmproxy para monitorizar el tráfico y la actividad del sistema.

Este enfoque permite realizar un análisis completo del comportamiento de la aplicación en un entorno controlado y sin riesgos para el sistema principal.

Claro, aquí tienes el texto corregido, mejor estructurado y más claro, manteniendo el contenido técnico y sin iconos ni adornos innecesarios:

Análisis dinámico avanzado con MobSF y Frida

Antes de realizar un análisis dinámico eficiente, es recomendable deshabilitar la aceleración 3D en la máquina virtual donde se ejecuta Android. Esto libera recursos del sistema, ya que la emulación gráfica no es prioritaria para este tipo de análisis.

Conexión con ADB

Para interactuar con la máquina virtual de Android desde nuestra consola, utilizamos adb (Android Debug Bridge). Los pasos básicos son:

  1. Ejecutar adb devices para comprobar que el dispositivo está disponible.

  2. Conectarse con adb connect [IP]:5555, donde [IP] es la dirección de red de la máquina Android y el puerto por defecto es 5555.

  3. Al volver a ejecutar adb devices, veremos que el dispositivo aparece como conectado.

Para elevar privilegios y realizar operaciones como root:

  • adb root reinicia el servicio ADB con permisos de superusuario (si el dispositivo lo permite).

  • adb shell abre una consola dentro del sistema Android emulado, desde donde podemos explorar el sistema de archivos, lanzar procesos o modificar configuraciones.

Análisis dinámico con MobSF y Frida

MobSF incluye una funcionalidad de análisis dinámico que se basa en el uso de Frida, una herramienta de instrumentación dinámica muy potente.

  • Frida permite interceptar funciones durante la ejecución de la aplicación. Cada vez que una función es llamada, se puede modificar su comportamiento, cambiar parámetros o registrar su actividad.

  • MobSF carga un servidor Frida en el dispositivo Android. Al instalar una aplicación, este servidor permite el hooking del código de la app objetivo.

  • Esto permite realizar análisis como el bypass de SSL pinning, que evita que la aplicación detecte certificados TLS falsos. MobSF incluye certificados falsos preconfigurados para interceptar tráfico TLS sin que la aplicación lo bloquee.

También es posible lanzar distintas activitys (pantallas) dentro de la aplicación para observar comportamientos específicos de cada módulo.

Evidencia de malware en muestras descompiladas

Cuando descompilamos una APK con apktool, obtenemos su estructura interna, incluyendo archivos como:

  • lovedbytheking.ttf: aunque parece un archivo de fuente, en realidad puede contener código o datos maliciosos camuflados.

  • juo.json: archivo de datos que puede contener una estructura bytehist para análisis de entropía. Una alta entropía sugiere que los datos están cifrados o comprimidos.

En este caso, observamos una técnica de ofuscación basada en un cifrado César, donde se utiliza un StringBuilder y se suman 3 posiciones a cada carácter. Por ejemplo, si el archivo muestra la palabra juo, y aplicamos un desplazamiento inverso de 3, obtenemos grl.

Para detectar estas manipulaciones se pueden buscar patrones como StringBuilder o clases relacionadas con manipulaciones de texto. Usando herramientas como jadx-gui, podemos explorar el código y encontrar que estas funciones suelen estar en clases con nombres genéricos como i.

Técnicas de detección y protección

  • Se pueden crear reglas YARA para detectar patrones comunes en malware como XOR, rotaciones (ROT13, César), cadenas sospechosas y uso de StringBuilder.

  • Estas reglas ayudan a prevenir, recuperar y detectar indicadores de compromiso.

  • En contextos de reversing, estas técnicas son clave para acelerar la identificación de funciones maliciosas y desarrollar contramedidas.

le decimos a frida que pincha las string que vayan construyendo para prodeder objdump descompilar elf los elf son los exe de linux

Graph View

Backlinks