The iOS keychain holds the passwords, tokens, certificates, private keys and VPN credentials that let a phone reach everything else, so an attacker with root-level access to an iPhone goes for it early. MITRE ATT&CK for Mobile tracks this as T1634 Credentials from Password Store, a Credential Access technique, with one sub-technique, T1634.001 Keychain. ATT&CK lists iOS as the only platform for both. This guide explains how keychain protection works, what an attacker needs to defeat it, how app teams should store secrets so a dump yields less, and how to detect and respond. It is for mobile security, mobile app and incident response teams. For the matrix as a whole, see the MITRE ATT&CK for Mobile Guide.
Key takeaways
- It needs a compromised device. ATT&CK states that bulk keychain access requires a privilege escalation exploit or existing root access, so this is a post-exploitation technique tied to spyware and jailbreaks.
- iOS only in ATT&CK. Android is not listed for T1634; the Android Keystore is designed so key material cannot be read out, which is a different model, not an equivalent target.
- Accessibility classes decide exposure. Items marked "when unlocked" and "this device only" are harder to use off the device than items available after first unlock or synced.
- Store keys, not long-lived secrets. Short-lived, sender-constrained tokens and Secure Enclave keys turn a keychain dump into far less than a full account takeover.
- Patch, attest and rotate. ATT&CK's mitigations are security updates, attestation and compromised device detection; response must assume every keychain secret is exposed.
What T1634 covers
ATT&CK describes T1634 as searching common password storage locations to obtain credentials, which can then be used for lateral movement and access to restricted information. T1634.001 Keychain covers collecting keychain data from an iOS device. ATT&CK lists what the keychain holds: Wi-Fi passwords, website credentials, secure notes, certificates, private keys and VPN credentials. It notes that the keychain database is stored outside application sandboxes, that standard APIs give an app access only to its own items, and that a privilege escalation exploit or existing root access lets an adversary reach the whole encrypted database. T1634.001 replaced the older ID T1579 Keychain, now revoked. The Enterprise equivalent is T1555, covered in the T1555 Credentials from Password Stores Defensive Guide.
How keychain protection works
Apple Platform Security describes the keychain as a single SQLite database. The securityd daemon decides which items each app can reach, based on its keychain-access-groups, application-identifier and application group entitlements. Access groups let apps from the same developer share items, enforced by code signing and provisioning profiles. Each item is protected with two AES-256-GCM keys, a table key for metadata and a per-row key for the secret, and secret-key operations go through the Secure Enclave, which also evaluates access control lists such as a biometric or passcode requirement.
| Accessibility class | When available | Backup and sync behaviour (per Apple) | Use for |
|---|---|---|---|
kSecAttrAccessibleWhenUnlocked | Only while the device is unlocked | Can be backed up | Foreground credentials |
kSecAttrAccessibleAfterFirstUnlock | After the first unlock following restart | Can be backed up | Items needed by background refresh |
| "ThisDeviceOnly" variants | As the base class | Protected with the device UID in backups, so unusable if restored to another device | Device-bound credentials |
kSecAttrAccessibleWhenPasscodeSetThisDeviceOnly | Unlocked, and only while a passcode is set | Never synced to iCloud Keychain, backed up or escrowed; removed passcode makes items unusable | Highest-value secrets |
The practical point: an attacker with code running on an unlocked, compromised device may still read items in any class that is currently available. Accessibility classes limit off-device and locked-state exposure; they do not stop an on-device implant. That is why the design choices below matter. See Apple Platform Security Explained for the wider architecture.
Real cases from ATT&CK
- Operation Triangulation (C0054): ATT&CK records that the threat actors dumped the device keychain, and that the TriangleDB implant (S1216) extracted it, citing Kaspersky's Securelist reporting from 2023.
- LightSpy (S1185): ATT&CK records that LightSpy accessed device keychain data, citing BlackBerry, ThreatFabric and Kaspersky reporting.
- INSOMNIA (S0463): ATT&CK records keychain extraction, citing Google Project Zero.
Android: what differs
ATT&CK does not list Android for T1634. Android's closest platform store, the Android Keystore, protects cryptographic keys rather than storing retrievable passwords. Android's documentation states that key material never enters the app process, that a compromised app can misuse its keys but cannot copy them off the device, and that keys can be bound to the TEE or StrongBox and to user authentication with setUserAuthenticationParameters(). Android apps that store tokens in plain files or shared preferences are a separate problem, mapped by ATT&CK to other techniques such as T1409 Stored Application Data. See the Android App Security Guide.
Prevention
| ATT&CK mitigation | Control |
|---|---|
| M1001 Security Updates | Enforce minimum iOS versions through MDM and block corporate access below them; the recorded cases used exploit chains that updates close |
| M1002 Attestation | Use managed device attestation (see Apple Declarative Device Management and Managed Device Attestation Guide) and App Attest in your apps to gate access |
| M1010 Deploy Compromised Device Detection Method | MTD or app-level jailbreak detection that blocks or limits access when compromise is detected |
| Hardening for high-risk users | Apple Lockdown Mode reduces the attack surface that exploit chains use |
App design that limits what a dump yields
- Prefer keys to secrets: generate a non-exportable key in the Secure Enclave and use it to sign requests, instead of storing a reusable password or API key.
- Short-lived tokens: keep access tokens short and refresh tokens rotated or sender-constrained, as RFC 9700 requires for public clients.
- Strictest workable class: use "ThisDeviceOnly" classes and require user presence for high-value items.
- No backend secrets in the app: a static API key or service credential in the keychain is a non-human identity shared by every install; move it to a backend. See Mobile Access Credentials.
Detection and response
ATT&CK's detection guidance for T1634 relies on Apple MDM state (installed and managed app lists, SecurityInfo, profile lists and compliance queries) and network flow metadata from Network Extension or per-app VPN, alerting on change inconsistent with the device baseline. Keychain reads themselves are not visible to a SOC. In practice:
- Device signals: MTD jailbreak or compromise alerts, failed attestation, unexpected profiles, and OS versions below policy.
- Identity signals: the same token or credential used from a new device, location or network shortly after a device alert; see How to detect use of a stolen OAuth refresh token.
- Forensics: the Mobile Verification Toolkit (MVT) checks iOS backups, filesystem dumps and sysdiagnose files against published indicators, with the owner's consent.
- Mark the device non-compliant and cut corporate access.
- Preserve a backup or sysdiagnose for analysis before wiping.
- Treat every credential the device held as exposed: Wi-Fi, VPN, certificates, app tokens, website passwords, including synced passwords.
- Revoke sessions and refresh tokens, reissue certificates, and reset passwords from a clean device.
- Restore from a clean state, update iOS, and consider Lockdown Mode. Follow the Mobile Spyware Infection Response Playbook.
Metrics
- Share of iOS devices on the minimum supported version.
- Share of corporate access requests gated by attestation.
- Number of app secrets stored as static, long-lived values (target: zero).
- Time from device compromise alert to revocation of all its credentials.
Common failure patterns
- Wiping without rotating: the device is reset but credentials copied from it remain valid.
- AfterFirstUnlock by default: every item uses the most permissive class because background refresh needed one.
- Shared API keys in apps: one dump exposes a credential used by every install.
- Trusting jailbreak detection alone: it is bypassable; pair it with server-side attestation and token binding.
- Forgetting VPN and Wi-Fi credentials: rotation covers app tokens but misses network access.
Framework mapping
| Framework | Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | IA-5 Authenticator Management; SC-28 Protection of Information at Rest; AC-19 Access Control for Mobile Devices | Credential storage and rotation on mobile |
| NIST CSF 2.0 | PR.AA-01 identities and credentials managed; PR.DS-01 data at rest protected | Credential lifecycle |
| CIS Controls v8.1 | Control 6 Access Control Management; Control 7 Continuous Vulnerability Management | Revocation and OS patching |
| ISO/IEC 27001:2022 | A.8.1 User endpoint devices; A.8.5 Secure authentication | Device and credential protection |
| OWASP MASVS | MASVS-STORAGE; MASVS-CRYPTO; MASVS-AUTH | How apps store and use secrets |
Practitioner checklist
- Enforce minimum iOS versions and block access below them.
- Gate corporate access on managed device attestation and MTD compromise signals.
- Review your apps' keychain accessibility classes and move high-value items to "ThisDeviceOnly" and passcode-bound classes.
- Replace static secrets in apps with Secure Enclave keys and backend-issued, short-lived tokens.
- Rotate or sender-constrain refresh tokens for mobile clients.
- Write a device-compromise runbook that lists every credential type to rotate.
- Offer Lockdown Mode to high-risk staff.
Standards and references
- MITRE ATT&CK: T1634 Credentials from Password Store (Mobile)
- MITRE ATT&CK: T1634.001 Keychain
- MITRE ATT&CK: C0054 Operation Triangulation
- Apple Platform Security: Keychain data protection
- Android Developers: Android Keystore system
- IETF: RFC 9700 Best Current Practice for OAuth 2.0 Security
- OWASP: Mobile Application Security Verification Standard
- Amnesty International Security Lab: Mobile Verification Toolkit documentation
Related NHI Mgmt Group resources: MITRE ATT&CK for Mobile Guide · iOS App Security Guide · Mobile Forensics Guide · Mobile Communications Protection for High-Risk Individuals Guide