RedHook Android RAT Uses Wireless ADB for Shell Access

RedHook, an Android remote access trojan first reported in 2025, has returned with a more dangerous trick: it can abuse Wireless ADB to gain shell-level privileges on an infected phone without rooting the device or connecting it to a computer.^[1] The new behavior matters because it turns a legitimate developer feature into a privilege path for malware that already has the victim’s Accessibility permission.

Group-IB published the primary technical analysis on July 9, 2026, and BleepingComputer highlighted the campaign for a wider security audience on July 12.^[1][2] The timing makes this a useful Android security story for howtofix.guide readers: the attack does not depend on a public Android zero-day, but on social engineering, sideloaded APKs, and permissions that many users do not understand well enough to refuse.

The malware still behaves like a classic Android RAT. Researchers describe screen streaming, keylogging, UI automation, credential theft, fake verification dialogs, SMS/contact collection, app installation and removal, camera activation, and device lock/unlock commands.^[1][2] Group-IB says the current build supports 53 server-issued commands and is being distributed through spoofed government and financial websites, with payloads hosted on trusted-looking infrastructure such as GitHub repositories and AWS S3 buckets.^[1]

The new part is the privilege chain. RedHook tricks the user into enabling Accessibility Service, then uses automated taps to enable Developer Options, turn on Wireless Debugging, open the pairing-code screen, read the displayed code, and pair with the phone’s own ADB daemon over 127.0.0.1.^[1][2] Google’s own Android developer documentation describes Wireless Debugging as a normal Android 11+ workflow that pairs a device to a workstation through a QR code or pairing code; RedHook’s twist is that the infected phone becomes both sides of that workflow.^[3]

After pairing, RedHook launches a Shizuku-derived privileged server named libmx.so under Android’s shell user uid 2000.^[1] That is not full root, but it is far more powerful than a regular app sandbox. Group-IB says the malware can use that position to grant itself runtime permissions, change protected settings such as WRITE_SECURE_SETTINGS, run shell commands, capture low-level touch events, and bypass normal confirmation dialogs.^[1]

For readers tracking mobile fraud, this is a useful escalation from older Android banking campaigns. howtofix.guide has previously covered Anubis banking trojan activity, SharkBot and Vultur apps reaching Google Play, and an Android Framework zero-day patch. RedHook sits at the intersection of those problems: fake mobile apps, banking fraud, and Android privilege features that are safe only when the user controls them.

What Android users and defenders should check

Individual users should treat unexpected Accessibility prompts as a red alert. If a banking, tax, delivery, benefits, or government-themed app asks to control the screen, read text on the screen, or perform gestures, stop and verify the app through the official organization website or Google Play listing. RedHook’s reported lures rely on calls and messaging apps that push victims toward fake Google Play-style pages, not on normal app-store discovery.^[1]

On a potentially exposed phone, check three areas first: installed apps from outside official stores, enabled Accessibility services, and Developer Options/Wireless Debugging status. If Wireless Debugging is enabled and the user did not intentionally use it, turn it off, revoke ADB debugging authorizations, remove suspicious apps, run Play Protect or a trusted mobile security scan, and change passwords from a separate clean device. If a banking session or wallet app was opened while the device was suspicious, contact the bank or service provider quickly.

Security teams managing Android fleets should look for a slightly different signal. MDM and EDR policies should flag newly enabled Accessibility services, unknown sideloaded APKs, Developer Options toggles, Wireless Debugging state changes, unexpected screen-capture behavior, and devices that suddenly show banking-fraud overlays or unusual app-install events. For financial institutions, Group-IB recommends session monitoring and brand-protection workflows to catch malware-driven sessions and fake sites before users enter sensitive data.^[1]

Group-IB published one SHA-256 APK hash and three network indicators for defenders: 453333bffdd1850ea2e0647f7c805530b578919978a01b1e2be52d6eb2add946, hxxps://api.3n7wj[.]com, wss://skt.3n7wj[.]com, and wss://sktv.3n7wj[.]com.^[1] These IOCs are useful for threat hunting, but the larger lesson is behavioral: an Android phone that suddenly needs Accessibility and Wireless Debugging for a bank or government service should be treated as compromised until proven otherwise.

References

1. Group-IB. “RedHook Returns with a Dangerous Upgrade.” Published July 9, 2026. group-ib.com
2. BleepingComputer. “RedHook Android malware now uses Wireless ADB for shell access.” Published July 12, 2026. bleepingcomputer.com
3. Android Developers. “Android Debug Bridge (adb): Connect to a device over Wi-Fi.” Accessed July 13, 2026. developer.android.com