How Fake Apps Steal OTPs in India: Accessibility Service Abuse Explained

Most banking-fraud stories in India end with a sentence like: “and then they got my OTP.” The story rarely explains how. The victim swears they didn’t share it. The bank reviews the logs and confirms an OTP was sent and used within seconds. Both are correct. The OTP was never “shared” in the way most people imagine; it was read, silently, off the victim’s own phone, by an app the victim installed themselves.

This post is the technical explanation that consumer-facing scam advice tends to skip. It walks through exactly how an OTP gets stolen from a phone, why “loan apps” are the dominant delivery mechanism in India, and the four defences that actually work. It is more detailed than the average guide because once you understand the mechanism, the defences make sense as a system rather than a list of rules to memorise.

Two ways an app can read your OTP

An OTP arriving on your phone is normally an SMS, a push notification, or both. There are two distinct technical mechanisms a malicious app can use to read it without you sharing it.

Mechanism 1: SMS_RECEIVE permission

Android exposes a permission called RECEIVE_SMS (and READ_SMS). An app holding this permission gets a callback whenever an SMS arrives, with full message content including OTP. Google has clamped down on this since around 2019, only the default SMS app can hold it on Play Store apps without an explicit Google review, but the permission still exists. A sideloaded APK that asks for SMS permission and is granted it can read every SMS the device receives.

This is the older, simpler attack. It is increasingly rare on Play Store apps because Google reviews and rejects apps that request SMS access without a justified reason. It remains common on apps distributed outside Play Store.

Mechanism 2: Accessibility Service abuse (the modern attack)

The Android Accessibility Service is a powerful framework designed to help users with disabilities, screen readers like TalkBack use it to read text aloud, magnifiers use it to render content larger, switch-access tools use it to drive the phone with a single button. By design, an Accessibility Service can:

• Read text on the screen of any app, including banking apps
• Read text in notifications, including OTP banners
• Tap, scroll, and type on behalf of the user
• Capture screen content

That set of capabilities is exactly what an OTP-stealer needs. A malicious app that gets Accessibility Service access, usually by asking for it under a plausible pretext like “allow this app to overlay your screen for protection”, can:

• Read the OTP from the notification when it arrives
• Read the bank account balance directly from the bank app screen
• Read login credentials as the user types them
• Sometimes drive the bank app itself to initiate a transfer

This is the attack used by SOVA, Drinik, and most of the active Indian Android banking trojans of recent years. CERT-In has issued multiple advisories specifically about Accessibility Service abuse.

Why loan apps are the dominant delivery channel

Of all the apps an Indian user might install, why are illegitimate “instant loan” apps disproportionately the ones that steal OTPs? Three reasons:

1. Plausible permission requests. A loan app legitimately needs your contacts, SMS, and call logs to assess creditworthiness in the credit-thin Indian market. Asking for those permissions does not, on its face, look suspicious. The user expects to grant them.
2. Distribution outside Play Store. Many illegal loan apps are not on Google Play (or get removed quickly). They distribute via SMS links, Facebook ads, and WhatsApp forwards, ending in an APK download. Sideloading is normal in this market segment.
3. Financial-stress pressure. The user is under pressure (often the reason they are looking for an instant loan). They are less likely to read the permission prompts carefully or check the developer.

RBI and CERT-In have published lists of known illegitimate loan-app operators, and Google has periodically swept Play Store. The problem persists because new operators set up faster than the takedowns. The defence cannot be “trust the platform” alone, the user has to apply judgment.

The permission audit

Here are the Android permissions a typical Indian user might encounter and how to think about each:

The four high-risk permissions are the ones that enable the OTP-stealer attack chain. Of these, BIND_ACCESSIBILITY_SERVICE is the most powerful and the one to watch most carefully, it is granted via Settings → Accessibility, not the regular permission dialog, and many users grant it without understanding what they are authorising.

The four defences (in order of effectiveness)

What to do if you suspect infection

If a phone has been used to make unexpected transactions, or if your Accessibility audit revealed a service you don’t recognise, the safest path is:

1. Switch the phone to aeroplane mode (cuts the malware’s C2 connection)
2. From a different device, change net-banking and UPI passwords; freeze the affected accounts via the bank’s 24-hour helpline
3. Call 1930 for any unauthorised transactions; the helpline can often freeze receiving accounts
4. Back up only your photos/contacts (don’t back up apps)
5. Factory reset the phone, full wipe is the only reliable cleanup for Accessibility-Service malware
6. Reinstall apps freshly from Play Store, not from cloud-backup
7. File a complaint at cybercrime.gov.in

The respectful note

Android’s Accessibility Service exists for a profoundly important reason, it makes phones usable by people with visual, motor, and cognitive impairments. The attack vector exists because the service is powerful enough to do real good. Google has made the abuse path harder over each Android version (Android 13 added a special prompt; Android 14 restricted some side-loaded paths further), and Play Protect specifically scans for known accessibility-abuse patterns. The defence is not to disable accessibility, that would harm the people who need it most, but to be deliberate about which apps you grant the access to.

Once you understand that an OTP can be silently read by any app you’ve granted Accessibility to, the rule becomes simple: grant Accessibility only to apps you specifically need it for, audit grants regularly, and treat any unsolicited request as suspicious by default. With that one habit, the OTP-stealer attack vector becomes very hard to land.