A new Android banking trojan called RatHat moved through the security trade press in a hurry this month. Zimperium's zLabs threat research team published the original technical work on September 16, 2026, and the write-ups that followed painted a familiar shape: an AI-powered malware family that hijacks a phone, drains a bank account and hides its tracks. Malwarebytes Labs reports that RatHat gives a live generative-AI assistant read access to the device's Accessibility Service tree and lets it decide in real time where to tap or scroll, instead of following a fixed automation script. That is the kind of detail that makes for an easy headline: the AI menace has arrived in your pocket.
Security Affairs reports that RatHat spreads primarily through malvertising, smishing campaigns and third-party forums that push victims toward fake phishing sites, tricking them into manually downloading malicious APK files disguised as legitimate apps. Once installed, SecurityWeek reports it deploys a WebView overlay-injection engine that serves fake interfaces of popular banking apps on top of the real ones, captures the device's screen and user input, intercepts SMS messages and requests Device Admin rights that can wipe the phone. BleepingComputer reports that researchers have linked RatHat to threat actors operating out of China, based on the fact that the prompts the malware sends to its embedded AI model are written in Chinese. Every outlet that picked up the story ran some version of it within days of the original disclosure.
It is worth slowing down on what that coverage keeps skipping past. Nearly every piece treats RatHat as a story about artificial intelligence automating an old crime. The more useful fact sits one layer down, in the part of the malware that has nothing to do with AI at all: RatHat never has to see a one-time password, because it never has to ask for one.
The Reserve Bank of India's own Authentication Mechanisms for Digital Payment Transactions Directions, 2025 state that the digital payments ecosystem has primarily adopted SMS-based One Time Password as the additional authentication factor, which is the status quo those very Directions are trying to move the industry past. That OTP wall assumes the attacker's problem is intercepting a message in transit, a text sitting on a SIM or a notification. Zimperium's zLabs team found that RatHat instead reconstructs a victim's bank PIN and unlock pattern from the raw touch coordinates read off the phone's input driver. That sidesteps Android's FLAG_SECURE screen-reading protection entirely, because the flag blocks screenshots and accessibility reads but never touches the input driver itself. The OTP was never in the room. RatHat reads the PIN the same way the owner does, by watching where the finger lands.
Reading the screen, not the message
Android's OTP-era defenses were built to guard the message, not the touchscreen.
| Defense layer | What it was built to stop | What RatHat does instead |
|---|---|---|
| SMS-based OTP | Interception of the second-factor code in transit | Never intercepts the OTP; it does not need one |
| FLAG_SECURE on the banking app's window | Screenshots and accessibility-service reads of the screen | Reads raw touch coordinates off the input driver, a layer FLAG_SECURE does not cover |
Comparison built from the Reserve Bank of India's Authentication Mechanisms for Digital Payment Transactions Directions, 2025 and Zimperium zLabs' technical breakdown of RatHat. Table: The Signal.
The Accessibility Service piece is what makes the theft look effortless rather than brittle. A live model reading the accessibility tree in real time can adapt when a bank redesigns a login screen or moves a button; a hardcoded script cannot. RatHat's designers built the flexible version.
From a tap to a takeover
Reading a PIN once is a nuisance. RatHat is built to keep coming back. CyberUpdates365 reports, citing Zimperium's findings, that RatHat automates enabling Android's Wireless Debugging setting and reads the resulting six-digit ADB pairing code itself, using an embedded ADB client to pair with the phone's local ADB service and open a shell session. That session gives it access to the Android shell context, with capabilities beyond those normally granted to a standard application. That shell survives the obvious fix. The Hacker News reports that even after a victim uninstalls RatHat, the attacker still retains shell access on the device and can use it to check whether the malicious app is still installed and silently reinstall it if not. Deleting the app does not end the intrusion; it just removes the part the victim could see.
The bigger wave RatHat is riding
A national tally like that is abstract; it does not say what an OTP-focused Android trojan costs Indian bank customers when one is actually aimed at India. There is a closer precedent, though it is not RatHat itself. A separate Zimperium zLabs investigation, published in February 2025, found a mobile malware campaign of nearly 900 samples that primarily targeted users of Indian banks by intercepting OTPs and other SMS messages, and traced a data exposure from that campaign's own backend infrastructure to an estimated 50,000 victims. That campaign stole OTPs in transit rather than skipping them outright the way RatHat's touch-reading does, so it is a cousin, not a match, and RatHat itself has not been reported targeting India. Even so, it is the clearest evidence yet that an Android trojan built to defeat India's SMS-OTP defense does not stay theoretical once it is actually pointed at Indian banks. The design gap it exploited is the same one RatHat exploits, and against Indian banks it already turned into tens of thousands of exposed accounts.
Regulators are visibly trying to keep pace with that curve. Under the Reserve Bank of India's Commercial Banks Cybersecurity, Technology: Risk, Resilience and Assurance Framework Directions, 2026, banks must now report cyber incidents within six hours of detection on the RBI's DAKSH supervisory platform and proactively notify CERT-In. That is a faster clock than banks worked to before, and it is aimed at incidents a bank can actually see. RatHat's entire design runs against exactly that kind of detection: an overlay the user cannot tell from the real app, a shell that survives an uninstall, and a theft method that never trips the one signal India's banking system was built to watch for, an intercepted OTP.
The honest objection
The strongest case against blaming the Accessibility Service itself is that it is not a design flaw. It is a feature doing precisely what it was built to do. Android's Accessibility Service exists so a screen reader can describe a button to a blind user, or a switch-access tool can tap on someone's behalf when they have limited motor control. Malwarebytes Labs' account of RatHat describes the malware borrowing that exact capability: a program that decides where to tap in real time rather than following a hardcoded script, the same way an assistive tool does. Strip that capability out at the operating-system level and the tool millions of disabled users depend on to use a banking app at all goes with it.
That case is real, but it does not fully hold once you look at where RatHat actually gets its PIN. Even if a bank somehow managed to detect and block every session where an untrusted accessibility service is running, the FLAG_SECURE protection banks already rely on to block screenshots and accessibility-service reads does not extend to the input driver, the layer RatHat reads the PIN from directly. The Accessibility Service abuse and the input-driver read are two separate holes. Closing the first one, however carefully, would not close the second.
The Signal
RatHat is not impressive because it uses artificial intelligence, and it is not dangerous because it is good at defeating OTPs. It is dangerous because it does not need to defeat them. India built its banking second factor around a text message, and this malware simply goes to where the message was always headed: the finger on the glass. That is a design gap, not a code exploit, and design gaps do not close with a signature update.
What to watch is not whether RatHat itself gets patched. It will, eventually, the way every named malware family does. Watch instead whether the fix touches the two things this piece actually found: whether Android starts gating what a financial app can infer from raw touch and ADB access the way it already gates what it can screenshot, and whether the six-hour incident-reporting clock the RBI now runs banks on catches attacks like this before the money moves, or only writes them up after. An OTP that was never asked for cannot be the thing that saves the account.
Reporting basis: RatHat's technical mechanics, including its Accessibility Service abuse, its FLAG_SECURE bypass, its ADB persistence, its overlay and Device Admin behavior, its distribution channels and its linkage to China-based operators, trace to a single origin, Zimperium's zLabs threat research team, whose original findings were recarried with added detail by Malwarebytes Labs, CyberUpdates365, The Hacker News, SecurityWeek, Security Affairs and BleepingComputer. India's OTP-centric authentication baseline and the RBI's move away from it are per the Reserve Bank of India's Authentication Mechanisms for Digital Payment Transactions Directions, 2025; the six-hour incident-reporting requirement is per the Reserve Bank of India's Commercial Banks Cybersecurity, Technology: Risk, Resilience and Assurance Framework Directions, 2026, a separate RBI instrument. The doubling of recorded cybersecurity incidents from 2022 to 2024 is per the Press Information Bureau, citing CERT-In data. The FatBoyPanel campaign figures, a separate malware family from RatHat, are per a February 2025 Zimperium zLabs investigation. The days-after-disclosure figures in the first chart are The Signal's calculations from each outlet's own publication date measured against Zimperium zLabs' September 16, 2026 disclosure date.
