Install any skill in seconds. Free to start, no credit card required.
Get Started Free →Adversaries can steal application access tokens as a means of acquiring credentials to access remote systems and resources.
.claude/skills/cyberstrikeus-t1528-steal-application-access-token/SKILL.md| Test case | Without → With | Effect | Δ tokens | Δ turns |
|---|---|---|---|---|
| case-07 | ✗→✓ | ▲ Improved | 94% | 0% |
| case-08 | ✗→✓ | ▲ Improved | 74% | 0% |
| case-10 | ✗→✓ | ▲ Improved | 74% | 0% |
| case-22 | ✗→✓ | ▲ Improved | 53% | 0% |
| case-18 | ✓→✓ | = Same ✓ | 85% | 0% |
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). 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.
Similarly, instances within continuous-development / continuous-integration (CI/CD) pipelines will often use API tokens to authenticate to other services for testing and deployment. 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.
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. 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. 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. 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.
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, allowing them to obtain new access tokens without prompting the user.
Platforms: SaaS, Containers, IaaS, Office Suite, Identity Provider
> Note: No Atomic Red Team tests available for this technique. See Atomic Red Team GitHub for updates.
Administrators can block end-user consent to OAuth applications, disabling users from authorizing third-party apps through OAuth 2.0 and forcing administrative consent for all requests. They can also block end-user registration of applications by their users, to reduce risk. A Cloud Access Security Broker can also be used to ban applications.
Azure offers a couple of enterprise policy settings in the Azure Management Portal that may help:
"Users -> User settings -> App registrations: Users can register applications" can be set to "no" to prevent users from registering new applications. "Enterprise applications -> User settings -> Enterprise applications: Users can consent to apps accessing company data on their behalf" can be set to "no" to prevent users from consenting to allow third-party multi-tenant applications
Administrators should audit all cloud and container accounts to ensure that they are necessary and that the permissions granted to them are appropriate. Additionally, administrators should perform an audit of all OAuth applications and the permissions they have been granted to access organizational data. This should be done extensively on all applications in order to establish a baseline, followed up on with periodic audits of new or updated applications. Suspicious applications should be investigated and removed.
Users need to be trained to not authorize third-party applications they don’t recognize. The user should pay particular attention to the redirect URL: if the URL is a misspelled or convoluted sequence of words related to an expected service or SaaS application, the website is likely trying to spoof a legitimate service. Users should also be cautious about the permissions they are granting to apps. For example, offline access and access to read emails should excite higher suspicions because adversaries can utilize SaaS APIs to discover credentials and other sensitive communications.
Enforce role-based access control to limit accounts to the least privileges they require. A Cloud Access Security Broker (CASB) can be used to set usage policies and manage user permissions on cloud applications to prevent access to application access tokens. In Kubernetes applications, set “automountServiceAccountToken: false” in the YAML specification of pods that do not require access to service account tokens.
| Finding | Severity | Impact | | --------------------------------------------------- | -------- | ----------------- | | Steal Application Access Token technique applicable | High | Credential Access |
| CWE ID | Title | | ------- | ------------------------------------ | | CWE-522 | Insufficiently Protected Credentials |
| Case | Status | Duration (ms) | Turns | Tokens | Tool calls | ||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Without | With | Δ | Without | With | Δ | Without | With | Δ | Without | With | Δ | ||
case-18 | pass→pass | 15,218 | 15,520 | +2% | 1 | 1 | 0% | 2,352 | 4,360 | +85% | 0 | 0 | — |
case-11 | pass→pass | 11,206 | 4,057 | -64% | 1 | 1 | 0% | 1,711 | 2,783 | +63% | 0 | 0 | — |
case-01 | fail→fail | 32,037 | 29,023 | -9% | 1 | 1 | 0% | 3,951 | 5,689 | +44% | 0 | 0 | — |
case-02 | fail→fail | 22,584 | 25,350 | +12% | 1 | 1 | 0% | 3,697 | 6,650 | +80% | 0 | 0 | — |
case-03 | fail→fail | 28,577 | 38,337 | +34% | 1 | 1 | 0% | 3,821 | 7,166 | +88% | 0 | 0 | — |
case-04 | fail→fail | 20,739 | 24,519 | +18% | 1 | 1 | 0% | 2,565 | 5,097 | +99% | 0 | 0 | — |
case-05 | pass→pass | 22,192 | 30,369 | +37% | 1 | 1 | 0% | 3,691 | 6,653 | +80% | 0 | 0 | — |
case-17 | pass→pass | 18,160 | 23,275 | +28% | 1 | 1 | 0% | 3,104 | 5,340 | +72% | 0 | 0 | — |
case-06 | pass→pass | 7,570 | 12,355 | +63% | 1 | 1 | 0% | 1,178 | 3,365 | +186% | 0 | 0 | — |
case-07 | fail→pass | 18,947 | 15,642 | -17% | 1 | 1 | 0% | 2,434 | 4,728 | +94% | 0 | 0 | — |
case-08 | fail→pass | 12,308 | 8,911 | -28% | 1 | 1 | 0% | 1,897 | 3,298 | +74% | 0 | 0 | — |
case-09 | pass→pass | 18,384 | 18,182 | -1% | 1 | 1 | 0% | 2,522 | 4,705 | +87% | 0 | 0 | — |
case-10 | fail→pass | 29,602 | 13,943 | -53% | 1 | 1 | 0% | 2,541 | 4,418 | +74% | 0 | 0 | — |
case-12 | pass→pass | 6,873 | 7,998 | +16% | 1 | 1 | 0% | 1,251 | 3,104 | +148% | 0 | 0 | — |
case-13 | pass→pass | 10,012 | 6,488 | -35% | 1 | 1 | 0% | 2,006 | 3,002 | +50% | 0 | 0 | — |
case-14 | pass→pass | 23,577 | 23,582 | +0% | 1 | 1 | 0% | 3,213 | 5,329 | +66% | 0 | 0 | — |
case-15 | pass→pass | 20,628 | 16,441 | -20% | 1 | 1 | 0% | 2,905 | 4,524 | +56% | 0 | 0 | — |
case-16 | pass→pass | 16,284 | 17,762 | +9% | 1 | 1 | 0% | 2,385 | 4,581 | +92% | 0 | 0 | — |
case-19 | pass→pass | 5,540 | 5,943 | +7% | 1 | 1 | 0% | 873 | 3,133 | +259% | 0 | 0 | — |
case-20 | pass→pass | 16,130 | 15,330 | -5% | 1 | 1 | 0% | 2,172 | 4,316 | +99% | 0 | 0 | — |
case-21 | pass→pass | 14,541 | 17,710 | +22% | 1 | 1 | 0% | 2,012 | 4,463 | +122% | 0 | 0 | — |
case-22 | fail→pass | 11,582 | 3,978 | -66% | 1 | 1 | 0% | 1,691 | 2,591 | +53% | 0 | 0 | — |
DecimalAI ran this skill against gemini-3.6-flash twice over the same eval suite — once with the skill loaded and once without — and compared the two runs case by case. 22 cases were attempted. The headline lift of +18 percentage points is the difference between those two pass rates over the 22 comparable cases.
Without the skill loaded, the model failed this case. With it loaded, the same prompt on the same model passed. This is one improved case from the latest verified run; every case, including any that regressed, is in the table above.
Other measured skills in the registry, with their headline benchmark lift.