An Android app cannot read your PIN as you type it. The keypad belongs to another app, the input events go to the system, and the sandbox exists precisely to keep one application out of another's business.
RatHat gets around that by not staying an app.
The sequence
After a victim sideloads the APK — distributed through smishing, malicious ads and fake download portals, disguised as a streaming service or a browser — the malware uses localised lure pages to persuade them to grant Accessibility permission.
Everything after that is automated, and the device does it to itself:
1 Synthetic taps open Settings and Developer Options 2 Build Number is tapped seven times 3 Wireless Debugging is switched on 4 The pairing screen is opened 5 The six-digit pairing code and the dynamic port are read off the screen the malware is already watching 6 An embedded ADB implementation pairs with the phone's own local ADB daemon
No USB cable. No computer. The phone pairs with itself, and the malware now holds a shell context with privileges no ordinary Android application can obtain.
The Accessibility permission is what the victim granted. Shell-level access is what the malware took with it.
Two Go binaries, disguised as native libraries, are deployed from there: liblocal-service.so, a privileged local agent running out of /data/local/tmp, and libmedia_codec.so, a reverse-proxy client that opens a persistent tunnel to the operator.
It does not read your PIN. It reconstructs it.
This is the capability worth understanding, because it defeats an assumption most people hold without articulating it.
The Go agent calls Android's getevent utility to monitor /dev/input and record raw touch coordinates with timestamps. Standard applications cannot read those device nodes — the shell context obtained through Wireless Debugging is what makes it possible.
Coordinates are then mapped back to values using a configuration file the malware ships, locateValues.json.
So the malware never needs to see the contents of a secure keypad. It only needs to know where your finger landed and what was at those coordinates. PINs, unlock patterns and passwords are rebuilt from geometry.
Alongside that it runs HTML overlays on banking, payment, cryptocurrency and messaging apps, intercepts SMS and notifications to capture one-time codes, records text-change events, and scrapes URLs directly from browser address bars — Chrome and Samsung Internet are both explicitly targeted.
The AI part, at its actual size
Most coverage leads with the AI. It deserves a paragraph, not a headline.
RatHat serialises the live Accessibility tree into XML and sends portions of it to a commercial generative AI assistant. The prompts — written in Chinese, which is part of the attribution — ask for three things: the centre coordinates of a named interface element, the actual visible text of an element, and a navigation instruction such as SCROLL_DOWN.
That is user-interface comprehension, outsourced. The benefit to the operator is durability: a hardcoded automation script breaks the moment a bank redesigns a screen, and this does not. It is the same finding Google's threat intelligence team reported earlier this month — attackers using AI for adaptability and efficiency, not for capabilities they did not previously have.
It is worth noting one consequence the malware authors may not have weighed. The operation depends on a third-party AI service, to which it is continuously sending the structure of victims' live screens. That is both a dependency and a lever.
Removing the app is not removing the malware
RatHat runs two components that restore each other. Delete the malicious app and the privileged agent reinstalls it; remove the agent and the app restores the agent.
It also fights the uninstall directly: the malware intercepts the confirmation dialog, cancels the operation, and displays a fake Google Play overlay showing a plausible error message. To the user it looks as though the removal failed for ordinary reasons.
Add anti-analysis on top — APK container tampering, a deliberately bloated manifest of around six megabytes, and invalid DEX pseudo-instructions designed to break analysis tooling — and the practical conclusion is that a device which has completed this infection chain should be reset from a trusted image, not cleaned.
What to do
On any Android phone, today, one minute:
Open Settings, find Accessibility, and look at which apps hold that permission. On most phones the correct list is a screen reader, or nothing at all.
This is the second Android family we have written about in two weeks that turns entirely on that one permission. It is the highest-value check available to an ordinary phone user, and almost nobody has ever done it.
Also worth checking: whether Developer Options is enabled on a phone where nobody remembers enabling it, and whether Wireless Debugging is on. Neither should be, on a phone used for banking.
The rule that prevents the whole chain: do not install APK files from outside Google Play, and leave Play Protect on.
For organisations:
- Treat SMS one-time codes as compromised on any device that may be affected. This malware reads them on arrival, as does every family in its class. Phishing-resistant authentication is the answer, and we have now made that point in three separate articles this month.
- If a personal phone reaches company mail or systems, this is a company problem. Overlays capture credentials, notification interception captures second factors, and the lock-screen PIN is recovered from touch geometry.
- Device compliance as a condition of access does not require managing an employee's personal phone. It requires deciding that an unmanaged one does not reach company data.
4Tify assesses which of your authentication factors depend on devices the organisation does not control. If you want that mapped, get in touch.