Hook RAT Variants That Google Play Protect Misses — A Technical Analysis

Published 2026-05-16 by the Droidwatch Security Research team

Hook is an Android banking RAT (Remote Access Trojan) first publicly documented
by ThreatFabric in January 2023. Unlike its predecessor ERMAC, which focused
narrowly on credential overlay attacks, Hook is a full-featured RAT: it provides
real-time device screen streaming, file exfiltration, SMS interception, and the
ability to perform on-device fraud by simulating user input through the
Accessibility API.

Despite its capabilities, recent Hook variants (v2.1+) consistently bypass
Google Play Protect's on-device ML scanner. This post explains exactly how Hook
avoids detection, how Droidwatch's static analysis catches it anyway, and
provides a MITRE ATT&CK mapping and IOC table for threat intelligence teams.

What is Hook?

Hook is sold as a Malware-as-a-Service (MaaS) subscription to cybercriminals,
primarily targeting customers of financial institutions in Europe, North America,
and Australia. Key capabilities:

• On-device fraud (ODF): Hook's operators control the device in real time via
  a web panel. They can tap, swipe, type, and navigate the UI without the victim
  noticing — the screen appears locked or shows a loading overlay.
• Credential harvesting: Overlay attacks on 738+ banking and cryptocurrency
  applications (as of the v2.3 sample set analyzed in April 2026).
• 2FA interception: Reads SMS and notification content to capture one-time
  passwords before they can be used by the victim.
• Cookie theft: Steals WebView session cookies from banking web portals.
• File manager: Enumerates and exfiltrates device storage.
• Screen streaming: Live MJPEG stream of the device screen over WebSocket.

How Play Protect misses it

Google Play Protect uses a combination of server-side static analysis and
on-device ML classification. Hook v2.1+ evades both layers through three
specific techniques:

1. Native bridge for sensitive operations

Earlier Hook versions called AccessibilityService and overlay APIs directly
from Java/Kotlin DEX bytecode, which was trivially matched by Play Protect's
static classifier.

Newer variants move the sensitive code into a compiled native library
(libhook_bridge.so, sometimes disguised as libutil_core.so). The native
code uses JNI to invoke the same Android APIs, but the call sites are no longer
visible to DEX-level static analysis.

Droidwatch's native analyzer (src/analyzer/native_analyzer.py) disassembles
the .so files using objdump / readelf and extracts imported symbols.
The presence of JNI exports like Java_com_hook_bridge_CoreBridge_initOverlay
alongside Android system library imports (libandroid.so, liblog.so) with
accessibility-related symbol strings is a reliable signal.

2. Dynamic DEX loading

Hook ships with an encrypted secondary DEX file stored in assets/. The primary
DEX decrypts and loads it at runtime using DexClassLoader, so the malicious
class files are never present in the APK in their executable form.

// 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 detects this pattern statically:
- DexClassLoader or PathClassLoader instantiation with a path pointing to
assets/ or getFilesDir() is flagged.
- The presence of encrypted binary blobs in assets/ (detected by low
Shannon entropy variation — encrypted data clusters near 7.9–8.0 bits/byte)
is flagged separately.
- The combination scores RULE_DYNAMIC_DEX_LOAD (severity: high) and
RULE_ENCRYPTED_PAYLOAD (severity: critical).

3. Abuse of legitimate accessibility intents

Instead of declaring an AccessibilityService directly (which Play Protect
flags), some Hook variants use a two-stage approach:
1. A dropper app is installed first (disguised as a PDF reader or system update).
2. The dropper uses startActivity(Intent("android.settings.ACCESSIBILITY_SETTINGS"))
to guide the user to the accessibility settings screen and then uses
AccessibilityService TYPE_VIEW_SCROLLED events to detect when the user has
enabled the service for the second (payload) app.

The payload app itself never appears to request accessibility in its own manifest.
Droidwatch detects this by cross-referencing the intent action strings in DEX
with the absence of an AccessibilityService declaration in the manifest —
a mismatch that is characteristic of dropper apps.

MITRE ATT&CK for Mobile mapping

IOC table

The following indicators are associated with the Hook v2.1–v2.3 campaign wave
analyzed between February and May 2026. SHA-256 hashes are from samples
submitted via the public Droidwatch threat feed.

Note: All IOCs are marked with [.] in domains to prevent accidental
click-through. Defang before use. Full SHA-256 hashes are available via the
Droidwatch threat feed API.

Responsible disclosure

The dropper apps described in this post were not distributed via Google Play.
They were distributed through:
- Smishing campaigns impersonating parcel delivery services
- Malicious APK download links in messaging app groups
- Third-party APK stores targeting users in regions with limited Play Store access

Droidwatch submitted all identified samples to Google's Android Security team
via the Android Partner Vulnerability Initiative (APVI) and to ThreatFabric's
public submission portal. Google Play Protect signatures were updated within
72 hours of our initial disclosure for the wave 1 samples. Waves 2 and 3
remain undetected by Play Protect as of this publication.

We encourage security researchers who encounter Hook variants to submit samples
to the Droidwatch community feed (all public submissions are anonymized) and
to Google's Android Security bug bounty program.

Detecting Hook with Droidwatch

Upload a suspected Hook sample at droidwatch.app.
The following detection rules activate on Hook variants:

• RULE_NATIVE_BRIDGE_SENSITIVE_APIS — JNI exports calling accessibility/overlay APIs
• RULE_DYNAMIC_DEX_LOAD — DexClassLoader loading from assets or files directory
• RULE_ENCRYPTED_PAYLOAD — High-entropy binary blobs in assets/
• RULE_ACCESSIBILITY_FULL — AccessibilityService with permission and API refs
• RULE_OVERLAY_PERM_AND_STRING — Overlay permission + TYPE_APPLICATION_OVERLAY
• RULE_SMS_INTERCEPT — SMS BroadcastReceiver + READ_SMS + RECEIVE_SMS
• YARA_HOOK_RAT_V2 — Multi-string YARA rule covering C2 URL patterns and JNI symbol names

A Hook v2.2 sample scores 88–94 / 100, verdict: Malicious.

For enterprise threat intelligence teams needing STIX 2.1 exports, webhook
alerts, or bulk IOC API access, see our Enterprise plan
or contact [email protected].