T1528
Steal Application Access Token
Containers · IaaS · Identity Provider · Office Suite · SaaS5 pieces on this siteT1528 on attack.mitre.org
Adversaries can steal application access tokens as a means of acquiring credentials to access remote systems and resources. Application access tokens are used to make authorized API requests on behalf of a user or service and are commonly used as a way to access resources in cloud and container-based applications and software-as-a-service (SaaS).
If this is happening now
Checklists and playbooks to open while the alert is still live.
Cloud account takeover response plan: sessions, methods, devices and grants, then what they read
A successful sign-in the user did not make, in Microsoft Entra ID and Microsoft 365. A password reset alone evicts almost nobody. The plan works through the order that does, how to tell a guessed password from a stolen session, and how to answer what they read.
Business email compromise response plan: the money first, then the mailbox
Two responses that have to run at once. One is a race with a bank transfer measured in hours. The other is evicting an operator who is still reading the mailbox, and who survives a password reset unless you remove what they left behind.
Cloud account compromise
Impossible travel, an unrecognised inbox rule, or a reported invoice-fraud attempt.
A malicious application has consent in the tenant
An unrecognised enterprise application, a consent grant nobody remembers approving, or mail access that survived a password reset.
A malicious package was installed
A registry advisory, a vendor alert or a dependency scanner says a package version you use was malicious, or a build or a developer laptop ran an install script it should not have.
how MITRE says to see it
Detection Strategy for T1528 - Steal Application Access Token
- Access and retrieval of container service account tokens followed by unauthorized API requests using those tokens to interact with the Kubernetes API server or internal services.
- Token retrieval from instance metadata endpoints such as AWS IMDS or Azure IMDS, followed by API usage using the obtained token from non-standard applications.
- Unusual OAuth app registration followed by user-granted OAuth tokens and subsequent high-privilege resource access via those tokens.
- Use of OAuth tokens by third-party apps to access user mail, calendar, or SharePoint resources where the token was granted recently or via spearphishing.
what reduces it
- M1021 Restrict Web-Based Content. Administrators can block end-user consent to OAuth applications, disabling users from authorizing third-party apps through OAuth 2.0 and forcing administrative consent for all requests. They can also block end-user registration of applications by their users, to reduce risk. A Cloud Access Security Broker can also be used to ban applications.
- M1017 User Training. Users need to be trained to not authorize third-party applications they don’t recognize. The user should pay particular attention to the redirect URL: if the URL is a misspelled or convoluted sequence of words related to an expected service or SaaS application, the website is likely trying to spoof a legitimate service. Users should also be cautious about the permissions they are granting to apps.
- M1018 User Account Management. Enforce role-based access control to limit accounts to the least privileges they require. A Cloud Access Security Broker (CASB) can be used to set usage policies and manage user permissions on cloud applications to prevent access to application access tokens. In Kubernetes applications, set “automountServiceAccountToken: false” in the YAML specification of pods that do not require access to service account tokens.
- M1047 Audit. Administrators should audit all cloud and container accounts to ensure that they are necessary and that the permissions granted to them are appropriate. Additionally, administrators should perform an audit of all OAuth applications and the permissions they have been granted to access organizational data.