"The current version of the malware supports 53 server-issued commands," researchers at Group-IB report — and the list helps explain why this is no ordinary Android nuisance.
How RedHook weaponizes Wireless ADB and Accessibility
Group-IB's analysis shows the new RedHook variant uses Android's Wireless Debugging (Wireless ADB) in an autonomous, novel way to obtain shell-level privileges without a separate computer. ADB (Android Debug Bridge) is the debugging interface that runs on the device as an ADB daemon and normally lets a computer execute shell commands via an ADB client. Wireless ADB, introduced in Android 11, provides that capability over the network without a USB cable.
RedHook tricks victims into granting Accessibility permissions, then automatically manipulates Settings to enable Developer Options and activate Wireless Debugging. The malware then reads the pairing code displayed on the device and connects to the device’s own ADB service over the loopback interface (127.0.0.1). Once paired, RedHook gains shell privileges associated with UID 2000 — far more powerful than typical app privileges, though not root-level — and the attack chain functions without requiring the device to be rooted.
Shizuku: legitimate tooling reused as a privileged server
To turn shell access into broad control, RedHook deploys a Shizuku-based framework. Shizuku is a legitimate utility used by power users and developers; it can invoke privileged Android APIs without root. Group-IB reports RedHook executes Shizuku code (including a privileged server, libmx.so) as part of its chain, using it to run shell commands, grant additional permissions, change protected Android settings, and silently install or remove applications — all without triggering normal user dialogs.
Capabilities: the 53 commands and retained RAT features
Group-IB documents that the current RedHook release retains remote access trojan (RAT) features while adding a wide command set. The report lists these capabilities among the 53 server-issued commands:
- Screen streaming and screenshot capture
- Simulated taps, swipes, gestures, dragging, and long clicks
- Device lock and unlock
- Install, launch, and uninstall applications
- Collection of contacts, SMS, and installed applications
- Creation of overlays or fake verification dialogs
- Camera activation
- Device reboot
Group-IB also notes RedHook can stream the screen, intercept keystrokes, automate user‑interface interactions, and steal credentials — capabilities typical of a RAT but escalated here by the shell-level access the malware secures via Wireless ADB and Shizuku.
Persistence and process hardening
Group-IB highlights multiple persistence and process-hardening techniques the malware uses to remain active. These include silent audio playback to raise process priority, WakeLocks to prevent the CPU from sleeping, and a pair of services that restart each other if one is terminated. Additional measures are a five-minute watchdog alarm, automatic restart after device boot, and setting the process oom_score_adj to -1000 to lower the chance the system will kill the process when memory is constrained.
What this means for technologists, enterprises, and end users
Technologists and security teams: Group-IB's findings make clear that monitoring for unexpected changes to Accessibility settings, Developer Options, and Wireless Debugging activation is relevant. Because RedHook operates without root and leverages legitimate tooling (Shizuku) and loopback pairing, defenders should consider detection rules that flag Accessibility permission requests combined with subsequent attempts to enable Wireless Debugging or spawn local ADB connections.
Enterprises and procurement leaders: Group-IB reports distribution through social engineering — messages and phone calls impersonating government agencies or financial institutions that direct victims to fake Google Play sites. That distribution vector points to the need for employee awareness programs and controls around side-loading or installing apps from non-official stores.
End users: Group-IB recommends users install apps only from Google Play, scrutinize requested permissions at installation (notably Accessibility access), and ensure Play Protect is active on devices. The report also underscores that the attack does not require a rooted device: tricking a user into granting Accessibility access is sufficient for RedHook's chain to begin.
Group-IB frames this variant as a significant expansion over the RedHook variant documented in 2025. By converting the phone into its own ADB client, pairing over loopback, and leveraging Shizuku as a privileged server, the malware raises the bar for detection while relying on social engineering to gain the single permission — Accessibility — that starts the chain.
