Details

• ID: CM0080
• Version: 1.0
• Created: 14 March 2025
• Modified: 14 March 2025
• Type: Disable, Refresh
• Status: Active

Intended Outcome

Blocking and reissuing tokens blocks adversary persistence and lateral movement using tokens.

Introduction

A token is an authorization file that is generated by a server and stored client-side. Tokens are often used for authentication, authorization, and for storing user preferences or session information. Tokens can either be "stateful" -- stored in a server-side database and sent to the client to be stored in a browser cookie (e.g., session IDs) -- or more commonly "stateless" and only stored in client-side data structures (e.g., JSON Web Tokens and opaque bearer tokens such as access tokens.)Adversaries can steal tokens used for stateful authentication by compromising a server and accessing session information stored in the server's database. However, because HTTP is inherently stateless, adversaries most often steal stateless tokens by compromising the client machine and performing "pass-the-cookie" attacks. For this reason, stateless tokens should be securely kept in cookies with the HttpOnly attribute to mitigate theft.An adversary that steals a token will be able to circumvent multi-factor authentication (MFA) to hijack a user account and impersonate a user, issuing fraudulent authenticated API calls. In doing so, an adversary may be able to access resources in cloud and container-based applications and software-as-a-service (SaaS).

Preparation

• Verify suspicious activity of the potentially compromised user account by reviewing user and machine logs.
• Utilize Microsoft's investigation checklist for suspicious activities and Microsoft Entra ID Protection (formerly Azure Active Directory) alerts.

Risks

• Reissuing tokens may disrupt legitimate sessions.

Guidance

If an organization suspects that a token associated with a hijacked account was stolen, they should immediately do the following.

1. Revoke compromised tokens or update revocation list. If the compromised account uses stateful authentication, any database records containing session information of the compromised user account should immediately be invalidated.
If access was granted using a stateless token (e.g., JWTs) they will not be stored in any server-side database and therefore cannot be invalidated. However, the refresh token used to sign the access token may be invalidated if stored server-side by using a revocation list (aka token deny list) on the server. Refresh tokens stored server-side may also be rotated, invalidating old refresh tokens and issuing new ones. Performing both actions to refresh tokens may temporarily disrupt the adversary when they request a new signed access token.
2. Force a password reset and consider disabling compromised account: By resetting an account's password and requiring the user set a new password, an adversary that has hijacked the session and modified the user's login credentials for access will be unable to use their credentials for access. This is a temporary solution, as an adversary who still has the ability to steal JWT may be able to perform credential modification again. Implementing multi-factor authentication may further slow the adversary. Disabling the account will inhibit the ability of the adversary to perform actions with the compromised user account.
3. Identify the expiration timeline of the token and shorten the duration of subsequent tokens. Short-lived tokens are advisable over long-term tokens. If a short-lived token is compromised, the time-window that an attacker will be able to use the stolen token will be narrowed. Incident response teams should review the life of tokens and reduce the duration of subsequent tokens if deemed necessary. Reducing the duration of stateless tokens to a shorter length of time (e.g., 5 minutes) may slow the adversary, as they will need to re-steal subsequent tokens. However, if an adversary manages to steal one, chances are they will be able to perform the theft again.
4. Trace source of attack: An adversary that can steal tokens has either compromised a client or server environment. As part of incident response, teams will need to identify the source of compromise, and whether the compromised account was part of a larger supply-chain compromise if authentication is provided by a provider.
5. Remove malicious changes introduced or used by the adversary. An adversary that gains access to a user account via token theft may have added malicious email rules or misconfigured MFA with new devices. To respond to these actions, see CM0082: Audit/Remove Suspicious Email Forwarding Rules and CM0071: Unenroll Suspicious Multifactor Authentication (MFA) Device from Microsoft User Account.

References

• What Happens If Your JWT Is Stolen? | https://developer.okta.com/blog/2018/06/20/what-happens-if-your-jwt-is-stolen
• Token tactics: How to prevent, detect, and respond to cloud token theft | https://www.microsoft.com/en-us/security/blog/2022/11/16/token-tactics-how-to-prevent-detect-and-respond-to-cloud-token-theft/
• Revoke user access in Microsoft Entra ID | https://learn.microsoft.com/en-us/entra/identity/users/users-revoke-access
• Token Theft Playbook | https://learn.microsoft.com/en-us/security/operations/token-theft-playbook
• Token-based Authentication: Everything You Need to Know | https://www.strongdm.com/blog/token-based-authentication
• Token Types | https://cloud.google.com/docs/authentication/token-types