ctipilot.ch
← Back to the live brief
NOTABLEthreatNATOB2

RedHook Android RAT abuses ADB Wireless Debugging to self-grant shell (uid 2000) privileges without an exploit

discovered 2026-07-09 12:30 UTCrun 2026-07-09T1211Z-intel1 sourcesingle-source

Group-IB documents a significantly upgraded variant of RedHook, an Android RAT first described by Cyble in July 2025 and previously focused on Vietnamese banking users (Group-IB, 2026-07-09). The notable new capability is self-service privilege abuse over ADB Wireless Debugging with no exploit involved. After the victim is socially engineered — via impersonation calls/messages and a fake Play-Store-styled site — into installing the APK and granting Accessibility through a "required setup" walkthrough, the malware uses Accessibility-driven UI automation to silently navigate Settings, enable Developer Options and Wireless Debugging, then embeds its own ADB client to connect to the device's own ADB daemon over the loopback interface (127.0.0.1) — no PC or USB cable needed. It launches a Shizuku-derived privileged helper that runs under shell uid 2000, from which it grants itself runtime permissions, sets WRITE_SECURE_SETTINGS, installs/uninstalls apps and executes shell commands with no user-facing confirmation dialogs. Group-IB states plainly that "there is no exploit here" — this is abuse of a legitimate developer feature, the same primitive tools like Shizuku have long used, weaponised for the first time by malware.

Persistence is layered: a 1×1-pixel foreground activity, silent MediaSession audio, a foreground-service WakeLock, two mutually cross-rebinding services (bindService with BIND_AUTO_CREATE) that resurrect each other, oom_score_adj tuning to -1000, mlock() memory pinning, and a BOOT_COMPLETED receiver that re-establishes Wireless ADB and the helper on every reboot; screen streaming runs over WebSocket with a parallel RTMP stream once shell privileges exist, bypassing the MediaProjection consent dialog. The command set has grown to 53 server-issued commands, APK payloads are hosted on GitHub and AWS S3 for delivery reliability, and OEM-specific UI-automation routines (Google, Huawei, Meizu, Oppo, Samsung, Vivo, Xiaomi) are present but not yet invoked — suggesting planned device-coverage expansion. Mapped for mobile defenders to T1453 Abuse Accessibility Features, T1541 Foreground Persistence, T1512 Video Capture, T1417 Input Capture, and — closest available mapping for the shell-uid grab — T1626 Abuse Elevation Control Mechanism.

This, however, is the first time we have seen it used by a malware to abuse privileges on a victim's device.

There is no exploit here, "merely" turning a debugging interface into a path to shell-level privileges.

Group-IB 2026-07-09

Defender actions

  • On MDM/Android-Enterprise-managed fleets, disable Developer Options and USB/Wireless debugging by default (DevicePolicyManager setDebuggingFeaturesAllowed or equivalent restriction) so an app cannot self-enable the ADB path.
  • Hunt for the abuse pattern: any non-system app programmatically flipping Settings.Global adb_wifi_enabled / enabling Developer Options without an IT-initiated pairing flow, or a non-ADB process binding a loopback (127.0.0.1) ADB connection, is anomalous on a managed device and should alert.
  • Gate BIND_ACCESSIBILITY_SERVICE to an approved allowlist and treat off-store APKs delivered via 'required setup' walkthroughs on spoofed government/financial sites as the initial-access vector to block.
PROVENANCE

AI-generated · no human review · this permalink is the shareable record for the finding · verify operationally critical claims against the linked primary source.