Zimperium details RatHat, an Android RAT that grants itself shell access via wireless debugging

Zimperium zLabs has published a report on RatHat, an Android remote access trojan that talks victims into granting accessibility permissions and then uses them to pair with the phone's own debugging interface, handing itself a persistent shell on the device. The report, dated September 16, 2026 and summarized on dev.to, rates the threat as critical. BleepingComputer covered the same research as an example of malware using AI to automate device control.

From a fake app to a local ADB shell

The infection starts with a dropper APK that the victim installs manually, typically after SMS phishing, malvertising, or download links posted on third-party forums. Once launched, the dropper unpacks its real payload from encrypted resources and asks the user to turn on accessibility features.

That permission is the hinge of the whole attack. According to Zimperium, the malware then operates the screen on its own: it opens Developer Options, switches on Wireless Debugging, and reads the six-digit pairing code and port number displayed on screen. Using a built-in ADB client, it connects to the device's own localhost interface, with no external computer involved, and reaches a state where it can run operating system commands with shell privileges, identified as UID 2000. The researchers are explicit that this is not root access.

Persistence that survives uninstall

From that shell, RatHat places two binaries in /data/local/tmp: a Go-based agent disguised as liblocal-service.so and an FRP (Fast Reverse Proxy) client disguised as libmedia_codec.so. The agent uses its shell rights to grant the malicious app sensitive permissions such as WRITE_SECURE_SETTINGS, exempt it from Doze power-saving restrictions, and shut down security applications.

The FRP client opens a reverse tunnel that relays connections from the attacker's server to the phone's internal ADB port, keeping a direct command channel alive even when the device sits behind carrier-grade NAT. The app and the agent also monitor each other: if the user removes the app, the standalone agent quietly reinstalls the APK and reconfigures accessibility, and either process restarts the other if it stops running.

What gets stolen

On the data-theft side, the malware watches which banking and payment apps are in the foreground and overlays them with fake HTML screens fetched from the attacker's server. It harvests one-time passwords from SMS and the notification bar, captures screen content through the MediaProjection API, and reads raw touch events from /dev/input using getevent, matching coordinates against on-screen keypad and pattern-lock layouts to infer PINs and unlock patterns. Stolen credentials and command output travel back to the command-and-control server over HTTP or WebSocket.

The AI angle rests on thinner public detail. The report's network indicators include traffic to generative AI APIs that researchers associate with analyzing screen structure, and BleepingComputer framed the finding as AI being used to automate device control. Zimperium has not published victim counts or financial losses tied to the campaign.

Signs of compromise and what blocks it

Victims may notice icons posing as video streaming apps or browsers, notifications disguised as security warnings, prompts steering them toward accessibility settings, or fake error screens that prevent deletion. For administrators, the report points to granted accessibility services, enabled developer options and wireless debugging, unknown executables in /data/local/tmp, and persistent communication with external FRP servers, while cautioning that not all of this survives in standard device management logs.

The attack fails when MDM policy or device settings block unmanaged APK installs and accessibility grants, or when developer options and wireless debugging are restricted and existing pairing authorizations are revoked. Cutting off command-and-control and FRP traffic disrupts remote control and exfiltration but does not remove the resident processes, and deleting the visible app alone is not a recovery.

Why it matters

RatHat shows how social engineering can be chained with Android's own developer tooling: accessibility services, built to assist users with disabilities, are used to drive the screen and complete the wireless-debugging pairing that was designed for developers. The privilege escalation is supplied by the victim's own phone, and because persistence lives in an independent shell process rather than in the app, the standard advice to uninstall the suspicious package does not work here. For organizations, the practical defenses are policy-level: block sideloaded apps, restrict accessibility grants and developer options on managed devices, and treat wireless-debugging activation as an alertable event. With OTP interception and unlock-pattern inference in the same toolkit, SMS-based second factors alone are not a dependable boundary once a device is compromised.