Android Banking Trojans Guide: Overlays, Accessibility Abuse and Bank-Side Defences

Android banking trojans defeat app passwords and SMS codes by running on the customer's own phone: they draw fake login screens over real banking apps, read one-time codes, and use Android's accessibility service to tap through transfers themselves. Because the fraud happens on a genuine, already-authenticated device, many server-side checks see a legitimate session. MITRE ATT&CK for Mobile v20 documents more than 20 Android families described as banking malware, from Cerberus and FluBot to SharkBot, GodFather and Crocodilus. This guide explains how these trojans work at a defender's level of detail, where they appear, the fraud they cause, how banks and enterprises detect them, and the platform and app controls that reduce the risk. It is for mobile app security, fraud and security operations teams at banks, fintechs and wallet providers, and for enterprise mobile teams. The broader landscape is covered in the Mobile Malware Guide; this page goes deeper on banking trojans and bank-side defences.

Key takeaways

• Accessibility abuse is the core capability. SharkBot, Chameleon, GodFather and others use accessibility services to read the screen, capture input and act for the user, which is ATT&CK technique T1453.
• SMS interception is the most common behaviour. Across banking families in ATT&CK v20, collection of SMS messages (T1636.004) is the most frequently recorded technique, so SMS one-time codes are weak on infected devices.
• Delivery is mostly outside the store. Smishing links, fake updates and lookalike apps (T1660 Phishing, T1476) lead users to sideload, then talk them through granting permissions.
• The platform has added friction. Restricted settings since Android 13, wider restrictions for internet-sideloaded apps in Android 15, and Play Protect live threat detection all target this abuse path.
• Banks must assume a hostile device. Play Integrity's app access risk verdict, behavioural fraud signals and out-of-band confirmation for high-risk payments matter more than any single login control.

How the attack works

The typical chain has five stages. Each maps to ATT&CK for Mobile techniques that defenders can monitor or design against.

• On-device fraud: ATT&CK describes SharkBot, first found in October 2021, as trying to start money transfers directly from compromised devices by abusing accessibility services. This defeats device binding because the device really is the customer's.
• Virtualisation: ATT&CK describes GodFather as using virtualisation to mimic legitimate applications while abusing accessibility, targeting nearly 500 banking, cryptocurrency wallet and exchange apps.
• Card relay: NGate, first seen in November 2023 against Czech and Polish banks, relays a victim's payment card data over NFC to the attacker's device for ATM withdrawals, per ATT&CK.
• Malware as a service: ATT&CK notes Cerberus could be rented on underground forums, the same economy described in the Phishing-as-a-Service Platforms Guide.

Where it shows up

Regional families also matter: Latin American banking malware has its own lineage, covered in the Latin American Banking Trojans Guide. For how ATT&CK structures mobile techniques, see the MITRE ATT&CK for Mobile Guide.

Impact

• Direct financial loss: unauthorised transfers, card relay withdrawals and drained crypto wallets, often fast enough that funds leave mule accounts before the customer notices.
• Weakened authentication: SMS codes, app passwords and even in-app confirmations can be captured or operated by the trojan, so step-up based on these factors alone gives false assurance.
• Customer harm and complaints: victims lose access to messages and calls from the bank while the trojan hides notifications.
• Enterprise exposure: on a work phone, the same accessibility abuse can read corporate email, chat and authenticator prompts. See the Android Enterprise Security Guide.

Detection

Responding to a suspected infection

1. Freeze first: when fraud signals and device risk coincide, block outgoing payments and new payees on the account, and contact the customer on a channel other than the infected phone, such as a call to a verified landline or a branch visit.
2. Recall funds: raise recall requests with receiving banks immediately and flag mule accounts; speed decides how much is recovered.
3. Clean the device: guide the customer to remove device administrator rights and accessibility access from the unknown app, uninstall it, and, if removal is blocked, back up personal data and factory reset. Advise against restoring apps from an old backup that may contain the trojan.
4. Re-establish trust: reset online banking credentials from a clean device, re-enrol the app, and re-bind it to the customer with identity verification that does not rely on SMS sent to the same phone.
5. Feed intelligence back: record the lure, app name and package details, share them with your threat intelligence provider and the national reporting service, and update detection rules.

For company-owned phones, follow the Mobile Spyware Infection Response Playbook and preserve the device for forensics before wiping it.

Metrics

• Risky-device sessions: share of banking sessions where app access risk or Play Protect verdicts show risk.
• Fraud on hostile devices: value and count of confirmed fraud cases where malware was present, tracked monthly.
• SMS dependency: percentage of customers still using SMS one-time codes for payment approval.
• Interception rate: percentage of fraudulent payment attempts stopped before funds left the bank.

Prevention and hardening

Platform controls

• Restricted settings: Google says Android 13 and later can lock settings such as accessibility for an installed app until the user explicitly allows restricted settings in the app's info menu. Google's May 2024 security post says Android 15 extends this extra approval to apps sideloaded from browsers, messaging apps and file managers.
• OTP and screen-sharing protections: the same post says Android 15 hides one-time passwords from most notifications and hides notification content and credential entry during screen sharing.
• Play Protect live threat detection: on-device analysis of apps that use sensitive permissions, with Google able to disable confirmed malicious apps.

Banking app controls

1. Integrate Play Integrity in measure mode first: log device integrity, app access risk and Play Protect verdicts for several weeks without enforcement to understand your install base, as Google recommends.
2. Use tiered enforcement: allow, allow with limits, challenge or deny based on verdicts, and do not cache verdicts. Bind each request to the action with a request hash or nonce.
3. Protect sensitive screens: follow MASVS-PLATFORM guidance on secure display of sensitive data, for example ignoring touches when a view is obscured by another window (Android's filterTouchesWhenObscured attribute) and blocking screenshots on credential and payment screens.
4. Move approval off SMS: use in-app cryptographic approval tied to a hardware-backed key, and for the highest-risk payments a second channel the trojan cannot see. See the Authenticator Apps and OTP Guide.
5. Add payment friction where risk is high: payee cooling-off periods, lower limits on risky devices and confirmation of payee.
6. Harden the app: apply MASVS-RESILIENCE measures against tampering and repackaging so lookalike apps are easier to detect.
7. Roll back safely: ship enforcement behind server-side flags so a false-positive spike can be reversed without an app release.

Enterprise and customer measures

• Managed devices: block installs from unknown sources through the work profile, and use mobile threat defence to flag accessibility abuse. See the Mobile Threat Defense Buyer's Guide.
• Customer messaging: tell customers the bank will never ask them to install an app from a link or enable accessibility for it.

Decision guidance

• Small fintechs: start with Play Integrity verdicts, transaction limits and out-of-band confirmation for new payees; buy behavioural analytics later.
• Large banks: combine integrity verdicts, behavioural biometrics, mule account detection and threat intelligence on active families targeting your app list.

Framework mapping

Lessons from incidents

No breach page on this site covers a mobile banking trojan campaign, but adjacent cases carry the same lessons. The 0ktapus campaign showed how quickly relayed SMS codes are used; see the Twilio Breach 2022 page. FluBot's disruption by law enforcement in 2022 reduced one family, but others such as SharkBot, GodFather and Crocodilus continued, so defences must target the techniques rather than a family name.

Practitioner checklist

• Map active Android banking families to your app list using threat intelligence and ATT&CK for Mobile.
• Integrate Play Integrity, including the app access risk and Play Protect verdicts, in measure mode, then enforce in tiers.
• Protect login and payment screens against overlays, obscured touches and screenshots.
• Replace SMS one-time codes for payment approval with in-app, hardware-backed approval.
• Apply payee cooling-off periods and limits when device risk is present.
• Feed behavioural biometrics and device risk into the fraud engine.
• Block unknown-source installs and monitor accessibility grants on managed devices.
• Tell customers clearly that the bank never asks them to sideload apps or enable accessibility.

Standards and references

• MITRE ATT&CK: Abuse Accessibility Features (T1453)
• MITRE ATT&CK: GUI Input Capture (T1417.002)
• MITRE ATT&CK: SharkBot (S1055)
• OWASP: Mobile Application Security Verification Standard
• Android Developers: Play Integrity API Overview
• Google: Allow Restricted Settings on Android
• Google Online Security Blog: What's New in Android Security (I/O 2024)

Related NHI Mgmt Group resources: Mobile Malware Guide · Online Banking Security Guide · Android App Security Guide · Latin American Banking Trojans Guide