Live Active security incident? Get immediate response
MITRE ATT&CK® Technique

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.

EnterpriseT1528TechniqueObject v1.5 Modified
Glexia's Take

Analyst context for executives and security teams

Analyst confidence High

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.

Official MITRE ATT&CK definition

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.

View the same entry on attack.mitre.org (MITRE-hosted reference; in-page links above use the Glexia ATT&CK library.)

Glexia analysis

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.

Associated objects

Groups, software, and campaigns

Group Enterprise

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]

Group Enterprise

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.

Malware Enterprise

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]

LinuxSaaSWindows
Tool Enterprise

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]

IaaSLinuxSaaS
Tool Enterprise

S0683: Peirates

Peirates is a post-exploitation Kubernetes exploitation framework with a focus on gathering service account tokens for lateral movement and privilege escalation. The tool is written in GoLang and publicly available on GitHub.[1]

Containers
Tool Enterprise

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]

WindowsOffice SuiteIdentity Provider
Campaign Enterprise

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]

Relationship explorer

All related ATT&CK context

Mitigations

Mitigation direction

Change history

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 .

ATT&CK release
19.1
Object version
1.5
Created
Modified
Raw hash
bd544b763025ad07...
Imported snapshots across ATT&CK releases (1)
Release Bundle imported Object version Modified Status Raw hash
19.1 1.5 Current bundle bd544b763025…
Raw source

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.

Source references

External references and citations

MITRE external references are preserved separately from Glexia analysis so citations remain traceable to their original source records.

  1. [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. [2]
    Kubernetes Service Accounts

    Kubernetes. (2022, February 26). Configure Service Accounts for Pods. Retrieved April 1, 2022.

    Open source URL
  3. [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. [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. [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. [6]
    Microsoft Identity Platform Protocols May 2019

    Microsoft. (n.d.). Retrieved September 12, 2019.

    Open source URL
  7. [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. [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. [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. [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. [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. [12]
    Auth0 Understanding Refresh Tokens

    Auth0 Inc.. (n.d.). Understanding Refresh Tokens. Retrieved November 17, 2024.

    Open source URL
  13. [13]
    mitre-attack T1528
    Open source URL
Source and licensing

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.