Applied Cybernetics Group
T1550.001 Application Access Token
- Technique
T1550.001- Tactics
- Lateral Movement
- Research, 90 days
- 1
- KEV CVEs mapped
- 0
- SigmaHQ rules
- 4
- Elastic, Splunk
- 48
- thrunt rules
- 0
- Upstream
- https://attack.mitre.org/techniques/T1550/001
MITRE description
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).(Citation: Auth0 - Why You Should Always Use Access Tokens to Secure APIs Sept 2019) 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.(Citation: okta) 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.(Citation: Microsoft Identity Platform Access 2019) With an OAuth access token an adversary can use the user-granted REST API to perform functions such as email searching and contact enumeration.(Citation: Staaldraad Phishing with OAuth 2017) 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 to 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.(Citation: Google Cloud Service Account Credentials)(Citation: AWS Temporary Security Credentials) 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.(Citation: Rhino Security Labs Enumerating AWS Roles) 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.(Citation: Crowdstrike AWS User Federation Persistence) 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.
Research citing this technique
Reports and advisories from the last 90 days that cite this technique.
-
2026-10-22Huntress: M365 Token Spray and Replay Campaign Compromises Business Email Accounts
Detection coverage
SigmaHQ community rules
- AWS Console GetSigninToken Potential Abuse (core)
- AWS STS AssumeRole Misuse (core)
- AWS STS GetSessionToken Misuse (core)
- AWS Suspicious SAML Activity (core)
Elastic and Splunk rules
- Potential Impersonation Attempt via Kubectl (elastic)
- Service Account Token or Certificate Access Followed by Kubernetes API Request (elastic)
- AWS First Occurrence of STS GetFederationToken Request by User (elastic)
- AWS Credentials Used from GitHub Actions and Non-CI/CD Infrastructure (elastic)
- AWS EC2 Instance Console Login via Assumed Role (elastic)
- AWS Lateral Movement from Kubernetes SA via AssumeRoleWithWebIdentity (elastic)
- AWS STS AssumeRole with New MFA Device (elastic)
- AWS EKS API Server Proxying Request to Kubelet (elastic)
- AWS STS Role Assumption by Service (elastic)
- AWS STS Role Assumption by User (elastic)
- AWS STS GetFederationToken with AdministratorAccess in Request (elastic)
- AWS STS Role Chaining (elastic)
- Microsoft Graph Email Access by Unusual User and Client (elastic)
- Entra ID Device-Bound PRT Replay via First-Party App from Unusual IP (elastic)
- Entra ID Device-Bound PRT from Unusual Device IP (elastic)
- Entra ID Concurrent Sign-in with Suspicious Properties (elastic)
- Azure AD Graph Access with Unusual Client and User (elastic)
- Entra ID Managed Device Client Sign-In to Graph Enumeration (elastic)
- Entra ID Actor Token User Impersonation Abuse (elastic)
- Entra ID OAuth Device Code Grant by Microsoft Authentication Broker (elastic)
- Entra ID Service Principal Federated Credential Authentication by Unusual Client (elastic)
- Entra ID OAuth Device Code Grant by Unusual User (elastic)
- Entra ID OAuth User Impersonation to Microsoft Graph (elastic)
- Entra ID Kali365 Default User-Agent Detected (elastic)
- Entra ID Microsoft Authentication Broker Sign-In to Unusual Resource (elastic)
Showing 25 of 48.