Mobile ATT&CK Credential Access Tactic (TA0031) Guide: Protecting Credentials on Android and iOS

Phones hold the credentials that unlock everything else: passwords typed into banking apps, one-time codes in notifications, OAuth tokens in app storage and secrets in the iOS Keychain. ATT&CK for Mobile v20 describes the Credential Access tactic (TA0031) as the adversary "trying to steal account names, passwords, or other secrets that enable access to resources", including passwords, tokens and cryptographic keys. This hub covers the six current techniques and their sub-techniques, how mobile malware chains them, which ones defenders should address first and how MDM, mobile threat defence (MTD), OS controls and app design reduce them. It is for mobile security engineers, identity teams and app developers. Each technique has its own guide; for the full matrix see the MITRE ATT&CK for Mobile Guide.

Key takeaways

• Overlays dominate. In the ATT&CK Mobile v20 dataset GUI Input Capture (T1417.002) has 30 recorded uses and Keylogging (T1417.001) 20, far more than any other credential technique.
• Accessibility is the common enabler. Keylogging, overlays, notification reading and screen reading on Android usually depend on an Accessibility service or notification listener the user was tricked into enabling.
• One-time codes are credentials too. Access Notifications (T1517, 15 uses) exposes codes delivered by push or SMS preview, which is why SMS and notification codes are weak second factors on a compromised handset.
• iOS credential theft is exploit-led. The documented Keychain (T1634.001) cases, TriangleDB, LightSpy and INSOMNIA, came from exploit chains, so patch currency and compromised-device detection are the controls MITRE maps.
• Tokens move the problem to the server. Steal Application Access Token (T1635) and URI Hijacking (T1635.001) are best fixed in app and authorisation server design: PKCE, claimed HTTPS links and short-lived, revocable tokens.

What the Credential Access tactic means on a mobile device

Desktop credential theft often means dumping memory or credential stores with administrator rights. On a modern phone the sandbox blocks that, so mobile adversaries take credentials at the edges: what the user types, what the screen shows, what notifications reveal and what other apps pass through the clipboard or redirect URIs. The exception is a full exploit chain on iOS or Android, which reaches the Keychain or app data directly.

Four of the six techniques also sit under Collection (TA0035): Clipboard Data, Input Capture, Abuse Accessibility Features and Access Notifications. The same malware feature counts twice because what it collects is often a secret. See the Mobile ATT&CK Collection Tactic hub for the collection view.

All Credential Access techniques in ATT&CK Mobile v20

Use counts are the number of software, group and campaign "uses" relationships in the ATT&CK Mobile v20.0 STIX bundle, excluding revoked and deprecated objects, counted per technique ID (sub-techniques separately). They show what MITRE has documented, not prevalence.

Zero recorded uses does not mean low risk: token interception through custom URI schemes is a design weakness that MITRE describes from research rather than named malware.

How adversaries chain Credential Access

Co-occurrence in the same v20 bundle (software using both technique families) shows a consistent path:

1. Delivery and hiding: an app arrives through Phishing or a dropper. Of the 39 software entries that use Input Capture, 23 also use Obfuscated Files or Information.
2. Enabler: the app persuades the user to enable an Accessibility service (8 of the 39 Input Capture entries are also recorded for T1453) or a notification listener (8 of 39 also use T1517).
3. Credential capture: an overlay mimicking the target banking or email app collects the password, or a keylogger records it from Accessibility events.
4. Second factor capture: 20 of the 39 Input Capture entries also use SMS Control, so SMS codes are read and often deleted.
5. Use: the attacker signs in from elsewhere, or performs the transaction on the device with Input Injection.

The targeted surveillance path is different. Operation Triangulation (C0054) used an iMessage zero-click chain on iOS, and its TriangleDB implant extracted the Keychain; LightSpy and INSOMNIA are also recorded for Keychain access. No user interaction, no Accessibility permission and no overlay were involved. See the Commercial Spyware Guide.

Where to start: ranking the techniques for defenders

1. T1417.002 GUI Input Capture: most documented and directly tied to account takeover. Controls: app source restriction, accessibility allow-lists on managed Android, and phishing-resistant sign-in so a captured password alone is not enough.
2. T1453 Abuse Accessibility Features: the enabler for overlays, keylogging and input injection. Fixing it collapses several techniques at once.
3. T1517 Access Notifications: move one-time codes out of notifications and SMS; for apps, avoid showing codes in notification text.
4. T1635 and T1635.001 tokens: a design fix in your own apps (see below) that removes a whole class of interception.
5. T1634.001 Keychain: for high-risk users, patch currency, Lockdown Mode and compromised-device detection.
6. T1414 Clipboard Data: discourage copying passwords; current OS versions limit background clipboard reads, which is why MITRE maps M1006.

Detection priorities

Each technique has a v20 detection strategy. The analytics lean on three sources: MDM or EMM state and permissions, application vetting, and network telemetry from Android enterprise logs or iOS NetworkExtension.

Server-side signals matter as much as device ones: a sign-in from a new device minutes after the user signed in on their phone, or a refresh token used from two networks, often shows theft before any device alert. For a suspected exploit-led compromise, capture evidence before reset with the Mobile Verification Toolkit (MVT).

Metrics

• Phishing-resistant coverage: share of mobile sign-ins using passkeys or device-bound credentials rather than passwords plus SMS.
• Enabler exposure: managed Android devices with an Accessibility or notification listener grant outside the allow-list.
• Token hygiene: share of your mobile apps using PKCE and claimed HTTPS redirect links.
• Time to revoke: median time from a mobile compromise alert to revocation of the user's sessions and tokens.
• Patch currency: devices within the minimum OS and security patch level.

Mitigation priorities and OS controls

MITRE maps seven mitigation IDs across the tactic. The table turns them into controls; see ATT&CK Mitigations for the model.

For app teams, the OAuth for Native and Mobile Apps Guide and the Mobile Deep Link and App Link Security Guide cover redirect handling, and Secrets in mobile apps covers keys shipped inside app packages.

Decision guidance

• Workforce, corporate-owned: allow-lists for Accessibility, keyboards and notification listeners, plus passkeys, remove most of the commodity chain.
• Workforce, BYOD: you cannot set device-wide allow-lists outside the work profile, so lean on phishing-resistant authentication, short session lifetimes and app protection policies.
• Customer apps: assume the device may be hostile. Detect enabled Accessibility services and overlays during login and payment, and use transaction signing for high-value actions. See the Mobile App Attestation guide.
• High-risk individuals: exploit-led Keychain theft calls for Lockdown Mode, rapid patching and periodic MVT checks; see Mobile Communications Protection for High-Risk Individuals Guide.

Where identity fits

Every technique in this tactic is an identity attack. Two angles are easy to miss. First, mobile apps hold non-human credentials: OAuth refresh tokens, API keys and device certificates that act without the user present. A stolen refresh token keeps working after the user changes their password unless the authorisation server revokes it, so revocation on device compromise must be automated. Second, the device itself is an authenticator; if malware captures what the user types and approves, possession of the device stops proving anything. Phishing-resistant, origin-bound credentials such as passkeys defeat overlays because there is no password to capture. See the OAuth Token Theft Incident Playbook and Device-Bound Passkeys.

Common failure patterns

• SMS or notification codes as the only second factor: Access Notifications and SMS Control read them on the same device.
• Custom URI schemes for OAuth redirects without PKCE: any app can register the scheme and receive the authorisation code.
• Long-lived refresh tokens with no revocation on device risk: theft persists after the device is cleaned.
• Accessibility left open on managed Android: one user tap gives malware keylogging and overlay control.
• Treating iOS as safe by default: Keychain theft cases show that exploit chains bypass app-level controls; patch lag is the real exposure.
• Resetting before capture: evidence of what was stolen, and therefore which credentials to rotate, is lost.

Framework mapping

Practitioner checklist

• Enforce Accessibility, keyboard and notification listener allow-lists on managed Android devices.
• Replace SMS and notification one-time codes with passkeys or number-matching app approval for workforce sign-in.
• Require PKCE and claimed HTTPS redirect links (App Links, Universal Links) in every mobile app you publish.
• Automate session and refresh token revocation when MTD or MDM marks a device as compromised.
• Gate access on minimum OS version and patch level; retire devices without updates.
• Offer Lockdown Mode to high-risk iOS users and schedule MVT checks for them.
• Alert on overlay and Accessibility grants to unapproved apps and correlate with identity provider sign-ins.
• Capture forensic evidence before resetting a device, then rotate every credential it held.

Standards and references

• MITRE ATT&CK: Credential Access, Mobile (TA0031)
• MITRE ATT&CK: Mobile Matrix
• NIST: SP 800-124 Rev. 2, Guidelines for Managing the Security of Mobile Devices in the Enterprise
• NIST: SP 800-53 Rev. 5, Security and Privacy Controls
• Google: Allow restricted settings on Android
• Google Play: Use of SMS or Call Log permission groups
• Apple: About Lockdown Mode
• Amnesty International Security Lab: Mobile Verification Toolkit documentation

Related NHI Mgmt Group resources: MITRE ATT&CK for Mobile Guide, ATT&CK Credential Access Tactic Guide, Android Banking Trojans Guide, Mobile Malware Guide, Mobile ATT&CK Impact Tactic.