In today's complex landscape of modern cybersecurity, organizations and cyber-defenders must remain vigilant as adversaries continuously refine their tactics, techniques, and procedures (TTPs) to exploit vulnerabilities in applications hosted across multi-cloud environments. This blog post aims to shed light on a specific technique outlined in the MITRE ATT&CK framework: Steal Application Access Token.
The MITRE ATT&CK Cloud Matrix for Enterprise includes a broad spectrum of tactics and techniques that adversaries use in cloud environments like IaaS, Google Workspaces, and Azure AD. As shown in the Cloud Matrix image below, the Steal Application Access Token technique is used by adversaries at the Credential Access tactic phase of an attack lifecycle. This technique involves adversaries stealing application access tokens, such as account API tokens, to gain unauthorized access to remote systems and resources in cloud-based, containerized applications, and software-as-a-service (SaaS) platforms.
It is worth noting that the MITRE ATT&CK framework is continually updated to reflect the evolving cybersecurity threat landscape. Organizations and cyber-defenders must check the latest version to ensure they are using the most up-to-date technique identifiers and descriptions when developing robust defense strategies for their companies or security solution products.
An Application Access Token is a type of security token used to authenticate a user, process, or device to an application. This means that the entity in possession of the token is granted access to resources without the need for a username and password at each request. However, adversaries employ several strategies and publicly available open-source tools to exploit these tokens. They specifically target account API tokens in cloud and containerized environments, using them to access data and perform actions with the permissions of these accounts. This can lead to privilege escalation and further compromise of the environment, all to achieve their malicious objectives.
According to the blog post by Microsoft Incident Response titled "Token tactics: How to prevent, detect, and respond to cloud token theft," the adoption of new work models, such as hybrid work environments or work from home, enables employees to use personal or unmanaged devices to access company data. This work model poses a higher security risk compared to the use of organization-managed devices. It was observed that adversaries often target these employees to compromise organizational resources by replaying (manipulating) tokens issued to employee identities that have already completed multi-factor authentication.
In Kubernetes environments, processes operating inside a container often 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, gaining access to Kubernetes API commands. Similarly, in continuous development/continuous integration (CI/CD) pipelines, instances frequently use API tokens to authenticate to other services for testing and deployment purposes. If these pipelines are compromised, adversaries can steal these tokens and leverage their privileges for unauthorized actions.
OAuth is a widely-used framework that issues tokens, allowing users access to systems. It is particularly useful for applications requiring access to cloud-based services or protected APIs. OAuth 2.0 employs a variety of authorization protocols to facilitate this access. A commonly used protocol within this framework is the Microsoft's Authorization Code Grant flow. The OAuth 2.0 authorization code grant type, also known as the 'auth code flow,' enables a client application to obtain authorized access to protected resources, such as web APIs, without the need to handle user credentials directly. Instead, it uses an authorization server as an intermediary. This method enhances security by minimizing the exposure of user credentials and manipulation on tokens for authentication and authorization processes. On the other hand, adversaries can exploit these OAuth authorization token by creating a malicious application that is designed to gain access to resources using the target user's OAuth token, a method known as token theft through social engineering. To achieve this (Phishing with OAuth and o365/Azure), the adversary will first register their application with an authorization server; for example, using the Microsoft Identity Platform via options like the Azure Portal, the Visual Studio IDE, the command-line interface, PowerShell, or REST API calls. After registration, the adversary can then dispatch a spear-phishing link to the target user, enticing them to grant access to the malicious application. Once the OAuth access token is obtained, the application can potentially gain long-term access to features of the user account through an Application Access Token.
According to TechTarget blog post on “Stolen OAuth tokens lead to 'dozens' of breached GitHub repos” published 18th April 2022. GitHub disclosed that numerous organizations had their private repositories accessed due to a data breach involving stolen OAuth tokens. The breach was linked to tokens maintained by Heroku and Travis CI, but not directly stolen from GitHub as it does not store tokens in a format that could be immediately used. The security breach was first detected on April 12 when unauthorized access was noticed in GitHub's npm production infrastructure through a compromised AWS API key. This key was traced back to the stolen OAuth tokens used to access private npm repositories. GitHub has since revoked the implicated tokens, and Travis CI has reissued new keys and tokens for their customers. Travis CI also confirmed a breach of a private OAuth key from a Heroku service, although it clarified that this did not compromise any customer repositories or data. Heroku responded by revoking all compromised OAuth tokens and temporarily suspending new token issuance. Likewise, the BleepingComputer security blog provided a detailed statistical report on on the OAuth token breach.
In a blog post by CrowdStrike incident response team, it was observed that adversaries use the sts:GetFederationToken API call to create federated sessions from IAM users In AWS environments. Federated tokens which allow users to assume temporary credentials, can give users extensive permissions which can unintentionally open doors to security risks if not properly monitored. An adversary who compromises a user’s AWS API credentials will 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. These tokens allow adversaries to manipulate internal tokens and access specific application data and transaction management tokens within AWS-hosted applications.
The adversary can use the compromised federated user session to perform the following actions:
Use of AADInternals Tool to steal users’ access tokens
Adversaries can use AADInternals to steal users' access tokens via phishing emails, which involves several steps that exploit common vulnerabilities in human and system security. These attacks typically begin with a phishing email containing a malicious link. When a user clicks on this link, they are redirected to a counterfeit website that mimics a legitimate login page, such as one for Microsoft. This fake page is designed to capture the user's credentials and any session or access tokens during the login attempt. Once the attacker obtains these tokens, they can access the victim's account and associated resources, potentially without the user's knowledge. The AADInternals tool is used to automates aspects of this process, enabling adversaries to easily exploit captured tokens and credentials.
An Adversary can utilize the AADInternal Function listed on the website to retrieve or export, refresh, renew, store and manipulate access tokens from cache, SQLite database and Azure CLI.
For example, an adversary can run the command below to retrieve Azure Active Directory (ADD) Graph access token and save it to cache. The token will be valid for an hour, after that, a new access token is fetched using the refresh token.
Adversary Command Execution
# Prompt for credentials and retrieve & store access token to cache
Get-AADIntAccessTokenForAADGraph -SaveToCache
# Show the cached credentials
Get-AADIntCache
OUTPUT
Name : user@sampledomain.com
ClientId : a7c2b83f-abc5-4b49-b65a-16284ef69a04
Audience : https://graph.microsoft.com
Tenant : 77f1c1c4-e18b-41a7-b589-5d8ae4731718
IsExpired : False
HasRefreshToken : True
Name : guest@sampledomain.com
ClientId : 5e490afc-2b45-41d6-8cc0-e005fd06551f
Audience : https://management.azure.com
Tenant : 77f1c1c4-e18b-41a7-b589-5d8ae4731718
IsExpired : True
HasRefreshToken : False
Similarly, an adversary can execute the command below to get OAuth Access Token for a given client and resource.
# Get access token for MS Graph API for "Microsoft Office" client using interactive login
$at=Get-AADIntAccessToken -ClientId "b830a68f-3489-4a83-b291-cf3107b1a456" -Resource "https://graph.microsoft.com"
# Get access token and refresh token for MS Graph API for "Microsoft Office" client using interactive login and save to cache
$at=Get-AADIntAccessToken -ClientId "b830a68f-3489-4a83-b291-cf3107b1a456" -Resource "https://graph.microsoft.com"
OUTPUT
AccessToken saved to cache.
Tenant : 2b2f77e4-ada3-4fcf-bf4c-2d91a3cf60e4
User : user@company.com
Resource : https://graph.microsoft.com
Client : b830a68f-3489-4a83-b291-cf3107b1a456
2. The APT28 strategy for token theft
The APT28 threat group has been active since at least 2004 and is attributed to a variety of aliases across different cybersecurity reports and intelligence agencies, including: IRON TWILIGHT, SNAKEMACKEREL, Swallowtail, Group 74, Sednit, Sofacy, Pawn Storm, Fancy Bear, STRONTIUM, Tsar Team, Threat Group-4127, TG-4127, Forest Blizzard, and FROZENLAKE. This threat group over the years utilized various types of cyber tools and strategies, including spear-phishing emails, malware, and information-stealing trojans to compromise their targets. It was reported in Trend Micro APT & Targeted Attacks blog post titled “Pawn Storm Abuses OAuth In Social Engineering Attacks” that this APT group abused OAuth to achieve their credential phishing schemes. They utilized several rogue applications to steal user OAuth access tokens including applications masquerading as "Google Defender" "Google Email Protection," and "Google Scanner" for Gmail users. They also targeted Yahoo users with applications masquerading as "Delivery Service" and "McAfee Email Protection.
3. The APT29 strategy for for token theft
The APT29 threat group has been operating since at least 2008 and is known for targeting government networks in Europe and NATO member countries, research institutes, and think tanks. This APT group is attributed to Russia's Foreign Intelligence Service (SVR) and a variety of aliases across different cybersecurity reports and intelligence agencies, including: IRON RITUAL, IRON HEMLOCK, NobleBaron, Dark Halo, StellarParticle, NOBELIUM, UNC2452, YTTRIUM, The Dukes, Cozy Bear, CozyDuke, SolarStorm, Blue Kitsune, UNC3524 and Midnight Blizzard. In a report by “SVR cyber actors adapt tactics for initial cloud access”, the NCSC (National Cyber Security Centre) and partners observed SVR actors using stolen cloud-based access tokens to access their victims’ accounts, without the need for passwords.
4. Use of Peirates Tool to steal users’ access tokens
Adversaries can use publicly available tool on GitHub called Peirates to gathers Kubernetes service account tokens using a variety of techniques. This tool is a post-exploitation Kubernetes exploitation framework with a focus on gathering service account tokens for lateral movement and privilege escalation.
An adversary can execute the command below to automates known techniques to steal and collect service account tokens, secrets, obtain further code execution, and gain control of the cluster. The techniques include enumerating secrets from etcd, exploiting insecurely configured RBAC permissions, intercepting tokens from insecure pod communication, extracting tokens from compromised containers, and scraping tokens from Kubernetes API server logs.
$kubectl attack --techniques all --output /tmp/attack_summary.txt
OUTPUT
[INFO] Starting kubectl attack: Comprehensive Kubernetes Exploitation
[INFO] Technique 1: Enumerating secrets from etcd...
[SUCCESS] Found 42 secrets in etcd, details stored in /tmp/etcd_secrets.txt
[INFO] Technique 2: Exploiting insecurely configured RBAC permissions...
[WARNING] Detected 5 roles with excessive permissions, detailed report at /tmp/rbac_issues.txt
[INFO] Technique 3: Intercepting tokens from insecure pod communication...
[FAILURE] No insecure communications detected. Ensure to test with more network traffic.
[INFO] Technique 4: Extracting tokens from compromised containers...
[SUCCESS] Extracted tokens from 3 containers, tokens stored in /tmp/compromised_tokens.txt
[INFO] Technique 5: Scraping tokens from Kubernetes API server logs...
[SUCCESS] Scraped 12 tokens from logs, see /tmp/api_server_tokens.txt for details
[INFO] Attack summary completed. Reports are stored under /tmp/ for review.
Kubernetes Attack Summary Report
Kubernetes Attack Summary Report
---------------------------------
Technique 1: Enumerating Secrets from etcd
-----------------------------------------
- Total Secrets Found: 42
- Critical Secrets: 15
- Output File: /tmp/etcd_secrets.txt
- Action Recommended: Review and restrict access to etcd, implement encryption at rest and in transit.
Technique 2: Exploiting Insecurely Configured RBAC Permissions
--------------------------------------------------------------
- Vulnerable Roles Found: 5
- High-Risk Permissions: Pod creation, Service manipulation
- Output File: /tmp/rbac_issues.txt
- Action Recommended: Apply principle of least privilege, regularly audit roles and permissions.
Technique 3: Intercepting Tokens from Insecure Pod Communication
----------------------------------------------------------------
- Insecure Communications Detected: None
- Attempted Intercepts: 37
- Action Recommended: Implement network policies, use encrypted communication channels.
Technique 4: Extracting Tokens from Compromised Containers
---------------------------------------------------------
- Tokens Extracted: 3
- Compromised Containers: web-app-1, api-gateway, db-service
- Output File: /tmp/compromised_tokens.txt
- Action Recommended: Harden container security, use read-only filesystems where possible.
Technique 5: Scraping Tokens from Kubernetes API Server Logs
-----------------------------------------------------------
- Tokens Found in Logs: 12
- Log Source: Kubernetes API Server
- Output File: /tmp/api_server_tokens.txt
- Action Recommended: Configure logging to exclude sensitive information, monitor logs for suspicious activity.
Summary
-------
This report outlines the vulnerabilities detected and the actions recommended to secure the Kubernetes environment.
Review each technique's output and implement the suggested security measures to enhance cluster security.
Microsoft Incident Response in their blog post recommends that organizations and cyber-defenders should take a significant step toward reducing the risk of token theft by ensuring that they have full visibility of where and how their users are authenticating through enforcing location, device compliance, and session lifetime controls to all applications.
To further strengthen security posture and enhance the detection of potential unauthorized activities within Azure cloud environment, it is crucial for organizations and cyber-defenders to adopt the following detection strategies:
source == "*Azure:m365"
and workload == "AzureActiveDirectory"
and (operation == "Add app role assignment grant to user" or operation == "Consent to application")
To counteract potential threats involving the sts:GetFederationToken API call, which enables adversaries to create federated sessions within the AWS cloud environment, organizations and cyber-defenders should effectively monitor and alert on users invoking the GetFederationToken API call. This can be tracked through CloudTrail with criteria such as eventName='GetFederationToken' and eventSource='sts.amazonaws.com'. Similarly, if federated sessions are not widely used in the AWS account or organization, cyber-defenders should be vigilant for event names related to userIdentity.type='FederatedUser', which may reveal indicators of compromise.
To effectively mitigate adversaries TTPs in Stealing or manipulation Application Access Token, organizations and cyber-defenders should adopt the following mitigation strategies:
automountServiceAccountToken: false in the YAML specifications for pods that do not require access to service account tokens. This setting prevents automatic mounting of tokens and enhance security by reducing potential exposure.To mitigate the risk of adversaries abusing the sts:GetFederationToken API call to create federated sessions in AWS environment, AWS recommends the use of service control policies (SCPs) or explicit deny-all IAM policy as shown below to users based on IdP user name or revoke session token. The SCP policy will deny the users John Doe and Mary Major from accessing AWS, in member accounts, regardless of their session duration, because each action will check against their aws:userid and aws:SourceIdentity values and be denied accordingly.
SCP to deny access based on IdP user name
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Deny",
"Action": "*",
"Resource": "*",
"Condition": {
"StringLike": {
"aws:userid": [
"*:JohnDoe@example.com",
"*:MaryMajor@example.com"
]
}
}
},
{
"Effect": "Deny",
"Action": "*",
"Resource": "*",
"Condition": {
"StringEquals": {
"aws:SourceIdentity": [
"JohnDoe@example.com",
"MaryMajor@example.com"
]
}
}
}
]
}
For further reading, check out AWS detailed blog post on revoking role session tokens generated via an external identity provider that can be referenced for additional mitigation strategies.
In February 2023, Obsidian reported a notable attack trend where adversaries stole Application Access Tokens. During this incident, an attacker managed to install malware on a CircleCI employee's laptop, which went undetected by antivirus software. This malware enabled the theft of the employee's session tokens, which were secured with MFA. The compromised employee had privileged access, allowing the attacker to impersonate them remotely and escalate access to a subset of CircleCI's production systems, including access to stored GitHub tokens for customer environments. Coincidentally, on the same day, Slack reported a security breach involving one of its vendors. This breach led to the compromise of a Slack employee’s GitHub token and access to a private repository. It has not been confirmed whether this attack is related to the CircleCI incident.
Organizations and cyber-defenders can stay ahead of adversaries’ techniques to Steal Application Access Tokens by implementing robust security measures, continually monitoring their environment, and staying informed about the latest threat intelligence. Here are several strategies that can help prevent the theft and misuse of application access tokens:
In this blog post, we discuss how adversaries can adopt the Steal Application Access Token technique to manipulate application account API tokens in cloud and containerized environments. This can lead to privilege escalation and further compromise of the environment, all aimed at achieving their malicious objectives.
Arvind Sakthivel, Global Practice Head IDAM at LTI - Larsen & Toubro Infotech, provides valuable insights into countering access token theft in his LinkedIn article titled “Access Token Breach? What Next...”. It is crucial for organizations and cyber-defenders to not only familiarize themselves with these best practices for managing access tokens as, discussed in this write-up, but also to actively implement them.
Furthermore, maintaining robust visibility and management of cloud applications, alongside adopting the comprehensive detection and mitigation strategies discussed in this blog, are essential steps for security teams aiming to safeguard their digital assets. We encourage security teams and leaders to continuously update their security measures in response to evolving threats and to stay engaged with the latest in cybersecurity defense tactics using frameworks like MITRE ATT&CK.