RatHat Turns Android’s Own Debugging Tools and Generative AI Into a Persistent Control Channel

A newly identified Android malware family called RatHat combines Accessibility abuse, autonomous ADB pairing, credential-stealing overlays, native background services, and AI-directed interface navigation. Researchers reported the malware on September 17, 2026, attributing its operation to threat actors based in China.

RatHat reaches victims through malicious advertisements, SMS phishing, deceptive download pages, third-party portals, and forums. These campaigns persuade users to sideload APK packages hosted outside Google Play.

Once installed and granted Accessibility permissions, RatHat can enable Wireless Debugging, pair with the device’s local Android Debug Bridge service, and obtain shell-level execution. Its components can then preserve access even if the victim removes the visible Android application.

Sideloaded APKs Open the Door to Accessibility Abuse

The initial APK acts as a dropper for RatHat’s primary payload. It also includes protections intended to interfere with automated inspection, debugging, and reverse engineering.

The infection depends heavily on social engineering. Android users must install the package from outside Google Play and then grant permissions that give the application substantial control over the interface.

Accessibility services are central to the attack. Although designed to help users interact with devices, they can also allow an application to observe interface elements and perform synthetic actions when misused.

After receiving this access, RatHat can navigate Android settings, enable Developer Options, activate Wireless Debugging, and retrieve the six-digit code used for ADB pairing. It can therefore establish a local debugging connection without requiring an attacker-controlled computer to be physically connected.

This self-pairing technique gives RatHat access to an ADB shell and capabilities extending beyond those directly implemented in the malicious application. Similar mechanisms have previously appeared in the ToxicPanda and RedHook Android malware families.

The affected Android versions have not been disclosed. No malicious package names, hashes, domains, IP addresses, or other campaign-specific indicators are currently available.

Three Components Create Redundant Persistence

RatHat uses three cooperating layers rather than relying on a single Android package.

The first is the malicious application itself. It manages Accessibility access, enables debugging functions, deploys other components, presents phishing overlays, intercepts communications, records the screen, and obstructs removal.

A second component is a Go-based local agent disguised or packaged as liblocal-service.so. Running with access obtained through the local ADB daemon, the agent can execute attacker-supplied commands, request battery-management exemptions, establish persistence, and collect keystrokes or screen presses.

The agent also checks whether the Android malware remains installed. If the application has been removed, it can reinstall it.

The third layer is an FRP reverse-proxy client. Reporting on RatHat’s architecture identifies its library as libmedia_codec.so. The component receives tunnel configuration through the Go agent and creates a persistent reverse connection to command-and-control infrastructure.

That tunnel gives operators a general-purpose route to the device’s ADB daemon, independent of RatHat’s built-in commands. It can maintain access even when individual malware functions are disrupted.

Persistence works in both directions. The Android application can restore the local agent if that component stops or disappears, while the agent can reinstall the application. Removing only the app icon or visible package may therefore leave the device compromised.

RatHat also actively interferes with uninstallation. It cancels the Android confirmation flow and displays a counterfeit Google Play-style error screen, misleading the victim into believing that removal failed for a legitimate system reason.

Generative AI Interprets Live Android Screens

RatHat’s distinguishing feature is an AI-assisted control mechanism that interprets the current user interface instead of depending entirely on fixed coordinates and predefined scripts.

The malware serializes the live Android Accessibility hierarchy into XML. It then sends that representation to an unnamed, widely used generative AI assistant.

The AI system is reportedly used for three tasks:

• Finding a named interface element and returning its center coordinates in JSON format.
• Extracting the text currently displayed by a selected element.
• Producing navigation instructions such as SCROLL_DOWN.

This creates a dynamic decision loop. If a button changes position, an application displays different text, or a screen requires scrolling, the AI can interpret the updated Accessibility tree and suggest the next action.

Rigid automation often breaks when applications change layouts, languages, or interface states. RatHat’s approach instead lets operators describe a target element and delegate part of the navigation process to the AI service.

The assistant’s identity is unknown. Researchers have not disclosed the model, provider, communication protocol, account arrangement, or whether the service is accessed directly or through attacker-controlled infrastructure.

The feature does not make the malware autonomous in every respect. RatHat still relies on an extensive control architecture, command-and-control instructions, Accessibility access, and local ADB execution. However, AI reduces the need for operators to manually navigate every screen or maintain scripts for each interface variation.

Banking Theft Is Only One Part of the Threat

RatHat can place HTML overlays over banking and cryptocurrency applications to capture account credentials. It can also intercept SMS messages and notifications, potentially exposing one-time passwords used during authentication.

Its surveillance capabilities extend across the device. They include:

• Capturing lock-screen PINs, passwords, and unlock patterns.
• Recording credentials entered into applications.
• Monitoring text-change events and keystrokes.
• Collecting URLs entered into browser address bars.
• Recording screen presses through the Go agent.
• Creating screenshots and recordings through Android’s MediaProjection API.
• Collecting files and the installed-application inventory.
• Remotely navigating applications and system settings.
• Executing arbitrary commands through the ADB shell.

The reverse tunnel increases the impact because it provides continuing access beyond a fixed menu of malware features. An operator with a path to the ADB daemon can use shell-level functions exposed by the compromised device.

RatHat consequently presents risks to banking accounts, cryptocurrency services, private messages, stored files, authentication codes, and device unlock secrets. Screen recording and touch monitoring may also reveal information that would not be captured through conventional credential overlays.

The campaign follows a broader pattern of Android threats using sideloaded packages for intrusive surveillance. Another recent example, Mantax Otax malware, was likewise distributed through APKs outside Google Play, although its capabilities and architecture differ from RatHat’s.

Malformed APK Structures Complicate Inspection

RatHat’s developers use several anti-analysis techniques to produce different behavior in Android’s own parsers and common reverse-engineering tools.

Some files are declared as directories or marked with the ZIP general-purpose encryption flag. Android’s libziparchive can ignore those entries while utilities such as unzip and apktool process them differently.

The AndroidManifest.xml contains undocumented 0x9999 chunk headers. Android’s native runtime skips these structures, but automated analysis systems may crash, time out, or fail to parse the package. The manifest has also been reported as reaching 61 MB, an abnormal size that further burdens scanning pipelines.

RatHat additionally inserts invalid DEX pseudo-instructions with an improper element_width attribute, potentially breaking disassemblers. A dual string-protection mechanism identified as StringCrypto: Base64 makes static examination more difficult.

These defenses do not directly provide device control. Their purpose is to delay classification, produce inconsistent tool results, and reduce the reliability of automated malware-analysis workflows.

Researchers assess RatHat as operated by China-based actors. Chinese-language prompts sent to the AI subsystem support that assessment, but no named threat group has been confirmed. Attribution remains provisional.

Detection Must Extend Beyond the Visible Application

Users should avoid APKs promoted through unsolicited text messages, advertisements, forums, phishing pages, or unfamiliar download portals. Applications should not receive Accessibility access unless their legitimate function clearly requires it.

Unexpected activation of Developer Options or Wireless Debugging is a significant warning sign. Users should also investigate unexplained ADB pairing prompts, requests for battery exemptions, suspicious screen-recording permissions, and applications that display Google Play-themed errors during removal.

Google Play Protect scans can help identify harmful applications, but RatHat’s independent services make response more complicated than deleting one APK.

Enterprise and mobile-security teams should look for:

• Unauthorized Accessibility services.
• Unexpected Wireless Debugging activation.
• Unrecognized local ADB pairing events.
• Native libraries named liblocal-service.so or libmedia_codec.so.
• Unusual FRP reverse-proxy traffic.
• Persistent processes surviving application removal.
• Repeated installation of a previously deleted package.
• Counterfeit Google Play uninstall-failure screens.

The library names alone are not sufficient proof of infection and should be evaluated with process, package, network, and ADB activity.

No complete vendor remediation procedure has been published. Because RatHat’s Go agent may survive removal of the primary application and subsequently reinstall it, responders must verify that the ADB-accessible service and reverse tunnel are also gone. Otherwise, apparent removal may only eliminate the most visible part of the compromise.