How RatHat turns Android permissions and debugging access into credential theft

Zimperium’s zLabs has detailed RatHat, an Android threat that can steal credentials through several distinct techniques, including fraudulent overlays, message interception and reconstruction of secrets from captured touch coordinates. The most unusual capability, however, depends on a longer compromise chain than descriptions of a touch-recording app might suggest.

Zimperium’s zLabs disclosed RatHat on 16 September 2026. According to its analysis, the malware first persuades a user to install an APK from outside Google Play and grant it Accessibility access. It then uses automated interface actions to activate debugging features, pairs with the device’s local ADB service and installs components with shell-level access. Only after those steps can its background agent read raw touchscreen coordinates from Android input events.

The findings describe serious credential-theft and persistence capabilities, but the known scale of the activity remains unclear. The reviewed sources provide no victim total, affected Android version range, confirmed financial losses or geographic concentration. There is also no confirmed account of data being stolen from a named victim.

A compromise that starts with sideloading

Zimperium reports that RatHat is promoted through smishing, malicious advertising, deceptive download sites and third-party forums. These routes are intended to convince a user to sideload a malicious APK rather than install an app through Google Play.

In the samples analysed by Zimperium, the app then requests access to Android’s Accessibility Service. That permission is pivotal because it lets the malware inspect and operate interface elements. RatHat reportedly uses those capabilities to enable Developer Options and Wireless Debugging, then obtains the local pairing details needed to connect to ADB on the same device.

Android’s developer documentation describes Developer Options and Wireless Debugging as features for connecting a device to development tools. RatHat repurposes that functionality. Zimperium says the malware self-pairs with the local ADB service, gains shell-level access and stages a Go-based agent and reverse-proxy client outside the ordinary app process.

This arrangement also explains why deleting the visible app may not remove the entire infection. Zimperium says the shell-level agent can continue operating after an uninstall, reinstall the app and monitor whether the other malicious component remains active. The app and agent can therefore help maintain each other’s presence.

The sequence matters when assessing the threat. Touch-coordinate collection is not presented as a capability available immediately to an ordinary app. In the analysed chain, it follows a deceptive installation, a user-granted Accessibility permission, automated activation of debugging and acquisition of a local ADB shell. The sequence reflects the samples Zimperium analysed; the public report does not establish whether other variants follow the same path.

Overlays and touch logging are separate mechanisms

RatHat has several reported ways to collect authentication information. Zimperium says analysed samples can place fraudulent interfaces over selected banking, cryptocurrency and payment apps. These overlays imitate legitimate screens to capture information entered by a user.

The malware can also intercept SMS messages and notifications, including one-time authentication codes, and collect screen or text-input data. These functions are distinct from the raw touch logging performed by the Go agent.

After obtaining shell access, that agent can read the coordinates of touchscreen events. Zimperium says RatHat compares the captured positions with stored layouts for keypads or pattern locks. Matching a sequence of coordinates to the corresponding interface layout can allow the malware to reconstruct a PIN, password or unlock pattern.

This is more precise than saying that a fraudulent overlay itself records every tap. The overlay presents a deceptive interface, while the shell-level agent handles the documented coordinate collection. Both can contribute to credential theft, but they operate through different parts of the malware architecture.

What the AI component actually does

Zimperium also identified a generative AI feature, although its public report does not name the service or model. The malware sends it information from the live Accessibility tree, which represents interface elements visible to the Accessibility service. The system is used to identify controls, interpret on-screen text and return navigation instructions.

That makes AI an aid for adapting interface actions, rather than evidence that RatHat independently plans the entire attack. The documented chain still relies on social engineering to secure installation and on permission abuse to expand access. Its credential-theft mechanisms include overlays, message interception, screen or text monitoring and touch-coordinate analysis, none of which should be conflated with autonomous AI decision-making.

Google’s controls and the limits of uninstalling

BleepingComputer reported on 21 September 2026 that Google said no apps containing RatHat had been found on Google Play. Google also said Play Protect covers known versions of the malware. That statement applies to versions already known to Google and does not establish detection of every variant.

Google’s documentation says Play Protect is enabled by default and checks apps from Google Play and other sources for harmful behaviour. Depending on what it finds, the service may warn the user, block an installation, disable an app or remove it. Users can reduce exposure by leaving Play Protect enabled and avoiding APKs offered through messages, adverts, forums or deceptive download pages.

Accessibility access also deserves particular scrutiny. Users should grant it only when it is necessary for an app’s legitimate purpose and they trust its publisher. An app asking someone to activate Developer Options or Wireless Debugging should likewise be treated cautiously. Those debugging functions should remain disabled when they are not actively needed.

Google says Android Advanced Protection blocks installation from unknown sources and limits Accessibility services to verified accessibility tools. That provides an additional control for users who choose the mode, subject to its compatibility limitations. It is not a guarantee against every malicious app.

For a device confirmed to have RatHat, Malwarebytes advises a factory reset because the persistent component may survive ordinary app removal. The reviewed research found no independent cross-device remediation study, so the advice should not be presented as proof that resetting is the only possible remedy for every device.

A reset is also consequential. Google’s support guidance warns that it erases local data and removes installed apps, making account and backup preparation necessary. The central distinction for users is therefore between prevention and recovery: blocking unofficial installation and refusing unnecessary permissions can interrupt the documented chain early, while a confirmed infection may require action beyond deleting the visible app. The remaining unknowns, including campaign prevalence, affected Android versions and operator identity, prevent a reliable estimate of how widely RatHat has spread.

Layered device access is easier to assess when permission grants and debugging controls are considered together, not as isolated settings. For readers who want to strengthen that foundation, The Hack Academy’s online cybersecurity training programme provides self-paced learning in cybersecurity fundamentals, pairing theory with practical exercises.