RedHook Uses Wireless ADB and Turns Android Itself into a Client Against the Owner

On July 12, Group-IB published an analysis of the new variant of the banking trojan RedHook, and this technical novelty marks a turning point for bank fraud teams. The malware family has begun to exploit the native Wireless ADB feature of Android to gain shell-level access without relying on a connected computer. Until the previous version cataloged in 2025, this type of escalation depended on the attacker having physical means to plug the device in. Now the phone itself acts as the ADB client against itself.

The Trick

The infection path begins with social engineering. RedHook operators impersonate servers of public agencies or bank support in calls and messages via Zalo, the leading messaging app in Vietnam, and lead the victim to fake sites styled to resemble the Google Play Store, from where the malicious APK is downloaded via sideload. After installation, the app requests Accessibility permission, which is a set of APIs intended for screen readers and users with visual impairments, providing the software with broad control over what appears and what is touched.

With this permission, RedHook manipulates Settings, activates Developer Options, enables Wireless Debugging, and captures the pairing code displayed on the screen. From there, it connects the ADB service through the device's own loopback, 127.0.0.1, and obtains shell access. ADB with shell is practically root access for practical purposes: it allows the installation of apps without additional consent, termination of processes that would be protected, injection of access, and reading storage areas beyond the reach of common apps. Group-IB records that RedHook maintains the classic RAT capabilities it had in 2025, including screen streaming, keystroke interception, UI automation, and credential theft, now enhanced by persistence through foreground activity spoofing and silent media playback to avoid being suspended by the system.

The Banking Angle

Telemetry collected by Group-IB at the time of analysis counted 570 user IDs reporting to the command server, indicating more than 500 actively infected devices. This is a modest volume by global campaign standards, but sufficient for a regional fraud operation, and the current distribution primarily targets banking and tax agency apps in Vietnam and Indonesia, two markets where the adoption of mobile banking has grown faster than the maturity of corporate fraud areas.

For the bank caught in the scam, the problem is not having its own app compromised, but rather seeing the customer's credential bypassing multifactor authentication via OTP capture on-screen and UI flow automation. This is the pattern that fraud analysts refer to as on-device compromise: the transfer request is authenticated from the legitimate device of the customer, from a legitimate IP, and with the token generated by the app itself. None of the traditional anomaly signals detect the operation as malicious in real-time because, technically, it is not.

What Concerns Beyond Southeast Asia

The pattern of RedHook interests security areas of global institutions for two reasons. First, the technique is not geographically exclusive. Wireless Debugging has been a native Android feature since version 11 and is available on any device worldwide with that base, which means nothing prevents recompiling the same family to impersonate Brazilian, European, or African banks as soon as the financial return justifies the adjustment. Secondly, the vector via Accessibility remains the bottleneck. Google has tightened the policy in recent versions requiring justification for the use of Accessibility Services by apps distributed in the Play Store, but RedHook operates outside the store, via sideload, which cleanly nullifies the protection.

What banking fraud teams can do in the short term is limited by the fact that the device owner has consented at each step. Alerts in the product when Wireless Debugging is activated, server-side detection of automated typing patterns in sensitive flows, out-of-band revalidation in high-value transactions, and preventive communication to customers against apps installed via sideload continue to be the basic toolkit. What this variant really changes is the cost of the initial stage for the attacker: without relying on physical access or manufacturer CVE, well-executed social engineering now opens a shell on a common device and turns multifactor authentication into theater. Brazilian banks that heavily rely on OTP in their apps have a direct interest in scrutinizing this chain before the same technique arrives translated.