Steal Application Access Token
Adversaries abuse application access tokens to gain unauthorized access to cloud, container-based, or SaaS resources, as seen in OAuth consent grant attacks.
Applications generate access tokens in order to give successfully authenticated (and authorized) users and services to APIs that allow them to perform actions within cloud resources, containers, SaaS applications, and other systems. Adversaries attempt to intercept these tokens because they need access to APIs in order to accomplish their objectives in the cloud.
OAuth application consent grant attacks are a specific variety of token theft that adversaries leverage because it allows them persistent access to resources without relying on user credentials. By tricking users into granting permissions to a malicious or compromised app, adversaries can act on the user’s behalf, bypassing traditional security controls and maintaining access even if user credentials are changed or revoked.
Both Entra ID and Google Workspace allow users to grant applications access to email, files, contacts, and other sensitive data through OAuth consent.
How do adversaries steal application access tokens?
In general, adversaries conduct adversary-in-the-middle (AitM) attacks where they steal access tokens by tricking users into disclosing their credentials by authenticating via a spoofed login page. These pages work by intercepting credentials as they are entered into the phishing page—including additional factors of authentication—and forwarding them to the adversary in real time so that they can then log into the legitimate domain. This allows the adversary to steal a token as it is issued to the user.
Adversaries also leverage stealer malware to steal both short and long-term passwords, keys, or tokens. The most recent Shai-Hulud attack is one prominent example of this, where adversaries leveraged compromised npm packages to deploy credential-stealing malware. The malware in turn used access keys stored on an infected endpoint to further enumerate cloud environments to gain access to more long-term access keys.
In the case of OAuth consent grant attacks, adversaries typically send targeted phishing emails or messages that appear to come from trusted sources, often promoting a new productivity tool or urgent business application. When users click the provided link, they are redirected to a legitimate OAuth consent screen. The screen displays the grants the malicious attacker’s app will utilize. If the user approves, the attacker gains persistent access to the permissions they agreed to.
OAuth application consent grant attack chain
OAuth application consent grant attacks are primarily a threat in Entra ID and Google Workspace environments because these platforms rely heavily on OAuth for third-party integrations and user productivity tools. Both environments allow users to grant applications access to email, files, contacts, and other sensitive data through OAuth consent.
Read our case studies on what OAuth application consent grant attacks look like on Entra ID and Google Workspace
Preventing token theft largely relies on minimizing social engineering risk, which in turn relies on user awareness programs designed to educate users about the dangers of phishing, AitM tradecraft, and more.
Other technical controls to consider:
- Audit all cloud, container, and OAuth accounts for necessity and appropriate permissions. Adhere to the principle of least privilege.
- Block end-user consent to OAuth apps; require admin approval for all OAuth requests.
- Prevent users from registering new applications; use a cloud access security broker (CASB) to ban risky apps.
- In Azure, set “Users can register applications” and “Users can consent to apps” to “no” in portal settings. Reduce the allowed permissions a user can grant a given OAuth app.
- In the Google Workspace Admin Console, navigate to the “Unconfigured third-party apps” settings. Select the option “Don’t allow users to access any third-party apps.” This action mandates that users submit access requests to administrators for any unconfigured third-party apps, allowing for proper review and approval or dismissal. Reduce the allowed permissions a user can grant a given OAuth app.
- Enforce role-based access control (RBAC) and least privilege for all accounts.
- Use a CASB to manage cloud app permissions and restrict access to application tokens.
- In Kubernetes, set
automountServiceAccountToken: falsefor pods not needing service account tokens.
Response
Remediating these threats changes upon how access tokens were stolen. In the case of an AitM attack or credential stealer malware, revoke active sessions and change the user’s password.
In the case of an OAuth application consent grant attack, then you need to identify and remove the malicious OAuth application, revoke active sessions, and change the password for all users the OAuth app was delegated to.
Tracking follow-on activity for stolen access tokens is highly dependent on the platform of origin.
SaaS apps
For SaaS application suites such as Office 365 and Google Workspace, it is important to look for signs of business email compromise. These signs will surface as things such as malicious inbox rules, internal phishing campaigns, and persistence through the enrollment of MFA devices.
Cloud platforms
For cloud platforms, it is important to quickly identify what the adversary was able to access with the access token, as the adversary may use it to achieve long-term persistence, elevate their privileges, or exfiltrate data.
Adversaries may also leverage stolen tokens to create new accounts, modify existing permissions, or deploy additional malicious applications to further entrench themselves. In some cases, adversaries use these tokens to bypass security controls, disable logging, or to tamper with audit trails to evade detection. Monitoring for unusual administrative actions, privilege escalations, and unexpected changes to security configurations is critical for early detection and response.
Note: The visibility sections in this report are mapped to MITRE ATT&CK data components.
Cloud Service Metadata and Modification
These data components will house important information about the cloud services that an adversary may try to access or manipulate after compromising after stealing an access token.
Cloud Storage Access, Creation, Metadata, and Modification
These data components will house important information about the cloud storage that an adversary may try to access or manipulate after compromising after stealing an access token.
Container Creation and Start
These data components will record logs related to the creation or starting of containers.
Web Credential Usage
Since adversaries will primarily attempt to steal credentials from users via phishing web pages or by using stealer malware that targets information stored in a browser, it may be helpful to have visibility into web credential usage.
Note: The collection sections of this report showcase specific log sources that you can use to collect relevant security information.
Cloud provider audit logs
- AWS CloudTrail
- Azure Activity Logs
- Google Cloud Audit Logs
Cloud Security Posture Management (CSPM) tools
- Wiz
- Microsoft Defender for Cloud
Storage access logs
- AWS S3 Access Logs
- Azure Storage
- Analytics, Google Cloud Storage Logs
Container orchestration logs
- Kubernetes Audit Logs
- Docker logs
Identity provider logs
- Okta
- Entra ID
- Google Workspace
In order to detect an adversary abusing a stolen token, security teams must be able to compare metadata from the legitimate authentication that generated the token to similar metadata as the token is being used. You’re looking for deviations, like if the initial login came from an expected ISP but then the token is granting access from an unusual one. The following pseudo-detector is one example of how a security team might detect stolen token use.
action = authentication
where isp = ubiquitous_isp
THEN within 1 minute
action = any_non_authentication_action
where isp = anomalous_isp
and user = same_user_as_aboveStart testing your defenses against Steal Application Access Token using Atomic Red Team—an open source testing framework of small, highly portable detection tests mapped to MITRE ATT&CK.
Getting started
The following atomics offer a great starting point for testing your defenses against adversaries who may steal application access tokens:
- T1528 atomic test number one: Inject code into Azure function
- T1528 atomic test number two: Inject code into an Azure function (RCE) to perform Subscription Privilege Escalation by retrieving the identity access token of an Azure functions instance.
Review and repeat
Now that you have executed one or several common tests and checked for the expected results, it’s useful to answer some immediate questions:
- Were any of your actions detected?
- Were any of your actions blocked or prevented?
- Were your actions visible in logs or other defensive telemetry?
Repeat this process, performing additional tests related to this technique. You can also create and contribute tests of your own.