RedHook Android Malware Uses Wireless ADB for Shell Access

Originally published on CyberNetSec.

Executive Summary

Security researchers have uncovered a new, more dangerous variant of the RedHook Android banking malware. This updated strain, active in campaigns targeting banking app users in Europe and Latin America, now incorporates a novel technique to gain persistent, elevated access. It abuses the Wireless Android Debug Bridge (ADB) feature, available on Android 11 and later, to grant itself shell access on the infected device. This allows the malware to execute arbitrary commands, steal data, and manipulate other applications without needing a physical USB connection, representing a significant evolution in its capabilities.

---

Threat Overview

RedHook is a banking trojan designed to steal credentials and financial information from Android users. This new variant enhances its ability to control the device and evade removal.

• Malware: RedHook
• Affected Platforms: Android 11 and later.
• Target Regions: Europe, Latin America.
• Primary Goal: Steal banking credentials and financial data.
• Key New Technique: Abusing Wireless ADB for persistent shell access.

Technical Analysis

The attack chain demonstrates a sophisticated abuse of Android's system features:

1. Initial Access: The victim is lured via a phishing message (smishing) to a fake Google Play Store page, where they are prompted to download and install a malicious APK file.
2. Permission Abuse: Upon installation, the malware aggressively requests permissions, with a focus on gaining access to Accessibility Services. This is a powerful permission that allows an app to read the screen and perform actions on behalf of the user.
3. Enabling Wireless ADB: The malware uses its Accessibility Services privileges to programmatically navigate through the device's settings menu to enable Developer Options and then toggle on Wireless debugging.
4. Self-Pairing: The malware then initiates the pairing process for Wireless ADB and, using its ability to read the screen and tap buttons, approves its own pairing request.
5. Shell Access: Once paired, the malware has shell-level access to the device over the local network. It can now execute adb shell commands to grant itself additional permissions, interact with other apps, exfiltrate files, and perform other malicious actions.
6. Persistence: To prevent removal, the malware uses a WakeLock to stay active and employs a "two-service cross-process resurrection mechanism." This involves two internal services that constantly monitor and relaunch each other if one is terminated by the user or the OS.

MITRE ATT&CK Mapping

• T1446 - Network-Based Replication: While not replicating, the abuse of a network service (Wireless ADB) for self-access is conceptually similar.
• T1417 - Input Capture: Using Accessibility Services to read the screen and capture user data from banking apps.
• T1424 - Exploitation for Privilege Escalation: Abusing Accessibility Services to enable Developer Options is a form of privilege escalation.
• T1403 - Command and Scripting Interpreter: Gaining access to the adb shell provides a powerful command interpreter on the device.

Impact Assessment

A device infected with this RedHook variant is fully compromised. The attacker has persistent, shell-level access, allowing them to:

• Steal credentials from any banking or financial app on the device.
• Intercept one-time passwords sent via SMS.
• Install additional malware or spyware.
• Access personal files, photos, and contacts.
• Make the device part of a mobile botnet.

The persistence mechanism makes the malware extremely difficult for a non-technical user to remove, often requiring a full factory reset of the device.

IOCs — Directly from Articles

No specific APK hashes, C2 domains, or IP addresses were provided in the source articles.

Cyber Observables — Hunting Hints

On a non-enterprise device, detection is difficult. However, the following are indicators of compromise:

Type	Value	Description	Context
other	Developer Options enabled	The unexpected enabling of Developer Options on a user's device is a major red flag.	User observation, Mobile Device Management (MDM) policy check
other	Wireless debugging enabled	The enabling of this feature, especially if the user did not do it themselves, is a strong indicator of compromise.	User observation, MDM policy check
process_name	adbd	The presence of the ADB daemon running and listening on a network port.	Device forensics, network scanning on the local Wi-Fi network
log_source	Android Logcat	Logs may show activity related to Accessibility Services being used to change system settings.	Device forensics

Detection & Response

• For Individuals: Be extremely wary of any app that requests Accessibility Services permissions. This permission is very powerful and should only be granted to highly trusted apps from reputable developers (e.g., password managers). If you suspect infection, the most reliable solution is to perform a factory reset.
• For Enterprises (MDM): Use a Mobile Device Management (MDM) solution to enforce policies that prevent users from enabling Developer Options or USB/Wireless debugging. Monitor the fleet for devices that fall out of compliance with this policy.

Mitigation

• Install from Official Stores: Only install applications from the official Google Play Store. Avoid sideloading APKs from third-party websites or links sent via text message.
• Scrutinize Permissions: Carefully review the permissions an app requests before and after installation. Be particularly suspicious of requests for Accessibility Services, Device Administrator, or the ability to draw over other apps.
• Keep Android Updated: Install Android security updates as soon as they become available to protect against the exploitation of known vulnerabilities.
• Disable Developer Options: Unless you are a developer and actively need it, ensure that Developer Options is disabled on your device.