RedHook Android RAT Weaponizes Wireless ADB for Shell Access

An upgraded version of the RedHook Android banking trojan now abuses a legitimate developer feature—Wireless ADB—to silently grant itself shell-level privileges on infected devices. Security firm Group-IB published findings this week showing how the malware automates the entire process without requiring the device to be rooted.

RedHook first surfaced in July 2025, documented by Cyble researchers targeting Vietnamese banking customers. The new variant expands its reach to Indonesia and adds a capability that's hard to defend against: weaponizing Android's own debugging infrastructure.

How RedHook Hijacks Wireless ADB

The attack chain starts with social engineering. Victims receive messages or calls impersonating government agencies or financial institutions, directing them to fake Google Play sites hosting malicious APKs. Once installed, the malware requests Accessibility Service permissions—a common tactic we've seen in other Android malware campaigns this year.

Here's where RedHook gets clever. Using those accessibility privileges, it:

1. Taps the device's build number seven times to unlock Developer Options
2. Navigates to Settings and enables Wireless Debugging
3. Reads the pairing code displayed on screen
4. Connects to the device's own ADB daemon via loopback (127.0.0.1)

The result is shell-level access (uid 2000) without any rooting. RedHook then deploys code borrowed from Shizuku, a legitimate open-source framework, to launch a privileged server process. This grants the malware WRITE_SECURE_SETTINGS permission—normally reserved for system apps—letting it modify protected settings and grant itself runtime permissions silently.

53 Commands, Full Device Control

The command set gives attackers comprehensive control over compromised devices:

• Screen streaming and capture for real-time surveillance
• Remote input simulation: taps, swipes, gestures, long clicks, dragging
• App management: install, launch, and uninstall applications silently
• Data theft: contacts, SMS messages, application data
• Camera activation including front-facing for face capture
• Device control: lock, unlock, reboot
• Anti-uninstall measures to prevent removal

The malware communicates with C2 servers at api.3n7wj[.]com over HTTPS and WebSocket connections, exfiltrating stolen data to endpoints like /member/info/addDevicePassword and /member/info/addsKeyboardInput. Like the EtherRAT campaign we covered recently, RedHook maintains persistent C2 channels that are difficult to disrupt through traditional domain blocking.

Aggressive Persistence Stack

RedHook employs every trick in the book to stay alive. Its persistence mechanisms include:

• Silent audio playback via MediaSession to maintain foreground process priority
• WakeLocks preventing CPU sleep
• Dual service binding with BIND_AUTO_CREATE—each service resurrects the other if killed
• Five-minute watchdog alarm checking service health
• BOOT_COMPLETED receiver for automatic restart
• oom_score_adj set to -1000 to exempt from memory pressure kills
• mlock() calls pinning memory pages in RAM

The 1×1 pixel invisible Activity keeps the malware classified as a foreground process, making Android reluctant to terminate it.

OEM-Specific Code Ready but Dormant

Group-IB found OEM-specific routines for Google, Huawei, Meizu, Oppo, Samsung, Vivo, and Xiaomi devices embedded in the malware. These routines aren't currently invoked, suggesting the operators are preparing for brand-specific evasion techniques in future updates.

This isn't the first time we've covered ADB exploitation. The xlabs_v1 botnet used exposed ADB ports on Android TV devices to build a DDoS-for-hire network earlier this year. RedHook takes a different approach—it doesn't need the port exposed externally because it enables and connects to Wireless ADB locally.

Indicators of Compromise

File Hash:

• 453333bffdd1850ea2e0647f7c805530b578919978a01b1e2be52d6eb2add946

C2 Infrastructure:

• hxxps://api.3n7wj[.]com
• wss://skt.3n7wj[.]com
• wss://sktv.3n7wj[.]com

Mitigation

The usual advice applies with extra urgency here:

• Install apps exclusively from Google Play—RedHook spreads through fake Play Store sites
• Scrutinize Accessibility Service requests—no banking or utility app legitimately needs this
• Keep Google Play Protect enabled—it detects known RedHook variants
• Disable Developer Options if you're not actively using them
• Check Settings > Developer Options > Wireless Debugging and disable if unexpectedly enabled

The attack affects all Android devices running version 11 or later, when Wireless ADB was introduced. For anyone wondering what malware is capable of on modern mobile devices, RedHook demonstrates that legitimate developer features can become attack surfaces when accessibility permissions are abused.