RatHat: AI-Powered Mobile Threat is Here for Your Credentials & Bank Accounts

Executive Summary

The zLabs team has uncovered RatHat, a novel Android malware strain linked to threat actors that appear to be operating in China. RatHat incorporates novel techniques for persistence and leverage generative AI for operational control.

Distributed primarily via targeted smishing (SMS/text phishing) and malvertising campaigns leading to deceptive third-party download portals, RatHat uses an automated multi-stage infection pipeline. Once deployed, it pairs Accessibility abuse with autonomous local ADB (Android Debug Bridge) self-pairing to break out of the standard Android application sandbox, staging independent native daemons that execute with shell-level privileges.

Key Technical Findings

• Global Financial Targeting: The malware deploys sophisticated, fake interfaces designed to mimic legitimate banking and payment apps, tricking users into providing their financial login credentials, while also intercepting OTP/2FA codes.
• AI-Driven Automation: RatHat uses AI to intelligently navigate and control the device interface in real-time, making its operations more adaptable and harder for security software to detect than traditional, scripted automation.
• Hardware-Level Credential Theft: By monitoring raw touch input at the hardware level, the malware bypasses standard security protections, allowing it to reconstruct PINs, passwords, and unlock patterns by tracking finger movements directly.
• Self-Escalating Privileges: The malware automatically grants itself deep, administrative-level control over the device without needing a host computer, enabling unrestricted access to critical system functions.
• Persistent & Self-Restoring Access: The malware installs a hidden background service that operates independently of the main app. If a user uninstalls the app, this service remains active, silently reinstalling the malware and restoring its malicious permissions.
• Stealthy Communication Channels: It establishes a covert, permanent connection to the attacker's server, bypassing network security measures to maintain continuous, unauthorized remote control.

RatHat highlights a distinct paradigm shift in the mobile threat landscape: moving away from static, easily disrupted automation toward adaptive, AI-assisted execution chains that operate outside the constraints of traditional mobile app sandboxes.

Delivery Vectors

Threat actors are constantly refining their malware to gain undetected, unauthorized access to sensitive financial information. To succeed, malware developers must overcome two primary obstacles: neutralizing modern OS security controls and deceiving increasingly cautious users.

Initial compromise relies on hybrid delivery channels that combine social engineering with technical obfuscation. During this research we have discovered how the malware has been adapting itself and improving in order to maximize infection rates.

RatHat is primarily distributed through deceptive phishing sites promoted via malvertising, smishing campaigns, and third-party forums, luring victims into manually downloading malicious APKs that appear to be legitimate apps (Figure 1).

Fig.1: Phishing site distributing RatHat malware

Installation & Anti-analysis Techniques

In response to continuous improvements in Android's security architecture, threat actors have refined their deployment methods to bypass real-time detection and ensure persistent access to compromised endpoints.

To remain silent, the installation is done by a dropper and the malware contains four anti-analysis layers and one anti-debug layer. All these stages are described below.

Dropper

The dropper carries its payload in two encrypted assets. Both use the same trivial transform: skip a 24-byte header, read a big-endian length, then per byte ((b ^ 0x4A) - 0xD2) ^ 0xF1, then gunzip. The stage 2 is an in-memory DEX loaded by reflection that contains the code inside to unpack and install the malware payload.

Droppers exploit native SessionInstaller APIs to bypass Android’s restricted settings and Accessibility Service protections, enabling the installation of the malicious payload and subsequent access to protected APIs.

Four Anti-Analysis layers

Droppers and payloads incorporate multiple sophisticated anti-analysis mechanisms to complicate static and dynamic inspection. These defenses span four distinct technical layers: container tampering, manifest manipulation, DEX bytecode poisoning, and dual string-encryption schemes.

Layer 1: Container Tampering

The container tampering layer consists of declaring some files as directories in the zip, or setting the ZIP general-purpose encryption bit on some files. These modifications are ignored by Android libziparchive but not by unzip, apktool and other tools. A similar technique is used by other malware families we blogged about in the past.

Layer 2: Manifest Bomb

The AndroidManifest.xml file is of 61MB and the 99% of it is composed by 2 chunks of undocumented type 0x9999 placed between string pool and the real element stream. This exploits a parse differential: Android’s native runtime simply skips the unknown 0x9999 chunk headers, whereas decompilers and static analyzers fail to parse the non-standard structure or exhaust their memory limits, causing automated analysis pipelines to crash or time out.

Layer 3: DEX Bytecode Poisoning

A substantial portion of the Dex code incorporates pseudo-instructions configured with an invalid element_width attribute. Although the Android Runtime (ART) never executes these payloads, disassemblers attempt to calculate the payload length. Consequently, while the application operates normally, the disassembly process fails.

Layer 4: String-Encryption Scheme

General strings use StringFog (a string encryption library for Android) that is based on a base64 ciphertext XORed with a per-string base64 key. In order to prevent the analysis, this malware uses a scheme called StringCrypto: base64. On top of this, the malware swaps adjacent byte pairs and XOR the result with a 16-byte key.

Anti-debugging Layer

The malware contains six runtime checks for avoiding the debugging:

• JDWP debugger check: Debug.isDebuggerConnected() and Debug.waitingForDebugger()
• Ptrace attach check: reads /proc/self/status and locates the “TracerPid:” line. Catches gdb, lldb and any native attach.
• Presence of FLAG_DEBUGGABLE: this is catching if an analyst is repackaging the APK.
• Properties check: checks for getprop ro.debuggable == "1" and getprop ro.secure == "0".
• Frida Check: TCP probe to port 27042, ps output and grepping for “frida” and scan of the /proc/self/maps for libfrida-agent.so presence.
• Xposed, root or emulator checks: 20 root paths and packages, three Xposed manager packages plus persist.sys.xposed.enable, Build fingerprint and QEMU device nodes

Architecture

The architecture of this Android threat can be broken down into three primary operational parts: the Malicious Android Application, the Go Agent (liblocal-service.so), and the FRP Client (libmedia_codec.so).

Fig.2: Architecture and Operational Flow

The Android App

Its main role is to act as the primary interface with the user, acquire critical system permissions, and bootstrap the rest of the infection chain:

• Lure & Delivery (UI Layer): This component uses sophisticated social engineering. In one build, server_config.json is set to pose as a well known streaming app, hiding behind that app's icon and label. The APK contains dynamic configuration that allows the operator to restyle the launcher icon later by enabling different activity aliases, such as one labeled "Chrome."
• Permissions Acquisition Engine: The critical dependency for everything else is the Accessibility Service. The app uses a localized HTML lure (svc_config.html) driven by pageStyleConfig. In some countries, it claims permission is needed "due to network restrictions" and offers financial bait.
• The Accessibility Service Activation (SystemHelper): once the service is granted, SystemHelperService becomes the engine for every automated system change. This service is used to:
  • Unlock Developer Options by tapping the "Build Number" 7 times.
  • Enable Wireless Debugging.
  • Scrape critical connection data from the UI, such as the 6-digit ADB Pairing Code and the dynamic port from the pairing dialog, falling back to scanning all TextViews if resource IDs are absent (Figure 3).
    
    
    
    Fig.3: Enable Wireless debugging and get pairing code
    
    
• Spyware Capabilities: Beyond orchestration, the APK has powerful direct-access capabilities:
  • Credential Theft: An advanced WebView overlay injection engine targets specific apps, primarily to steal banking credentials.
  • Screen and Input Capture: A combination of MediaProjection Screen streaming and a Lock-screen credential capture mechanism.
  • Data Interception: An SMS receiver and notification listener work in tandem to intercept 2FA/OTP codes.
  • Device Admin & Anti-Uninstall: The app can request Device Admin rights, which grants it the capability to wipe the device if an uninstall attempt is made.
• Generative AI UI-Automation Engine: This is a particularly unique feature. The malware serializes the device's live Accessibility tree to XML and communicates with one of the world’s most popular Generative AI assistants (Figure 4). This AI is used for non-malicious actions including:
  • Resolving a named target's centre coordinates on the screen as JSON to direct synthetic clicks.
  • Resolving a target's actual on-screen text from the XML (without translating).
  • Signaling automatic navigation commands like SCROLL_DOWN.
    
    

Fig.4: AI Prompts used by RatHat indicating potential of China-based threat actors

The Local Privileged Executor: liblocal-service.so Go Agent

The malware includes a sophisticated agent written in Go, which is dropped and executed by the APK once a shell is acquired via the local ADB daemon. It is shipped disguised as a native library (liblocal-service.so) and staged to /data/local/tmp.

The agent is the command-and-control brain executing commands from an ADB shell context, bypassing security limitations that the user-facing app faces.

It is responsible for applying critical system-level persistence and power management exemptions. These are crucial for steady-state operation but are absent from the APK's DEX file, existing only within the Go binary. These commands are visible in the Go agent's strings:

• dumpsys deviceidle whitelist +%s: Exempts the app from Doze mode (battery saving).
• am set-standby-bucket %s active: Puts the app in the "active" standby bucket, prioritizing its background execution.
• pm disable-user --user 0 %s: Allows the operator to disable arbitrary packages on the system.
• pm uninstall -k --user 0 %s: Allows full uninstallation of security or other packages.

The Stealth Persistence Tunnel: libmedia_codec.so FRP Client

The third main part is the reverse-proxy client, frpc (derived from fatedier/frp). This is also a Go binary, shipped disguised as libmedia_codec.so. Once staged to /data/local/tmp/frpc, its only function is to establish a secure, persistent reverse tunnel back to the C2 server. It connects back to the attacker using configuration data (IP, Port, and Token) fetched from the C2 server by the Go Agent (main.fetchFrpcConfigFromServer).

This connection is used by attackers to have access to the ADB daemon: it's a general-purpose road into the device that carries whatever the operator wants, independent of the malware's own feature set.

Operational Flow

The infection and operational flow illustrates the precise sequence through which these components interact.

Initially, the Android application secures Accessibility service access and employs synthetic tap gestures to enable Developer Options and access the Wireless Debugging pairing interface. Subsequently, the application leverages its Accessibility service to extract the local pairing PIN and dynamic port from the user interface. Utilizing the embedded libadb-android library, the application authenticates against the local device's ADB daemon, thereby securing shell-level access to the /data/local/tmp directory.

Via this established ADB connection, the application executes commands to stage and launch both the Go Agent and the FRP Client.

The application interacts with the active Go Agent over a local loopback HTTP interface. Operating within its elevated shell context, the Go Agent executes key system commands—including pm grant and deviceidle—to grant the application persistent operation and WRITE_SECURE_SETTINGS permissions.

Finally, the Go Agent retrieves the FRP tunnel configuration from the C2 server, enabling the FRP Client to establish a persistent, active reverse tunnel to the operator.

Persistence

The App intercepts the uninstall confirmation dialog and renders a fake failure overlay styled as Google Play, cancelling the uninstallation. But even if the user manages to uninstall it, there is another mechanism in place: the local-service is running outside the package lifecycle, so it is not removed when the app is uninstalled.

After the uninstallation, the attacker still has a shell on the device. The service checks if the app is still installed and if the presence is not confirmed, then the app is reinstalled.

The service launches the following commands that allow the reinstallation of the apk, granting every runtime permission automatically and re-granting the accessibility without interacting with the UI:

On the other side, until the app is present and running, it runs a heartbeat that redeploys and relaunches local-service if it stops responding, rescanning the ADB port ladder and re-enabling debugging settings if needed.

C&C Communication Channels

The malware establishes persistent, real-time command-and-control channels to execute remote commands and exfiltrate telemetry, though they rely on fundamentally different networking protocols.

The Android App registers over HTTP, then holds a WebSocket open with heartbeats. Requests are authenticated with HMAC-SHA256 over a device key derived from deviceKeySalt.

Using the embedded Go Agent (liblocal-service.so), the malware spins up an HTTP server bound to 127.0.0.1:7910.

Additionally, as said before, it deploys a masqueraded native library (libmedia_codec.so), which is actually a Fast Reverse Proxy Client (frpc), to expose the internal loopback server and local device interfaces to the internet, bypassing NAT and firewall restrictions.

Communication Endpoints

Espionage and Keylogging

Keylogging remains a staple technique across Remote Access Trojans (RATs). While malware authors employ various strategies to harvest keystrokes, exploiting Android's Accessibility service to track screen activity and exfiltrate data to command-and-control (C&C) servers is among the most prevalent.

To achieve this, RatHat implements the 3 specialized mechanisms described below.

Accessibility text-event keylogger

UniversalInputMonitor consumes accessibility text-change events and reconstructs what was typed, tracking beforeText, eventText, nodeText, hintText, fieldId and pkg per event. It classifies credential fields using the localised PASSWORD_KEYWORDS, PIN_KEYWORDS and ENTER_PASSWORD_KEYWORDS categories, and specifically handles masked_input, reconstructing content from a field showing only dots, with password_field, new_field and per-character char_ records.

Browser URL Harvesting

KeystrokeCapture reads address bars by resource ID: com.android.chrome:id/url_bar, com.brave.browser:id/url_bar, com.opera.browser:id/url_field, com.opera.mini.native:id/url_field, com.microsoft.emmx:id/url_bar, com.duckduckgo.mobile.android:id/omnibarTextInput, com.sec.android.app.sbrowser:id/location_bar_edit_text, plus AOSP and ColorOS browsers.

Raw /dev/input from Go Agent

This is the most capable of the three, and it's a genuine hardware-level keylogger. The class driving it is named AdbTouchCapture.

This logging is executed by the Go Agent and it is able to record where the finger touched the screen.

Fig.5: Go Agent keylogging

The malware is leveraging the fact that it is executed in a shell environment and is using the tool getevent. The command getevent is a standard Android debugging tool that reads (Figure 5) the raw device file the kernel writes to. Its output looks like this:

That's it: a X, a Y, and a timestamp. No text, no app name, no idea what was on screen. Just "someone touched pixel (540, 1624) at this moment."

Normal apps cannot read /dev/input/*; the permissions don't allow it. Shell UID 2000 can. That's a large part of why the malware goes through the whole Wireless Debugging self-pairing dance in the first place, this capability is one of the prizes.

A raw coordinate is useless on its own. What makes it a keylogger is the second half: the malware ships locateValues.json, which contains the keypad layouts for every major phone brand, where key "0" sits, where "5" sits, the geometry of the pattern-lock grid.

So touch at (540, 1624) + "this is a Samsung PIN pad" = "5"

The same trick is used for pattern unlock: the sequence of touch points is matched against the 3×3 dot grid to recover the pattern. That's what the Point and DotAlign helper classes in the cipher package do, and it's why the malware tags recovered credentials with a type called PASSWORD_QUALITY_TOUCH_POINTS: it knows this credential came from geometry rather than from text.

This approach seems to be quite complex and very powerful since it is able to bypass the protections that Android put in place for the other techniques:

• FLAG_SECURE on a window: Blocks screenshots and accessibility reads. Doesn't touch the input driver.
• Usage of a custom keyboard: The app never hands text to the system but the fingers still hit the screen.
• Lock screen protection: Deliberately hides PIN digits from accessibility. Coordinates are unaffected.

Injection Overlay Technique

RatHat is able to steal the credentials of some banking/crypto applications: the malware monitors the foreground application and, upon detecting a targeted package, triggers the corresponding HTML injection mechanism.

The malicious HTML content is supplied by the attacker and is associated with the targeted application, allowing the malware to present a deceptive interface over the legitimate application to capture sensitive banking credentials as shown in Figure 6.

Fig.6: Malware targeting banking apps

RatHat malware focuses also on payment applications like WeChat and Alipay, deploying deceptive screen overlays (Figure 7) that are directly embedded in its code to steal user PINs.

Fig.7: RatHat targeting payment apps

Zimperium vs. RatHat

RatHat’s multi-tiered architecture, reliance on out-of-lifecycle daemons, and use of real-time GenAI decision loops illustrate why traditional, signature-based mobile security controls are insufficient. Both Zimperium’s Mobile Threat Defense (MTD) and Mobile Runtime Protection (zDefend) provide comprehensive zero-day coverage against RatHat across every stage of the attack chain.

Zimperium Mobile Threat Defense (MTD)

For enterprise mobile devices, Zimperium MTD detects and neutralizes RatHat through on-device, dynamic machine learning models:

• Zero-Day Malware Detection: Powered by the on-device z9 engine, MTD flags the dropper and secondary payloads without relying on cloud-tethered lookups or static signatures, not being affected by the bundle manipulation tailored to prevent the analysis.
• Privilege Escalation & ADB Abuse: MTD monitors runtime behavioral indicators, alerting on anomalous Accessibility Service exploitation, synthetic developer option activation, and local loopback pairing attempts targeting the device's internal ADB daemon.
• Network & Phishing Protection: MTD’s on-device web protection blocks malicious domains used in the initial smishing and malvertising distribution stages, while isolating active C2 communications and FRP reverse-proxy tunnels. This would effectively prevent malicious actors from remotely controlling the device.

Zimperium Mobile Runtime Protection (zDefend)

For financial institutions, e-wallets, and payment providers targeted by RatHat’s credential-harvesting overlays and input scraping:

• Overlay detection: zDefend detects fraudulent HTML injection screens and synthetic UI clicks, preventing malicious overlays from intercepting user credentials and PINs.
• Untrusted Environment & Tooling Detection: zDefend identifies when a banking or payment application is executing in an environment compromised by active Accessibility scraping, screen capture utilities, or elevated debugging services, allowing the app to terminate sensitive sessions or trigger real-time mitigation before credentials can be exfiltrated.
• Tamper & Hooking Mitigation: Detects unauthorized system manipulation and dynamic instrumentation, protecting application integrity even on compromised endpoints with shell-level access.

IOCs

RatHat IOCs can be found in this repository.