T1634.001: Keychain
Adversaries may collect keychain data from an iOS device to acquire credentials. Keychains are the built-in way for iOS to keep track of users' passwords and credentials for many services and features such as Wi-Fi passwords, websites, secure notes, certificates, private keys, and VPN credentials.
On the device, the keychain database is stored outside of application sandboxes to prevent unauthorized access to the raw data. Standard iOS APIs allow applications access to their own keychain contained within the database. By utilizing a privilege escalation exploit or existing root access, adversaries can access the entire encrypted database.[1][2]
Analyst context for executives and security teams
Keychain credential collection matters because the iOS keychain can hold high-value secrets such as website passwords, Wi-Fi credentials, certificates, private keys, VPN credentials, and secure notes. ATT&CK describes this as requiring privilege escalation exploit capability or existing root access to reach the broader encrypted keychain database beyond normal app access. For leaders, this is less about routine mobile app behavior and more about whether compromised or unpatched iOS devices could become a credential-loss path into enterprise services.
Executive priority
Treat this as a mobile identity and access risk. Priority decisions should focus on whether enterprise access is allowed from outdated, unsupported, jailbroken, rooted, or otherwise compromised iOS devices; whether mobile credential exposure would affect VPN, Wi-Fi, certificate-based access, or privileged workflows; and whether compliance evidence can show device update enforcement and compromised-device detection. The ATT&CK relationships to Operation Triangulation, INSOMNIA, LightSpy, and TriangleDB show this behavior is relevant to mobile spyware and targeted iOS intrusion scenarios, but the supplied data does not support claims about current activity in any specific environment.
Technical view
SOC, detection engineering, and IR teams should validate iOS-focused coverage around compromised-device indicators, privilege escalation/root access conditions, and attempts to access credential material outside normal application keychain API boundaries. ATT&CK provides no official detection text for this sub-technique, but it is related to DET0664, Detection of Keychain, and mitigations M1001 Security Updates, M1002 Attestation, and M1010 Deploy Compromised Device Detection Method. Because tactics are not specified, teams should anchor use cases to credential exposure and post-compromise mobile investigation rather than assuming a specific ATT&CK tactic phase.
Likely telemetry
- MDM/EMM device inventory, iOS version, update status, and support status
- Mobile device compliance state and enterprise access decisions
- Compromised-device, jailbreak, or root-detection signals where available
- Remote attestation results where available
- Mobile security application alerts related to device compromise or suspicious credential-store access
Detection direction
- Confirm whether DET0664 or equivalent internal logic is implemented; ATT&CK does not provide detection details in the supplied object.
- Prioritize detection of prerequisite conditions: privilege escalation, root access, jailbreak/compromise indicators, and devices failing attestation or compliance checks.
- Correlate mobile compromise signals with enterprise authentication, VPN, certificate, and Wi-Fi access to identify possible credential misuse after device compromise.
- Tune carefully for false positives from legitimate keychain API use by apps; the material concern is access beyond normal app sandbox permissions or signs the device integrity model has failed.
- Track blind spots where iOS endpoint telemetry is limited, devices are personally owned, MDM enrollment is partial, or unsupported devices can still reach enterprise resources.
Mitigation priorities
- Enforce timely iOS security updates and restrict enterprise access from devices missing recent updates or no longer supported, consistent with M1001.
- Use attestation where available and prohibit devices that fail attestation from accessing enterprise resources, consistent with M1002.
- Deploy compromised-device detection through built-in, MDM/EMM, mobile security, or other methods, recognizing ATT&CK notes some methods may be easier to evade than others, consistent with M1010.
- Review conditional access policies for mobile access to VPN, Wi-Fi, certificates, and sensitive applications so a compromised phone does not automatically become a broad credential bridge.
- Prepare IR playbooks for suspected iOS compromise that include credential rotation decisions for secrets likely stored in keychain.
Analyst notes and limits
This is a sub-technique of T1634 Credentials from Password Store and applies to iOS. The key business issue is the concentration of reusable credentials and private key material on mobile devices, combined with the need for root access or privilege escalation to collect the broader keychain database. Relationship context links the behavior to Operation Triangulation and to INSOMNIA, LightSpy, and TriangleDB in ATT&CK, which supports prioritizing mobile spyware readiness without implying local exposure.
The supplied ATT&CK object has no official detection text and no specified tactics. Relationship descriptions for some mitigations are truncated in the supplied data. Practical coverage depends on local MDM/EMM capabilities, iOS telemetry availability, attestation support, device ownership model, and identity/access logging.
Keychain
Adversaries may collect keychain data from an iOS device to acquire credentials. Keychains are the built-in way for iOS to keep track of users' passwords and credentials for many services and features such as Wi-Fi passwords, websites, secure notes, certificates, private keys, and VPN credentials.
On the device, the keychain database is stored outside of application sandboxes to prevent unauthorized access to the raw data. Standard iOS APIs allow applications access to their own keychain contained within the database. By utilizing a privilege escalation exploit or existing root access, adversaries can access the entire encrypted database.[1][2]
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 | T1579 | Keychain | Keychain revoked by this object. |
| Mobile | T1634 | Credentials from Password Store | This object subtechnique of Credentials from Password Store. |
Groups, software, and campaigns
S1216: TriangleDB
TriangleDB is an Objective-C written implant deployed after Binary Validator and after root privileges are obtained during Operation Triangulation’s infection chain. Upon execution, TriangleDB communicates with the C2 server, relaying information about the victim device.[1]
S1185: LightSpy
First observed in 2018, LightSpy is a modular malware family that initially targeted iOS devices in Southern Asia before expanding to Android and macOS platforms. It consists of a downloader, a main executable that manages network communications, and functionality-specific modules, typically implemented as `.dylib` files (iOS, macOS) or `.apk` files (Android). LightSpy can collect VoIP call recordings, SMS messages, and credential stores, which are then exfiltrated to a command and control (C2) server.[1]
S0463: INSOMNIA
C0054: Operation Triangulation
Operation Triangulation is a mobile campaign targeting iOS devices.[1] The unidentified actors used zero-click exploits in iMessage attachments to gain Initial Access, then executed exploits and validators, such as Binary Validator before finally executing the TriangleDB implant.
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 | 1.1 | Current bundle | 7c10528e3de4… |
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]
Apple Keychain Services
Apple, Inc.. (n.d.). Keychain Services. Retrieved June 24, 2020.
Open source URL -
[2]
Elcomsoft Decrypt Keychain
V. Katalov. (2018, December 18). Six Ways to Decrypt iPhone Passwords from the Keychain. Retrieved June 24, 2020.
Open source URL -
[3]
NIST Mobile Threat Catalogue AUT-11Open source URL
-
[4]
mitre-attack T1634.001Open 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.