Variantes del RAT Hook que Google Play Protect no detecta — análisis técnico

Publicado el 2026-05-16 por el equipo de investigación de seguridad de Droidwatch

Hook es un RAT bancario de Android (troyano de acceso remoto) documentado
públicamente por primera vez por ThreatFabric en enero de 2023. A diferencia de
su predecesor ERMAC, centrado de forma acotada en ataques de overlay para robo
de credenciales, Hook es un RAT con todas las funciones: ofrece streaming en
tiempo real de la pantalla del dispositivo, exfiltración de archivos,
interceptación de SMS y la capacidad de cometer fraude on-device simulando la
entrada del usuario mediante la API de Accesibilidad.

Pese a sus capacidades, las variantes recientes de Hook (v2.1+) eluden de forma
consistente el escáner ML on-device de Google Play Protect. Este post explica
exactamente cómo Hook evita la detección, cómo el análisis estático de Droidwatch
lo atrapa igualmente, y aporta un mapeo MITRE ATT&CK y una tabla de IOCs para
equipos de threat intelligence.

¿Qué es Hook?

Hook se vende como una suscripción Malware-as-a-Service (MaaS) a cibercriminales,
apuntando principalmente a clientes de entidades financieras en Europa,
Norteamérica y Australia. Capacidades clave:

• Fraude on-device (ODF): los operadores de Hook controlan el dispositivo en
  tiempo real desde un panel web. Pueden tocar, deslizar, escribir y navegar la
  UI sin que la víctima lo note — la pantalla parece bloqueada o muestra un
  overlay de carga.
• Robo de credenciales: ataques de overlay sobre más de 738 apps bancarias y
  de criptomonedas (según el conjunto de muestras v2.3 analizado en abril de 2026).
• Interceptación de 2FA: lee el contenido de SMS y notificaciones para
  capturar contraseñas de un solo uso antes de que la víctima las use.
• Robo de cookies: roba cookies de sesión de WebView de los portales web
  bancarios.
• Gestor de archivos: enumera y exfiltra el almacenamiento del dispositivo.
• Streaming de pantalla: stream MJPEG en vivo de la pantalla sobre WebSocket.

Cómo se le escapa a Play Protect

Google Play Protect combina análisis estático server-side y clasificación ML
on-device. Hook v2.1+ evade ambas capas con tres técnicas concretas:

1. Puente nativo para operaciones sensibles

Las versiones anteriores de Hook llamaban a AccessibilityService y a las APIs
de overlay directamente desde el bytecode DEX en Java/Kotlin, lo que el
clasificador estático de Play Protect detectaba trivialmente.

Las variantes nuevas mueven el código sensible a una librería nativa compilada
(libhook_bridge.so, a veces disfrazada como libutil_core.so). El código
nativo usa JNI para invocar las mismas APIs de Android, pero los call sites ya no
son visibles para el análisis estático a nivel de DEX.

El analizador nativo de Droidwatch (src/analyzer/native_analyzer.py)
desensambla los archivos .so con objdump / readelf y extrae los símbolos
importados. La presencia de exports JNI como
Java_com_hook_bridge_CoreBridge_initOverlay junto a imports de librerías de
sistema Android (libandroid.so, liblog.so) con strings de símbolos
relacionados con accesibilidad es una señal fiable.

2. Carga dinámica de DEX

Hook incluye un archivo DEX secundario cifrado almacenado en assets/. El DEX
primario lo descifra y lo carga en runtime usando DexClassLoader, de modo que
los archivos de clase maliciosos nunca están presentes en el APK en su forma
ejecutable.

// Primary DEX bootstrap (simplified decompile)
File optimizedDir = getDir("dex_opt", MODE_PRIVATE);
DexClassLoader loader = new DexClassLoader(
    getAssets().extractAssetToFile("payload.dex.enc"),  // encrypted blob
    optimizedDir.getAbsolutePath(),
    null,
    getClassLoader()
);
Class<?> core = loader.loadClass("com.hook.internal.Core");
core.getMethod("init", Context.class).invoke(null, this);

Droidwatch detecta este patrón de forma estática:
- Se marca la instanciación de DexClassLoader o PathClassLoader con una ruta
que apunta a assets/ o getFilesDir().
- Se marca por separado la presencia de blobs binarios cifrados en assets/
(detectados por la baja variación de entropía de Shannon — los datos cifrados
se agrupan cerca de 7,9–8,0 bits/byte).
- La combinación puntúa RULE_DYNAMIC_DEX_LOAD (severidad: high) y
RULE_ENCRYPTED_PAYLOAD (severidad: critical).

3. Abuso de intents de accesibilidad legítimos

En lugar de declarar un AccessibilityService directamente (lo que Play Protect
marca), algunas variantes de Hook usan un enfoque en dos etapas:
1. Primero se instala una app dropper (disfrazada de lector de PDF o
actualización del sistema).
2. El dropper usa
startActivity(Intent("android.settings.ACCESSIBILITY_SETTINGS")) para guiar
al usuario a la pantalla de ajustes de accesibilidad y luego usa eventos
TYPE_VIEW_SCROLLED de AccessibilityService para detectar cuándo el usuario
ha habilitado el servicio para la segunda app (el payload).

La app del payload nunca parece pedir accesibilidad en su propio manifest.
Droidwatch lo detecta cruzando los strings de acción de intent en el DEX con la
ausencia de una declaración de AccessibilityService en el manifest — una
incongruencia característica de las apps dropper.

Mapeo MITRE ATT&CK for Mobile

Tabla de IOCs

Los siguientes indicadores se asocian a la oleada de la campaña de Hook v2.1–v2.3
analizada entre febrero y mayo de 2026. Los hashes SHA-256 provienen de muestras
enviadas al threat feed público de Droidwatch.

Nota: todos los IOCs llevan [.] en los dominios para evitar clics
accidentales. Defang antes de usarlos. Los hashes SHA-256 completos están
disponibles vía la
API del threat feed de Droidwatch.

Divulgación responsable

Las apps dropper descritas en este post no se distribuyeron por Google Play. Se
distribuyeron mediante:
- Campañas de smishing suplantando servicios de paquetería.
- Enlaces de descarga de APK maliciosos en grupos de apps de mensajería.
- Tiendas de APK de terceros dirigidas a usuarios en regiones con acceso limitado
a Play Store.

Droidwatch envió todas las muestras identificadas al equipo de Android Security
de Google vía la Android Partner Vulnerability Initiative (APVI) y al portal de
envío público de ThreatFabric. Las firmas de Google Play Protect se actualizaron
en 72 horas tras nuestra divulgación inicial para las muestras de la oleada 1.
Las oleadas 2 y 3 siguen sin ser detectadas por Play Protect a la fecha de esta
publicación.

Animamos a los investigadores de seguridad que encuentren variantes de Hook a
enviar muestras al feed comunitario de Droidwatch (todos los envíos públicos se
anonimizan) y al programa de bug bounty de
Android Security de Google.

Detectar Hook con Droidwatch

Sube una muestra sospechosa de Hook en droidwatch.app.
Las siguientes reglas de detección se activan ante las variantes de Hook:

• RULE_NATIVE_BRIDGE_SENSITIVE_APIS — exports JNI que llaman a APIs de accesibilidad/overlay
• RULE_DYNAMIC_DEX_LOAD — DexClassLoader cargando desde assets o el directorio de archivos
• RULE_ENCRYPTED_PAYLOAD — blobs binarios de alta entropía en assets/
• RULE_ACCESSIBILITY_FULL — AccessibilityService con permiso y referencias de API
• RULE_OVERLAY_PERM_AND_STRING — permiso de overlay + TYPE_APPLICATION_OVERLAY
• RULE_SMS_INTERCEPT — BroadcastReceiver de SMS + READ_SMS + RECEIVE_SMS
• YARA_HOOK_RAT_V2 — regla YARA multi-string que cubre patrones de URL C2 y nombres de símbolos JNI

Una muestra de Hook v2.2 puntúa 88–94 / 100, veredicto: Malicioso.

Para equipos de threat intelligence enterprise que necesiten exports STIX 2.1,
alertas por webhook o acceso por API a IOCs en bloque, ve nuestro
plan Enterprise o contacta a
[email protected].