RatHat: Android Malware Uses AI to Control Your Device

RatHat: Android Malware Uses AI to Control Your Device

A new Android remote access trojan called RatHat, uncovered by Zimperium's zLabs, mixes the worst of the last two years of mobile malware with something genuinely new: a generative-AI assistant driving its UI automation. Distributed through smishing, malvertising and phishing sites pushing APKs outside Google Play, it automatically pairs itself to its own ADB transport, installs a persistent agent outside the app lifecycle, and — the twist — asks a popular GenAI assistant how to navigate the infected device's interface in real time.

Zimperium believes the operators are China-based threat actors, partly because the malware's own LLM prompts are written in Chinese. Targets call out Chinese platforms too: the credential overlay themes include WeChat and Alipay alongside banking and cryptocurrency apps. But the automation pattern is universal — and it will show up in other malware within months.

The automation chain: from smishing to a mobile backdoor

RatHat's distribution is unglamorous and effective: SMS phishing, malvertising, and spoofed download portals that convince victims to install an APK. Nothing lands on Google Play. Once installed, the app asks for Accessibility services — a permission the victim grants because the fake app looks like a utility or game.

The full chain, per the zLabs report:

1. Accessibility abuse + self-pairing ADB. Using Accessibility, RatHat toggles Developer Options (tapping the build number seven times) and enables Wireless debugging. It then reads the pairing code and port directly from the system UI, pairs to its own ADB transport — no external computer — and drops a Go-based agent (liblocal-service.so) into /data/local/tmp. As an ADB shell (uid=2000), the agent runs shell commands with elevated privileges the sandboxed app doesn't have.
2. Persistence outside the app lifecycle. The Go agent is a standalone process. It takes care of its own persistence: bypassing battery restrictions (dumpsys deviceidle whitelist, am set-standby-bucket active), and re-installing the APK (pm install -r -g from the temp dir) even if the user uninstalls the main app. Attempt to remove it and the app claims Device Administrator, intercepts the uninstall confirmation and presents a fake Google Play overlay instead.
3. A reverse tunnel into your network. A second component — libmedia_codec.so — is actually an frpc client (from the fatedier/frp project), giving the C2 a persistent reverse proxy tunnel to the device's local HTTP server (127.0.0.1:7910). This is the network equivalent of walking through the front door because the lock was never changed.
4. Credential harvesting. HTML overlays sit on top of banking, crypto, WeChat and Alipay screens to capture credentials. SMS and notification interception catches OTPs. A URL grabber reads the browser address bar. And a hardware-level keylogger reconstructs lock-screen PINs, patterns and passwords from raw touch events.

The part that is new: an AI assistant as the automation brain

Traditional Android banking trojans use scripted, rigid layouts: tap these fixed coordinates for this app. If the app updates its UI, the script breaks. RatHat answers that with GenAI-assisted UI automation:

• The malware serializes the Accessibility tree to XML.
• It submits that XML to a well-known generative AI assistant, asking it to do three concrete jobs: return the center coordinates of a specifically named UI element as JSON (for a synthetic tap), resolve what text is actually on screen (so it can adapt), and produce navigation instructions like SCROLL_DOWN.
• The resulting coordinates and instructions are executed against the device.

Why that matters: the malware is no longer a fixed script. Screen dimensions, RTL layouts, keyboard differences, per-app UI changes — none of it matters, because the model reads the screen and decides what to touch, live. Zimperium's assessment is that this makes the malware more adaptable and harder for security software to detect than traditional, scripted automation.

For defenders, that collapses the old assumption that "if I change the app's UI, the trojan breaks." That mitigation is dead.

The keylogger detail worth your attention

The hardware keylogger is arguably the nastiest single feature. Because the Go agent runs as ADB shell (uid=2000), it can read raw device files Android apps cannot normally touch:

# Simplified /dev/input event stream captured by the agent
EV_ABS       ABS_MT_TRACKING_ID   0000002b
EV_ABS       ABS_MT_POSITION_X    0000021c
EV_ABS       ABS_MT_POSITION_Y    00000658
EV_KEY       BTN_TOUCH             DOWN
EV_SYN       SYN_REPORT           00000000
EV_ABS       ABS_MT_POSITION_X    0000021e
EV_ABS       ABS_MT_POSITION_Y    00000656
EV_SYN       SYN_REPORT           00000000

Each record is matched against the device's own locateValues.json keypad maps, reconstructing PINs, unlock patterns and passwords typed on the lock screen — which defeats FLAG_SECURE (used by apps to block screenshots) and even custom keypads, because it bypasses the UI layer entirely. This is the same blind spot browsers and apps have been fighting: if the input ever hits the kernel event device, a process with ADB privileges can log it.

Anti-analysis and anti-removal

zLabs documents four defensive layers plus anti-debugging, so this is not a static-analysis problem either:

1. Container tampering — the APK is modified when distributed.
2. A 61 MB AndroidManifest.xml "manifest bomb" — 99% of it is undocumented 0x9999 type chunks, pushing standard parsers to the limit.
3. Invalid DEX pseudo-instructions — invalid element_width fields that make bytecode disassembly garbage.
4. String encryption — StringFog and StringCrypto hide all string constants (URLs, commands, prompts).

On the anti-debug side: JDWP and ptrace (TracerPid) checks, FLAG_DEBUGGABLE / ro.debuggable / ro.secure detection, a probe for Frida's default TCP port (27042), and Xposed / root / emulator detection. The report publishes IOCs on GitHub Zimperium/IOC under 2026-09-RatHat.

What to do about it

If you work in mobile security or run end-user Android fleets, the actionable list is short:

1. Treat "install outside Google Play" as a red line. RatHat's entire attack surface is sideloaded APKs. Device owners who install from official stores are not in this population.
2. Audit Accessibility grants. Every one of these trojans climbs the same mountain. Review which apps hold Accessibility, and revoke it from anything you did not install knowingly. On managed fleets, policy-lock it.
3. Watch wireless debugging. A user with Developer Options enabled, plus a "Wireless debugging" toggle they do not remember flipping, is the RatHat signature. RatHat extracts the pairing code and port from the system UI automatically — so the pairing dialog existing is not a barrier. Disable Wireless debugging entirely when it is not in active use.
4. Plan for AI-driven UI automation. The classic "change your app UI to break the trojan" control is now ineffective against this class. Detection shifts to the accessibility and activation pattern (build-number taps, accessibility grant, suddenly-enabled developer options), not the overlay layout.

This joins a pattern we have been tracking around AI agents: the same technology giving developers superpowers is now giving malware an autopilot. Where prompt-injected tools and hijacked coding sessions weaponize the AI assistant your engineers trust, RatHat shows the consumer side — malware that asks an AI how to operate a phone it has already compromised. Same lesson on both sides of the fence: treat the assistant as a capability, not as a boundary.

Sources

• Zimperium zLabs: RatHat — AI-Powered Mobile Threat Is Here For Your Credentials & Bank Accounts
• BleepingComputer: New RatHat Android malware uses AI to automate device control
• Zimperium/IOC (GitHub): 2026-09-RatHat indicators of compromise