It Tapped "Build Number" Seven Times, Then Read the PIN Off Your Fingertips

It tapped "Build Number" seven times, and the phone did the rest

A user installs what looks like a streaming app. They grant it one permission, the Android Accessibility Service, after a convincing pop-up explains it is needed because of network restrictions. From that moment the phone starts operating itself. Synthetic taps walk through Settings, hit the build number seven times to unlock Developer Options, switch on Wireless Debugging, and then read the six-digit pairing code straight off the pairing dialog Android has just put on screen.

The phone then pairs with itself. Zimperium's research team published the malware, called RatHat, on 16 September 2026, and what it wins from that handshake is the part worth understanding, because it is the difference between an app that can spy on you and a process that can read your fingertips.

What Zimperium found

zLabs traced RatHat to actors who appear to be operating from China, the strongest indicator being that the malware's own AI prompts are written in Mandarin. Distribution is unglamorous: smishing (SMS phishing), malvertising and third-party forums push victims towards fake download pages for APK files, Android's installer packages, from outside Google Play. Zimperium has published no victim count and no loss figure. The targets are banking and cryptocurrency apps worldwide, along with the payment apps WeChat and Alipay.

The mechanism is where this stops being routine. Android Debug Bridge, or ADB, is the developer tool that gives a connected computer shell-level control of a phone. RatHat cuts out the computer by pairing the phone with its own debug daemon over the local loopback, which promotes it to the shell user account, an identity sitting outside the normal app sandbox. From there it stages two Go programs disguised as system libraries into a temporary directory: one acts as a privileged command executor, the other is an off-the-shelf reverse proxy that holds a permanent tunnel open to the operator through any firewall. The shell account can also read /dev/input, the raw stream of touch coordinates the kernel produces, which ordinary apps cannot. That stream contains no text, only an X, a Y and a timestamp. RatHat ships a file of keypad layouts for every major handset brand, so a touch at a given pixel on a known Samsung PIN pad resolves to the digit 5. Pattern unlocks come back the same way, by matching the sequence of taps against the three-by-three grid.

• That geometry trick walks past three separate Android defences. FLAG_SECURE blocks screenshots and accessibility reads but leaves the input driver alone. A custom keyboard never hands text to the system, yet the fingers still land on the glass. The lock screen hides PIN digits from accessibility, and coordinates are unaffected.
• A second component serialises the live accessibility tree, Android's structured map of what is on screen, into XML and sends it to a mainstream generative AI assistant, asking for the centre coordinates of a named button, the real text of an element, or a command such as SCROLL_DOWN. Zimperium did not name the assistant.
• Uninstalling the app does not remove it. The privileged agent runs outside the app's lifecycle, notices the app is gone and reinstalls it with every runtime permission pre-granted and accessibility switched back on, with no dialog for the user to refuse.

Why it matters

Nobody has published a figure for what RatHat has taken, and Zimperium does not offer one. The harm that is certain is the credential set: banking logins captured through fake overlays, one-time passcodes lifted from SMS and notifications, and lock-screen PINs rebuilt from touch geometry, which between them defeat both factors of a typical mobile banking login. For your organisation the awkward part is the remediation step. Ask whoever handles a report of a compromised personal phone what the playbook says, and it almost certainly says uninstall the app and run a scan. Against this family, uninstalling is the trigger for reinstallation, and the device has to be treated as a full compromise with every credential typed on it rotated. Anyone running bring-your-own-device with a banking app and an authenticator on the same handset should read that twice.

Underneath sits a boundary that quietly gave way. Android's threat model long assumed shell access needed a cable and a computer, which made it something an attacker did to a phone they were holding. Wireless debugging turned it into something an app can arrange for itself, given one permission grant and the patience to tap through a menu. The AI layer is the smaller half of the story and the more telling one, because the model is not writing malware here. It is acting as the eyes of an operator who is not watching, and every request it receives looks reasonable in isolation, since "where is the confirm button in this XML" is an ordinary question. That is exactly what makes it awkward for a provider to refuse.

What to do about it

1. Rewrite the mobile compromise playbook so it ends in a factory reset, not an uninstall. The persistence agent outlives the app it arrived with, so anything short of wiping the device leaves the operator holding a shell.
2. Check whether your mobile device management can see Developer Options and Wireless Debugging, and alert when they switch on. A user enabling either on purpose is rare enough to investigate, and here the phone enables them by itself, which makes it one of the few observable moments in the whole chain.
3. Tell staff the Accessibility permission request is the decision point, not the install. Every capability described above follows from that single grant, and the lure is localised and plausible rather than obviously broken.

Bottom line

The detail to keep is the file of keypad layouts. Somebody sat down and mapped where the digits sit on the PIN pad of every major phone brand, so that a stream of meaningless pixel coordinates would resolve into a passcode. That is not a clever exploit of a bug. It is patient work against a surface nobody was defending, because nobody expected an app to be standing outside the sandbox looking in. Take it to your next review as a question about what else the shell account can see on a device your staff also bank on, and whether you would notice if something were already there.