A new version of the RedHook Android malware abuses the Android Wireless Debugging (Wireless ADB) mechanism in a novel way to gain shell-level privileges without requiring a computer connection.
Researchers at cybersecurity company Group-IB analyzed the new release of the mobile malware and say that it significantly expands its capabilities compared to the previous variant documented in 2025.
At the same time, the malware retains its remote access trojan (RAT) features, allowing it to stream the screen, intercept keystrokes, automate UI interactions, and steal credentials.
Autonomous Wireless ADB abuse
ADB (Android Debug Bridge) is Google’s debugging interface that lets a user control an Android device from a command line.
The system, which runs on an Android device as an ADB daemon, enables executing shell commands from a computer running the ADB client.
Wireless ADB, first introduced in Android 11, provides the same capability wirelessly, without requiring the devices to be linked via a USB cable.
RedHook essentially turns the phone into its own ADB client by tricking the victim into granting it Accessibility permissions, which let it automatically manipulate Settings, enable Developer Options, and activate Wireless Debugging.
After that, the malware retrieves 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, the malware gains shell (UID 2000) privileges, which are significantly more powerful than those available to normal Android apps, though not root-level.
The entire attack chain does not require the device to be rooted, so it works across all Android devices as long as the user is tricked into approving the Accessibility Service permission request.
Next, the malware 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 displaying user dialogs.
Shizuku is a legitimate Android utility popular among power users and developers, and does not require a rooted device.
RedHook executes Shizuku code as part of its attack chain, using it as a privileged server (libmx.so) to invoke privileged Android APIs as UID 2000.
RedHook malware attack chain
Source: Group-IB
According to Group-IB’s report, the current version of the malware supports 53 server-issued commands, which include:
- Screen streaming and screenshot capturing
- Simulate taps, swipes, gestures, dragging, and long clicks
- Device locking/unlocking
- Install, launch, and uninstall apps
- Collect contacts, SMS, and applications
- Create overlays or fake verification dialogs
- Activate the camera
- Reboot the device
The malware’s multiple persistence mechanisms are also highlighted in Group-IB’s report.
RedHook uses silent audio playback to increase process priority, WakeLocks to prevent CPU sleep, and two services that restart each other when one is terminated.
Other mechanisms include a five-minute watchdog alarm, automatic restart after device boot, and setting oom_score_adj to -1000 to reduce the likelihood of being killed when available system memory is low.
The latest version of RedHook is distributed through social engineering, via 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 Google Play, scrutinize requested permissions at installation, and ensure that Play Protect is active on the device.
Security teams log 54% of successful attacks and alert on just 14%. The rest move through your environment unseen.
The Picus whitepaper shows how breach and attack simulation tests your SIEM and EDR rules so threats stop slipping by detection.
Get the whitepaper
