Shizuku, la herramienta legítima que da a los malware las llaves de Android

Análisis técnico

Shizuku es una herramienta open source legítima, muy apreciada por los usuarios avanzados de Android. Permite a una aplicación obtener los privilegios de un técnico sin rootear el teléfono. El malware RedHook, aparecido en 2025, demostró que estas capacidades también interesan a los atacantes: su variante analizada en julio de 2026 reutilizaba el código de Shizuku para concederse esos privilegios sin explotar ninguna vulnerabilidad.

Nuestros expertos quisieron medir con precisión lo que esta herramienta pone en manos de una aplicación. Desarrollaron una aplicación de prueba, ejecutaron 41 comandos con y sin Shizuku en Android 16 y reprodujeron después cuatro escenarios de abuso. Esto es lo que observaron, y cómo detectar Shizuku en un dispositivo.

Shizuku, la credencial del técnico prestada a las aplicaciones

En Android, cada aplicación vive en un sandbox. Solo ve sus propios datos y debe obtener cada permiso sensible mediante una ventana de confirmación. El shell ADB, que utilizan los desarrolladores cuando controlan el teléfono desde un ordenador, dispone de derechos mucho más amplios. Puede leer todo el registro logcat, de todas las aplicaciones y componentes del sistema (el registro del kernel, en cambio, sigue denegado), listar todas las aplicaciones, modificar ajustes protegidos o controlar el instalador.

Durante mucho tiempo, una aplicación que quería estos derechos tenía que exigir root, lo que suele implicar un bootloader desbloqueado: la integridad del dispositivo deja de estar garantizada y las aplicaciones que se basan en Play Integrity, en particular las bancarias, pueden negarse a funcionar. Shizuku propone una tercera vía. No eleva la aplicación, le presta la identidad del shell.

Cómo funciona

1. El usuario inicia un servidor Shizuku mediante ADB, por cable o por depuración inalámbrica. Este servidor se ejecuta con la identidad shell (uid 2000), en un proceso distinto de la propia aplicación Shizuku.
2. Una aplicación cliente solicita la autorización para utilizar este servidor. El usuario la acepta una sola vez.
3. A continuación, la aplicación transmite sus comandos al servidor, que los ejecuta con sus propios derechos.

Para un experto, el punto clave está en el contrato de interfaz que utiliza nuestra aplicación de prueba. El servidor carga y ejecuta código proporcionado por la aplicación cliente, y ese código acepta una cadena arbitraria:

// IUserService.aidl
interface IUserService {
    String run(String command);   // cualquier comando
}

No existe ninguna lista blanca de operaciones. Lo que se delega es una identidad, no una capacidad concreta. Una aplicación autorizada puede hacer todo lo que puede hacer el shell.

Los usos legítimos son numerosos: gestores de paquetes alternativos, eliminación de aplicaciones preinstaladas, copias de seguridad, automatización, cortafuegos. Es precisamente lo que lo convierte en un problema de seguridad. Un mecanismo diseñado para eludir legítimamente el sandbox sigue siendo, por construcción, un mecanismo para eludir el sandbox.

Shizuku también funciona en modo root (uid 0), con derechos aún más amplios. Nuestras mediciones se refieren únicamente al modo ADB, el más accesible, ya que no requiere root. Los resultados que siguen son, por tanto, un mínimo.

Lo que midieron nuestros expertos

De 41 comandos, 27 devuelven estrictamente más información cuando pasan por Shizuku. El protocolo es sencillo: el mismo comando se ejecuta dos veces, una por la propia aplicación y otra a través de Shizuku. Solo cambia la identidad del proceso.

Gran parte de estas diferencias se explica por una sola barrera. Las herramientas settings, cmd, pm o appops empiezan por identificar al usuario actual, lo que exige el permiso INTERACT_ACROSS_USERS. Solo el shell, el sistema y root lo poseen. Shizuku no desbloquea, por tanto, trece capacidades independientes: franquea una barrera tras la cual todo el utillaje del shell queda disponible.

Las diferencias de visibilidad son igual de reveladoras:

Sin Shizuku, la aplicación solo ve literalmente sus propios procesos. Con él, obtiene el mismo inventario que un adb shell: la lista completa de paquetes del usuario y todos los procesos visibles para el shell, incluidos init, los procesos root y los hilos del kernel.

Demostración 1: leer los logs de otras aplicaciones, códigos OTP incluidos

Otro proceso escribe dos secretos en el registro del sistema, como haría una aplicación demasiado locuaz: un falso código de validación bancaria y un token de autenticación. La aplicación de prueba ejecuta después logcat -d -s OTPDEMO:I.

[A través de Shizuku]
I OTPDEMO : Your MyBank verification code is 471953 - do not share it
I OTPDEMO : Bearer eyJhbGciOiJIUzI1NiJ9.demo.token

[Sin Shizuku]
(ninguna salida)

El permiso READ_LOGS está reservado a los componentes firmados por la plataforma. En el dispositivo, su nivel de protección es signature|privileged|development, fuera del alcance de una aplicación de Play Store. El shell, en cambio, pertenece al grupo log (1007), que levanta este filtro. Cualquier secreto escrito en el registro del sistema sigue siendo legible, mientras permanezca en el búfer circular de logd, por cualquier aplicación que el usuario haya autorizado en Shizuku. Una aplicación no autorizada solo ve sus propias líneas.

Demostración 2: instalar una aplicación sin ninguna pantalla

La carga útil es un APK inofensivo de 8,5 KB, sin ningún código. Nuestros expertos lo probaron en dos mediciones distintas. La primera aísla la barrera de permisos: sin Shizuku, el comando pm install-create se deniega desde la apertura de la sesión (INTERACT_ACROSS_USERS_FULL). La aplicación sí puede abrir una sesión mediante la API PackageInstaller, pero el commit queda a la espera de una acción del usuario y no se instala ningún paquete.

pm install-create

[A través de Shizuku]
Success: created install session [1908906140]

[Sin Shizuku]
java.lang.SecurityException: Permission Denial: doCreateSession ...
    this requires android.permission.INTERACT_ACROSS_USERS_FULL

La segunda medición demuestra la instalación de principio a fin: a través de Shizuku, pm install -r devuelve Success (el APK debe ser legible por el sistema: colocado en /data/local/tmp o transmitido por la entrada estándar con pm install -S, ya que SELinux deniega un archivo situado en Android/data) y la aplicación aparece después en la lista de paquetes instalados.

No se mostró ninguna ventana. Nuestros expertos lo comprobaron de tres maneras: la aplicación de prueba permaneció en primer plano durante toda la ejecución, no se inició ninguna activity del instalador (en el sentido de Android: ninguna ventana), aunque el registro del sistema recoge la propia instalación y el despertar del proceso del instalador para difundir el evento PACKAGE_ADDED, y las capturas de pantalla nunca muestran una pantalla de instalación. Es el comportamiento típico de un dropper, que descarga e instala otros malware.

Demostración 3: concederse un permiso sin popup

Solo para esta demostración, la aplicación de prueba se modificó para declarar dos permisos sensibles, el acceso a los contactos y a los SMS, sin solicitarlos. A continuación ejecuta pm grant únicamente sobre los contactos. Los SMS sirven de testigo. La aplicación consulta a Android antes y después:

ANTES    READ_CONTACTS  granted=false
ANTES    READ_SMS       granted=false
DESPUÉS  READ_CONTACTS  granted=true    ← concedido, sin ninguna interacción
DESPUÉS  READ_SMS       granted=false   ← testigo sin cambios

La ventana de permisos es el mecanismo de consentimiento de Android desde la versión 6. Aquí, la aplicación lo elude por completo. Como el permiso se ha concedido realmente, todas las llamadas siguientes parecen legítimas a ojos del sistema. Nada impide hacer lo mismo con la ubicación, el micrófono o la cámara.

Demostración 4: elaborar el perfil completo del dispositivo

A través de Shizuku, la aplicación recupera el android_id del shell (el que devuelve adb shell settings get secure android_id, común a todas las aplicaciones que pasan por Shizuku o adb, y distinto del android_id propio de la aplicación, que esta ya lee sin ningún permiso), el número de serie, la lista de las 261 aplicaciones con su ubicación, las cuentas registradas y las estadísticas de uso de las últimas 24 horas.

Lo más intrusivo sigue siendo la tabla de conexiones de red (/proc/net/tcp y /proc/net/tcp6), que asocia cada conexión al identificador de la aplicación que la mantiene. Cruzada con cmd package list packages -U, revela qué aplicación habla con qué servidor. Todo ello sin ningún permiso de red.

Más allá de las demostraciones

En modo ADB, Shizuku no abre los datos privados de las demás aplicaciones: la carpeta /data/data sigue denegada al shell. Una aplicación no puede, por tanto, leer directamente la base de datos de una aplicación bancaria, siempre que esta no esté marcada como debuggable. Solo un paquete debuggable se abre al shell, mediante run-as. En cambio, Shizuku permite leer el IMEI, capturar la pantalla y simular gestos: RedHook lo utiliza para capturar la pantalla sin ventana de consentimiento.

Por qué es un punto ciego

Shizuku no es una vulnerabilidad. Es una funcionalidad utilizada conforme a su diseño y, por tanto, no hay nada que corregir, ni en Shizuku ni en Android. Lo que cambia es el modelo de consentimiento.

El usuario que instala Shizuku lo hace para un uso legítimo. Nada le indica que autorizar una aplicación equivale a cederle sus logs, el inventario de sus aplicaciones y el derecho a concederse permisos.

Otro punto destacable: detectar Shizuku no requiere ningún privilegio. Nuestra aplicación de prueba sabe si un servidor está en marcha incluso antes de haber obtenido la menor autorización. Una aplicación maliciosa puede, por tanto, permanecer latente en los dispositivos sin Shizuku y actuar solo donde vaya a tener éxito.

RedHook va más allá

El escenario probado supone que el propio usuario ha instalado e iniciado Shizuku. RedHook prescinde de ello. Una vez obtenidos los derechos de accesibilidad mediante ingeniería social, activa por sí solo las opciones para desarrolladores y la depuración inalámbrica. Después se empareja con el servicio ADB del propio teléfono y despliega su propio servidor basado en Shizuku. Tras un reinicio, reactiva la depuración y recupera sus privilegios en pocos segundos.

Las capacidades medidas en nuestras demostraciones coinciden con las que explota: instalación silenciosa de aplicaciones, modificación de ajustes protegidos y concesión de permisos sin ventana de confirmación.

Cómo detectar Shizuku

Cuatro señales deben alertar en un dispositivo.

• Opciones para desarrolladores activadas. Son el requisito previo del modo ADB.
• Depuración USB o inalámbrica activa. La depuración inalámbrica permite relanzar Shizuku sin cable, y RedHook la activa por sí mismo.
• Aplicación Shizuku instalada. Revela un uso de la herramienta, legítimo o no.
• Aplicación desconocida con acceso a la accesibilidad. Es la puerta de entrada de RedHook, que incorpora su propio servidor basado en Shizuku y, por tanto, no aparece con ese nombre en la lista de aplicaciones.

Para los equipos técnicos, mediante ADB

Los equipos técnicos pueden comprobar estos puntos desde un equipo conectado, con los comandos que utilizaron nuestros expertos en su banco de pruebas:

# Depuración USB e inalámbrica (1 = activada)
adb shell settings get global adb_enabled
adb shell settings get global adb_wifi_enabled

# Servidor Shizuku activo
adb shell ps -A -o USER,PID,NAME | grep -i shizuku

Si hay un servidor activo, el último comando devuelve un proceso shizuku_server ejecutado con la identidad shell.

Para los editores de aplicaciones sensibles

Una aplicación puede detectar Shizuku desde su sandbox, sin autorización especial. Nuestra aplicación de prueba combina tres enfoques complementarios: las huellas de instalación, la respuesta del servidor y las huellas del sistema.

El ping no requiere ninguna biblioteca: una aplicación que declara el permiso moe.shizuku.manager.permission.API_V23 y expone un provider <package>.shizuku recibe de Shizuku un bundle que contiene su binder, y un pingBinder() sobre ese binder responde verdadero o falso.

Cómo responde Pradeo

Comprobar cada teléfono a mano no es viable a escala de una flota. La solución Mobile Threat Defense de Pradeo supervisa de forma continua, en todos los dispositivos, las condiciones que hacen explotable Shizuku:

• Configuraciones de riesgo. Señala cualquier activación anómala de las opciones para desarrolladores y de la depuración inalámbrica, requisitos previos del modo ADB de Shizuku.
• Permisos críticos. Cualquier aplicación que solicite acceso a la accesibilidad se señala como potencialmente maliciosa.
• Aplicaciones fuera de las tiendas oficiales. Detecta las apps instaladas desde otra fuente, el modo de distribución de RedHook.
• Phishing móvil. El bloqueo de los enlaces fraudulentos recibidos por SMS o mensajería instantánea, canales de difusión de RedHook, corta la cadena de infección desde el origen.

Para los editores de aplicaciones, nuestra solución Runtime Application Self Protection detecta cuando una aplicación se ejecuta en un teléfono en modo desarrollador, requisito previo del modo ADB de Shizuku. La aplicación sabe así que se ejecuta en un entorno de riesgo y puede reaccionar antes de que un tercero abuse de esos privilegios.