MITRE ATT&CK T1528 Steal Application Access Token Guide: Detecting OAuth Token Theft

A stolen application access token lets an attacker call cloud and SaaS APIs with someone else's permissions, without a password and usually without triggering MFA. MITRE ATT&CK tracks this as T1528 Steal Application Access Token in the Credential Access tactic (TA0006), on the Containers, IaaS, Identity Provider, Office Suite and SaaS platforms. This guide explains how the technique works in ATT&CK v20, where tokens are taken from, what to log and alert on, and which controls make a stolen token worth less. It is written for detection engineers, identity and cloud security teams, and SaaS administrators. For the response once a token theft is confirmed, use the OAuth Token Theft Incident Playbook.

Key takeaways

• Two routes, one outcome. T1528 covers both tricking a user into granting a token to a malicious app (consent phishing) and lifting tokens already issued to workloads, pipelines and integrations. It sits alongside the techniques in our Top 10 Identity Attacks.
• The token is the session. Access tokens and refresh tokens are bearer credentials: whoever holds them is treated as the user or app, so password resets alone do not end the access.
• Refresh tokens are the real prize. ATT&CK notes that stolen refresh tokens let an adversary obtain new access tokens without prompting the user, turning a one-hour window into weeks.
• Detect grants and use, not just sign-ins. Consent events, new app credentials and token use from unfamiliar client IDs, IP ranges or user agents are the signals; interactive sign-in logs often show nothing.
• Make stolen tokens worth less. Restrict user consent, scope and audience-restrict tokens, shorten lifetimes, sender-constrain tokens (mTLS, DPoP, device binding) and keep a tested revocation path.

How the attack works

ATT&CK v20 (technique version 1.5, last modified 12 May 2026) defines T1528 as adversaries stealing application access tokens to acquire credentials for remote systems and resources. Application access tokens authorise API requests on behalf of a user or service, which is why they are the currency of cloud, container and SaaS access. T1528 has no sub-techniques. It pairs with T1550.001 Application Access Token (Lateral Movement), which is the use of the stolen token.

Route 1: consent phishing (user action required)

1. The adversary registers an application with an authorisation server such as the Microsoft identity platform, often with a name and logo that imitate a trusted service.
2. A T1566.002 Spearphishing Link sends the target to a genuine consent page that asks for scopes such as mail read and offline access.
3. The user approves. The authorisation server issues tokens to the attacker's app through a normal OAuth 2.0 flow, such as the authorisation code grant.
4. The app uses the access token, and the refresh token where granted, to read mail, files or chat through the provider's APIs. No password is captured and MFA has already been satisfied by the user.

A variant abuses the OAuth device authorisation grant: the attacker starts a device code request and persuades the victim to enter the code. ATT&CK v20 records the Kali365 kit obtaining access and refresh tokens this way. See the Device Code Phishing Guide and the Consent Phishing and Illicit OAuth Grants Guide.

Route 2: harvesting tokens already issued

• Containers: a process in a compromised pod reads the mounted Kubernetes service account token and calls the API server with it.
• IaaS: an attacker on an Azure VM with a managed identity requests short-lived tokens from the Instance Metadata Service (IMDS); the AWS equivalent yields temporary role credentials.
• CI/CD: runners hold API tokens for deployment; ATT&CK v20 records TeamPCP Cloud Stealer reading runner process memory for plaintext tokens and the Shai-Hulud and Mini Shai-Hulud worms stealing pipeline and repository tokens.
• SaaS integrations: an integration vendor's infrastructure stores OAuth tokens for thousands of customer tenants, so one breach there yields tokens for all of them.

Where it shows up

Named users of T1528 in ATT&CK v20 include APT29 (G0016), APT28 (G0007), which used malicious OAuth apps masquerading as Google security tools, and ShinyHunters (G1057). The CISA and partner advisory on SVR cloud access states that APT29 used system-issued access tokens to reach accounts without needing a password.

Impact

• Data access that looks legitimate: API reads of mail and files under a valid token often map to T1114.002 Remote Email Collection and T1213 Data from Information Repositories, with no malware on any endpoint.
• Persistence that survives password resets: a consented app keeps its grant, and refresh tokens keep minting access tokens until revoked.
• Privilege escalation in cloud and Kubernetes: a workload token is often far more privileged than the workload needs, and ATT&CK notes this can lead to further compromise of the environment.
• Supply-chain blast radius: in the Salesloft Drift breach, OAuth tokens taken from Drift's AWS environment were used between 8 and 18 August 2025 to export Salesforce data from hundreds of customer tenants, and the actor then searched that data for further AWS keys and Snowflake tokens.

Detection

ATT&CK v20 maps one detection strategy, DET0515, with an analytic per platform. The table turns each into concrete events. Correlate grant or retrieval with subsequent use, because either alone is noisy.

High-value alert rules

• Consent with risky scopes: any user consent that includes offline access plus mail, file or chat read. ATT&CK's user training guidance singles out offline access and mail read as the scopes that should raise suspicion.
• New app, fast data access: a service principal first seen in the last 7 days that reads many mailboxes or exports records.
• Token replay from the wrong place: the same app or refresh token used from two networks or autonomous systems within a short window, or from hosting providers when the integration normally calls from fixed egress IPs.
• Credentials added to an existing app: new secrets or certificates on a service principal outside change windows, which overlaps with T1098.001 Additional Cloud Credentials.
• Workload token used off-workload: a Kubernetes or managed identity token presented from an IP outside the cluster or VNet.
• Canary identities: CISA recommends canary service accounts that legitimate services never use; any token issued to or used by one is a high-fidelity alert.

Metrics that show it is working

• Share of OAuth apps with an owner, a business justification and a review in the last 90 days.
• Number of user-consented grants with high-risk scopes, trending to zero.
• Median time from a suspicious consent alert to grant revocation and session revocation.
• Percentage of SaaS and IdP token-use logs actually ingested by the SIEM, per platform in the table above.
• Percentage of pods running with automountServiceAccountToken: false where no API access is needed.

Prevention and hardening

Phased rollout

1. Inventory (weeks 1 to 2): export every OAuth app, its grants, publisher status and last use from each IdP and major SaaS platform. Flag apps with mail, file or offline access scopes and no owner.
2. Log and alert (weeks 2 to 4): ingest the audit events in the detection table and deploy the consent and new-credential rules before changing any policy, so you see the baseline.
3. Restrict consent in report mode (month 2): move to verified-publisher, low-impact consent with an admin consent workflow; in Google Workspace, set high-risk services to Restricted for one organisational unit first. Watch the request queue for two to four weeks.
4. Enforce and clean up (month 3): extend the restriction tenant-wide, revoke unowned or unused grants, and block device code flow, starting each Conditional Access policy in Report-only mode.
5. Bind and shorten (months 3 to 6): pilot token protection or DPoP-capable clients, rotate refresh tokens, and disable token automount on workloads.
6. Rollback: keep the previous consent policy assignment and Conditional Access policy definitions exported; reverting is a policy change, and revoked grants can be restored from the documented restore procedure if a business-critical app was cut off.

Small vs large organisations: a small tenant can usually disable user consent outright and approve the handful of apps it needs. Large estates with thousands of grants should use permission classification and the admin consent workflow so that low-risk sign-in scopes stay self-service while data-access scopes go to review. See the Token and Session Security Guide for lifetime design.

Lessons from incidents

• Legacy apps keep dangerous grants: in the Microsoft Midnight Blizzard breach, a password-sprayed test tenant account led to a legacy test OAuth app with elevated access, which the actor used to grant malicious apps the Exchange Online full_access_as_app role and read corporate mailboxes.
• Integration vendors concentrate tokens: the Salesloft Drift case shows one vendor's token store opening hundreds of customer tenants; customers had to revoke and treat every Drift-connected token as compromised.
• Consent on a trusted brand: the Cyberhaven Chrome extension breach began with an email impersonating a Chrome Web Store policy notice; an employee approved a genuine Google consent screen for a malicious app, which received a token with extension publishing rights and no MFA prompt.
• Pipelines leak tokens at scale: the Shai-Hulud npm worm, listed under T1528 in ATT&CK v20, stole CI/CD and repository tokens and reused them to spread.
• Resetting the password is not containment: in every case above the fix was revoking grants and tokens and rotating app credentials, not changing user passwords.

Framework mapping

Practitioner checklist

• Export every OAuth app and grant in your IdP and top SaaS platforms, with owner, scopes and last use.
• Restrict user consent to verified publishers and low-impact permissions, with an admin consent workflow.
• Block or restrict high-risk scopes (mail, files, offline access) for unreviewed apps.
• Ingest consent, app credential and service principal sign-in events and alert on the rules above.
• Block device code flow by Conditional Access except for documented exceptions.
• Disable service account token automount on pods that do not need the Kubernetes API.
• Pilot sender-constrained tokens (device binding, DPoP or mTLS) for the most sensitive resources.
• Rehearse revocation: grant removal, refresh token revocation and app credential rotation, timed end to end.
• Ask integration vendors how they store your OAuth tokens and how fast they can revoke them.

Standards and references

• MITRE ATT&CK: Steal Application Access Token (T1528)
• MITRE ATT&CK: Use Alternate Authentication Material: Application Access Token (T1550.001)
• IETF: RFC 9700 Best Current Practice for OAuth 2.0 Security
• CISA: SVR Cyber Actors Adapt Tactics for Initial Cloud Access
• Microsoft Learn: Configure how users consent to applications
• Microsoft Learn: Review permissions granted to enterprise applications
• Microsoft Learn: Token protection in Conditional Access
• Google Workspace: Control which third-party and internal apps access Google Workspace data

Related NHI Mgmt Group resources: OAuth Token Theft Incident Playbook · Consent Phishing and Illicit OAuth Grants Guide · SaaS and OAuth App Governance Guide · DPoP Guide · MITRE ATT&CK Guide for Defenders