New Android Banking Malware: RatHat Emerges with Advanced Threat Capabilities
Recently, cybersecurity experts have unveiled a new family of Android banking malware known as RatHat. This malware stands out due to its multifaceted approach, which includes abusing Accessibility features, utilizing local Android Debug Bridge (ADB) pairing, and employing native shell-level components. Notably, it incorporates generative AI to automate its interface interactions, presenting an unprecedented threat to mobile device security.
The operation of RatHat appears to be linked to threat actors based in China, who have primarily designed it to steal sensitive financial data. The malware targets banking credentials, payment PINs, one-time passwords (OTPs), device unlock secrets, and other high-value information from compromised Android devices. As financial transactions increasingly rely on mobile platforms, malware like RatHat poses significant risks to users.
One of the alarming aspects of RatHat is its capability to impersonate well-known applications, including popular streaming services. In particular, an analyzed version of the malware demonstrated the ability to dynamically change its visible icon and app label, even mimicking a “Chrome” activity alias. This level of customization is particularly concerning, as it enables the malware to remain undetected among applications installed on users’ devices.
The most critical facet of RatHat’s infection strategy is its autonomous exploitation of Android Wireless Debugging. Once a victim is persuaded to activate the Android Accessibility Service, RatHat’s SystemHelper component executes a series of synthetic taps. These taps unlock Developer Options, activate Wireless Debugging, and open the pairing interface. Subsequently, it scrapes the temporary ADB pairing code and dynamic port displayed on the screen.
Through this method, it achieves pairing with the device’s local ADB daemon using an embedded ADB library, which grants attackers shell-level execution access without requiring a connection to a host computer. Such access enables RatHat to deploy two disguised Go binaries into the device’s local storage. The first, named liblocal-service.so, acts as a privileged local agent that can issue commands exempt from Doze restrictions, relocate itself into an active standby mode, grant necessary permissions, and disable or remove specific applications.
The second binary, libmedia_codec.so, functions as a Fast Reverse Proxy Client derived from FRP tools. This component establishes a persistent reverse tunnel that exposes internal device services to the attackers, allowing them to bypass Network Address Translation (NAT) and firewall barriers.
RatHat’s sophisticated design also includes an array of anti-analysis measures to impede attempts at understanding and reverse-engineering its operations. The APK may display ZIP container inconsistencies that are harmless to Android but pose challenges to common unpacking tools. It also employs obfuscation techniques, including a 61 MB Android manifest cluttered with undocumented chunks and malformed DEX pseudo-instructions that disrupt standard disassembly processes.
Furthermore, the malware incorporates runtime defenses that actively check for debuggers, root artifacts, emulator signs, and modification indicators. Its most distinctive credential-theft capability features a shell-enabled raw-input collector. The Go agent within the malware utilizes Android’s getevent utility to track touch events and capture coordinates along with their timestamps. This unique approach allows it to bypass conventional application limitations on reading device input nodes, thereby enabling data capture through Wireless Debugging.
According to a detailed report shared by Zimperium with GBhackers, RatHat spreads through targeted smishing campaigns, malicious advertisements, deceptive download portals, and third-party forums tricking victims into sideloading APK files disguised as legitimate applications. The malware converts raw coordinates into actionable credentials by referencing a file named locateValues.json, which contains keypad and pattern-lock layouts for various prominent device brands.
This unique mapping effectively circumvents protections designed to block screenshot captures or conceal lock-screen digits from Accessibility features. In addition to raw input capture, RatHat logs text changes in Accessibility, harvests browser URLs, records screen activity, and utilizes HTML overlays to mimic financial applications. Notably, it can also intercept SMS and notification content to capture OTPs and two-factor authentication codes.
An alarming aspect of RatHat is its ability to serialize the live Accessibility tree into XML, subsequently sending this information to a popular generative AI assistant for operational tasks. This feature expands its functionality by allowing it to reduce reliance on rigid automation scripts tailored to specific applications. Instead, it can dynamically adapt to changes, enhancing its resilience against updates and alterations in target interfaces.
The malware maintains two primary command-and-control pathways: an HTTP/WebSocket channel utilized by the Android application and a local HTTP service connected to the Go agent. This dual structure enables the retrieval of reverse-tunnel settings, device telemetry processing, screen monitoring, file transfers, video uploads, and the management of command queues.
Preventing removal efforts by the victim is part of RatHat’s design. It intercepts uninstall flows and displays a counterfeit Google Play-style error overlay. More critically, its embedded local service operates outside of the regular Android package lifecycle, allowing the malware to reinstall itself with runtime permissions if the visible app is uninstalled.
The emergence of RatHat exemplifies the evolving landscape of mobile threats, where attackers no longer rely solely on kernel exploits for control. By leveraging a combination of sideloaded APKs, Accessibility permissions, Wireless Debugging, and reverse tunneling, RatHat transcends traditional overlay fraud, achieving a persistent presence on compromised devices.
To bolster defense against such threats, Android users are advised to avoid APKs promoted through unsolicited messages and unofficial download portals. They should treat requests for Accessibility permission with caution, disable Developer Options and Wireless Debugging when not required, and remain vigilant for unexpected accessibility service notifications. Organizations must also monitor managed devices for signs of Accessibility misuse, Developer Options activation, and ADB pairing attempts, particularly on devices frequently used for banking or sensitive corporate access.