RedHook Android Malware Hijacks Built-In Debugging to Gain Shell Access Without a Cable

A new version of the RedHook Android trojan, documented by researchers at Group-IB, abuses Android's Wireless Debugging feature to gain shell-level access on any unrooted phone as long as the victim approves a single Accessibility Service prompt.

One Permission. Catastrophic Consequences.

The attack begins before the malware does anything technical. Criminals call or message targets while impersonating a bank or a government office, then direct them to a counterfeit Google Play page. The victim installs what looks like a legitimate app. The app asks for Accessibility Service access, a permission Android created so screen readers and assistive tools can help people with disabilities.

That is the only moment the victim is asked for anything.

Once Accessibility access is granted, RedHook operates like a human finger that never stops. It opens the device's Settings menu, navigates to Developer Options, and activates Wireless Debugging, a feature Google introduced in Android 11 to let developers send commands to a phone over Wi-Fi instead of a USB cable. Most consumer phones ship with Wireless Debugging off. RedHook switches it on.

Then the malware reads the on-screen pairing code and connects the phone to itself using the loopback address 127.0.0.1, the address every device uses to communicate with its own internal services. No external computer is needed. No USB cable. No second device. The phone becomes its own attacker.

What Shell Access Actually Means

The session RedHook establishes runs at UID 2000, the same privilege level a developer holds when they plug in via Android Debug Bridge. That sits well above a normal app but below full root. It is enough to matter enormously.

Group-IB counted 53 remote commands the malware accepts from its operators. The list is broad:

• Real-time screen streaming
• Keystroke capture and credential harvesting
• Silent installation and removal of apps
• Contact and SMS exfiltration
• Camera activation
• Fake overlay screens painted on top of real banking apps to capture credentials
• Device lock and unlock
• Simulated taps and swipes

RedHook also works hard to stay alive. It plays silent audio to keep its own process priority high, uses Android WakeLocks to prevent the phone from sleeping, and runs two services that restart each other if one is terminated. A watchdog alarm fires every five minutes. The malware also sets a Linux kernel parameter called oom_score_adj to negative 1000, which tells Android's memory manager never to kill the process. To run calls that require elevated permissions, RedHook loads Shizuku, a legitimate developer utility, as an embedded helper library named libmx.so and calls protected Android APIs through it.

The Control Failure: Accessibility Permission as an Attack Surface

Android's Accessibility Service was designed for inclusion. It is one of the most powerful permission classes on the platform precisely because it needs to simulate human interaction. That same power is what makes it attractive to malware authors. RedHook did not break Android. It followed Android's rules, then used those rules to break every other guardrail on the device.

The Verizon 2024 Data Breach Investigations Report found that the human element was present in 68 percent of breaches. This incident fits that pattern almost perfectly. The technical exploitation only worked because a person approved a permission without understanding what it does. No vulnerability was patched. No zero-day was purchased. The attacker's investment was a convincing phone call and a fake app store page.

This is exactly the scenario that security-awareness training is built to address: teaching people to recognize a social engineering setup before a permission prompt ever appears on screen.

The Missing Controls

Several layers of defense were absent or bypassed here. First, no out-of-band verification existed when a caller directed the victim to install software. A person trained to treat unsolicited installation requests as red flags would have stopped the attack before it started.

Second, the Accessibility permission itself carries no friction beyond a single dialog. Android does warn users that Accessibility apps can observe and control the device, but the warning is text, and people click through text. Organizations managing Android devices through a mobile device management platform can block Accessibility grants for unknown apps entirely, a control most consumer-facing victims simply do not have.

Third, Wireless Debugging has no place on a production device. Enterprise administrators should audit device policies and ensure Developer Options are disabled across any managed fleet. For consumers, knowing that no bank or government agency will ever ask you to enable developer features is a practical, memorable rule.

Finally, RedHook distributes through fake app store pages, which means Google Play Protect is a meaningful line of defense for consumers who keep it active. Sideloading, or installing apps from outside the official store, removes that protection entirely.

Organizations wanting to review how their own policies compare to current best practice can consult NIST SP 800-124, the federal guideline on mobile device security, which covers both MDM configuration and acceptable use policy requirements. Train2Secure has mapped its training catalog to relevant security standards for teams that need to demonstrate compliance alignment.

What Android Users Should Do Now

The practical guidance is short and specific:

• Never install an app from a link sent during a phone call, regardless of who the caller claims to be.
• Treat any request for Accessibility Service access as a major warning sign. Legitimate apps almost never need it.
• Keep Google Play Protect enabled in the Play Store settings.
• If you manage Android devices for a business, review your MDM policy to block Developer Options and restrict Accessibility grants to approved apps only.
• Check the Train2Secure pricing page if your organization needs to roll out mobile phishing awareness training at scale.

The permission model on Android is sound. The vulnerability is human, and it is the one attackers keep choosing because it works.