Ransomware Móvil: Bloqueo de Pantalla y Cifrado en Android
Análisis técnico de ransomware en Android: desde lockers de pantalla hasta crypto-ransomware con cifrado real. Familias clave como DoubleLocker, MalLocker y CovidLock, abuso de Device Admin, overlays de rescate y métodos de recuperación.
Por qué el ransomware llegó a los móviles
El ransomware de escritorio genera miles de millones en rescates anuales. Era cuestión de tiempo que los operadores adaptaran el modelo al dispositivo que más usamos: el smartphone. Pero la transición no fue directa. Android impone restricciones que hacen inviable replicar el cifrado masivo de un LockBit o BlackCat. La respuesta de los atacantes fue pragmática: si no puedes cifrar todo, bloquea la pantalla.
El resultado son dos categorías de ransomware móvil con mecánicas muy distintas, vectores de distribución propios del ecosistema móvil y técnicas de abuso de APIs de Android que todo analista SOC debe reconocer.
Dos tipos de ransomware móvil
El ransomware en Android se divide en dos categorías fundamentales que difieren en complejidad técnica, impacto real y dificultad de recuperación.
Screen lockers (lockers de pantalla)
Los screen lockers representan la mayoría del ransomware móvil. No cifran archivos. Su único mecanismo es impedir el acceso al dispositivo mostrando una pantalla de rescate persistente que el usuario no puede cerrar.
| Característica | Detalle |
|---|---|
| Cifrado de archivos | No |
| Mecanismo principal | Overlay a pantalla completa o cambio de PIN |
| Impacto real | Denegación de acceso temporal |
| Recuperación | Safe Mode, ADB, factory reset |
| Complejidad técnica | Baja a media |
| Rescate típico | 50 a 200 USD en gift cards o criptomonedas |
Los screen lockers explotan el hecho de que la mayoría de usuarios no saben arrancar en Safe Mode ni conectar ADB. Desde un punto de vista técnico son triviales de eliminar. Desde la perspectiva del usuario medio son devastadores.
Crypto-ransomware móvil
Los crypto-ransomware cifran archivos reales del almacenamiento del dispositivo. Son significativamente menos comunes en móvil que en escritorio por varias razones: Android limita el acceso al almacenamiento (especialmente desde Android 11 con Scoped Storage), los archivos críticos del usuario suelen estar sincronizados en la nube, y la capacidad de cifrado en hardware móvil es inferior a la de un PC.
| Característica | Detalle |
|---|---|
| Cifrado de archivos | Sí (almacenamiento externo, fotos, documentos) |
| Mecanismo principal | AES-256 o similar sobre archivos del usuario |
| Impacto real | Pérdida de datos no respaldados |
| Recuperación | Backup en la nube o pérdida de datos |
| Complejidad técnica | Media a alta |
| Rescate típico | 100 a 500 USD en criptomonedas |
Familias notables
DoubleLocker (2017)
DoubleLocker marcó un punto de inflexión al combinar ambos tipos de ataque en una sola familia. Documentado por ESET en octubre de 2017, fue el primer ransomware Android que implementó cifrado real de archivos junto con bloqueo de pantalla.
Cadena de infección: se distribuía como una actualización falsa de Adobe Flash Player. Al instalarse, solicitaba permisos de Accessibility Service. Con esos permisos activaba Device Admin, cambiaba el PIN del dispositivo a un valor aleatorio y cifraba archivos del almacenamiento externo con AES.
Características técnicas destacables:
- Doble mecanismo: cambiaba el PIN (bloqueando la pantalla) y cifraba archivos (destruyendo datos). Ninguno de los dos mecanismos dependía del otro.
- Accessibility Service abuse: usaba el servicio de accesibilidad para simular pulsaciones y activar Device Admin sin interacción del usuario visible.
- Cifrado AES: cada archivo se cifraba con AES y se renombraba con extensión
.cryeye. - Rescate: 0.0130 BTC (aproximadamente 54 USD en ese momento), pagadero en 24 horas.
La recuperación era posible de dos formas: factory reset (perdiendo datos no cifrados) o, si el dispositivo tenía root y modo debug activo antes de la infección, se podía resetear el PIN vía ADB.
MalLocker (2020)
Detectado por Microsoft en octubre de 2020, MalLocker.B representó una evolución en técnicas de evasión y bloqueo de pantalla. A diferencia de las familias anteriores que usaban overlays TYPE_SYSTEM_ALERT (bloqueados en Android 8+), MalLocker abusaba de dos mecanismos legítimos del sistema.
Técnicas de bloqueo:
- Notificaciones de llamada: usaba la categoría de notificación
callque Android muestra a pantalla completa en la pantalla de bloqueo, diseñada para llamadas entrantes. - onUserLeaveHint(): interceptaba este callback del ciclo de vida de Activity, que se invoca cuando el usuario intenta salir de la app (botón Home). MalLocker relanzaba su Activity inmediatamente, impidiendo la salida.
Evasión de detección:
- El código malicioso se almacenaba en la carpeta
assets/del APK como un archivo cifrado, no enclasses.dex. Esto evadía análisis estáticos que solo examinaban el bytecode Dalvik. - Usaba un esquema de machine learning básico (un perceptrón de dos capas) para clasificar si estaba siendo analizado en un entorno de sandbox o en un dispositivo real.
CovidLock (2020)
CovidLock aprovechó la pandemia de COVID-19 para su distribución. Se disfrazaba como una app de seguimiento de casos de coronavirus, descargable desde un sitio web que imitaba interfaces oficiales de salud pública.
Una vez instalada y con permisos de Device Admin otorgados, cambiaba el PIN de la pantalla de bloqueo y mostraba un mensaje exigiendo 100 USD en Bitcoin. El mensaje amenazaba con borrar contactos, fotos y la memoria del teléfono si no se pagaba en 48 horas.
Debilidad criptográfica: investigadores de DomainTools descubrieron que el PIN generado era predecible. La función de generación usaba un seed estático combinado con un valor derivado del timestamp de instalación. Esto permitió publicar una herramienta de desbloqueo que generaba el PIN correcto para cada dispositivo infectado.
Vectores de distribución
El ransomware móvil no se distribuye como el de escritorio. No hay exploits de red tipo EternalBlue ni movimiento lateral por SMB. Los vectores son específicos del ecosistema móvil.
Tiendas de aplicaciones de terceros
La fuente principal. Tiendas alternativas como APKPure, APKMirror o mercados regionales (Tencent MyApp, Xiaomi GetApps) tienen controles de seguridad significativamente inferiores a Google Play. Los atacantes suben apps que imitan aplicaciones populares: reproductores de vídeo, herramientas de limpieza, apps de linterna.
Descarga directa (sideloading)
Links a APKs enviados por SMS, WhatsApp, Telegram o email. El pretexto más común es una actualización urgente del sistema, un códec de vídeo necesario para ver contenido o una app exclusiva no disponible en la tienda oficial.
Google Play Store
Casos menos frecuentes pero documentados. Los atacantes usan técnicas de dropper: la app inicial pasa los controles de Google Play Protect porque es benigna. Una vez instalada, descarga el payload malicioso desde un servidor externo. Google elimina estas apps cuando las detecta, pero la ventana de exposición puede ser de días a semanas.
Phishing y smishing
Mensajes SMS o de mensajería con enlaces a páginas que simulan alertas del sistema operativo o del operador de telecomunicaciones. El usuario descarga e instala manualmente la app maliciosa creyendo que es legítima.
Abuso de Device Admin API
La API de Device Administration de Android fue diseñada para aplicaciones empresariales de gestión de dispositivos (MDM). Proporciona capacidades que el ransomware explota directamente.
Capacidades que explota el ransomware
USES_POLICY_FORCE_LOCK → lockNow(): bloquea el dispositivo inmediatamente
USES_POLICY_RESET_PASSWORD → resetPassword(): cambia el PIN/contraseña
USES_POLICY_WIPE_DATA → wipeData(): factory reset (amenaza de destrucción)
El flujo típico de abuso:
- La app solicita al usuario activar Device Admin con un diálogo que imita una actualización del sistema.
- El usuario acepta, otorgando privilegios elevados.
- La app invoca
resetPassword("nuevo_pin")para bloquear la pantalla con un PIN desconocido para el usuario. - Muestra la nota de rescate.
- Si el usuario intenta desinstalar la app, Device Admin impide la desinstalación (requiere desactivar Device Admin primero, lo cual la app no permite).
Mitigación en versiones recientes
Google ha restringido progresivamente estas APIs:
- Android 7.0:
resetPassword()ya no funciona si el usuario tenía un PIN configurado previamente. Solo puede establecer PIN en dispositivos sin protección. - Android 9.0: las apps con Device Admin solo pueden establecer requisitos de complejidad de contraseña, no cambiarla directamente.
- Android 10+: Device Admin está deprecado a favor de Device Owner y Profile Owner, que requieren provisioning especial (NFC, QR code o cuenta gestionada).
Estas restricciones explican por qué el ransomware móvil moderno se apoya más en overlays y Accessibility Service que en Device Admin directamente.
Overlays de pantalla de rescate
Los overlays son ventanas que se dibujan encima de todas las demás aplicaciones. Android permite esto para funcionalidades legítimas como burbujas de chat o controles de reproducción. El ransomware los usa para cubrir toda la pantalla con la nota de rescate.
Evolución de las técnicas de overlay
| Versión Android | Técnica | Estado |
|---|---|---|
| Android 4-7 | TYPE_SYSTEM_ALERT | Funciona sin restricciones |
| Android 8+ | TYPE_APPLICATION_OVERLAY | Requiere permiso SYSTEM_ALERT_WINDOW (el usuario puede denegar) |
| Android 10+ | Restricciones adicionales | Las overlays no pueden interceptar toques en la barra de navegación |
| Android 12+ | Overlay sobre notificaciones | Bloqueado para apps de terceros |
Las familias modernas como MalLocker evitan overlays tradicionales y abusan de mecanismos del sistema (notificaciones de llamada, Activity relaunching) que no están sujetos a las mismas restricciones.
Anatomía de una pantalla de rescate móvil
Las notas de rescate en móvil difieren de las de escritorio. Elementos típicos:
- Logos oficiales falsos: escudos policiales, logos del FBI, Europol o policía nacional del país de la víctima.
- Acusación falsa: el dispositivo ha sido bloqueado por visitar contenido ilegal (pornografía, piratería). Este enfoque aprovecha el miedo y la vergüenza para que la víctima pague sin investigar.
- Pago en gift cards: a diferencia del ransomware de escritorio que pide Bitcoin, el ransomware móvil frecuentemente solicita tarjetas de regalo de Google Play, iTunes o Amazon. El motivo es pragmático: los usuarios móviles tienen acceso más fácil a gift cards que a exchanges de criptomonedas.
- Temporizador: cuenta regresiva que amenaza con borrar todos los datos o enviar el historial de navegación a los contactos.
Implementación del cifrado en Android
Los crypto-ransomware móviles enfrentan desafíos técnicos que no existen en escritorio.
Acceso al almacenamiento
Android ha restringido progresivamente el acceso al almacenamiento:
- Android 10: Scoped Storage limita el acceso a archivos a los propios de la app. Acceder a otros archivos requiere MediaStore API o Storage Access Framework (SAF).
- Android 11+: MANAGE_EXTERNAL_STORAGE requiere justificación y aprobación de Google Play. Las apps fuera de Play Store pueden solicitarlo, pero necesitan que el usuario lo active manualmente en Configuración.
- Android 13+: permisos granulares para fotos, vídeos y audio por separado.
Los crypto-ransomware móviles típicamente apuntan a las rutas que aún son accesibles:
/sdcard/DCIM/ → fotos de la cámara
/sdcard/Download/ → descargas
/sdcard/Documents/ → documentos
/sdcard/Pictures/ → imágenes
/sdcard/WhatsApp/Media → fotos y vídeos de WhatsApp
Cifrado típico
Las familias que implementan cifrado real (DoubleLocker, Simplocker, CryCryptor) usan esquemas más simples que sus equivalentes de escritorio:
- AES-256 en modo CBC o ECB: sin cifrado híbrido RSA en la mayoría de casos. La clave AES se envía al C2 o se genera de forma predecible.
- Sin cifrado parcial: los archivos móviles son generalmente pequeños (fotos, documentos), por lo que el cifrado completo no genera los problemas de rendimiento que motivan el cifrado intermitente en escritorio.
- Extensiones objetivo limitadas: .jpg, .png, .pdf, .doc, .xls, .zip, .mp4. Las familias móviles no buscan bases de datos corporativas ni discos virtuales.
Métodos de recuperación
La recuperación de un dispositivo afectado por ransomware móvil es generalmente más sencilla que en escritorio, especialmente para screen lockers.
Safe Mode (Modo seguro)
Arrancar en Safe Mode desactiva todas las aplicaciones de terceros, incluyendo el ransomware. Desde ahí se puede desinstalar la app maliciosa y desactivar Device Admin.
Cómo acceder: mantener pulsado el botón de apagar hasta que aparezca la opción "Modo seguro". El procedimiento varía según fabricante (Samsung, Xiaomi, etc.).
ADB (Android Debug Bridge)
Si el modo debug estaba activado antes de la infección:
adb shell pm list packages | grep sospechoso
adb shell pm uninstall com.paquete.malicioso
adb shell locksettings clear --old 0000
Factory reset
El último recurso. Elimina todo el ransomware pero también todos los datos del usuario. Los datos sincronizados con Google (contactos, fotos en Google Photos, documentos en Drive) se recuperan al iniciar sesión de nuevo.
Herramientas de descifrado
Para crypto-ransomware con debilidades criptográficas (como CovidLock o Simplocker), investigadores de seguridad publican herramientas de descifrado. ESET, Avast y Kaspersky han publicado decodificadores para familias móviles específicas.
Prevención
Para usuarios
- No instalar APKs fuera de la tienda oficial. Si es necesario, verificar el hash y la fuente.
- No otorgar permisos de Accessibility Service a apps que no los necesiten legítimamente.
- No activar Device Admin para apps que no sean MDM corporativo.
- Mantener backups automáticos en Google Photos, Google Drive o similar.
- Actualizar Android a la última versión disponible para el dispositivo.
Para organizaciones
- MDM con políticas de apps: whitelist de apps permitidas, bloqueo de sideloading.
- Google Play Protect activo: verificación continua de apps instaladas.
- MTD (Mobile Threat Defense): soluciones como Lookout, Zimperium o CrowdStrike Falcon Mobile que detectan comportamientos de ransomware en tiempo real.
- Formación: concienciar sobre los vectores de distribución móvil específicos.
MITRE ATT&CK Mobile
Las técnicas ATT&CK del framework Mobile más relevantes para ransomware Android:
| Técnica | ID | Uso en ransomware |
|---|---|---|
| Masquerading: Match Legitimate Name | T1655.001 | Apps disfrazadas de actualizaciones del sistema |
| Input Capture: GUI Input Capture | T1417.002 | Overlay de pantalla de rescate |
| Device Lockout | T1447 | Bloqueo de pantalla mediante Device Admin |
| Data Encrypted for Impact | T1471 | Cifrado de archivos (crypto-ransomware) |
| Abuse Elevation Control Mechanism | T1626 | Abuso de Device Admin y Accessibility Service |
| Phishing | T1660 | Distribución vía SMS y mensajería |
| Foreground Persistence | T1541 | Activity relaunching para mantener el overlay |
Recursos
- ESET: DoubleLocker analysis (reporte técnico original)
- Microsoft: MalLocker.B analysis (técnicas de evasión)
- MITRE ATT&CK Mobile (matriz completa de técnicas móviles)
- Google: Device Admin deprecation (documentación oficial)
- NoMoreRansom.org (herramientas de descifrado para familias específicas)
- NIST SP 1800-21: Mobile Device Security (guía de seguridad empresarial)
Preguntas frecuentes
Libros recomendados
Artículos relacionados
Este contenido tiene fines exclusivamente educativos y de investigación en ciberseguridad defensiva. No se proporcionan binarios maliciosos ni payloads ejecutables. El uso indebido de esta información es responsabilidad exclusiva del usuario. Leer disclaimer completo.