RatHat Abuses Android Wireless Debugging to Gain Shell Access and Steal Banking PINs

RatHat, a newly identified Android banking malware family that combines Accessibility abuse, local Android Debug Bridge (ADB) pairing, native shell-level components, and generative-AI-assisted interface automation.

The operation appears linked to China-based threat actors and is primarily designed to steal banking credentials, payment PINs, one-time passwords, device-unlock secrets, and other high-value data from infected Android devices.

In one analyzed build, the malware could impersonate a well-known streaming service and dynamically alter its visible icon and app label, including use of a “Chrome” activity alias.

The most consequential part of the infection chain is its autonomous abuse of Android Wireless Debugging.

After persuading a victim to enable its Android Accessibility Service, RatHat’s SystemHelper component uses synthetic taps to unlock Developer Options, activate Wireless Debugging, open the pairing interface, and scrape the temporary six-digit ADB pairing code and dynamic port from the screen.

It then pairs with the device’s local ADB daemon through an embedded ADB library, giving the attackers a shell-level execution context without requiring a connected host computer.

That shell access allows RatHat to stage two masqueraded Go binaries in /data/local/tmp.

The first, liblocal-service.so, acts as a privileged local agent capable of issuing commands that exempt the malware from Doze restrictions, move it into an active standby bucket, grant permissions, and disable or remove selected packages.

The second, libmedia_codec.so, is a Fast Reverse Proxy Client derived from FRP tooling. It creates a persistent reverse tunnel that can expose internal device services to the operator, effectively bypassing NAT and firewall boundaries.

RatHat also employs a layered anti-analysis stack intended to frustrate malware-research workflows.

The APK may include ZIP container inconsistencies that Android tolerates but common unpacking tools do not, a 61 MB Android manifest padded with undocumented 0x9999 chunks, malformed DEX pseudo-instructions that disrupt disassembly, and multiple string-obfuscation methods.

Runtime defenses additionally check for JDWP debuggers, ptrace attachments, Frida, Xposed, root artifacts, emulators, altered build properties, and repackaging indicators.

The malware’s most unusual credential-theft capability is a shell-enabled raw-input collector.

Its Go agent invokes Android’s getevent utility to monitor /dev/input events and capture touch coordinates with timestamps.

Standard Android applications cannot normally read these device input nodes; the shell context obtained through Wireless Debugging makes the collection possible.

Zimperium said in a report shared with GBhackers, RatHat spreads through targeted smishing messages, malicious advertisements, third-party forums, and deceptive download portals that convince victims to sideload APK files disguised as legitimate applications.

RatHat Malware Attack

RatHat converts raw coordinates into credentials by referencing locateValues.json, which contains keypad and pattern-lock layouts for major device brands.

A touch coordinate can therefore be mapped to a digit on a PIN pad, while a series of coordinates can be aligned to the 3×3 Android pattern grid.

This gives the malware a route around protections that limit screenshot capture, hide lock-screen digits from Accessibility, or use custom keyboards.

Alongside raw input capture, RatHat logs Accessibility text-change events, harvests browser URLs, captures screen activity, and uses WebView-based HTML overlays to imitate targeted financial applications.

It can also intercept SMS and notification content to obtain OTP and 2FA codes. Zimperium’s analysis specifically notes overlays targeting banking and crypto apps, as well as payment services such as WeChat and Alipay.

RatHat serializes the live Accessibility tree into XML and sends it to a popular generative-AI assistant for operational tasks, according to zLabs.

The prompts can request coordinates for a named on-screen element, extract visible text from the interface, or return navigation actions such as SCROLL_DOWN.

This capability reduces the malware’s reliance on rigid, app-specific automation scripts and potentially makes it more resilient to interface changes.

The malware maintains two primary command-and-control paths: an HTTP/WebSocket channel used by the Android application and a local HTTP service bound to 127.0.0.1:7910 by the Go agent.

The agent can retrieve reverse-tunnel settings, send device telemetry, process queued commands, conduct screen monitoring, transfer files, upload video, and check for component updates.

RatHat attempts to prevent removal by intercepting uninstall flows and displaying a fake Google Play-style failure overlay. More significantly, its local shell-level service exists outside the normal Android package lifecycle.

If the victim succeeds in uninstalling the visible app, the resident agent can detect its absence and reinstall the APK with runtime permissions, then re-enable Accessibility settings without further interaction.

The campaign illustrates a growing mobile threat model in which attackers do not need a kernel exploit to achieve meaningful control.

By chaining a sideloaded APK, Accessibility permission, Wireless Debugging, local ADB pairing, and reverse tunneling, RatHat moves beyond conventional overlay fraud toward durable on-device access.

Android users should avoid APKs promoted through unsolicited texts, ads, and unofficial portals; treat Accessibility requests as high-risk; keep Developer Options and Wireless Debugging disabled when not explicitly needed; and immediately investigate unexpected accessibility services, device-admin requests, or debugging notifications.

Organizations should monitor managed devices for Accessibility abuse, Developer Options activation, and local ADB pairing attempts, particularly on phones used for banking, MFA, and corporate access.

Cut every SOC alert investigation by 21 min. Power your SOC with instant IOC context for immediate response: Integrate TI Lookup in your SOC