RatHat: AI-Powered Mobile Threat Steals Android Shell

1. Basic Information

• Original Title: RatHat: AI-Powered Mobile Threat is Here for Your Credentials & Bank Accounts
• Source: Zimperium zLabs
• Publication Date: 2026-09-16
• Update Date: None
• Severity: Critical
• Basis of Severity: RatHat prompts users to grant accessibility permissions, completing self-pairing for wireless debugging (ADB) locally on the device without connecting an external PC. It then runs a persistent native process with shell privileges (UID 2000), independent of the main app. Sample analysis identified capabilities to reinstall the app after removal, steal financial credentials and one-time passwords (OTPs), and reconstruct touch input using getevent. Actual case counts and financial losses are not publicly disclosed.
• Original Link: RatHat: AI-Powered Mobile Threat is Here for Your Credentials & Bank Accounts
• Related Sources: BleepingComputer: New RatHat Android malware uses AI to automate device control, Zimperium RatHat IOC repository
• Related Entities: RatHat, Android, Android Debug Bridge, Wireless Debugging, FRP

2. Executive Summary

RatHat is an Android remote access trojan (RAT) that abuses accessibility features to connect to the device's own ADB (Android Debug Bridge) interface. It establishes a resident process running with Android shell privileges and a reverse tunnel via FRP, enabling credential theft and self-recovery of the application.

3. Attack Flow

Phase 1 establishes the ADB connection to the device itself, and Phase 2 uses the acquired shell privileges to create a persistent process and a communication channel for remote control. Information theft is grouped as a related capability of the same malware. This does not imply a strict execution order or that all functions begin only after Phase 2 is complete.

Phase 1: Acquiring an ADB Shell via a Fake APK

1. The user manually installs a fake dropper APK onto the device via SMS phishing, malvertising, or download links from third-party forums.
2. The dropper app extracts the main payload from encrypted resources and runs it, requesting the user to enable accessibility features.
3. Using the permitted accessibility features, the malware automatically operates the screen to open "Developer Options," enables "Wireless Debugging," and reads the 6-digit pairing code and port number displayed on the screen.
4. Using its built-in ADB communication library, it connects to the device's own localhost and establishes a state where arbitrary OS commands can be executed with shell privileges (UID 2000, distinct from acquiring root privileges).

Phase 2: Persistence and Remote Control via the Acquired ADB Shell

1. Using the established ADB shell, the malware stages a Go-based agent, packaged as liblocal-service.so, and an FRP client, packaged as libmedia_codec.so, under /data/local/tmp and launches them in the background.
2. The Go-based agent uses its shell privileges to grant permissions such as WRITE_SECURE_SETTINGS to the malicious app, exempt the app from Doze power-saving restrictions, and disable security applications.
3. Using FRP (Fast Reverse Proxy, a tool that relays connections from external sources to internal ports), the malware establishes a reverse tunnel from behind mobile networks or NAT to the attacker's external server, maintaining a direct external communication channel to the internal ADB port.
4. Even if the user uninstalls the main app, the independently operating Go agent silently reinstalls the APK and reconfigures accessibility features. The app and agent also monitor each other's survival and restart the process if it stops.

Related Capabilities: Theft of Financial Credentials and Device Information (Execution Order Not Implied)

• Monitors banking and payment apps launched in the foreground on the device, displaying a fake HTML screen obtained from the attacker's server on top of the legitimate app (overlay attack).
• Intercepts one-time passwords (OTP) by monitoring SMS messages and the notification bar, and collects screen data using the screen capture API (MediaProjection).
• Reads touch operation data from /dev/input using the Android input event tool getevent, matching coordinates against keypads or pattern lock layouts to infer PINs and screen unlock patterns.
• Sends the collected credentials and command execution results to the C2 server via HTTP or WebSocket.

4. Attacker Position and Execution Location

• A remote attacker positioned to trick users into installing unofficial APKs and granting accessibility permissions.
• Once self-pairing is complete, the attacker performs remote control by accessing the internal ADB port and local services directly over the internet via FRP.

5. Indicators for Victims and Administrators

Victims

• Users may see fake video streaming apps or browser icons, notifications disguised as security warnings, prompts guiding them to accessibility settings, or fake error screens preventing app deletion.

Administrators

• Inference: Clues for investigation include granted accessibility features, enabled developer options and wireless debugging, unknown binaries running in /data/local/tmp, and persistent communication with external FRP servers. Not all of these will remain in standard device management logs, requiring verification of available information based on the device, management method, and monitoring product.

6. Success and Failure Conditions

Success Conditions

• The user manually installs an APK from an unknown source and enables accessibility services in system settings.
• Wireless debugging is automatically enabled in the device's OS environment, local host self-pairing succeeds, and an ADB shell becomes available.
• Outbound network traffic from the device to the attacker's C2 server and FRP relay server is maintained.

Failure Conditions

• MDM policies or device security settings block the installation of unmanaged APKs and the enabling of accessibility features.
• Developer options and wireless debugging are disabled or restricted, and existing ADB pairing authorizations are revoked.
• Inference: Blocking C2 and FRP traffic disrupts remote control and external data exfiltration, but it does not remove persistent processes. Do not assume recovery simply by deleting the main app; check for remaining independent processes or reinstallation attempts.

7. What Happens Upon Success

• Theft of login credentials for online banking and cryptocurrency accounts, one-time passwords (OTP), and screen unlock PINs.
• Remote device control with ADB shell privileges (UID 2000), including granting additional permissions and disabling security applications. This does not establish that the malware obtained root privileges.
• Automatic re-installation and persistence of malware that bypasses user uninstallation attempts.

8. Observable Logs

Email

• Inference: As part of the initial vector investigation, check for SMS delivery sources, shortened URLs within messages, and suspicious links shared via internal chat or email.

Proxy / SWG / DNS

• Inference: Extract and investigate log entries for fake app distribution sites, C2 communications via HTTP/WebSocket, external FRP servers, and generative AI APIs used for screen structure analysis.

Endpoint / EDR

• Inference: Check for accessibility permission grant events, developer option activation logs, wireless debugging enablement and ADB connections, executable files inside /data/local/tmp (local-service, frpc, etc.), and package manager (pm) permission changes or background installation logs.

Identity / IdP

• Inference: Monitor for login attempts from unusual locations or unknown devices using corporate accounts or financial credentials potentially stolen from the compromised device.

SaaS / Cloud

• Inference: Audit the MDM/EMM management console for unmanaged APK installation alerts, developer mode activation flags, accessibility feature exception settings, and changes to device administrator privileges.

Network

• Inference: Investigate long-duration WebSocket connections from mobile devices to external destinations, reverse tunnel sessions via FRP, and abnormal traffic patterns opening device local listening ports to external networks.

9. Attack Success Determination

Criteria for Internal Assessment

• Confirmed Malware Execution or Authentication Success: Criteria: Confirmed installation of malicious APKs and permission grants for accessibility, alongside the operation of background main processes or services. The mere presence of an APK or permission grants does not confirm full remote control.
• Confirmed Subsequent Compromise: Criteria: Confirmed evidence of successful ADB self-pairing, persistent processes running with UID 2000, established FRP tunnels, automatic permission grants, and app re-installation (simply having wireless debugging enabled does not confirm a RatHat compromise).
• Confirmed Information Theft or Session Compromise: Criteria: Confirmed external transmission of overlay-inputted credentials, OTPs, PINs, or screen captures via network traffic or device transmission records. Credential input, the existence of collection functions, and C2 connection alone do not confirm successful information theft.

10. Investigation Playbook

Triggers

• Inference: Triggered by MDM detection of unmanaged APKs, simultaneous alerts for accessibility features and wireless debugging being enabled, FRP traffic detection, or user reports of suspicious screens when launching financial apps.

Initial Triage

• Inference: Verify the hash value of the installed APK, download source URL, accessibility permission status, developer options and wireless debugging pairing history, and device administrator privilege status.

Device / Server

• Inference: Preserve the contents of the /data/local/tmp directory, running process lists, ADB authentication key files (adb_keys), package installation/deletion history, and traces of MediaProjection or accessibility usage.

Authentication / Cloud

• Inference: Promptly invalidate active sessions for banking services, corporate cloud services, and single sign-on (SSO) accounts that may have been accessed from the compromised device, and investigate unauthorized transfers or data access.

Subsequent Operations

• Inference: Track external remote commands sent to the Go agent, internal access via FRP, forced termination of security apps, file transfer logs, and data exfiltration volume to external C2.

Containment

• Inference: Isolate the device from the network and preserve evidence as much as possible. If persistent processes or automatic re-installation is suspected, consider factory resetting the device after verifying data and business impact. Change credentials from a secure secondary device based on the scope of compromise, and do not assume recovery by simply deleting the app.

Decision Categories

• Inference: Strictly distinguish and log each stage: mere APK download, accessibility permission grant, self-establishment of an ADB shell, startup of persistent processes, and external exfiltration of credentials.

11. Defense and Detection Ideas

Single Event

• Inference: Set up single-event detection rules for granting accessibility permissions to unmanaged third-party APKs, enabling wireless debugging, and granting permissions (pm grant) or background installations (pm install) via the ADB shell.

Time-Series Correlation

• Inference: Correlate sequences in chronological order, ranging from the installation of unofficial APKs, enablement of accessibility features and developer mode, ADB self-pairing, binary execution under /data/local/tmp, to communication with external FRP servers.

Threat Hunting

• Inference: Hunt across enterprise devices for corporate endpoints with developer options and accessibility features simultaneously enabled, communication signatures of FRP clients, processes utilizing loopback listening ports (such as port 7910), and published RatHat-related IOCs.

Log Gaps

• Inference: Depending on the Mobile Device Management (MDM) product configuration, logs for background processes running inside the OS shell or direct access to /dev/input may not be collectible. Understand the scope of monitorable logs and design detection rules that filter out noise from legitimate development and maintenance work.

Priority Countermeasures

• Inference: On managed devices, use supported MDM policies to block installation from unknown sources, allow accessibility services only for approved apps, and disable developer options and wireless debugging. Also promote the implementation of screen overlay and debug connection detection in financial and critical applications.

12. Facts / Inference / Hypothesis

Facts

• Zimperium reported RatHat as Android malware associated with threat actors assessed to operate in China, without specifying a particular threat group name.
• Distribution channels include manual installation of fake APKs via SMS phishing, malvertising, and forum links. The dropper extracts DEX code from encrypted resources and uses the Android SessionInstaller API to attempt bypassing restricted settings.
• Once accessibility permissions are granted, the malware automatically taps build numbers to open developer options, enables wireless debugging, automatically retrieves the 6-digit pairing code and port number displayed on the UI, and self-connects to localhost ADB.
• Using the ADB shell, it stages the Go-based agent and FRP client under /data/local/tmp. The agent grants the malicious app WRITE_SECURE_SETTINGS, exempts it from Doze restrictions, and can disable security apps; the FRP client establishes a reverse tunnel to the external server.
• The Go agent persists in the OS even after the main app is uninstalled, silently reinstalling the APK and reconfiguring accessibility features. The app also features mutual recovery capabilities where it periodically monitors the agent's survival and restarts it.
• Credential theft capabilities include overlay displays on banking and payment apps, OTP retrieval from SMS and notifications, and key input capture via accessibility features. Additionally, it executes Android's getevent via shell privileges to correlate touch coordinates obtained from /dev/input with on-screen layouts, reconstructing PINs and unlock patterns.
• Generative AI is used to automate screen operations—analyzing UI hierarchy XML data obtained via accessibility features to determine exact tap coordinates and scrolling instructions on the screen (not evidence that AI autonomously determines attack objectives).

Inference

• Linking accessibility permission grants, developer option activation, localhost ADB connections, process execution in /data/local/tmp, and external FRP communications in chronological order serves as a clue for narrowing down investigations. However, the detection accuracy of this correlation has not been evaluated in public information. Organizations must verify available logs, legitimate development and maintenance activities, and potential false positives internally.

Hypothesis

No additional hypotheses. Unconfirmed items are listed in "Unknowns and Additional Investigation."

13. MITRE ATT&CK Mapping

• T1453 Abuse Accessibility Features (Confidence: high): Mobile ATT&CK technique. Abused Android accessibility features to automatically operate screen elements and illicitly capture input content.

14. Unknowns and Additional Investigation

• Total number of actual infected victim devices, details of targeted countries and organizations, and actual financial loss amounts.
• Names of external generative AI services abused for screen analysis, API key management methods, and attacker-side prompt structures.
• Specific boundary conditions under which ADB self-pairing and automatic reinstallation succeed across various Android OS versions and vendor-customized UIs.

15. Impact on SOCs and Organizations

For organizations operating corporate smartphones or BYOD devices, the key takeaway of this incident is the configuration where an independent process can remain running and reinstall the main app after the user uninstalls it. Depending on device management methods and business requirements, restrict the use of apps from unknown sources, accessibility features, developer options, and wireless debugging, and review collectible logs. On suspected infected devices, investigate processes in /data/local/tmp and FRP traffic, and do not assume recovery simply by deleting the app. If persistence or reinstallation is suspected, consider a factory reset after confirming evidence preservation and impact on data and operations, and change credentials according to the scope of compromise.

16. Summary by Role

• SOC: Inference: Correlate accessibility permission grants, wireless debugging self-pairing, process residency in /data/local/tmp, and FRP traffic as a single incident chain. Tune detection rules after understanding legitimate development use cases.
• Administrators: Prohibit the installation of APKs from unknown sources via MDM, and restrict and audit unnecessary accessibility-service access, developer options, and wireless debugging using the controls supported by the device-management platform.
• Users: Never install APKs sent via SMS or suspicious websites, and stop using suspicious apps that request accessibility access or developer options; report them to your IT or security team.