Mobile T1417 Input Capture: Stopping Keyloggers and Overlay Phishing on Android and iOS

Mobile banking trojans and spyware rarely break app encryption: they read what the user types, or draw a fake login screen on top of the real app and let the user type straight into it. MITRE ATT&CK for Mobile T1417 Input Capture covers both, through two sub-techniques: T1417.001 Keylogging and T1417.002 GUI Input Capture. ATT&CK lists both platforms, Android and iOS, under Collection (TA0035) and Credential Access (TA0031), though nearly all procedure examples are Android malware abusing accessibility services and overlay windows. This guide explains how each sub-technique works at the level a defender needs, the platform controls that block it, and how to detect and respond. It is for mobile security, fraud and MDM teams and app developers. For Enterprise keylogging, see MITRE ATT&CK T1056 Input Capture.

Key takeaways

• Accessibility is the main abuse path on Android. ATT&CK describes keylogging through an AccessibilityService that listens for TYPE_VIEW_TEXT_CHANGED events, and overlay timing that uses accessibility to know which app is in front.
• Allow-lists beat user judgement. ATT&CK mitigation M1012 Enterprise Policy names DevicePolicyManager.setPermittedAccessibilityServices and keyboard allow-listing as controls an MDM can enforce.
• Newer Android versions close specific gaps. Android 10 restricts background activity starts, Android 12 blocks touches through untrusted overlays and adds setHideOverlayWindows(), and Android 14 adds accessibilityDataSensitive.
• iOS exposure is narrower. Third-party keyboards need explicit user enablement and run sandboxed unless the user grants Full Access; GUI capture on iOS appears in ATT&CK mainly as fake prompts inside trojanised apps.
• Phishing-resistant authentication limits the damage. A captured password or PIN is far less useful when the account uses passkeys or device-bound credentials.

How T1417 works on each platform

ATT&CK notes that the small mobile screen gives users little context to judge whether a prompt is genuine. The defensive aim is therefore to stop the capability being granted, not to rely on users spotting a fake.

T1417.001 Keylogging

ATT&CK lists more than twenty software entries for keylogging, almost all Android banking trojans and spyware: Anubis, Cerberus, BRATA, Chameleon, SharkBot, Gustuff, EventBot (which recorded the screen PIN through accessibility), Crocodilus and GodFather among them. Windshift (G0112) included keylogging in its mobile operations, and VajraSpy and DocSwap are recent additions. BusyGasper took a different route, recording screen taps and mapping coordinates to characters.

On iOS a custom keyboard is an app extension that users enable in Settings, General, Keyboard, Keyboards. Apple's documentation states that a keyboard must set RequestsOpenAccess to gain network access or write to a shared container, which surfaces to the user as Allow Full Access. A keyboard with Full Access is the iOS asset to review.

• Android control: allow-list accessibility services with setPermittedAccessibilityServices and input methods with setPermittedInputMethods on managed devices; ATT&CK also notes that Samsung Knox requires third-party keyboards to be allow-listed.
• Android user control: Android's restricted settings keep sensitive settings such as accessibility locked for an app until the user explicitly allows restricted settings for it; Google advises against doing so unless the developer is trusted.
• Developer control: on Android 14 and later, mark sensitive views with accessibilityDataSensitive so only services declared as accessibility tools can read them; setting filterTouchesWhenObscured enables it implicitly.
• iOS control: review third-party keyboards with Full Access in your managed app inventory and tell users to report keyboards they did not install themselves.

T1417.002 GUI Input Capture

Overlay attacks are the defining Android banking trojan behaviour. ATT&CK records Anubis, Cerberus, Ginp, FluBot, SharkBot, S.O.V.A., Gustuff (which also asked for the device unlock code), BRATA, Chameleon, Exobot and Escobar using overlays or fake WebView login pages against banking and crypto apps, and NGate showing a fake website to collect banking details. Mandrake manipulated visual components to trick users into granting dangerous permissions. On iOS, XcodeGhost could show a fake alert to phish credentials, and ATT&CK records Phenakite (under the parent technique T1417) using phishing sites for iCloud and Facebook.

For the trojan families that rely on this technique, see the Android Banking Trojans Guide.

Where identity fits

Input capture is a credential theft technique: the targets are passwords, PINs, card numbers, crypto wallet secrets and one-time codes. Two identity controls reduce its value. Passkeys and platform authenticators do not involve typing a reusable secret, so there is nothing for a keylogger or overlay to take. Device-bound sessions and risk-based checks on the server side catch a stolen credential used from a new device. Treat any device with confirmed input capture as having exposed every credential typed on it since infection and reset them, including service account and admin credentials an engineer may have entered.

Implementation steps

1. Inventory risky grants. Report managed Android apps holding accessibility, overlay or input method roles, and iOS keyboards with Full Access, from MDM and MTD data.
2. Build allow-lists. Agree the accessibility services and keyboards the business genuinely needs, including assistive technology users require; never block those without an alternative.
3. Pilot enforcement. Apply setPermittedAccessibilityServices and setPermittedInputMethods to a pilot ring for two weeks and record breakage, then widen.
4. Raise the OS floor. Block corporate access below Android 12 where you can, since untrusted touch blocking and overlay hiding start there; plan the exceptions.
5. Harden your own apps. Add setHideOverlayWindows, filterTouchesWhenObscured and accessibilityDataSensitive to login, payment and approval screens, and test them against MASVS-PLATFORM.
6. Roll back by policy version. Keep the previous MDM policy so a ring can be reverted quickly if an assistive or business app stops working.

Detection and measurement

ATT&CK's detection strategies for T1417 and its sub-techniques correlate app vetting traces, managed app state, permission grants and network data:

• Android keylogging analytic: AccessibilityEvent.TYPE_VIEW_TEXT_CHANGED received by a listener not on the accessibility allow-list, at a high event rate, across many source apps.
• Android GUI capture analytic: permission grant state via DevicePolicyManager.getPermissionGrantState() and manifest review, managed package inventory, and proxy or gateway traffic.
• iOS analytics: code-signing entitlements and Info.plist usage keys from app vetting, InstalledApplicationList and ManagedApplicationList from MDM, and Network Extension or per-app VPN flows.
• Fraud signals: banking and payment teams often see the first evidence as session anomalies after a credential is captured; feed confirmed cases back to the mobile team.

Measures that show progress:

• Percentage of managed Android devices with accessibility and input method allow-lists enforced.
• Number of non-allow-listed apps holding accessibility or overlay rights (target zero).
• Percentage of devices at Android 12 or later and current iOS.
• Percentage of in-house sensitive screens with overlay and accessibility protections, verified in testing.
• Share of workforce sign-ins using passkeys or other phishing-resistant methods.

Common failure patterns

• Allowing sideloading on managed devices. Most ATT&CK examples arrive outside the official store, so unknown sources open the door to accessibility trojans.
• Approving accessibility for convenience. Users grant accessibility to "make the app work"; once granted, the app can read screens and act for the user.
• No exception path for assistive technology. Blanket blocking pushes users to unmanaged devices; allow-list the tools people need.
• Relying on SMS codes. Several trojans capture both credentials and codes, so SMS one-time passwords add little against this technique.
• Unprotected sensitive screens in your own apps. Login and payment screens without overlay and accessibility protections are the ones overlays target.

Framework mapping

Practitioner checklist

• Enforce accessibility service and input method allow-lists on managed Android devices.
• Block installation from unknown sources on managed devices.
• Review iOS third-party keyboards with Full Access.
• Set an OS floor that includes Android 12 overlay protections where feasible.
• Add overlay hiding, obscured-touch filtering and accessibilityDataSensitive to your sensitive screens.
• Move high-value sign-ins to passkeys or other phishing-resistant authentication.
• Reset all credentials typed on a device with confirmed input capture.
• Share confirmed overlay cases between fraud, SOC and mobile teams.

Standards and references

• MITRE ATT&CK: Input Capture, Mobile T1417
• MITRE ATT&CK: Keylogging, Mobile T1417.001
• MITRE ATT&CK: GUI Input Capture, Mobile T1417.002
• Android Developers: Tapjacking
• Android Developers: Privacy changes in Android 10
• Google: Allow restricted settings
• Apple Developer: Creating a custom keyboard
• OWASP: Mobile Application Security Verification Standard

Related NHI Mgmt Group resources: MITRE ATT&CK for Mobile Guide · Android Banking Trojans Guide · Keyloggers Guide · MITRE ATT&CK T1056 Input Capture · Mobile Device Management Security Guide · Mobile T1453 Abuse Accessibility Features · Mobile T1414 Clipboard Data