T1417: 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).
Analyst context for executives and security teams
Input Capture on mobile devices matters because it targets the moment users enter credentials or sensitive information. On Android and iOS, this can be transparent, such as keylogging, or deceptive, such as a fake prompt that looks legitimate. For leaders, the practical risk is loss of trust in mobile authentication and user-facing workflows, especially where mobile devices are used for banking, cryptocurrency, enterprise access, or sensitive business applications.
Executive priority
Prioritize this as a mobile identity and fraud-resilience issue, not only a malware issue. Executives should ask whether managed mobile devices are kept on recent OS versions, whether enterprise policy controls risky app behavior and permissions, and whether users receive clear guidance about third-party keyboards, accessibility prompts, and unexpected credential dialogs. Because ATT&CK does not provide official detection text for this technique, organizations should require evidence of actual mobile telemetry and response playbooks rather than assuming endpoint-style visibility exists on phones.
Technical view
SOC, detection, and IR teams should validate coverage for Android and iOS input capture behaviors across the parent technique and its sub-techniques: Keylogging (T1417.001) and GUI Input Capture (T1417.002). Relationship context shows a detection strategy, DET0705 Detection of Input Capture, but no official detection details are supplied here, so teams should map local controls to observable mobile signals such as suspicious keyboard authorization, accessibility-service abuse indicators, fake or unexpected credential prompts, risky app permissions, and anomalous authentication outcomes. Related software examples include Phenakite on iOS and CherryBlos and GodFather on Android, supporting the need to test both major mobile platforms without assuming identical telemetry or controls.
Likely telemetry
- Mobile device inventory with Android/iOS platform and OS version
- EMM/MDM policy state and compliance status
- Installed application inventory and app provenance where available
- Mobile permission and configuration data, especially keyboard and accessibility-related authorization where available
- User reports or help desk tickets about unexpected login prompts or credential dialogs
Detection direction
- Confirm whether DET0705 or equivalent local detection logic is implemented and what mobile data sources it requires.
- Validate coverage separately for keylogging-style behavior and GUI prompt deception; a control that handles one may miss the other.
- Tune investigations around high-risk permission grants and unexpected credential prompts, while accounting for legitimate third-party keyboards, accessibility tools, and normal application login flows.
- Correlate mobile-side evidence with identity telemetry because successful input capture may first become visible as suspicious authentication rather than as a clear device alert.
- Document blind spots where iOS or Android privacy, unmanaged devices, or limited EMM enrollment prevents collection of app, permission, or prompt-level evidence.
Mitigation priorities
- Keep mobile operating systems on recent versions, aligned to M1006, because newer OS releases include patches and security architecture improvements.
- Use enterprise mobility policy controls, aligned to M1012, to manage allowed device behavior, app posture, and configuration on enrolled devices.
- Provide user guidance, aligned to M1011, focused on cautious approval of third-party keyboards, accessibility requests, and unexpected credential prompts.
- Sequence controls by first establishing mobile asset and OS visibility, then enforcing policy on managed devices, then validating user-facing reporting and IR procedures for suspected credential capture.
Analyst notes and limits
The ATT&CK object is a mobile parent technique for Android and iOS with no tactics specified and no official detection text provided. The most actionable context comes from the related sub-techniques, the mitigation relationships M1006, M1011, and M1012, and the detection strategy relationship DET0705. The software relationships show that ATT&CK has associated this behavior with named mobile malware on Android and iOS, but this take does not infer current exploitation or exposure in any specific environment.
This assessment is limited to the supplied ATT&CK fields, external references, and relationships. It cannot confirm an organization’s detection coverage, device exposure, active compromise, or specific control effectiveness without local EMM/MDM, mobile security, identity, and incident data.
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).
How security teams should use this page
Treat this object as behavior context, not an attribution claim. Validate the related groups, software, data sources, and mitigations against official ATT&CK relationships and your own telemetry before making control-coverage decisions.
Related techniques
This mirrors the MITRE pattern of making group, software, campaign, and technique relationships scannable. Relationship notes come from mirrored ATT&CK relationship text when available.
| Domain | ID | Name | Relationship / procedure |
|---|---|---|---|
| Mobile | T1417.002 | GUI Input Capture Sub-technique | GUI Input Capture subtechnique of this object. |
| Mobile | T1417.001 | Keylogging Sub-technique | Keylogging subtechnique of this object. |
Groups, software, and campaigns
S1225: CherryBlos
CherryBlos is an Android malware that steals credentials and redirects cryptocurrency to adversary-controlled wallets. CherryBlos was labelled Robot 999 in its first appearance in April 2023; since then, various aliases have been used, including GPTalk, Happy Miner, and SynthNet. The threat actors behind CherryBlos uploaded the malware to different Google Play regions, such as Malaysia, Vietnam, Indonesia, Philippines, Uganda, and Mexico.[1]
S1126: Phenakite
S1231: GodFather
GodFather is an Android banking malware that uses virtualization to mimic legitimate applications and abuses accessibility services and other permissions to evade detection and exfiltrate sensitive data. First identified in 2020, GodFather targets nearly 500 banking applications, cryptocurrency wallets, and exchanges worldwide; however, its virtualization-based attacks have primarily focused on several Turkish financial institutions. This capability enables threat actors to steal banking credentials and other sensitive account information. [1][2]
All related ATT&CK context
Mitigation direction
Object version and sync metadata
The fields below describe the current mirrored snapshot. When Glexia retains multiple ATT&CK source imports, you can open the table to compare the same object across releases (hashes and MITRE timestamps). For MITRE’s own release notes and roadmap, see ATT&CK resources — Updates .
Imported snapshots across ATT&CK releases (1)
| Release | Bundle imported | Object version | Modified | Status | Raw hash |
|---|---|---|---|---|---|
| 19.1 | 2.3 | Current bundle | 34bcb2b9fdec… |
Mirrored ATT&CK source object
The raw object is retained through the mirrored ATT&CK source bundle and object hash. The raw endpoint returns the exact object from the mirrored bundle when available.
External references and citations
MITRE external references are preserved separately from Glexia analysis so citations remain traceable to their original source records.
-
[1]
NIST Mobile Threat Catalogue APP-31Open source URL
-
[2]
NIST Mobile Threat Catalogue AUT-13Open source URL
-
[3]
mitre-attack T1417Open source URL
Source: MITRE ATT&CK®. © 2026 The MITRE Corporation. This work is reproduced and distributed with the permission of The MITRE Corporation. MITRE ATT&CK and ATT&CK are registered trademarks of The MITRE Corporation. Glexia is not affiliated with or endorsed by MITRE.