RedHook Returns with a Dangerous Upgrade

Introduction

RedHook is an Android Remote Access Trojan (RAT) that has re-emerged with significant improvements. While retaining core RAT functionalities, such as screen streaming and keylogging, the latest iterations demonstrate a sophisticated shift toward privilege abuse. This analysis details how RedHook abuses Android’s ADB Wireless Debugging features to autonomously obtain shell-level access (uid 2000). Also, by examining the malware’s persistence stack and its expanded command-and-control capabilities, this report provides technical insights into this evolving mobile threat. RedHook was first documented by Cyble researchers in July 2025.

Key Discoveries

• RedHook abuses ADB Wireless Debugging to obtain shell-level privileges
• Integrates the Shizuku framework to execute protected system APIs
• Recent activity indicates an expansion of targeting beyond Vietnam to include users in Indonesia, suggesting a broader regional focus across Southeast Asia.
• Distributed via spoofed government and financial websites, but the malicious APK payloads are hosted on reputable cloud and development platforms, including AWS S3 Buckets and GitHub repositories, likely to enhance delivery reliability
• Features an expanded command infrastructure – current iteration now supports 53 distinct server-issued commands
• Employs a multi-layered persistence stack

Who may find this blog interesting:

• Malware analysts
• Cybersecurity analysts and corporate security teams
• Law enforcement investigators

Group-IB Threat Intelligence Portal:

Group-IB customers can access our Threat Intelligence portal for more information about the threat actor and malware mentioned in this blog:

• RedHook

Distribution

RedHook’s distribution primarily occurs through social engineering, which are common techniques previously discussed in our GoldFactory blog on Android trojans. Attackers typically initiate contact through phone calls, or messaging applications, impersonating trusted organizations or support personnel. The victim is then persuaded to download and install a malicious APK file from fake websites under the pretext of required steps for accessing services or completing official procedures. These fraudulent websites are designed to closely mimic the appearance of the Google Play Store. The underlying APK payloads are frequently hosted on publicly accessible infrastructure, including GitHub repositories and Amazon S3 buckets, leveraging trusted platforms to facilitate malware distribution.

Once installed, the malicious application can gain unauthorized access to the device, enabling data theft, surveillance, or further compromise.

Figure 1: Example of social engineering. Reported dialogue between victim and fraudsters in Zalo (source: facebook.com translated from Vietnamese).

Figure 2: Example of a Github repository abused by attackers to host malicious APKs (now inactive).

Phishing Flow

RedHook’s phishing UI screens remain pretty consistent, exhibiting the same design patterns across samples and prior campaigns – mimicking government or financial services visual identity. They prompt the user to enter credentials, personal information and security codes. The malware then tricks users into enabling Accessibility through a guided walkthrough, under the guise that it is a necessary step to enable full features and functionality of the app.

Capabilities

RedHook’s capabilities are largely consistent with what we typically see in an Android RAT: Accessibility-driven gestures, node layout (UI tree) collection, screen streaming, keylogging, and theft of the device’s screen-lock credentials. Rather than dwell on these well-understood features, we will instead highlight several of the more interesting capabilities we observed.

Self-service Privilege Abuse over ADB Wireless Debugging

ADB Wireless Debugging is nothing new to Android enthusiasts who enjoy customizing their devices. Tools like Shizuku have long leveraged it to grant applications elevated, shell-level permissions without rooting the device. This, however, is the first time we have seen it used by a malware to abuse privileges on a victim’s device.

What is ADB?

ADB (Android Debug Bridge) is a tool that lets a computer interact with and control an Android device through a command-line interface. It is used primarily by developers to debug applications, install software, and access the device’s file system. ADB Wireless Debugging extends this functionality by establishing the connection over a network rather than a physical USB cable.

While ADB is designed for legitimate purposes, it can be abused to obtain elevated privileges. By leveraging ADB, the malware gains shell-level privileges (uid 2000) and uses them to silently install and uninstall applications, modify secure settings, and grant sensitive permissions without user interaction or confirmation dialogs.

Automated ADB Wireless Debugging Activation

First, the malware enables Developer Options and ADB Wireless Debugging through a sequence of automated UI steps, navigating the Settings screens and toggling the required options by simulating user input through the Accessibility service it has been granted.

In the screen recording below, the Accessibility service had already been enabled prior. Under normal circumstances, a full-screen overlay is present throughout; all of these activities take place in the background unbeknownst to the victim. We have removed the overlay during analysis so the steps taken by the malware are visible in this example.

Figure 5: Screen recording of automated ADB Wireless Debugging Activation.

These actions were performed automatically:

1. Taps on build number 7 times to enable Developer Options
2. Developer Options -> Wireless Debugging
3. Use Wireless Debugging
4. Click Pair device with pairing code
5. Retrieves the pairing code

ADB Shell

The privileged shell implementation references code heavily from Shizuku, a popular application that runs a privileged shell process (uid 2000) to give other applications elevated capabilities, special permissions that ordinary applications cannot access without ADB or root.

Normally, ADB needs a computer as the host: a PC runs an ADB client that connects to the phone’s ADB daemon. Shizuku’s trick is that with Wireless Debugging, the device can be its own host. The malware embeds its own ADB client and connects to the device’s own daemon over the loopback interface (127.0.0.1), so that the whole ADB flow runs on-device, neither needing a PC nor USB cable.

Once ADB connection is successfully established, it launches the privileged server process “libmx.so” under shell uid 2000 – a special Linux user that Android grants significantly more trust. This server is the Shizuku server that the application connects to via Binder IPC and borrows that uid identity for privileged system API calls. With it, it is able to grant itself runtime permissions, run arbitrary shell commands as uid 2000 and capture low-level touch events. It also grants WRITE_SECURE_SETTINGS. With that, it is able to modify entries in Settings.Secure.

Figure 6: Privilege abuse chain.

OEM-specific routines

The malware also includes OEM-specific routines for enabling Wireless ADB. For a given OEM ROM, it runs a multi-step, Accessibility-driven sequence of gestures to toggle Wireless debugging on. Brand-specific implementations are present in the code, such as Google, Huawei, Meizu, Oppo, Samsung, Vivo and Xiaomi. However, these routines are not currently invoked anywhere in the execution flow, suggesting they may be intended for future use.

Persistence Stack

RedHook features a robust persistence stack. By leveraging techniques that artificially boost process priority, such as foreground activity spoofing, silent media playback, and cross-process monitoring, it ensures that its malicious services and communications remain uninterrupted when the device is idle.

One-pixel Activity

When the screen is off, it launches a near-invisible 1×1 pixel activity to keep it running. By keeping a technically “visible” activity on screen, the malware tricks Android’s process management system into classifying the app as a foreground process, granting it the highest process priority and shielding it from being killed.

Silent Audio

It plays silent audio via MediaSession. A process that is actively playing audio is considered a high priority process and avoids being killed.

WakeLock

Normally, Android aggressively kills background processes to save battery. A WakeLock held inside a foreground service prevents the CPU from sleeping, meaning the malicious service never gets suspended.

Cross-process Binding and Alarm

RedHook implements a two-service cross-process resurrection mechanism for persistence.  Each service runs in a separate process and binds to the other via bindService() with BIND_AUTO_CREATE flag. This flag keeps each bound service alive and auto-recreates it if its process is killed, while the surviving process also re-binds on the onServiceDisconnected() callback. The result is a mutual-resurrection loop when either process is killed, the surviving service detects the disconnection and immediately relaunches its partner, creating a loop that requires both processes to be terminated simultaneously to break.

There is also an alarm every 5 minutes to verify that two services are alive, restarting any that are not.

BOOT_COMPLETED Receiver

RedHook auto-starts after reboot by registering a BOOT_COMPLETED broadcast receiver, which forces the app process to start and run the application. The receiver then re-enables Wireless ADB via Settings.Global, reloads its stored ADB key, and re-establishes the shell-uid (2000) privileged helper — silently restoring full privilege within seconds of power-on, no user interaction needed.

OOM (Out-of-memory) score adjustment

Every Android process has an oom_score_adj value that determines its priority for being killed when memory runs low. By writing the lowest possible value, -1000, into its own /proc/<pid>/oom_score_adj, the process is fully exempted from being killed.

Touching Memory Pages

This technique allocates a small block of memory and calls mlock() on it, pinning it in physical RAM so it cannot be paged out. The process then writes to it periodically to keep it active.

Connections

RedHook utilizes WebSocket protocols for its command-and-control (C2) infrastructure and screen streaming, whereas more substantial data payloads are sent to specific REST API endpoints.

Screen Streaming

Like most Android RATs, RedHook can stream the victim’s screen. Its original screen-streaming service captures the device’s screen and streams the data over a WebSocket (to wss://sktv[.]3n7wj[.]com/ws/device?menberId=<accountId>&deviceId=<deviceId>) for real-time monitoring.

When the shell-privileged server (uid 2000) is active, however, RedHook simultaneously streams over RTMP in parallel, capturing the screen directly with shell privileges which bypasses the MediaProjection API and its mandatory consent dialog.

Command Table

* intended outcome but not functional

Conclusion

RedHook’s abuse of ADB Wireless Debugging and Shizuku shows how readily attackers can repurpose legitimate tools and open-source frameworks to expand their malware capabilities. There is no exploit here, “merely” turning a debugging interface into a path to shell-level privileges.

Mobile threats keep advancing, often by borrowing techniques straight from the developer and enthusiast communities. Capabilities like Accessibility and Wireless Debugging deserve to be treated as high-value abuse vectors, and defenders need to stay alert to how malware misuses them and keep pace as these techniques evolve.

Recommendation

For Financial Organizations

• Implement a user session monitoring system such as Group-IB’s Fraud Protection to detect the presence of malware and block anomalous sessions before the user enters any personal information.
• Use a Digital Risk Protection platform that detects the illegitimate use of your logos, trademarks, content, and design layouts across your digital surface.
• Maintaining a secure organization requires ongoing vigilance, and using a proprietary solution such as Group-IB’s Threat Intelligence can help organizations shore up their security posture by equipping security teams with the latest insights into new and emerging threats.
• Educate end-users about the risks of mobile malware, including how to spot fake websites, malicious applications and how to protect their passwords and personal information.

For End Users

• Do not click on suspicious links. Mobile malware is often spread through malicious links in emails, text messages, and social media.
• Download applications only from official platforms such as the Google Play Store, the Apple App Store, and Huawei AppGallery.
• Proceed with caution if it is necessary to download third-party applications.
• Carefully review the requested permissions when installing a new application, and be on extreme alert when applications request Accessibility Service.
• Do not add unknown people to your messaging applications.
• When contacting your bank, find and use their official contact number. Do not click on the bank alert/pop-up if you think your device has been infected.
• If you believe you have been defrauded, contact your bank to freeze immediately any bank accounts that your device has accessed.

Group-IB Fraud Matrix

Indicators of Compromise (IOCs)

File Indicators

• 453333bffdd1850ea2e0647f7c805530b578919978a01b1e2be52d6eb2add946

Network IOCs

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

DISCLAIMER: All technical information, including malware analysis, indicators of compromise and infrastructure details provided in this publication, is shared solely for defensive cybersecurity and research purposes. Group-IB does not endorse or permit any unauthorized or offensive use of the information contained herein. The data and conclusions represent Group-IB’s analytical assessment based on available evidence and are intended to help organizations detect, prevent, and respond to cyber threats.

Group-IB expressly disclaims liability for any misuse of the information provided. Organizations and readers are encouraged to apply this intelligence responsibly and in compliance with all applicable laws and regulations.

This blog may reference legitimate third-party services such as Telegram and others, solely to illustrate cases where threat actors have abused or misused these platforms.

This material is provided for informational purposes, prepared by Group-IB as part of its own analytical investigation, and reflects recently identified threat activity.

All trademarks referenced herein are the property of their respective owners and are used solely for informational purposes, without any implication of affiliation or sponsorship.