Application access tokens are what cloud, container and SaaS services use to authorize API calls on behalf of a user or service. MITRE tracks their theft and use as T1550.001, Application Access Token, a Lateral Movement technique across Containers, IaaS, Identity Provider, Office Suite and SaaS.
How attackers use it
Tokens are usually stolen from users or services and used in place of login credentials. OAuth is the common framework: it verifies the user, decides what they may do, and then lets actions be authorized without passing the actual credentials around.
That design is the risk. MITRE notes that with a cloud email service, once an OAuth access token is granted to a malicious application, the application may gain long-term access to the account if a refresh token enabling background access is granted. With the token an adversary can use the REST API the user authorized for functions such as email search and contact enumeration.
Tokens can start a chain. If one gives access to a victim's primary email, the adversary may be able to reach every other service the victim uses by triggering forgotten password routines.
In AWS and GCP, MITRE notes adversaries can request a short-lived access token with the privileges of another account. If permissions are misconfigured, for example if all users may request a token for a particular account, that can give initial access to a cloud account or let privileges escalate.
Direct API access through a token negates a second authentication factor and may survive a password change. MITRE's AWS example: someone with a user's API credentials may call sts:GetFederationToken to create a federated session with the same permissions, and that session can persist even when the original credentials are deactivated.
Finally, API abuse can be hard to detect even for the provider, since it can look just like a legitimate workflow.
How to detect it
MITRE's detection strategy has an analytic for each context.
- AWS STS or GCP IAM requests for temporary tokens or federation sessions that do not fit normal activity, including from unexpected principals or regions.
- OAuth or SAML tokens reused across sessions or clients without a matching MFA or login event.
- Tokens calling APIs, for example Google Workspace or Salesforce, with no interactive login, often with unusual scopes or elevated permissions.
- OAuth token use against Exchange Online or SharePoint without a preceding login, or from unauthorized clients.
- Service account tokens mounted into containers and reused for external API calls or lateral movement across services.
How to reduce the risk
MITRE lists five mitigations.
- Account Use Policies: restrict token use outside expected contexts. In AWS, consider data perimeters to prevent credential use outside an expected network.
- Application Developer Guidance: consider token binding such as Azure AD token protection or OAuth Proof of Possession, which ties a token to a secret.
- Audit: audit all cloud and container accounts for need and for appropriate permissions. Where possible, disable the ability to request temporary tokens on behalf of other accounts. Audit reports can show role creations and policy changes that follow initial access.
- Encrypt Sensitive Information: enforce file encryption on email communications that carry sensitive information, since an email token exposes them.
- Restrict Web-Based Content: limit which third-party apps may connect to company accounts. MITRE advises being specific, with a list of pre-approved applications and everything else denied, and blocking end-user consent in admin portals so that administrators must consent.
Token hygiene in your own code matters as well. Tokens in logs, in source repositories or in container images are the easiest ones to steal, and automated checks can find them before an attacker does.
Check your own environment
- Which third-party apps hold OAuth grants against your identity provider and mail platform? Who approved each one?
- Can any user request tokens for another account in your cloud accounts? Should they?
- Do your logs let you join API calls to a login event, so token only activity stands out?
- Are tokens scanned for in code, logs and images?
Click through it at your own pace, or open it full screen.
Quick check
Why does a stolen token defeat a second authentication factor?
The token authorizes API calls directly, so the service never asks for the factor at the point of use.
Why might a federation session survive a credential being disabled?
MITRE notes that a session created through sts:GetFederationToken can persist even if the original user credentials are deactivated.
Sources
- MITRE ATT&CK, Use Alternate Authentication Material: Application Access Token: https://attack.mitre.org/techniques/T1550/001
