Indian Android Banking Trojans 2026 — SoumniBot, Brokewell, Gigabud and the Accessibility-Service Endgame

Last updated: May 18, 2026

Indian banking customers lost ₹1,750 crore to UPI fraud in FY2024 (RBI data). The dominant attack vector is no longer skimming or phishing — it’s Android banking trojans that gain Accessibility Service access, intercept OTPs, and drive UPI transfers from inside the victim’s authenticated session. The technical pattern is converged across at least four malware families, all targeting Indian users specifically.

The four families to know — TTP comparison

SoumniBot (first sighted Apr 2024, Kaspersky) — Korean origin, retargeted to India. Distinguishing technique: corrupts the AndroidManifest.xml in a way that Android still parses but most static analyzers do not. Result: the malicious capabilities are invisible to manifest-only scans.

Brokewell (Apr 2024, ThreatFabric) — full device takeover. Beyond banking-app overlay, Brokewell streams the screen in real time to the operator, who manually drives the device. Used heavily for “MFA-bypass-via-pretending-to-be-the-user” attacks against Indian fintech.

Gigabud RAT (active 2023-2026) — disguises as Income Tax Refund / GST refund apps. Heavy use of Telegram for C2. Distinguished by zero-click capability when paired with a malicious WhatsApp document the user only previews.

GoldDigger (Group-IB, late 2023, sustained 2024-2026) — Vietnamese-origin family with India variants. Notable: uses Apple TestFlight + Mobile Device Management (MDM) profiles to compromise iPhones, not just Android.

The infection chain — how an Indian victim gets owned

1. Lure — SMS or WhatsApp from “+91” sender impersonating IT department, electricity bill, courier delivery, or KYC update. Contains a shortened URL to income-tax-refund.in.xyz/apk or similar.
2. Side-load — Victim taps link, Android browser shows “Allow installation from this source?” prompt. Most users tap allow — Indian Android users have years of legitimate side-loading habit (older Jio Pay, government apps).
3. Permission grants — App requests Accessibility Service (“for visually-impaired support”). User taps allow. App now reads every screen, simulates every tap.
4. Banking app overlay — User opens HDFC / SBI / PhonePe app. Trojan detects via Accessibility, draws a transparent overlay capturing entered credentials.
5. SMS interception — Trojan reads incoming OTP SMS via SMS_READ permission (or Accessibility on Android 13+ which deprecated SMS read).
6. Fraudulent transaction — With credentials + OTP, attacker (or automated script) initiates UPI / NEFT transfer. User sees nothing because trojan auto-dismisses confirmation dialogs.

Total time from install to first ₹1L transfer: under 2 minutes in observed cases.

Why Indian banking apps remain easy targets

The Reserve Bank’s Digital Payments Security Controls guidelines (Feb 2021, updated 2023) require banking apps to detect rooting, screen capture, accessibility-service abuse, and overlay attacks. In practice:

• RASP coverage is uneven. Tier-1 private banks (HDFC, ICICI, Axis) ship Promon SHIELD or AppSealing. Tier-2 banks (cooperatives, regional banks) often have no runtime protection at all.
• Accessibility-service detection is reactive. Most apps detect AccessibilityManager.isEnabled() at launch and warn the user, but allow continued use. Trojans simply wait until the user dismisses the warning.
• FLAG_SECURE for screen recording is set inconsistently. Login screens have it; transaction-confirmation screens often don’t. Trojan-driven screen capture exfils the OTP-confirmation screen.
• UPI app permissions are too permissive. A user only needs UPI-Lite for <₹500 transactions; the full UPI-PIN flow is what enables ₹2L+ trojan transfers.

Static-analysis evasion — the SoumniBot trick

SoumniBot’s APK has an AndroidManifest.xml that uses a malformed manifest_size field in the binary XML (AXML format). Android’s parser is lenient and reads past the malformed length; many Java-based static analyzers (apktool versions before 2.10, MobSF before recent updates) crash or skip the manifest. Effect: the malware’s declared BIND_ACCESSIBILITY_SERVICE capability never appears in static scans.

Detection: open the APK with aapt dump badging app.apk; if it errors but Android installs the app fine, treat as suspicious. Yara rule for the binary-XML malformation pattern is in the Kaspersky Securelist write-up.

Defensive playbook — banks

1. Mandatory app integrity at runtime — every banking app should verify Play Integrity API token on every transaction request, not just login. AppAttestation token must be replay-protected and bound to the transaction nonce.
2. Detect Accessibility Service abuse aggressively — if any non-system, non-allow-listed app has Accessibility enabled, refuse to render the transaction screen. Yes, this is friction; it is the right friction.
3. FLAG_SECURE on every screen showing PII — login, account balance, transaction history, OTP entry, UPI-PIN entry. No exceptions.
4. Behavioral biometrics for high-value transactions — typing cadence, touch pressure, accelerometer signature. Trojans driving the device fail behavioural biometrics; legitimate users pass.
5. Out-of-band confirmation for transactions over ₹50,000 — banking SMS is bypassable; an in-app push notification to a separately-rooted MDM-managed phone is not.

Defensive playbook — users (the awareness section)

1. Never side-load APKs. Use Play Store and bank’s official iOS App Store listing only. Disable “Install unknown apps” permission for every browser, messenger.
2. Treat any “click to install for your refund” SMS as fraud. Government and banks never distribute APKs by SMS.
3. Audit the Accessibility menu (Settings → Accessibility → Installed apps). Every app there should have a clear reason for the permission. If you don’t recognise an app, uninstall it immediately and run a Google Play Protect scan.
4. Enable Google Play Protect in real-time mode (Settings → Security → Google Play Protect → Improve harmful app detection: ON).
5. Set a daily UPI transaction limit on your apps. ₹10,000-25,000 daily is enough for normal use; trojans cannot drain accounts beyond it in one shot.

FAQ

Are Indian iPhone users safe from this class of attack?

Lower risk but not zero. GoldDigger’s iOS variant uses TestFlight beta-app distribution and MDM profile installation to bypass App Store review. Same lure (SMS link → “install our beta app”) then MDM profile gives the attacker app-installation rights. Don’t accept TestFlight invites or MDM profiles from sources you don’t fully trust.

Can a banking trojan work on a fully patched Android 14 device?

Yes. The attack does not exploit any Android vulnerability. It relies on user-granted permissions (Accessibility Service, SMS Read on older versions). Android 13+ deprecated SMS Read for non-default-SMS-app, which dented some older trojans, but Accessibility-Service-based OTP capture works regardless.

Should we ban side-loading entirely on corporate devices?

For BYOD employees with banking app access — yes. Use Android Enterprise Work Profile or full MDM mode that disables install-unknown-sources. The productivity cost is minimal; the fraud-prevention benefit is large.

How does Promon SHIELD / AppSealing actually defend?

RASP libraries hook into the app at runtime and monitor for: debugger attach, hooking framework presence (Frida, Xposed), code injection, screen-capture attempts, and Accessibility-Service abuse against the app’s own UI. Properly configured, they refuse to render sensitive screens or kill the app process when threats are detected. The catch: they need ongoing tuning and usually a vendor support contract to stay effective.

Are these trojans on the Play Store too?

Periodically yes — droppers slip past Play Protect, fetch the malicious payload after install (so the Play Store version is clean). Recent examples include Bahamut-droppered apps in the “phone cleaner” category. Play Store presence is no guarantee of safety; review the developer history and permissions.

⚖️ Legal: Defensive content. Reverse-engineering banking trojans for research is generally lawful in India under fair-use research exceptions, but distribution of working samples is not — IT Act §66 (unauthorised access) and §66F (cyberterrorism). For RE work, use sandboxed AVD or hardware test devices, never your personal phone, and document the research purpose.

Related engagement → How we ran a mobile + API security review for a BFSI client