T1634: Credentials from Password Store
Adversaries may search common password storage locations to obtain user credentials. Passwords can be stored in several places on a device, depending on the operating system or application holding the credentials. There are also specific applications that store passwords to make it easier for users to manage and maintain. Once credentials are obtained, they can be used to perform lateral movement and access restricted information.
Analyst context for executives and security teams
T1634 matters because credentials stored on an iOS device can become a path from a mobile compromise to broader enterprise access. For leaders, the key issue is not only whether passwords are stored, but whether mobile device posture, update status, attestation, and compromised-device detection are strong enough to keep stored credentials from becoming reusable access to restricted information.
Executive priority
Prioritize this as an identity and mobile security resilience issue. Ask whether enterprise access from iOS devices is conditional on current security updates, device integrity signals, and decommissioning of unsupported devices. This technique also affects incident response decisions: if an iOS device is suspected to be compromised, responders should evaluate whether credentials, certificates, VPN credentials, Wi-Fi passwords, or other keychain-backed secrets may need rotation or access review.
Technical view
ATT&CK lists iOS as the supported platform and provides no tactic or official detection text for the parent technique. The relationship context identifies DET0633, Detection of Credentials from Password Store, and the iOS sub-technique T1634.001 Keychain. SOC and IR teams should therefore validate visibility around iOS device integrity, access to enterprise resources from mobile devices, security update compliance, and signs that a device may be jailbroken or otherwise compromised. Because the related sub-technique centers on iOS Keychain data, investigations should consider whether credentials or secrets normally protected by the iOS keychain could be exposed if device protections fail.
Likely telemetry
- Mobile device management or enterprise mobility management inventory for iOS devices
- iOS security update and device support status
- Remote attestation or device integrity results where available
- Compromised, rooted, or jailbroken device detection signals
- Enterprise access logs tied to mobile device posture and compliance state
Detection direction
- Validate whether DET0633 or an equivalent detection strategy is implemented for iOS credential access risk rather than assuming native ATT&CK detection guidance exists.
- Correlate enterprise access from iOS devices with device compliance, update status, attestation outcome, and compromised-device detection results.
- Tune triage to distinguish normal credential use by managed applications from access occurring from devices that are outdated, unsupported, failed attestation, or suspected compromised.
- Account for blind spots where unmanaged iOS devices, missing MDM coverage, unavailable attestation, or weak compromised-device detection prevent reliable confirmation.
- During incidents, treat suspected keychain exposure as an identity event requiring access review, not only as a mobile endpoint event.
Mitigation priorities
- Keep iOS devices current with security updates and limit or block enterprise access from devices that have not installed recent updates, consistent with M1001 Security Updates.
- Prefer devices and support models with prompt security update commitments, and decommission devices that no longer receive updates.
- Use attestation where available and prohibit devices that fail attestation from accessing enterprise resources, consistent with M1002 Attestation.
- Deploy compromised-device detection methods through device, MDM/EMM, mobile security application, or other available mechanisms, consistent with M1010.
- For suspected exposure, review and rotate affected credentials or secrets based on local evidence and enterprise access impact.
Analyst notes and limits
The most useful defensive framing is identity risk from mobile credential storage. The supplied relationship to T1634.001 Keychain makes iOS keychain-backed secrets especially relevant, but the parent object should still be handled broadly as credentials from password stores on iOS. Detection and response quality will depend heavily on MDM/EMM coverage, device posture enforcement, and the organization’s ability to connect mobile device state to identity and application access logs.
MITRE does not provide official detection text or tactics for this object in the supplied fields. The mitigation text is limited to the related ATT&CK mitigations, and one supplied M1001 description is truncated. This take does not assert active exploitation, attribution, or guaranteed detection coverage. Local device management, identity, and access telemetry are required to determine actual exposure.
Credentials from Password Store
Adversaries may search common password storage locations to obtain user credentials. Passwords can be stored in several places on a device, depending on the operating system or application holding the credentials. There are also specific applications that store passwords to make it easier for users to manage and maintain. Once credentials are obtained, they can be used to perform lateral movement and access restricted information.
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.
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 | 6b0302bad4ba… |
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 AUT-11Open source URL
-
[2]
mitre-attack T1634Open 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.