RedHook Android malware exploits Wireless ADB for shell access

A newly updated variant of the RedHook Android malware is exploiting Android Wireless Debugging (Wireless ADB) in a novel way, granting itself shell-level access without requiring any physical computer connection. Cybersecurity researchers at Group-IB have analyzed this latest version and report that it represents a significant leap in capability compared to the earlier strain documented in 2025. Despite these upgrades, the malware retains its core identity as a remote access trojan (RAT), capable of streaming the device screen, logging keystrokes, automating UI interactions, and stealing sensitive credentials.

How the autonomous Wireless ADB attack works

ADB, or Android Debug Bridge, is Google’s standard debugging interface that allows a user to control an Android device from a command line. On the device side, it runs as an ADB daemon, enabling shell commands from a connected computer. Wireless ADB, introduced in Android 11, removes the need for a USB cable, letting the same functionality happen over a network. RedHook turns the victim’s own phone into its ADB client by first tricking the user into granting Accessibility permissions. With that access, it automatically navigates device Settings, enables Developer Options, and activates Wireless Debugging. The malware then reads the pairing code displayed on the screen and connects to the phone’s ADB service via the loopback interface (127.0.0.1). Once paired, RedHook gains shell (UID 2000) privileges , far more powerful than what normal Android apps can access, though not root-level. Crucially, the entire attack chain does not require a rooted device, meaning it works on any Android handset as long as the user is deceived into approving the Accessibility Service permission.

Shizuku-based privilege escalation

After securing shell access, RedHook deploys a Shizuku-based framework to execute shell commands, grant itself additional permissions, modify protected Android settings, silently install or remove applications, and perform various operations without triggering user dialogs. Shizuku is a legitimate utility popular among power users and developers, and it does not require root. In this attack, RedHook runs Shizuku code as a privileged server (libmx.so), invoking protected Android APIs under UID 2000.

53 server-issued commands and persistence mechanisms

Group-IB’s analysis reveals that the current RedHook variant supports 53 distinct server-issued commands. These include screen streaming and screenshot capture, simulating taps, swipes, gestures, dragging, and long clicks, locking and unlocking the device, installing, launching, and uninstalling apps, collecting contacts, SMS messages, and installed applications, creating overlays or fake verification dialogs, activating the camera, and rebooting the device. The malware also employs multiple persistence mechanisms. It uses silent audio playback to increase process priority, WakeLocks to prevent the CPU from sleeping, and two services that restart each other when one is terminated. Additional methods include a five-minute watchdog alarm, automatic restart after device boot, and setting oomscoreadj to -1000 to reduce the likelihood of being killed when system memory runs low.

Distribution and defense

The latest RedHook variant spreads through social engineering, using messages and phone calls where attackers impersonate government agencies or financial institutions to direct victims to fake Google Play sites. Android users are advised to install apps only from the official Google Play Store, carefully scrutinize requested permissions at installation time, and ensure Play Protect is active on the device.