Group-IB published an analysis of a new RedHook Android remote access trojan variant that achieves shell-level privileges on Android devices without rooting them, using a technique that turns the infected phone into its own Android Debug Bridge client through the device’s loopback interface. The approach converts a standard Accessibility Service abuse into persistent elevated access, bypassing root-detection mechanisms used by banking and enterprise mobile applications.
How RedHook’s New Variant Exploits Android’s Wireless Debugging Feature
RedHook is a remote access trojan with capabilities including screen streaming, keystroke interception, automated UI interactions, and credential theft. The new variant analyzed by Group-IB adds a novel escalation path that exploits Android’s Wireless Debugging feature — a developer tool introduced for ADB connections over Wi-Fi — by initiating a connection from the device to itself.
The Accessibility Service Grant That Enables Wireless Debugging and ADB Pairing
The attack begins when the malware tricks the user into granting Accessibility Service permission. This is the sole required user interaction; no additional grants are needed after this point. Using Accessibility Services, RedHook automatically enables Developer Options and then activates Wireless Debugging on the device — features normally toggled manually in Android’s developer settings. The malware then reads the Wireless Debugging pairing code directly from the screen using the same Accessibility Service access, giving it the credential needed to authorize an ADB connection. RedHook then connects to the device’s own ADB service through the loopback address 127.0.0.1, authenticating with the captured pairing code and achieving UID 2000 — Android’s shell-level privilege tier.
Shizuku Framework Deployment After RedHook Achieves UID 2000 Shell Access
After obtaining shell-level access via loopback ADB, RedHook deploys Shizuku, a legitimate Android developer framework designed to let applications run with elevated privileges by communicating with a shell-level service. Shizuku is ordinarily used by developers who need to automate device operations without a full root environment. In RedHook’s hands, it becomes the mechanism for executing privileged commands on the compromised device after ADB shell access establishes the required UID 2000 permission level. The technique works across all Android devices where the initial Accessibility Service permission is granted, and it requires neither device rooting nor physical access to the handset.
Why the Loopback ADB Technique Bypasses Root Detection in Banking and Enterprise Apps
The security architecture of many banking and enterprise Android applications includes root detection as a defense layer: if the application detects that the device is rooted, it refuses to run or denies access to sensitive functions. These checks are a response to the risk that a rooted device gives malware unrestricted access to app data and memory. RedHook’s new technique avoids triggering these checks by never rooting the device. The device’s security model from Android’s perspective remains intact — the bootloader is not unlocked, the kernel has not been modified, and root certificates are unchanged. The elevated capabilities come through a chain of permitted features — Accessibility Services, Developer Options, Wireless Debugging, and a developer framework — that Android does not flag as compromised.
Group-IB did not attribute the updated RedHook variant to a specific threat actor.
The Broader Implication for Organizations Relying on Root Detection as a Security Control
The technique Group-IB documented does not exploit a vulnerability in Android’s Wireless Debugging feature. It exploits the combination of Accessibility Service permissions and the design of Wireless Debugging to reach a privilege level that developers legitimately need but that RedHook repurposes for persistent shell access. This distinction matters for organizations that enforce mobile device management policies: root detection remains a useful control, but it does not address malware that achieves elevated capabilities through Android’s permitted developer tooling. Any application that accepts an initial Accessibility Service grant without subsequent behavioral monitoring is potentially exposed to the full RedHook capability set, including screen streaming, credential interception, automated UI manipulation, and now persistent loopback shell access that can survive the removal of the initial Accessibility Service permission if the ADB session remains active.
Defenders with Android device fleets should review MDM policies for Accessibility Service permission grants to unverified applications and consider whether Developer Options and Wireless Debugging should be disabled by policy on managed devices.
