How RedHook Turns Android's Developer Settings Into an Open Backdoor

For years, the robust sandbox model of the Android operating system has successfully isolated applications, forcing malicious actors to seek complex root exploits to gain deep system access. However, a newly discovered evolution in mobile threats turns the platform's own native diagnostic tools into a silent weapon of compromise. By manipulating built-in developer features, the RedHook malware can now bypass standard app restrictions completely from within the device itself.

The Loopback Privilege Escalation Method

The core of this threat lies in the abuse of a feature first introduced in Android 11: Wireless ADB (Android Debug Bridge). Normally, this interface allows developers to execute shell commands on a mobile device from a desktop computer. However, cybersecurity analysts at Group-IB recently discovered that the latest iteration of the malware bypasses the need for an external computer entirely. Instead, the malware tricks the victim into enabling Accessibility permissions to turn the infected smartphone into its own debugging client.

Once the victim grants this initial permission, the malware programmatically navigates the device's Settings menu to activate Developer Options and turn on Wireless Debugging. It then scrapes the pairing code displayed on the screen and initiates a local connection to the system's ADB service via the loopback interface (127.0.0.1). This self-pairing maneuver elevates the malware's privileges to UID 2000, giving it shell-level access. While not a full root compromise, this permission level grants the Trojan unprecedented control over the operating system, bypassing standard application sandboxing.

Exploiting Shizuku for Privileged API Execution

With shell access secured, the malware deploys a framework based on Shizuku, a popular open-source utility typically used by power users to run specialized applications without rooting. In the hands of this Trojan, this legitimate tool becomes a vehicle for silent administrative abuse. The malware runs the code as a privileged server, operating under the file name libmx.so, which allows it to directly invoke system APIs.

By executing commands through this channel, the threat actors can modify protected Android settings, silently install or remove applications, and grant themselves additional permissions without ever prompting the user with a confirmation dialog. It essentially transforms the mobile device into a remote-controlled terminal, operating entirely under the radar of the victim.

A Broad and Resilient Arsenal of Commands

Compared to the previous variant analyzed in 2025, the updated version has drastically expanded its capabilities to function as a full-featured Remote Access Trojan (RAT). The command-and-control framework allows operators to execute a massive variety of intrusive functions. To understand the scale and technical precision of this updated threat, consider the following parameters and capabilities documented by researchers:

• A total of 53 server-issued commands are supported, enabling functions like camera activation, contact harvesting, and SMS intercepting.
• The self-pairing connection is established locally on the loopback interface to bypass network detection.
• System access is elevated directly to the shell level, which does not require a rooted device to function.
• A built-in five-minute watchdog alarm actively monitors the malware's processes to ensure continuous operation.
• The process priority configuration adjusts the oom_score_adj value to -1000 to prevent the Android operating system from terminating the app when memory runs low.

To ensure the malware remains active, developers implemented multiple redundancy systems. The application plays silent audio to boost its background process priority and utilizes WakeLocks to block CPU sleep cycles. Furthermore, it runs two companion services designed to monitor and restart each other immediately if one is shut down.

Implications for Enterprise and Consumer Security

The distribution of this threat relies on classic social engineering tactics, such as phone calls and SMS messages where attackers pretend to represent financial institutions or government agencies, guiding victims to fake Google Play platforms. Because the entire exploit chain relies on legitimate, built-in features like Wireless ADB and Shizuku rather than software vulnerabilities, traditional signature-based antivirus solutions may struggle to identify the behavior as malicious.

For enterprise security teams and individual users alike, this evolution highlights a critical vulnerability in trust-based permission models. Once a user is deceived into granting Accessibility permissions, the safety guarantees of the entire operating system crumble. Organizations must enforce strict mobile device management policies that disable Developer Options by default on corporate endpoints. For consumers, the defense remains simple but vital: treat high-level permission requests with extreme skepticism, verify the source of every application, and ensure that built-in security suites like Play Protect remain active at all times.