T1528: Steal Application Access Token
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).[1] Adversaries who steal account API tokens in cloud and containerized environments may be able to access data and perform actions with the permissions of these accounts, which can lead to privilege escalation and further compromise of the environment.
For example, in Kubernetes environments, processes running inside a container may communicate with the Kubernetes API server using service account tokens. If a container is compromised, an adversary may be able to steal the container’s token and thereby gain access to Kubernetes API commands.[2]
Similarly, instances within continuous-development / continuous-integration (CI/CD) pipelines will often use API tokens to authenticate to other services for testing and deployment.[3] If these pipelines are compromised, adversaries may be able to steal these tokens and leverage their privileges.
In Azure, an adversary who compromises a resource with an attached Managed Identity, such as an Azure VM, can request short-lived tokens through the Azure Instance Metadata Service (IMDS). These tokens can then facilitate unauthorized actions or further access to other Azure services, bypassing typical credential-based authentication.[4][5]
Token theft can also occur through social engineering, in which case user action may be required to grant access. OAuth is one commonly implemented framework that issues tokens to users for access to systems. An application desiring access to cloud-based services or protected APIs can gain entry using OAuth 2.0 through a variety of authorization protocols. An example commonly-used sequence is Microsoft's Authorization Code Grant flow.[6][7] An OAuth access token enables a third-party application to interact with resources containing user data in the ways requested by the application without obtaining user credentials. Adversaries can leverage OAuth authorization by constructing a malicious application designed to be granted access to resources with the target user's OAuth token.[8][9] The adversary will need to complete registration of their application with the authorization server, for example Microsoft Identity Platform using Azure Portal, the Visual Studio IDE, the command-line interface, PowerShell, or REST API calls.[10] Then, they can send a Spearphishing Link to the target user to entice them to grant access to the application. Once the OAuth access token is granted, the application can gain potentially long-term access to features of the user account through Application Access Token.[11]
Application access tokens may function within a limited lifetime, limiting how long an adversary can utilize the stolen token. However, in some cases, adversaries can also steal application refresh tokens[12], allowing them to obtain new access tokens without prompting the user.
Analyst context for executives and security teams
Stealing application access tokens matters because it can let an attacker act through trusted cloud, SaaS, identity, container, or CI/CD integrations without needing a user password. For leaders, the risk is not just credential theft; it is unauthorized API access using permissions already granted to applications, service accounts, managed identities, or OAuth consent. This can affect data access, deployment pipelines, Kubernetes control-plane access, and cloud service actions.
Executive priority
Prioritize this technique where business-critical services depend on SaaS, cloud APIs, Kubernetes, managed identities, or CI/CD automation. Key governance questions are: which tokens can access sensitive data or production systems, who can grant OAuth consent, how quickly can tokens be revoked or rotated, and whether audit evidence exists to reconstruct token use during an incident. This is especially relevant to identity and cloud security readiness because stolen tokens may bypass normal credential-based authentication controls.
Technical view
ATT&CK maps this technique to Credential Access across Containers, IaaS, Identity Provider, Office Suite, and SaaS platforms. SOC and IR teams should validate visibility into token issuance, consent grants, service account token use, managed identity token requests, API activity performed with application/service identities, and CI/CD secret exposure. The object has no official ATT&CK detection text, but a related detection strategy, DET0515, is listed; teams should treat local telemetry validation as mandatory rather than assuming coverage. Relationship context also shows relevance to Azure AD/Entra-oriented tooling, Kubernetes post-exploitation tooling, repository/CI/CD secrets discovery, and supply-chain scenarios involving repository tokens.
Likely telemetry
- Identity provider audit logs for OAuth app registration, consent grants, token issuance, refresh token activity, and application permission changes
- Cloud control-plane logs showing API actions by managed identities, service principals, service accounts, or application identities
- Azure Instance Metadata Service-related token request evidence where available from host, workload, or cloud logs
- Kubernetes audit logs for service account token use, API server requests, pod/service account bindings, and unusual access from containers
- CI/CD platform logs for secret access, pipeline job execution, repository token use, and deployment credentials
Detection direction
- Validate that detections distinguish normal automation from abnormal token use, such as new locations, unusual API calls, unexpected service identities, or access outside expected pipeline/runtime context.
- Review OAuth consent and application registration events for risky or unexpected grants, especially where user interaction can authorize third-party application access.
- Monitor Kubernetes service account activity for API calls inconsistent with the pod, namespace, or workload role normally assigned to that account.
- Correlate CI/CD job activity, repository changes, and token use because pipeline compromise can turn build/deployment credentials into broader access.
- Account for short-lived access tokens and refresh tokens separately; refresh token theft can extend access beyond the original token lifetime.
Mitigation priorities
- Start with auditing: ensure identity, cloud, Kubernetes, SaaS, and CI/CD logs record token issuance, consent, API use, and permission changes with enough retention for investigations and compliance evidence.
- Apply user account management and least privilege to application identities, service accounts, managed identities, and OAuth permissions so stolen tokens have constrained authority.
- Restrict web-based content and phishing paths where OAuth consent abuse can begin through malicious links or deceptive authorization flows.
- Use user training for scenarios requiring user consent, focusing on recognizing suspicious application authorization requests and reporting unexpected prompts.
- Establish operational procedures to revoke, rotate, or invalidate access and refresh tokens during incidents, especially for CI/CD, SaaS, cloud, and Kubernetes environments.
Analyst notes and limits
This technique is material because it sits at the intersection of identity, cloud control planes, container orchestration, SaaS authorization, and software delivery pipelines. The supplied relationships show use by multiple groups/campaigns and tools, including Azure AD/Entra administration/exploitation tooling, Kubernetes token collection tooling, and secrets-discovery tooling. Those relationships should inform threat modeling and detection validation, but they should not be interpreted as proof of activity in any specific environment.
The ATT&CK object does not provide official detection guidance, so detection recommendations are derived conservatively from the platforms, description, external references, and listed relationships. Local architecture determines which telemetry exists and which token types are in scope. No claim is made that any organization is exposed or that detection coverage is guaranteed.
Steal Application Access Token
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).[1] Adversaries who steal account API tokens in cloud and containerized environments may be able to access data and perform actions with the permissions of these accounts, which can lead to privilege escalation and further compromise of the environment.
For example, in Kubernetes environments, processes running inside a container may communicate with the Kubernetes API server using service account tokens. If a container is compromised, an adversary may be able to steal the container’s token and thereby gain access to Kubernetes API commands.[2]
Similarly, instances within continuous-development / continuous-integration (CI/CD) pipelines will often use API tokens to authenticate to other services for testing and deployment.[3] If these pipelines are compromised, adversaries may be able to steal these tokens and leverage their privileges.
In Azure, an adversary who compromises a resource with an attached Managed Identity, such as an Azure VM, can request short-lived tokens through the Azure Instance Metadata Service (IMDS). These tokens can then facilitate unauthorized actions or further access to other Azure services, bypassing typical credential-based authentication.[4][5]
Token theft can also occur through social engineering, in which case user action may be required to grant access. OAuth is one commonly implemented framework that issues tokens to users for access to systems. An application desiring access to cloud-based services or protected APIs can gain entry using OAuth 2.0 through a variety of authorization protocols. An example commonly-used sequence is Microsoft's Authorization Code Grant flow.[6][7] An OAuth access token enables a third-party application to interact with resources containing user data in the ways requested by the application without obtaining user credentials. Adversaries can leverage OAuth authorization by constructing a malicious application designed to be granted access to resources with the target user's OAuth token.[8][9] The adversary will need to complete registration of their application with the authorization server, for example Microsoft Identity Platform using Azure Portal, the Visual Studio IDE, the command-line interface, PowerShell, or REST API calls.[10] Then, they can send a Spearphishing Link to the target user to entice them to grant access to the application. Once the OAuth access token is granted, the application can gain potentially long-term access to features of the user account through Application Access Token.[11]
Application access tokens may function within a limited lifetime, limiting how long an adversary can utilize the stolen token. However, in some cases, adversaries can also steal application refresh tokens[12], allowing them to obtain new access tokens without prompting the user.
How security teams should use this page
Treat this object as behavior context, not an attribution claim. Validate the related groups, software, data sources, and mitigations against official ATT&CK relationships and your own telemetry before making control-coverage decisions.
Groups, software, and campaigns
G0016: APT29
APT29 is threat group that has been attributed to Russia's Foreign Intelligence Service (SVR).[1][2] They have operated since at least 2008, often targeting government networks in Europe and NATO member countries, research institutes, and think tanks. APT29 reportedly compromised the Democratic National Committee starting in the summer of 2015.[3][4][5][6]
In April 2021, the US and UK governments attributed the SolarWinds Compromise to the SVR; public statements included citations to APT29, Cozy Bear, and The Dukes.[7][8] Industry reporting also referred to the actors involved in this campaign as UNC2452, NOBELIUM, StellarParticle, Dark Halo, and SolarStorm.[9][10][11][12][13][14]
G0007: APT28
APT28 is a threat group that has been attributed to Russia's General Staff Main Intelligence Directorate (GRU) 85th Main Special Service Center (GTsSS) military unit 26165.[1][2] This group has been active since at least 2004.[3][4][5][6][7][8][9][10][11][12][13]
APT28 reportedly compromised the Hillary Clinton campaign, the Democratic National Committee, and the Democratic Congressional Campaign Committee in 2016 in an attempt to interfere with the U.S. presidential election.[5] In 2018, the US indicted five GRU Unit 26165 officers associated with APT28 for cyber operations (including close-access operations) conducted between 2014 and 2018 against the World Anti-Doping Agency (WADA), the US Anti-Doping Agency, a US nuclear facility, the Organization for the Prohibition of Chemical Weapons (OPCW), the Spiez Swiss Chemicals Laboratory, and other organizations.[14] Some of these were conducted with the assistance of GRU Unit 74455, which is also referred to as Sandworm Team.
S9008: Shai-Hulud
Shai-Hulud is a supply chain worm, first reported in September 2025, that spreads through code repositories, including GitHub and NPM packages. It exploits CI/CD pipeline dependencies to propagate to victims and poisons the supply chain by publishing malicious packages. Once inside a victim environment, Shai-Hulud steals credentials and access tokens from compromised repository accounts and exfiltrates them to attacker-controlled servers via encoded GitHub Actions workflows.[1][2][3][4][5][6][7]
S9009: TruffleHog
TruffleHog is an open-source secrets-discovery tool that is used to search for credentials, API keys, and encryption keys across a variety of data sources and environments.[1][2] TruffleHog has the ability to discover credentials and secrets stored in code repositories, git history, CI/CD pipelines, among other common storage locations to include filesystems and cloud storage buckets.[1][3][2] TruffleHog was first released by its author in 2016.[2]
S0683: Peirates
S0677: AADInternals
AADInternals is a PowerShell-based framework for administering, enumerating, and exploiting Azure Active Directory. The tool is publicly available on GitHub.[1][2]
C0049: Leviathan Australian Intrusions
Leviathan Australian Intrusions consisted of at least two long-term intrusions against victims in Australia by Leviathan, relying on similar tradecraft such as external service exploitation followed by extensive credential capture and re-use to enable privilege escalation and lateral movement. Leviathan Australian Intrusions were focused on exfiltrating sensitive data including valid credentials for the victim organizations.[1]
All related ATT&CK context
Mitigation direction
Object version and sync metadata
The fields below describe the current mirrored snapshot. When Glexia retains multiple ATT&CK source imports, you can open the table to compare the same object across releases (hashes and MITRE timestamps). For MITRE’s own release notes and roadmap, see ATT&CK resources — Updates .
Imported snapshots across ATT&CK releases (1)
| Release | Bundle imported | Object version | Modified | Status | Raw hash |
|---|---|---|---|---|---|
| 19.1 | 1.5 | Current bundle | bd544b763025… |
Mirrored ATT&CK source object
The raw object is retained through the mirrored ATT&CK source bundle and object hash. The raw endpoint returns the exact object from the mirrored bundle when available.
External references and citations
MITRE external references are preserved separately from Glexia analysis so citations remain traceable to their original source records.
-
[1]
Auth0 - Why You Should Always Use Access Tokens to Secure APIs Sept 2019
Auth0. (n.d.). Why You Should Always Use Access Tokens to Secure APIs. Retrieved September 12, 2019.
Open source URL -
[2]
Kubernetes Service Accounts
Kubernetes. (2022, February 26). Configure Service Accounts for Pods. Retrieved April 1, 2022.
Open source URL -
[3]
Cider Security Top 10 CICD Security Risks
Daniel Krivelevich and Omer Gil. (n.d.). Top 10 CI/CD Security Risks. Retrieved November 17, 2024.
Open source URL -
[4]
Entra Managed Identities 2025
Microsoft Entra. (2025, February 27). How to use managed identities for Azure resources on an Azure VM to acquire an access token. Retrieved March 18, 2025.
Open source URL -
[5]
SpecterOps Managed Identity 2022
Andy Robbins. (2022, June 6). Managed Identity Attack Paths, Part 1: Automation Accounts. Retrieved March 18, 2025.
Open source URL -
[6]
Microsoft Identity Platform Protocols May 2019
Microsoft. (n.d.). Retrieved September 12, 2019.
Open source URL -
[7]
Microsoft - OAuth Code Authorization flow - June 2019
Microsoft. (n.d.). Microsoft identity platform and OAuth 2.0 authorization code flow. Retrieved September 12, 2019.
Open source URL -
[8]
Amnesty OAuth Phishing Attacks, August 2019
Amnesty International. (2019, August 16). Evolving Phishing Attacks Targeting Journalists and Human Rights Defenders from the Middle-East and North Africa. Retrieved October 8, 2019.
Open source URL -
[9]
Trend Micro Pawn Storm OAuth 2017
Hacquebord, F.. (2017, April 25). Pawn Storm Abuses Open Authentication in Advanced Social Engineering Attacks. Retrieved October 4, 2019.
Open source URL -
[10]
Microsoft - Azure AD App Registration - May 2019
Microsoft. (2019, May 8). Quickstart: Register an application with the Microsoft identity platform. Retrieved September 12, 2019.
Open source URL -
[11]
Microsoft - Azure AD Identity Tokens - Aug 2019
Microsoft. (2019, August 29). Microsoft identity platform access tokens. Retrieved September 12, 2019.
Open source URL -
[12]
Auth0 Understanding Refresh Tokens
Auth0 Inc.. (n.d.). Understanding Refresh Tokens. Retrieved November 17, 2024.
Open source URL -
[13]
mitre-attack T1528Open source URL
Source: MITRE ATT&CK®. © 2026 The MITRE Corporation. This work is reproduced and distributed with the permission of The MITRE Corporation. MITRE ATT&CK and ATT&CK are registered trademarks of The MITRE Corporation. Glexia is not affiliated with or endorsed by MITRE.