MITRE ATT&CK® Technique

T1550.001: Application Access Token

Adversaries may use stolen application access tokens to bypass the typical authentication process and access restricted accounts, information, or services on remote systems. These tokens are typically stolen from users or services and used in lieu of login credentials.

Application access tokens are used to make authorized API requests on behalf of a user or service and are commonly used to access resources in cloud, container-based applications, and software-as-a-service (SaaS).[1]

OAuth is one commonly implemented framework that issues tokens to users for access to systems. These frameworks are used collaboratively to verify the user and determine what actions the user is allowed to perform. Once identity is established, the token allows actions to be authorized, without passing the actual credentials of the user. Therefore, compromise of the token can grant the adversary access to resources of other sites through a malicious application.[2]

For example, with a cloud-based email service, once an OAuth access token is granted to a malicious application, it can potentially gain long-term access to features of the user account if a "refresh" token enabling background access is awarded.[3] With an OAuth access token an adversary can use the user-granted REST API to perform functions such as email searching and contact enumeration.[4]

Compromised access tokens may be used as an initial step in compromising other services. For example, if a token grants access to a victim’s primary email, the adversary may be able to extend access to all other services which the target subscribes by triggering forgotten password routines. In AWS and GCP environments, adversaries can trigger a request for a short-lived access token with the privileges of another user account.[5][6] The adversary can then use this token to request data or perform actions the original account could not. If permissions for this feature are misconfigured – for example, by allowing all users to request a token for a particular account - an adversary may be able to gain initial access to a Cloud Account or escalate their privileges.[7]

Direct API access through a token negates the effectiveness of a second authentication factor and may be immune to intuitive countermeasures like changing passwords. For example, in AWS environments, an adversary who compromises a user’s AWS API credentials may be able to use the `sts:GetFederationToken` API call to create a federated user session, which will have the same permissions as the original user but may persist even if the original user credentials are deactivated.[8] Additionally, access abuse over an API channel can be difficult to detect even from the service provider end, as the access can still align well with a legitimate workflow.

EnterpriseT1550.001Sub-techniqueObject v2.0 Modified May 12, 2026, 15:12 UTC (UTC+00:00)

Discuss defensive coverage Back to ATT&CK

Application access tokens matter because they can let an adversary use a trusted cloud, SaaS, identity, container, or office application session without repeating the normal login process. This can bypass password changes and second-factor prompts, especially when refresh tokens or short-lived cloud tokens remain valid. For leaders, the business issue is not just credential theft; it is whether API-based access to email, cloud accounts, service accounts, or SaaS data can continue unnoticed through legitimate-looking workflows.

Executive priority

Prioritize this where identity providers, SaaS platforms, office suites, IaaS, or container platforms support high-value operations. Executives should ask whether the organization can quickly identify risky token grants, revoke application access, audit API use, and prove to auditors that token lifecycle controls are reviewed. This technique is especially relevant to incident response readiness because changing a password may not remove an adversary’s access if application tokens, refresh tokens, or federated sessions remain active.

Technical view

ATT&CK maps this sub-technique to lateral movement across Containers, IaaS, Identity Provider, Office Suite, and SaaS. SOC and IR teams should validate visibility into token issuance, consent grants, refresh-token behavior, API access patterns, and cloud temporary credential requests. The supplied ATT&CK description highlights OAuth tokens, cloud email API access, AWS temporary security credentials including sts:GetFederationToken, GCP short-lived service account credentials, and Kubernetes service account token abuse through related software context. Official detection text is not provided, but ATT&CK links DET0185 as a behavioral detection strategy for this technique, so detection engineering should focus on behavior rather than static indicators.

Likely telemetry

Identity provider sign-in, OAuth consent, application grant, token issuance, refresh, and revocation logs
SaaS and Office Suite audit logs for API access, email search, contact enumeration, and application-based access to user data
Cloud control-plane audit logs for temporary credential requests, federated sessions, service account credential creation, and role/token use
Container and Kubernetes audit data showing service account token use and access to cluster resources
Application and API gateway logs showing authorized API calls made by applications or service identities

Detection direction

Validate DET0185-style behavioral coverage for unusual application token use, not only interactive logins.
Tune for token activity that diverges from normal user, service, application, location, time, or API usage patterns, while accounting for legitimate automation and integrations.
Correlate token grants and refresh activity with subsequent SaaS, cloud, and container API actions to identify access that persists after password resets or account deactivation.
Review high-risk events such as new OAuth application consent, unexpected refresh-token use, temporary cloud credential requests, or service account token use from unfamiliar contexts.
Treat lack of official ATT&CK detection guidance as a gap requiring local baselining; service-provider logs may show legitimate API workflows even when access is adversary-controlled.

Mitigation priorities

Start with auditing: ensure identity, SaaS, cloud, and container token events are logged, retained, and reviewed as required by M1047.
Enforce account use policies for token lifetime, inactivity, scope, and revocation where supported, aligning with M1036.
Apply application developer guidance to reduce insecure token handling in applications, APIs, and SDLC practices, aligning with M1013.
Encrypt sensitive information at rest, in transit, and during processing to reduce exposure if tokens or related secrets are stored or transmitted, aligning with M1041.
Restrict risky web-based content and unauthorized browser behaviors where token theft or malicious OAuth consent paths are a concern, aligning with M1021.

Analyst notes and limits

This object is a sub-technique of T1550 Use Alternate Authentication Material and is tied to lateral movement. Relationship context includes use by the SolarWinds Compromise campaign, APT28, HAFNIUM, and software such as Peirates, CreepyDrive, and Shai-Hulud, but those relationships should be used for threat-informed prioritization rather than as evidence of activity in any specific environment.

MITRE does not provide official detection text for this object in the supplied fields. The practical detection approach depends heavily on which identity providers, SaaS applications, IaaS providers, container platforms, token lifetimes, consent models, and audit logs are present locally. This summary does not assert active exploitation or existing detection coverage.

Official MITRE ATT&CK definition

Application Access Token

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.

ATT&CK relationship table

Related techniques

This mirrors the MITRE pattern of making group, software, campaign, and technique relationships scannable. Relationship notes come from mirrored ATT&CK relationship text when available.

Filter related techniques 2 rows

Domain	ID	Name	Relationship / procedure
Enterprise	T1527	Application Access Token	Application Access Token revoked by this object.
Enterprise	T1550	Use Alternate Authentication Material	This object subtechnique of Use Alternate Authentication Material.

Associated objects

Groups, software, and campaigns

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.

G0125: HAFNIUM

HAFNIUM is a likely state-sponsored cyber espionage group operating out of China that has been active since at least January 2021. HAFNIUM primarily targets entities in the US across a number of industry sectors, including infectious disease researchers, law firms, higher education institutions, defense contractors, policy think tanks, and NGOs. HAFNIUM has targeted remote management tools and cloud software for intial access and has demonstrated an ability to quickly operationalize exploits for identified vulnerabilities in edge devices.[1][2][3]

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

S1023: CreepyDrive

CreepyDrive is a custom implant has been used by POLONIUM since at least early 2022 for C2 with and exfiltration to actor-controlled OneDrive accounts.[1]

POLONIUM has used a similar implant called CreepyBox that relies on actor-controlled DropBox accounts.[1]

WindowsOffice Suite

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

C0024: SolarWinds Compromise

The SolarWinds Compromise was a sophisticated supply chain cyber operation conducted by APT29 that was discovered in mid-December 2020. APT29 used customized malware to inject malicious code into the SolarWinds Orion software build process that was later distributed through a normal software update; they also used password spraying, token theft, API abuse, spear phishing, and other supply chain attacks to compromise user accounts and leverage their associated access. Victims of this campaign included government, consulting, technology, telecom, and other organizations in North America, Europe, Asia, and the Middle East. This activity has been labled the StellarParticle campaign in industry reporting.[1] Industry reporting also initially referred to the actors involved in this campaign as UNC2452, NOBELIUM, Dark Halo, and SolarStorm.[2][3][4][5][1][6][7][8]

In April 2021, the US and UK governments attributed the SolarWinds Compromise to Russia's Foreign Intelligence Service (SVR); public statements included citations to APT29, Cozy Bear, and The Dukes.[9][10][11] The US government assessed that of the approximately 18,000 affected public and private sector customers of Solar Winds’ Orion product, a much smaller number were compromised by follow-on APT29 activity on their systems.[12]

Relationship explorer

All related ATT&CK context

detects · Detection Strategy DET0185: Behavioral Detection Strategy for Use Alternate Authentication Material: Application Access Token (T1550.001) Enterprise revoked by · Technique T1527: Application Access Token Enterprise uses · Tool S0683: Peirates Enterprise mitigates · Mitigation M1036: Account Use Policies Enterprise uses · Malware S1023: CreepyDrive Enterprise subtechnique of · Technique T1550: Use Alternate Authentication Material Enterprise uses · Campaign C0024: SolarWinds Compromise Enterprise mitigates · Mitigation M1047: Audit Enterprise mitigates · Mitigation M1021: Restrict Web-Based Content Enterprise mitigates · Mitigation M1013: Application Developer Guidance Enterprise uses · Group G0007: APT28 Enterprise uses · Group G0125: HAFNIUM Enterprise uses · Malware S9008: Shai-Hulud Enterprise mitigates · Mitigation M1041: Encrypt Sensitive Information Enterprise

Mitigations

Mitigation direction

M1036: Account Use Policies

Account Use Policies help mitigate unauthorized access by configuring and enforcing rules that govern how and when accounts can be used. These policies include enforcing account lockout mechanisms, restricting login times, and setting inactivity timeouts. Proper configuration of these policies reduces the risk of brute-force attacks, credential theft, and unauthorized access by limiting the opportunities for malicious actors to exploit accounts. This mitigation can be implemented through the following measures:

Account Lockout Policies:

- Implementation: Configure account lockout settings so that after a defined number of failed login attempts (e.g., 3-5 attempts), the account is locked for a specific time period (e.g., 15 minutes) or requires an administrator to unlock it. - Use Case: This prevents brute-force attacks by limiting how many incorrect password attempts can be made before the account is temporarily disabled, reducing the likelihood of an attacker successfully guessing a password.

- Implementation: Set up login time policies to restrict when users or groups can log into systems. For example, only allowing login during standard business hours (e.g., 8 AM to 6 PM) for non-administrative accounts. - Use Case: This prevents unauthorized access outside of approved working hours, where login attempts might be more suspicious or harder to monitor. For example, if an account that is only supposed to be active during the day logs in at 2 AM, it should raise an alert or be blocked.

Inactivity Timeout and Session Termination:

- Implementation: Enforce session timeouts after a period of inactivity (e.g., 10-15 minutes) and require users to re-authenticate if they wish to resume the session. - Use Case: This policy prevents attackers from hijacking active sessions left unattended. For example, if an employee walks away from their computer without locking it, an attacker with physical access to the system would be unable to exploit the session.

Password Aging Policies:

- Implementation: Enforce password aging rules, requiring users to change their passwords after a defined period (e.g., 90 days) and ensure passwords are not reused by maintaining a password history. - Use Case: This limits the risk of compromised passwords being used indefinitely. Regular password changes make it more difficult for attackers to reuse stolen credentials.

Account Expiration and Deactivation:

- Implementation: Configure user accounts, especially for temporary or contract workers, to automatically expire after a set date or event. Accounts that remain unused for a specific period should be deactivated automatically. - Use Case: This prevents dormant accounts from becoming an attack vector. For example, an attacker can exploit unused accounts if they are not properly monitored or deactivated.

**Tools for Implementation**:

- Group Policy Objects (GPOs) in Windows: To enforce account lockout thresholds, login time restrictions, session timeouts, and password policies. - Identity and Access Management (IAM) solutions: For centralized management of user accounts, session policies, and automated deactivation of accounts. - Security Information and Event Management (SIEM) platforms: To monitor and alert on unusual login activity, such as failed logins or out-of-hours access attempts. - Multi-Factor Authentication (MFA) Tools: To further enforce secure login attempts, preventing brute-force or credential stuffing attacks.

M1047: Audit

Auditing is the process of recording activity and systematically reviewing and analyzing the activity and system configurations. The primary purpose of auditing is to detect anomalies and identify potential threats or weaknesses in the environment. Proper auditing configurations can also help to meet compliance requirements. The process of auditing encompasses regular analysis of user behaviors and system logs in support of proactive security measures.

Auditing is applicable to all systems used within an organization, from the front door of a building to accessing a file on a fileserver. It is considered more critical for regulated industries such as, healthcare, finance and government where compliance requirements demand stringent tracking of user and system activates.This mitigation can be implemented through the following measures:

System Audit:

- Use Case: Regularly assess system configurations to ensure compliance with organizational security policies. - Implementation: Use tools to scan for deviations from established benchmarks.

Permission Audits:

- Use Case: Review file and folder permissions to minimize the risk of unauthorized access or privilege escalation. - Implementation: Run access reviews to identify users or groups with excessive permissions.

Software Audits:

- Use Case: Identify outdated, unsupported, or insecure software that could serve as an attack vector. - Implementation: Use inventory and vulnerability scanning tools to detect outdated versions and recommend secure alternatives.

Configuration Audits:

- Use Case: Evaluate system and network configurations to ensure secure settings (e.g., disabled SMBv1, enabled MFA). - Implementation: Implement automated configuration scanning tools like SCAP (Security Content Automation Protocol) to identify non-compliant systems.

Network Audits:

- Use Case: Examine network traffic, firewall rules, and endpoint communications to identify unauthorized or insecure connections. - Implementation: Utilize tools such as Wireshark, or Zeek to monitor and log suspicious network behavior.

M1021: Restrict Web-Based Content

Restricting web-based content involves enforcing policies and technologies that limit access to potentially malicious websites, unsafe downloads, and unauthorized browser behaviors. This can include URL filtering, download restrictions, script blocking, and extension control to protect against exploitation, phishing, and malware delivery. This mitigation can be implemented through the following measures:

Deploy Web Proxy Filtering:

- Use solutions to filter web traffic based on categories, reputation, and content types. - Enforce policies that block unsafe websites or file types at the gateway level.

Enable DNS-Based Filtering:

- Implement tools to restrict access to domains associated with malware or phishing campaigns. - Use public DNS filtering services to enhance protection.

Enforce Content Security Policies (CSP):

- Configure CSP headers on internal and external web applications to restrict script execution, iframe embedding, and cross-origin requests.

Control Browser Features:

- Disable unapproved browser features like automatic downloads, developer tools, or unsafe scripting. - Enforce policies through tools like Group Policy Management to control browser settings.

Monitor and Alert on Web-Based Threats:

- Use SIEM tools to collect and analyze web proxy logs for signs of anomalous or malicious activity. - Configure alerts for access attempts to blocked domains or repeated file download failures.

M1013: Application Developer Guidance

Application Developer Guidance focuses on providing developers with the knowledge, tools, and best practices needed to write secure code, reduce vulnerabilities, and implement secure design principles. By integrating security throughout the software development lifecycle (SDLC), this mitigation aims to prevent the introduction of exploitable weaknesses in applications, systems, and APIs. This mitigation can be implemented through the following measures: Preventing SQL Injection (Secure Coding Practice):

- Implementation: Train developers to use parameterized queries or prepared statements instead of directly embedding user input into SQL queries. - Use Case: A web application accepts user input to search a database. By sanitizing and validating user inputs, developers can prevent attackers from injecting malicious SQL commands.

Cross-Site Scripting (XSS) Mitigation:

- Implementation: Require developers to implement output encoding for all user-generated content displayed on a web page. - Use Case: An e-commerce site allows users to leave product reviews. Properly encoding and escaping user inputs prevents malicious scripts from being executed in other users’ browsers.

Secure API Design:

- Implementation: Train developers to authenticate all API endpoints and avoid exposing sensitive information in API responses. - Use Case: A mobile banking application uses APIs for account management. By enforcing token-based authentication for every API call, developers reduce the risk of unauthorized access.

Static Code Analysis in the Build Pipeline:

- Implementation: Incorporate tools into CI/CD pipelines to automatically scan for vulnerabilities during the build process. - Use Case: A fintech company integrates static analysis tools to detect hardcoded credentials in their source code before deployment.

Threat Modeling in the Design Phase:

- Implementation: Use frameworks like STRIDE (Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, Elevation of Privilege) to assess threats during application design. - Use Case: Before launching a customer portal, a SaaS company identifies potential abuse cases, such as session hijacking, and designs mitigations like secure session management.

**Tools for Implementation**:

- Static Code Analysis Tools: Use tools that can scan for known vulnerabilities in source code. - Dynamic Application Security Testing (DAST): Use tools like Burp Suite or OWASP ZAP to simulate runtime attacks and identify vulnerabilities. - Secure Frameworks: Recommend secure-by-default frameworks (e.g., Django for Python, Spring Security for Java) that enforce security best practices.

M1041: Encrypt Sensitive Information

Protect sensitive information at rest, in transit, and during processing by using strong encryption algorithms. Encryption ensures the confidentiality and integrity of data, preventing unauthorized access or tampering. This mitigation can be implemented through the following measures:

Encrypt Data at Rest:

- Use Case: Use full-disk encryption or file-level encryption to secure sensitive data stored on devices. - Implementation: Implement BitLocker for Windows systems or FileVault for macOS devices to encrypt hard drives.

Encrypt Data in Transit:

- Use Case: Use secure communication protocols (e.g., TLS, HTTPS) to encrypt sensitive data as it travels over networks. - Implementation: Enable HTTPS for all web applications and configure mail servers to enforce STARTTLS for email encryption.

Encrypt Backups:

- Use Case: Ensure that backup data is encrypted both during storage and transfer to prevent unauthorized access. - Implementation: Encrypt cloud backups using AES-256 before uploading them to Amazon S3 or Google Cloud.

Encrypt Application Secrets:

- Use Case: Store sensitive credentials, API keys, and configuration files in encrypted vaults. - Implementation: Use HashiCorp Vault or AWS Secrets Manager to manage and encrypt secrets.

Database Encryption:

- Use Case: Enable Transparent Data Encryption (TDE) or column-level encryption in database management systems. - Implementation: Use MySQL’s built-in encryption features to encrypt sensitive database fields such as social security numbers.

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: 2.0
Created: Jan 30, 2020, 17:37 UTC (UTC+00:00)
Modified: May 12, 2026, 15:12 UTC (UTC+00:00)
Raw hash: e1314ba71f1971fc...

Imported snapshots across ATT&CK releases (1)

Release	Bundle imported	Object version	Modified	Status	Raw hash
19.1	May 18, 2026, 07:08 UTC (UTC+00:00)	2.0	May 12, 2026, 15:12 UTC (UTC+00:00)	Current bundle	`e1314ba71f19…`

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.

Open mirrored raw JSON Open MITRE-hosted copy

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]
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]
okta

okta. (n.d.). What Happens If Your JWT Is Stolen?. Retrieved September 12, 2019.
Open source URL
[3]
Microsoft Identity Platform Access 2019

Cai, S., Flores, J., de Guzman, C., et. al.. (2019, August 27). Microsoft identity platform access tokens. Retrieved October 4, 2019.
Open source URL
[4]
Staaldraad Phishing with OAuth 2017

Stalmans, E.. (2017, August 2). Phishing with OAuth and o365/Azure. Retrieved October 4, 2019.
Open source URL
[5]
Google Cloud Service Account Credentials

Google Cloud. (2022, March 31). Creating short-lived service account credentials. Retrieved April 1, 2022.
Open source URL
[6]
AWS Temporary Security Credentials

AWS. (n.d.). Requesting temporary security credentials. Retrieved April 1, 2022.
Open source URL
[7]
Rhino Security Labs Enumerating AWS Roles

Spencer Gietzen. (2018, August 8). Assume the Worst: Enumerating AWS Roles through ‘AssumeRole’. Retrieved April 1, 2022.
Open source URL
[8]
Crowdstrike AWS User Federation Persistence

Vaishnav Murthy and Joel Eng. (2023, January 30). How Adversaries Can Persist with AWS User Federation. Retrieved March 10, 2023.
Open source URL
[9]
mitre-attack T1550.001
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.

Official MITRE ATT&CK site Official STIX data repository MITRE ATT&CK terms of use