Detecting and Mitigating Stolen Access Tokens (T1528)

Steal Application Access Token (T1528) is a Credential Access technique. Application access tokens authorize API requests on behalf of a user or a service, and they are the normal way cloud, container and SaaS applications authenticate. An adversary who steals one can act with that identity's permissions, with no password needed. MITRE lists Containers, IaaS, Identity Provider, Office Suite and SaaS as platforms.

This technique matters a lot for software teams, because tokens are everywhere in build systems and clusters.

How attackers use it

MITRE describes several places where tokens get stolen:

• Kubernetes. Processes in a container talk to the API server with service account tokens. If a container is compromised, the adversary may take the token and gain access to Kubernetes API commands.
• CI/CD pipelines. Pipeline instances often use API tokens to authenticate to other services for testing and deployment. If a pipeline is compromised, those tokens can be stolen and used with their privileges.
• Azure managed identities. An adversary who compromises a resource with an attached managed identity, such as a VM, can request short lived tokens through the Azure Instance Metadata Service. Those tokens can open further access to other Azure services.
• OAuth and social engineering. An application asks the user for consent and receives an access token that works without the user's credentials. The adversary builds a malicious application, registers it with the authorization server, and sends a spearphishing link so the target grants access. Once granted, the app may keep long term access to features of the account.

Access tokens often have a limited lifetime, but MITRE notes adversaries can also steal refresh tokens, which let them obtain new access tokens without prompting the user.

MITRE's page lists a number of tools and malware that gather CI/CD and cloud tokens, including entries that harvest tokens from pipeline solutions and repositories. The lesson is that the build and deploy path is a rich source of tokens, and that is why it is a target.

How to detect it

MITRE's detection strategy covers five scenarios:

1. Container service account tokens read, followed by unauthorized API requests with them against the Kubernetes API server or internal services.
2. Token retrieval from instance metadata endpoints such as AWS or Azure IMDS, followed by API use of that token from non standard applications.
3. An unusual OAuth app registration, followed by user granted OAuth tokens and later high privilege resource access.
4. Third party apps using OAuth tokens to access mail, calendar or SharePoint, where the token was granted recently or through spearphishing.
5. Programmatic access to user content in platforms such as Slack, GitHub and Google Workspace using stolen tokens, particularly from new IPs and apps or with excessive resource access.

Put simply, look for a token being used from somewhere it has never been used. Useful data sources: Kubernetes audit logs, cloud audit logs, identity provider sign in and consent logs, and SaaS audit logs. Alert on new OAuth app consents with broad scopes, and on a token whose source IP or user agent changes abruptly.

How to reduce the risk

MITRE lists four mitigations:

1. Restrict Web Based Content. Block end user consent to OAuth applications so admin consent is required for every request. Block end user app registration to reduce risk. A Cloud Access Security Broker can also ban applications.
2. Audit. Audit all cloud and container accounts to be sure they are necessary and hold appropriate permissions. Audit all OAuth applications and what they may access, and set a baseline so later changes stand out.
3. User Training. Teach people not to authorize third party applications they do not recognize. Look hard at the redirect URL, and be careful about the permissions an app requests.
4. User Account Management. Use role based access control for least privilege. In Kubernetes, set automountServiceAccountToken to false in the pod specification for pods that do not need access to the API.

Extra practical steps in the same spirit:

• Prefer short lived credentials from your platform over long lived static tokens.
• Keep secrets out of repositories and build logs, and scope each pipeline token to one job.
• Rotate any token you suspect was exposed, including refresh tokens.

Safeguard has a free in-browser dependency scan at gold.safeguard.sh/scan that needs no login, keeps the file on your machine and handles up to 100 dependencies. For the secrets side of this problem, the demo below shows how scanning finds credentials before they leak.

Check your own environment

A read only Kubernetes check that shows which pods have an explicit service account token setting (a blank value means the default applies):

kubectl get pods -A -o custom-columns=NS:.metadata.namespace,NAME:.metadata.name,AUTOMOUNT:.spec.automountServiceAccountToken

Then work through the list:

• Which pods really need to call the Kubernetes API?
• Who may consent to OAuth apps in your identity provider, and when was the app list last reviewed?
• Which tokens do your pipelines hold, and what can each one do?
• Do your logs tie a token to its normal source address?
• Is there a documented way to revoke and rotate tokens in a hurry?

Try it yourself

Click through it at your own pace, or open it full screen.

Quick check

Sources

• MITRE ATT&CK T1528, Steal Application Access Token