Steal Application Access Token
Application access token theft exposes delegated authority represented by tokens.
What it means
Application access token theft exposes delegated authority represented by tokens. A token can remain useful independently of the user's current password or browser session.
MITRE ATT&CK catalogs this behavior as T1528, within credential access. The technique describes a behavior; assigning the label does not by itself prove an actor identity or successful compromise.
An investigation example
An endpoint compromise is followed by API access using an application token outside its expected execution context.
Evidence to examine
Review token scope, issuer, audience, storage exposure, API access, and revocation capabilities.
A common analytical pitfall
Changing a password may not invalidate every application token already issued.
Response considerations
Revoke affected tokens and grants as appropriate, preserve access evidence, and investigate how the token became exposed.
A token carries delegated authority
A fictional reporting integration holds an access token for a document API. If that token is exposed, an unauthorized holder may exercise its granted access without knowing the user's password. The effect depends on audience, permissions, lifetime, sender constraints where present, and receiver enforcement. A token is therefore a credential with its own scope and lifecycle.
Exposure can occur in storage, logs, browser contexts, or compromised applications. Investigators should trace where the token was available and which service accepted it. Do not paste a live token into a ticket to prove the finding; use protected evidence handling and non-secret identifiers where possible.
A password reset may not invalidate an already-issued token. Review the identity provider and resource service's actual revocation behavior. Refresh capability, active sessions, and already-open connections can create separate continuing access paths. The recovery plan needs to cover the credentials the incident actually exposed.
Map a token's permitted reach
For a paper exercise, define a dummy token intended for one API with read-only access to a limited dataset. State what the holder can do, what should be rejected, and when access ends. Add a second API to show why audience validation matters.
If misuse is confirmed, examine resource access logs for consequential reads or changes while retaining appropriate privacy controls. Revoke the affected grant or credential, repair the exposure path, and verify that receivers reject continued use under the chosen policy. The key lesson is that strong original authentication does not protect a token after issuance unless storage, transmission, permissions, and revocation are also controlled.
Related concepts
References & further reading
Original explanations, with primary references for deeper study.
MITRE ATT&CK T1528: Steal Application Access Token