Mobile T1516 Input Injection: Stopping Accessibility Abuse on Android

When malware can tap, swipe and type on the user's behalf, it can approve its own permissions, close security apps and complete payments while the user watches or sleeps. MITRE ATT&CK for Mobile tracks this as T1516 Input Injection, under both Defense Evasion and Impact. ATT&CK v20 lists it for Android only, and every route it describes runs through Android's accessibility APIs. This guide covers how the technique works, what it has been used for, and the policy, app and detection controls that limit it. It is for mobile security engineers, MDM administrators, fraud teams and detection engineers. For the wider matrix, see the MITRE ATT&CK for Mobile Guide.

Key takeaways

• One permission, many outcomes. An enabled accessibility service lets malware click, run global actions such as Back, and insert text into other apps, which turns a single user grant into full device control.
• It defends the malware. ATT&CK procedure examples show injected input used to grant more permissions, set the malware as default SMS handler, block uninstall and close antivirus apps.
• It defeats user-presence checks. SharkBot and similar families use injected input to bypass MFA prompts and drive fraudulent transfers inside genuine banking apps.
• The allow list is the control. On managed Android, an explicit permittedAccessibilityServices list is the mitigation ATT&CK names; on personal devices, restricted settings and user guidance carry the load.
• iOS is not listed. ATT&CK v20 does not list T1516 for iOS, so this page is Android only.

How input injection works

ATT&CK describes three methods, all through Android accessibility APIs:

The same API serving genuine assistive tools is why the technique is hard to block outright. Google Play restricts the isAccessibilityTool declaration to apps whose purpose is helping people with disabilities, requires a prominent in-app disclosure and affirmative consent for other uses, requires a Play Console declaration for apps targeting API level 31 or higher, and prohibits using the Accessibility API to autonomously initiate, plan and execute actions. Those rules apply only to Play-distributed apps, so sideloaded apps escape them, which is why device policy matters more.

T1516 is closely tied to Mobile T1513 Screen Capture: the same service that reads the screen also acts on it.

Real cases from ATT&CK procedure examples

ATT&CK v20 maps 14 malware families to T1516. Grouped by purpose, as ATT&CK and its cited reports describe them:

The defence evasion half matters for responders: once the malware can close settings screens and block uninstall, users often cannot remove it themselves, and the device needs managed quarantine or reset. For the family background, see the Android Banking Trojans Guide.

Prevention

ATT&CK lists two mitigations for T1516: M1012 Enterprise Policy and M1011 User Guidance.

Managed devices

• Accessibility allow list: set permittedAccessibilityServices in the Android Management API (the DPC method is DevicePolicyManager.setPermittedAccessibilityServices). If the field is not set, any accessibility service can be used. Include only the assistive tools your users need, and keep a fast exception process so users who rely on them are not blocked.
• App sources: use advancedSecurityOverrides.untrustedAppsPolicy to block installs from unknown sources and googlePlayProtectVerifyApps to keep Play Protect verification enforced.
• Compliance gating: mark devices with an unapproved accessibility service as non-compliant so conditional access blocks corporate apps until it is removed. See the Android Enterprise Security Guide.

Personal and BYOD devices

• Restricted settings: on Android 13 and later, a sideloaded app cannot be granted accessibility until the user opens the app's info page, taps More and chooses "Allow restricted settings". Teach users that being asked to do this by anything that is not an assistive tool is a sign of malware.
• High-risk users: consider Android Advanced Protection, which tightens sideloading and related settings.

Your own apps

• Do not trust the tap: a click inside your app may not come from a human. Bind high-value actions to a separate confirmation that injected input cannot complete alone, such as a server-side risk check plus a passkey or device-bound signature.
• Overlay resistance: declare HIDE_OVERLAY_WINDOWS (Android 12 and later) on sensitive screens so overlays cannot be drawn over them, as Android's fraud prevention guidance recommends.
• Signals, not blocks: fraud teams can use the presence of enabled non-assistive accessibility services as one risk signal for step-up, rather than blocking all users of assistive technology. See the Mobile Banking App Security Guide.

Detection and measurement

ATT&CK's detection strategy for T1516 (Detection of Input Injection) correlates two sources and warns against inferring API calls from management state alone:

• Application state: managed package inventory and metadata from Android Enterprise or the EMM, to spot new packages with an enabled accessibility service.
• Runtime traces from app vetting: an accessibility-enabled app that is not on the allow list calling performAction() clicks, global actions such as Back, Home or Recents, or insertText() on a UI element owned by a different foreground app. Cross-app UI action is the core signal.

Server-side, fraud telemetry often shows the effects: sessions with no human timing variation, settings changes immediately after install, or default SMS handler changes. Metrics to track:

1. Percentage of managed Android devices with an enforced accessibility allow list.
2. Number of devices with an enabled accessibility service not on the allow list (target zero on managed devices).
3. Count of devices where the default SMS app changed to a non-approved package.
4. Share of vetted apps that request accessibility, and the share of those approved.
5. Time from MTD or EMM alert to quarantine.

Response

1. Quarantine through management: because injected input can block uninstall and close settings, do not rely on the user to remove the app. Mark the device non-compliant, revoke sessions and tokens, and wipe the work profile or device.
2. Preserve evidence: record the app inventory, accessibility grants, device admin apps and default SMS app before wiping.
3. Check accounts: review banking, email and identity provider activity during the exposure window for actions the user did not make, including new trusted devices and changed recovery settings.
4. Recover: reset, re-enrol and confirm the allow list policy before returning the device. Use the Mobile Spyware Infection Response Playbook for targeted cases.

Framework mapping

Common failure patterns

• No allow list: leaving permittedAccessibilityServices unset lets any app the user approves act on every other app.
• Blanket bans that break accessibility: blocking all services pushes disabled users to unmanaged devices; allow-list the tools they need instead.
• Relying on the user to uninstall: families such as Cerberus and Mandrake inject input to prevent removal.
• Treating a tap as consent: apps that approve payments or recovery changes on a single in-app confirmation can be completed by injected input.
• Sideloading left open: sideloaded apps never pass Play's accessibility declaration and disclosure review, so allowing unknown sources removes that layer.

Practitioner checklist

• Enforce an explicit accessibility allow list on all managed Android devices and work profiles.
• Block unknown app sources and enforce Play Protect verification.
• Make an unapproved accessibility service a compliance failure tied to conditional access.
• Add cross-app performAction and insertText behaviour to app vetting criteria.
• Require out-of-band or device-bound confirmation for high-value actions in your own apps.
• Declare HIDE_OVERLAY_WINDOWS on sensitive screens.
• Teach users what "Allow restricted settings" means and when to refuse.
• Quarantine and wipe through management rather than asking users to remove the app.

Standards and references

• MITRE ATT&CK: Input Injection (Mobile T1516)
• Google: Android Management API policies reference
• Google Play: Use of the AccessibilityService API
• Google: Allow restricted settings
• Android Developers: Secure sensitive activities
• OWASP: Mobile Application Security Verification Standard

Related NHI Mgmt Group resources: MITRE ATT&CK for Mobile Guide · Android Banking Trojans Guide · Mobile App Permissions · Mobile Threat Defense Buyer's Guide