Mobile T1453 Abuse Accessibility Features: Detecting Data Collection on Android

Abuse Accessibility Features (T1453) is Android malware persuading the user to switch on an accessibility service, then using the power that feature gives to people with disabilities to read the screen, capture what is typed and tap through the device on the user's behalf. MITRE ATT&CK for Mobile v20 lists T1453 under Collection and Credential Access, for Android only. It is the engine behind most modern Android banking trojans and a growing number of spyware families. This guide is for mobile security, MDM and fraud teams: what the technique is, why ATT&CK does not list iOS, which platform controls and policies apply, ATT&CK's v20 detection analytic and how to respond. It goes deeper than the MITRE ATT&CK for Mobile Guide.

Key takeaways

• Android only, by ATT&CK's definition. T1453 lists Android as its only platform and every procedure example is Android malware.
• One user approval unlocks everything. Once a malicious accessibility service is enabled, ATT&CK records families granting themselves more permissions, preventing uninstall, stealing credentials and one-time passcodes.
• Authenticator codes are in scope. ATT&CK records GodFather exfiltrating Google Authenticator one-time passwords, and ThreatFabric reports Crocodilus reading the Google Authenticator screen on command.
• Android has added friction. Restricted settings on Android 13 and later lock accessibility for some installed apps until the user explicitly allows it, and Google Play restricts use of the AccessibilityService API. Malware droppers try to get around both.
• Enterprises can allowlist accessibility services. On managed Android devices, restrict accessibility services to an approved list and alert when an unapproved service is enabled.

What T1453 covers and how it relates to other techniques

ATT&CK describes adversaries abusing accessibility features in Android to steal sensitive data and to spread malware to other devices. It gives two examples from FluBot research: overlaying an HTML object that mimics a login screen so the user types credentials into it, and a malicious accessibility service acting as a keylogger by watching changes to text input fields. ATT&CK notes that keylogging this way is also described in Keylogging (T1417.001), while T1453 captures the overall abuse of accessibility features. GUI Input Capture (T1417.002) and Input Injection (T1516) are separate techniques that accessibility abuse often enables.

Android and iOS: why the platforms differ

ATT&CK lists T1453 for Android only and records no iOS procedure examples. On Android, an app can provide an accessibility service that receives events from other apps once the user enables it in Settings, under Accessibility. That design is what malware abuses. iOS is not listed for this technique, so this page does not describe an iOS equivalent. iOS collection of screen content and input is covered under other ATT&CK techniques, such as Input Capture (T1417), and in practice relies on elevated privileges rather than a user-granted accessibility service.

Restricted settings and Play policy raise the bar but do not close the route. ThreatFabric reported in March 2025 that Crocodilus is installed through a dropper that bypasses Android 13 and later restrictions, so treat the platform controls as one layer. See the Android Banking Trojans Guide for the wider family landscape.

Real cases recorded by ATT&CK

• FluBot (S1067): abuses accessibility in three ways: stealing app credentials, evading detection and removal, and sending SMS to spread.
• Crocodilus (S9004): requests Accessibility Service, then connects to C2 for instructions and monitors accessibility events. ThreatFabric's report, published on 28 March 2025, describes early campaigns against banks in Spain and Turkey and cryptocurrency wallets, an accessibility logger that records on-screen text, and a black overlay used to hide remote control.
• Chameleon (S1083): switches biometric authentication to PIN, grants itself permissions and prevents uninstall after accessibility is granted.
• GodFather (S1231): prevents uninstall, exfiltrates Google Authenticator one-time passwords and steals credentials.
• VajraSpy (S9006) and DocSwap (S9005): spyware use, from intercepting messaging apps to keylogging.

The common thread is a social engineering step that gets the user to enable the service, often with an app disguised as something familiar. ThreatFabric's Crocodilus sample was disguised as a browser.

Detection: ATT&CK v20 analytic

ATT&CK v20 attaches DET0697 Detection of Abuse Accessibility Features to T1453, with a single Android analytic. It correlates three sources:

• Dynamic analysis: an accessibility service receiving events from more than a threshold number of distinct apps, including apps on a target list such as banking, wallet, messaging and authenticator apps. ATT&CK notes that broad monitoring across apps distinguishes malware from single-purpose assistive tools.
• Permission state: permission grant state from the device policy controller and the app's requested permissions, reviewed in app vetting.
• Network traffic: gateway or proxy inspection where it is deployed, to tie the app to C2 or exfiltration.

Operationally, the strongest signals for most enterprises are an MDM or MTD report that an unapproved accessibility service is enabled, an app installed from outside the managed store, and an app that requested accessibility shortly after install. For banks and other app owners, in-app risk signals that an accessibility service is active while a sensitive screen is shown are worth feeding to fraud scoring. See the Mobile Banking App Security Guide.

Prevention

Where identity fits

Accessibility malware is a credential and token theft tool. It reads passwords as they are typed, one-time codes from SMS and authenticator apps, and wallet seed phrases. For workforce identity, that argues for phishing-resistant methods and short session lifetimes on mobile. For app owners, keep tokens and API keys out of anything shown on screen, and bind sessions to the device with attestation so stolen values are less useful elsewhere. See the Mobile App Attestation and Phishing-Resistant MFA Guide.

How to implement

1. Inventory: report which accessibility services are enabled across managed Android devices and which apps provide them.
2. Agree the allowlist: with your accessibility lead, list the assistive apps staff need so the policy does not block people who rely on them.
3. Audit mode: alert on unapproved services for two to four weeks without blocking, and contact users of each finding.
4. Enforce in rings: apply the allowlist and app source restrictions to a pilot ring, then widen. Roll back for an individual through a documented exception rather than lifting the policy.
5. Connect response: route alerts to a playbook that isolates the device and revokes the user's sessions.

Decision guidance

• Fully managed devices: enforce the allowlist and block unknown sources.
• Work profile BYOD: the enterprise cannot see personal apps, so rely on MTD, conditional access and phishing-resistant MFA.
• App owners: decide whether to warn, step up or block sensitive actions when an unrecognised accessibility service is active, balancing fraud loss against users who depend on assistive tools.

Responding to suspected accessibility abuse

• Isolate: remove the device from corporate access through conditional access.
• Revoke: end sessions, reset passwords from a clean device and re-register MFA, since codes and credentials may have been read.
• Preserve: capture the app package name, MDM inventory and network logs before removal.
• Remove: if the app blocks uninstall, use MDM removal or a factory reset after evidence is collected.
• Notify: for banking or wallet exposure, tell the relevant institutions.

Detection and measurement

• Unapproved services: managed devices with an unapproved accessibility service enabled (target zero).
• Sideload exposure: devices with apps from unknown sources.
• Code-based MFA on mobile: percentage of users relying on SMS or authenticator codes.
• Time to isolate: from alert to conditional access block.
• Allowlist exceptions: number and age of open exceptions.

Framework mapping

Common failure patterns

• Allowing sideloading on corporate devices: the delivery route for most families in ATT&CK's list.
• Blocking all accessibility services: staff who rely on assistive tools lose access and the policy gets lifted.
• Trusting authenticator codes on the same phone: a service that reads the screen reads the code.
• Treating Play distribution as proof of safety: ATT&CK's own user guidance warns otherwise.
• Remediating without rotating credentials: removing the app leaves stolen passwords and sessions valid.

Practitioner checklist

• Report enabled accessibility services across managed Android devices.
• Agree an allowlist of assistive apps with your accessibility lead.
• Restrict corporate devices to managed or official app stores.
• Alert on unapproved accessibility services and on apps that request it soon after install.
• Move mobile users from code-based MFA to phishing-resistant methods.
• Teach users what an accessibility request looks like and where to check it.
• Rotate credentials and sessions as part of every removal.

Standards and references

• MITRE ATT&CK: Abuse Accessibility Features (T1453)
• Google Play Console Help: Use of the AccessibilityService API
• Google Android Help: Allow restricted settings
• ThreatFabric: Exposing Crocodilus
• MITRE ATT&CK: Keylogging (T1417.001)
• OWASP: Mobile Application Security Verification Standard

Related NHI Mgmt Group resources: MITRE ATT&CK for Mobile Guide · Android Banking Trojans Guide · Android Enterprise Security Guide · Mobile Malware Guide