TA0031: Credential Access
The adversary is trying to steal account names, passwords, or other secrets that enable access to resources.
Credential access represents techniques that can be used by adversaries to obtain access to or control over passwords, tokens, cryptographic keys, or other values that could be used by an adversary to gain unauthorized access to resources. Credential access allows the adversary to assume the identity of an account, with all of that account's permissions on the system and network, and makes it harder for defenders to detect the adversary. With sufficient access within a network, an adversary can create accounts for later use within the environment.
Analyst context for executives and security teams
Credential Access in the mobile ATT&CK domain is about attempts to steal account names, passwords, tokens, cryptographic keys, or other secrets that let an adversary act as a legitimate user. For leaders, the practical issue is not only theft of a password; it is the loss of trust in identity, access decisions, and downstream activity that may appear authorized.
Executive priority
Treat this tactic as a high-priority identity and incident-response concern. If credentials or secrets are exposed, attackers may inherit the permissions of real accounts, making business systems harder to defend and investigations harder to scope. Executives should ask whether the organization can rapidly determine which accounts, tokens, keys, and secrets are exposed; revoke or rotate them; preserve evidence; and prove to auditors or stakeholders that identity controls are working.
Technical view
ATT&CK does not provide detection text or platform detail for this tactic object, so SOC and IR teams should validate coverage by mapping local mobile-relevant credential and secret exposure scenarios to specific ATT&CK techniques under Credential Access. Practical validation should focus on whether identity, endpoint/mobile, application, and access logs can show suspicious use of accounts, tokens, cryptographic keys, or secrets, and whether responders can distinguish legitimate user activity from account misuse after credential theft.
Likely telemetry
- Authentication and access logs for account use and failed or unusual login activity
- Identity provider and account management events, including account creation and permission changes
- Mobile device, application, or management telemetry where available for secret, token, or credential exposure indicators
- Key, certificate, token, and secret management audit records
- Network or resource access logs showing use of credentials to reach protected resources
Detection direction
- Because no official detection guidance is supplied for this tactic, build detection from the specific credential-access techniques relevant to the environment rather than from the tactic name alone.
- Validate that monitoring can correlate credential or token use with account context, permissions, device context, and resource access, since stolen credentials may make adversary activity look like normal authorized behavior.
- Tune for false positives around legitimate administrative work, password resets, token refreshes, key rotation, account provisioning, and mobile device enrollment or recovery workflows.
- Look for blind spots where secrets are stored or used outside centralized identity, logging, or secret-management systems, because those gaps can prevent confident incident scoping.
- Ensure investigations can identify whether an account was merely targeted, successfully used, or used to create additional accounts for later access.
Mitigation priorities
- Prioritize inventory and governance of accounts, tokens, cryptographic keys, and other secrets that grant access to business resources.
- Enforce strong identity controls appropriate to the environment, including least privilege, credential lifecycle management, and rapid revocation or rotation procedures.
- Centralize logging for authentication, account management, secret use, and access to critical resources so SOC and IR teams can reconstruct misuse.
- Prepare incident response playbooks for suspected credential compromise, including account containment, secret rotation, evidence preservation, and validation of newly created or modified accounts.
- Use the tactic as a control-assurance theme for compliance readiness: demonstrate who can access critical resources, how secrets are protected, and how misuse would be detected and contained.
Analyst notes and limits
This is a tactic-level object, not a technique. The supplied ATT&CK fields establish the adversary objective: stealing account names, passwords, tokens, cryptographic keys, or other secrets to gain unauthorized access and assume account identity. The strongest defensive value comes from mapping this tactic to the specific mobile techniques, systems, and identity flows present in the local environment.
No official detection guidance, platforms, tactics list, aliases, labels, or relationship context were supplied. This take therefore avoids claims about specific mobile platforms, active exploitation, attribution, or guaranteed detection coverage. Local architecture, identity design, logging, and incident history are required to determine actual exposure and control maturity.
Credential Access
The adversary is trying to steal account names, passwords, or other secrets that enable access to resources.
Credential access represents techniques that can be used by adversaries to obtain access to or control over passwords, tokens, cryptographic keys, or other values that could be used by an adversary to gain unauthorized access to resources. Credential access allows the adversary to assume the identity of an account, with all of that account's permissions on the system and network, and makes it harder for defenders to detect the adversary. With sufficient access within a network, an adversary can create accounts for later use within the environment.
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.
All related ATT&CK context
No relationships are available in the current normalized data for this object.
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.0 | Current bundle | 47d9a823cc28… |
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]
mitre-attack TA0031Open 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.