T1528: Steal Application Access Token

Application access tokens exist to solve a real problem: services and applications need to authenticate to APIs and cloud resources without prompting a human user for credentials every time. OAuth, Kubernetes service accounts, cloud instance metadata services, and CI/CD pipeline secrets all rely on token-based access for exactly this reason. The same properties that make tokens convenient for legitimate automation — they are portable, self-contained authentication credentials — make them highly valuable to adversaries who can obtain them.

T1528 is a top-tier cloud and SaaS credential access technique. Unlike password theft, which produces credentials that may be blocked by MFA, token theft delivers credentials that have already passed the authentication challenge. A stolen OAuth access token represents a completed login. A stolen Kubernetes service account token is a valid API key. A stolen Azure Managed Identity token authenticates to Azure services with no further verification required. The technique spans five platform categories in MITRE ATT&CK — SaaS, Containers, IaaS, Office Suite, and Identity Provider — reflecting how broadly token-based authentication has become the norm across modern infrastructure.

How Steal Application Access Token Works

Token theft takes different forms depending on where the tokens live and how the adversary gains access. The four primary variants address OAuth consent abuse, adversary-in-the-middle token capture, container and cloud environment token extraction, and CI/CD pipeline token compromise.

OAuth Consent Phishing (Malicious App Registration)

The adversary registers a malicious application with an OAuth authorization server — Microsoft Entra ID (Azure AD), Google Workspace, or similar — giving it a convincing name and requesting permissions that match a plausible business use case. They then deliver a spearphishing link to the target that redirects to a legitimate OAuth consent page for the fake application. If the user consents, the authorization server issues an access token and, frequently, a refresh token to the adversary's application. The access token provides immediate API access; the refresh token allows the adversary to obtain new access tokens indefinitely, even after the user's password is changed, until the refresh token is explicitly revoked or expires.

APT28 (Forest Blizzard) executed this approach against Gmail and Yahoo users, registering applications under names including "Google Defender," "Google Email Protection," and "Google Scanner." Users who consented granted APT28 long-term read access to their email without giving up their password at all.

Adversary-in-the-Middle Token Capture

Rather than waiting for a user to consent to a malicious app, adversary-in-the-middle (AiTM) phishing proxies the legitimate authentication flow in real time. A phishing page transparently forwards the victim's credentials and MFA responses to the real identity provider while capturing the resulting tokens. Tools such as Evilginx2 implement this technique by acting as a reverse proxy between the user and services like Microsoft 365. The user completes a genuine MFA challenge against the real Microsoft infrastructure — and the attacker captures the issued access and refresh tokens before they reach the user's browser. From Azure AD's perspective the authentication was fully successful; from the victim's perspective the login worked normally.

Device Code Flow Abuse

A more recent OAuth abuse variant exploits the device code authentication flow — a legitimate OAuth 2.0 mechanism designed for devices that cannot display a browser, such as smart TVs and IoT hardware. The adversary generates a device code and presents it to the target through social engineering, directing the victim to the real microsoft.com/devicelogin portal and asking them to enter the code. When the victim completes authentication (including MFA) on the legitimate Microsoft domain, the attacker polls the OAuth token endpoint and receives the resulting tokens. Because the victim authenticates against a real Microsoft URL with no spoofed pages, standard phishing indicators are absent. Multiple Russia-aligned groups including APT29 and Storm-2372 have adopted this technique extensively, with Huntress documenting a campaign in early 2026 that targeted over 340 Microsoft 365 organizations across five countries using this method.

Kubernetes Service Account Token Extraction

Kubernetes automatically mounts a service account token into every pod at /var/run/secrets/kubernetes.io/serviceaccount/token unless the pod's automountServiceAccountToken field is explicitly set to false. An adversary who compromises a container — through a vulnerability in the application, a misconfiguration, or lateral movement from another pod — can read this file and use the token to authenticate directly to the Kubernetes API server with the service account's permissions. Depending on RBAC configuration, this may allow the adversary to enumerate cluster resources, escalate privileges, or move laterally to other namespaces. The Peirates post-exploitation tool automates this process, gathering Kubernetes service account tokens using multiple techniques and enabling cluster-wide enumeration and lateral movement.

# Reading a Kubernetes service account token from within a compromised container
cat /var/run/secrets/kubernetes.io/serviceaccount/token

# Using the token to query the Kubernetes API directly
curl -H "Authorization: Bearer $(cat /var/run/secrets/kubernetes.io/serviceaccount/token)" \
     https://kubernetes.default.svc/api/v1/namespaces/default/pods

Cloud Instance Metadata Service (IMDS) Token Theft

AWS, Azure, and GCP all provide instance metadata services that allow compute resources to retrieve short-lived credentials tied to the instance's attached IAM role or Managed Identity. In Azure, any process running on a VM with an attached Managed Identity can query http://169.254.169.254/metadata/identity/oauth2/token to receive an access token scoped to the Managed Identity's permissions. An adversary who compromises the VM — through any means — can query this endpoint to obtain tokens granting access to Azure Key Vaults, Storage Accounts, and other Azure services without any stored credentials. The equivalent AWS endpoint provides temporary IAM role credentials in the same manner. IMDS tokens are short-lived by design but are trivially refreshed from the same endpoint, giving the adversary persistent access as long as they maintain a foothold on the compromised resource.

CI/CD Pipeline Token Compromise

Continuous integration and deployment pipelines authenticate to external services using API tokens stored as environment variables or secrets — to push container images, deploy to cloud environments, access code repositories, and interact with third-party APIs. If a pipeline is compromised through injection of malicious code into a build definition, poisoning of a dependency, or direct access to the pipeline configuration, an adversary can exfiltrate these tokens. CI/CD tokens frequently carry broad permissions because the pipeline needs to perform deployment operations across multiple services, making them particularly high-value targets.

Real-World Case Studies

APT29 and the SolarWinds Compromise Token Abuse

During the SolarWinds supply chain attack, APT29 (Midnight Blizzard / NOBELIUM) used token theft as a key technique for expanding and maintaining access within victim environments. After obtaining initial access through the trojanized SolarWinds Orion update, the group used token theft and API abuse to establish persistence mechanisms within Microsoft 365 and Azure tenants that, as CISA documented, were designed to survive credential resets. Rather than relying on stolen passwords — which could be rotated — APT29 obtained OAuth tokens and forged SAML tokens that provided ongoing access to cloud resources. The group's ability to move laterally within cloud environments using stolen tokens contributed to the breadth of the compromise, which affected thousands of organizations including multiple US government departments.

APT28 Malicious OAuth App Campaign

APT28 (Forest Blizzard) conducted targeted OAuth consent phishing campaigns against journalists, human rights defenders, and government officials documented by Amnesty International and Trend Micro's Pawn Storm research. The group registered applications with names designed to appear as legitimate security tools — including "Google Defender," "Google Email Protection," and "Google Scanner" — and delivered spearphishing links to target users. Victims who clicked the links and granted consent to these fake applications gave APT28 OAuth tokens providing long-term read access to their Gmail and Yahoo Mail accounts. Because the tokens granted access through legitimate API calls, the intrusion did not require continued network access or any malware running on the victim's machine, making detection particularly difficult.

APT29 Device Code Flow Phishing (2024–2026)

APT29 and associated Russia-aligned threat groups shifted heavily toward device code flow abuse against Microsoft 365 targets beginning in 2024. Amazon's threat intelligence team disrupted one campaign in which APT29 compromised legitimate websites frequently visited by targets and injected obfuscated JavaScript that redirected approximately 10% of visitors to attacker-controlled pages mimicking Cloudflare verification portals. Solving the fake CAPTCHA initiated a Microsoft device code authentication flow, with the resulting tokens captured by the attacker's infrastructure. By early 2026, Huntress documented a related campaign that reached over 340 organizations across five countries using device code phishing delivered through phishing emails that wrapped malicious URLs inside redirect services from legitimate security vendors to bypass spam filters. The authentication abuse came from a small cluster of Railway.com IP addresses.

APT29 Microsoft Corporate Network Breach (2024)

In January 2024, APT29 used a password spraying attack against a legacy Microsoft corporate account that lacked MFA to gain initial access. The targeted account had access to an OAuth application with elevated permissions in Microsoft's corporate environment. Using the stolen OAuth tokens from that application, APT29 accessed corporate mailboxes belonging to members of Microsoft's leadership team and its cybersecurity and legal departments. The attackers subsequently used authentication secrets — tokens, API keys, and credentials — found in those mailboxes to gain access to Microsoft's source code repositories and internal systems, a compromise Microsoft disclosed in March 2024. The case demonstrates how a single OAuth application with broad token scope can serve as a pivot point into high-value internal systems far beyond what the original compromised account could directly access.

Detection Strategies

Detecting T1528 requires monitoring across identity provider logs, cloud platform audit logs, and container orchestration audit logs. No single data source covers all variants — OAuth consent abuse is caught in the identity provider; IMDS access is caught in cloud platform logs; Kubernetes token abuse requires API server audit logging.

Azure / Entra ID — OAuth Consent and Anomalous Token Use

# KQL (Microsoft Sentinel): detect OAuth consent grants to non-verified apps
AuditLogs
| where OperationName == "Consent to application"
| extend AppDisplayName = tostring(TargetResources[0].displayName)
| extend ConsentedBy = tostring(InitiatedBy.user.userPrincipalName)
| extend Permissions = tostring(AdditionalDetails)
| where AppDisplayName !in (known_approved_apps)
| project TimeGenerated, ConsentedBy, AppDisplayName, Permissions
| sort by TimeGenerated desc

# KQL: detect tokens used from anomalous locations
SigninLogs
| where AuthenticationRequirement == "singleFactorAuthentication"
| where TokenIssuerType == "AzureAD"
| extend Country = tostring(LocationDetails.countryOrRegion)
| where Country !in (expected_countries)
| project TimeGenerated, UserPrincipalName, AppDisplayName, Country, IPAddress
| sort by TimeGenerated desc

Kubernetes — API Server Audit Log

# Splunk: detect reads of service account token files from unexpected processes
index=kubernetes sourcetype=audit
verb=get
requestURI="/api/v1/namespaces/*/serviceaccounts/*/token"
| where user.username != "system:serviceaccount:kube-system:*"
| stats count by user.username, requestURI, sourceIPs
| sort - count

Behavioral Indicators

Indicator	What It Means
OAuth consent grant to an application not in the approved app registry, especially with mail read or admin permissions	Possible malicious OAuth app consent phishing; legitimate enterprise apps are pre-registered and should not appear as new consent events
Token-based authentication from a new country, ASN, or IP block with no prior sign-in history for that user	Stolen token being replayed by the adversary from their own infrastructure; the token carries the user's identity but originates from an unexpected location
Access to /var/run/secrets/kubernetes.io/serviceaccount/token from a process that is not the pod's primary application	Kubernetes service account token extraction from within a compromised container; normal application code does not need to read this file directly
HTTP GET requests to 169.254.169.254/metadata/identity/oauth2/token from unexpected processes on a cloud VM	IMDS token harvesting; only processes that legitimately use the Managed Identity should access this endpoint
CI/CD pipeline environment variable access or secret retrieval outside of a scheduled build or deployment context	Possible pipeline token exfiltration; API tokens stored as pipeline secrets should only be accessed during legitimate build runs

Known Threat Actors Using T1528

Application access token theft is used across a wide range of threat actor categories, with particular concentration among nation-state actors targeting cloud-first organizations and SaaS-dependent government and enterprise environments.

• APT29 (Russia, SVR / Midnight Blizzard) — Has used OAuth token theft and SAML token forgery extensively in cloud intrusions including the SolarWinds compromise, the 2024 Microsoft corporate breach, and sustained device code flow phishing campaigns targeting Microsoft 365 tenants across government and critical infrastructure sectors.
• APT28 (Russia, GRU / Forest Blizzard) — Registered malicious OAuth applications masquerading as Google security tools to harvest Gmail and Yahoo OAuth tokens from journalists, human rights workers, and government officials targeted in spearphishing campaigns.
• Storm-2372 (Russia-aligned) — Conducted large-scale device code flow phishing campaigns against Microsoft 365 organizations across multiple countries in 2025 and 2026, abusing the OAuth device code authentication mechanism to capture tokens without credential theft.
• TeamTNT (cybercrime, cloud-focused) — Steals cloud provider credentials and API tokens from compromised cloud environments, including Kubernetes service account tokens, to expand cryptomining infrastructure across victim cloud accounts.
• Peirates operators — Peirates is an open-source Kubernetes attack tool that specifically automates service account token extraction and cluster-wide lateral movement; its use indicates targeted Kubernetes compromise.

Defensive Recommendations

1. Enforce OAuth application allow-listing and block user consent to unverified apps: Configure Azure AD / Entra ID, Google Workspace, and similar identity platforms to require administrator approval for third-party OAuth application consent, preventing users from granting access to malicious registered applications. Allow-list approved enterprise applications and block consent to applications not in the registry. Audit existing consented applications periodically and revoke permissions granted to applications no longer in use.
2. Enable Continuous Access Evaluation (CAE) and token binding where available: Microsoft's Continuous Access Evaluation terminates active sessions when risk conditions change — such as when a user account is disabled or their IP changes to a high-risk location — rather than waiting for the token to expire. CAE reduces the window an adversary has to use a stolen token. Token protection features in Entra ID bind tokens to the device on which they were issued, making stolen tokens non-replayable on other devices. Enable these features across all Microsoft 365 workloads.
3. Reduce token lifetimes and refresh token persistence: Configure access token lifetimes to the shortest interval that does not impair legitimate application functionality. For refresh tokens, consider setting shorter absolute lifetimes and sliding window expiration policies that require re-authentication after periods of inactivity. Shorter token lifetimes limit the window an adversary has to exploit stolen material.
4. Disable automounting of Kubernetes service account tokens: For pods and deployments that do not need to communicate with the Kubernetes API server, set automountServiceAccountToken: false in the pod spec. This eliminates the token from the container's file system entirely, removing the target for T1528 in the container context. Follow the NSA/CISA Kubernetes Hardening Guide for comprehensive RBAC and service account hygiene recommendations.
5. Restrict IMDS access to expected processes: On cloud VMs that use Managed Identities, apply host-based firewall rules or iptables rules that restrict access to the IMDS endpoint (169.254.169.254) to specific processes or service accounts that legitimately require it. Alert on IMDS access from any process outside the allow-list. This limits the blast radius if an adversary compromises the VM through an application vulnerability.
6. Audit and rotate CI/CD pipeline secrets regularly: Treat CI/CD API tokens as high-value credentials subject to the same lifecycle management as service account passwords. Use ephemeral, short-lived tokens generated per-run where the pipeline platform supports it (GitHub Actions OIDC, for example, eliminates the need for stored secrets entirely). Audit pipeline configuration files in source control for committed secrets and rotate any tokens that have been exposed in logs or configuration history.
7. Monitor identity provider logs for anomalous token usage patterns: Configure SIEM alerting on token use from impossible-travel scenarios, simultaneous sessions from geographically distant IP addresses, access to sensitive resources by accounts that do not normally access them, and OAuth consent grants to new applications. Identity Protection policies in Entra ID can automate risk-based responses — such as requiring step-up authentication — when anomalous token patterns are detected.

MITRE ATT&CK Mapping

Field	Value
Technique ID	T1528
Technique Name	Steal Application Access Token
Parent Technique	None (standalone technique)
Tactic	Credential Access (TA0006)
Platforms	Containers, IaaS, Identity Provider, Office Suite, SaaS
Data Sources	Web Credential: Web Credential Usage; User Account: User Account Modification; Application Log: Application Log Content
Mitigations	M1047 Audit; M1021 Restrict Web-Based Content; M1026 Privileged Account Management; M1018 User Account Management
ATT&CK Version	v18 (Last Modified: 2025)
MITRE Reference	attack.mitre.org/techniques/T1528

Frequently Asked Questions

What is T1528 Steal Application Access Token?

T1528 is a MITRE ATT&CK Credential Access technique in which adversaries steal application access tokens — OAuth tokens, Kubernetes service account tokens, cloud IMDS tokens, and CI/CD pipeline API tokens — to access remote systems and resources without needing a password. Stolen tokens allow adversaries to make authenticated API requests on behalf of the compromised user or service account, often bypassing MFA entirely.

How do adversaries steal application access tokens?

Adversaries use several approaches: malicious OAuth application consent phishing that tricks users into granting token access; adversary-in-the-middle phishing proxies that capture tokens in real time as users authenticate; reading Kubernetes service account tokens from the default mount path inside compromised containers; querying cloud instance metadata endpoints such as AWS IMDS or Azure IMDS from compromised VMs to obtain Managed Identity tokens; and compromising CI/CD pipeline environments where API tokens are stored as environment variables or secrets.

How can organizations detect stolen application access tokens?

Detection focuses on monitoring OAuth application consent events for unusual permission grants, alerting on API activity from unexpected IP addresses or geographic locations using previously issued tokens, tracking access to cloud instance metadata endpoints from unexpected processes, and reviewing CI/CD pipeline secret access logs. Identity provider sign-in logs should be correlated with device and location information to surface tokens being used outside their expected context.

Sources and References

• MITRE ATT&CK — T1528 Steal Application Access Token: attack.mitre.org
• Amnesty International — Evolving Phishing Attacks Targeting Journalists and Human Rights Defenders from the Middle-East and North Africa: amnesty.org
• Trend Micro — Pawn Storm Abuses Open Authentication in Advanced Social Engineering Attacks: trendmicro.com
• CISA / NSA — Kubernetes Hardening Guide: defense.gov
• SpecterOps — Managed Identity Attack Paths, Part 1: Automation Accounts: specterops.io
• The Hacker News — Device Code Phishing Hits 340+ Microsoft 365 Orgs Across Five Countries: thehackernews.com
• Microsoft — APT29 Gains Access to Microsoft Systems and Source Code (March 2024): microsoft.com
• InGuardians — Peirates: Kubernetes Attack Tool: github.com/inguardians