RedHook Android Malware Turns Phones Into Their Own Debugging Tool

A new build of the RedHook trojan tricks Android users into switching on Wireless Debugging, then quietly promotes itself to a privilege level normal apps can never reach.

ThreatVectr NewsdeskAI-assistedPublished Updated · Editor: Lee Brown· 4 min read
Illustration: a modern Android smartphone lying on a dark matte desk
Illustration made with AI. Not a photograph of the events described.
Share

Key points

  • Researchers at Group-IB have documented a new version of the RedHook Android malware that abuses Wireless Debugging, a built-in developer feature, to gain shell-level access without any computer connected.
  • Granting one Accessibility Service permission prompt is all RedHook needs; it then enables Developer Options and pairs with the phone's own debugging service over the loopback address 127.0.0.1.
  • RedHook accepts 53 remote commands, covering screen streaming, keystroke capture, silent app installation, camera activation and fake verification overlays.
  • Distribution relies on social engineering calls and messages impersonating government agencies or banks, pushing victims toward fake Google Play pages.
  • The attack works on any Android device, rooted or not, provided the user approves the initial Accessibility permission.

A new strain of Android malware has found a way around the usual limits placed on phone apps. It talks to the phone's own debugging tools, the same ones a developer would use, and claims a level of control that ordinary apps are never given.

The malware is called RedHook. Group-IB analysts say this version is a significant step up from the variant they documented earlier in 2025. We first covered RedHook on 12 July 2026 in the context of Android fraud kits targeting banking customers. The new capability changes the threat's profile considerably.

It keeps the core remote access trojan features: screen streaming, keystroke interception, credential theft. What's new is how it hands itself extra powers using a legitimate Android feature.

How does this attack actually work on someone's phone?

Victims are directed, usually through a call or message impersonating a bank or a government office, to a fake Google Play page. They install the app. The app requests Accessibility Service access, a powerful Android permission designed to help users with disabilities operate their device.

Once granted, RedHook uses that access to do what a human finger would. Settings opens. Developer Options activates. Wireless Debugging switches on. That feature, added in Android 11, lets a computer send commands to a phone over Wi-Fi rather than a USB cable.

Then comes the clever part. Instead of waiting for a remote computer to connect, RedHook reads the pairing code off the screen and connects the phone to itself over the loopback address 127.0.0.1, a network address every device uses to talk to its own services.

The malware now holds a shell session with UID 2000 privileges. That's the same access level a developer gets with a cable plugged in: well above what any normal app can do, though short of full root.

What can RedHook do once it has that access?

Group-IB counted 53 commands the malware accepts from its operators. Screenshots, screen streaming, simulated taps and gestures, device locking, silent app installation and removal, contact and message harvesting, camera activation, fake verification overlays painted over real banking apps, and a full device reboot.

RedHook also fights hard to stay alive. Silent audio playback keeps its process priority high. WakeLocks stop the phone sleeping. Two services restart each other if one is killed, and a watchdog alarm fires every five minutes. A Linux kernel setting called oom_score_adj gets pushed to -1000, telling Android not to kill the process when memory runs low.

To execute privileged commands, RedHook piggybacks on Shizuku, a legitimate tool popular with developers and power users. It loads Shizuku's code as a helper library (libmx.so) and uses it to call protected Android APIs at UID 2000, without ever displaying a user dialog.

For defenders, the practical consequence is stark: a single tapped permission prompt hands an attacker the same command surface as a physical USB connection to a developer workstation.

Should you worry?

Yes, if you're the type who clicks links in unexpected messages and taps through permission prompts quickly. The attack chain requires no exotic vulnerability, just social engineering and one careless approval.

Install apps only from the official Google Play Store. Treat any Accessibility Service request with suspicion, because very few apps genuinely need it. Keep Google Play Protect active. If someone calls claiming to be from your bank or a government office and asks you to install something from a link, end the call and ring the number on the back of your card.

© 2026 Threat Vectr