Input Capture

Adversaries may use methods of capturing user input to obtain credentials or collect information. During normal device usage, users often provide credentials to various locations, such as login pages/portals or system dialog boxes. Input capture mechanisms may be transparent to the user (e.g. Keylogging) or rely on deceiving the user into providing input into what they believe to be a genuine application prompt (e.g. GUI Input Capture).

ID: T1417
Sub-techniques:  T1417.001, T1417.002
Tactic Type: Post-Adversary Device Access
ⓘ
Platforms: Android, iOS
ⓘ
MTC ID: APP-31, AUT-13
Version: 2.3
Created: 25 October 2017
Last Modified: 24 October 2025

Procedure Examples

ID Name Description
S1225 CherryBlos

CherryBlos has captured victims' credentials through predefined fake activities.[1]

S1231 GodFather

GodFather has the captured information about the device's screen to include detailed tap events.[2]

S1126 Phenakite

Phenakite has used phishing sites for iCloud and Facebook if either of those were used for authentication during the chat sign up process.[3]

Mitigations

ID Mitigation Description
M1012 Enterprise Policy

When using Samsung Knox, third-party keyboards must be explicitly added to an allow list in order to be available to the end-user.[4] An EMM/MDM can use the Android DevicePolicyManager.setPermittedAccessibilityServices method to set an explicit list of applications that are allowed to use Android's accessibility features.

M1006 Use Recent OS Version

The HIDE_OVERLAY_WINDOWS permission was introduced in Android 12 allowing apps to hide overlay windows of type TYPE_APPLICATION_OVERLAY drawn by other apps with the SYSTEM_ALERT_WINDOW permission, preventing other applications from creating overlay windows on top of the current application.[5]

M1011 User Guidance

Users should be wary of granting applications dangerous or privacy-intrusive permissions, such as keyboard registration or accessibility service access.

Detection Strategy

ID Name Analytic ID Analytic Description
DET0705 Detection of Input Capture AN1825

For Android, detect Input Capture by correlating analyst-visible device/network evidence and management state; use streaming or batched telemetry only where the documented collector is deployed. Correlate API Calls via Application Vetting / Instrumented Dynamic Analysis [Dynamic API/runtime trace: AccessibilityEvent.TYPE_VIEW_TEXT_CHANGED received by listener_app NOT IN $AccessibilityAllowList$]; Network Traffic Flow via Android Enterprise Network Logging / Enterprise VPN [DevicePolicyManager.retrieveNetworkLogs(): DnsEvent / ConnectEvent; VPN flow metadata]; Permissions Request via Android Enterprise DPC / Application Vetting [DevicePolicyManager.getPermissionGrantState(); PackageManager manifest/requested-permission review]. Alert on a sequence or state change inconsistent with the device/app baseline, approved management policy, or expected user workflow; do not infer unobserved API calls, file/process activity, or payload content from management state alone.

AN1826

For iOS, detect Input Capture by correlating analyst-visible device/network evidence and management state; use streaming or batched telemetry only where the documented collector is deployed. Correlate Application State via Apple MDM [InstalledApplicationList / ManagedApplicationList]; Network Traffic Flow via Apple Network Extension / Enterprise VPN [NEFilterFlow / per-app VPN / secure-web-gateway flow metadata]; Permissions Request via Application Vetting [Code-signing entitlements and Info.plist privacy usage-description keys]. Alert on a sequence or state change inconsistent with the device/app baseline, approved management policy, or expected user workflow; do not infer unobserved API calls, file/process activity, or payload content from management state alone.

References