14.1 How M365 Tokens Work

How M365 Tokens Work

You cannot investigate token replay if you do not understand what a token is, how it is issued, how long it lives, and what revocation actually does. This subsection provides the operational reference.

The token hierarchy

When a user authenticates to M365, the identity provider (Entra ID) issues a chain of tokens:

Primary Refresh Token (PRT). Issued to the device during Windows sign-in or device registration. The PRT represents “this device is authenticated to this tenant.” It is stored in the device’s TPM (Trusted Platform Module) and is not directly accessible to applications. The PRT is used to obtain access tokens for M365 services without re-prompting the user for credentials. Lifetime: tied to the device — valid as long as the device is registered and the user’s session is active. This is the token that enables single sign-on across M365 applications on a managed device.

Refresh Token. Issued by Entra ID after a successful authentication (including MFA). The refresh token is a long-lived credential that can obtain new access tokens without re-authentication. Default lifetime: 90 days (configurable). The refresh token is what the attacker captures in an AiTM attack — and it is why the attacker maintains access for days or weeks after the initial compromise.

Access Token. A short-lived token issued by Entra ID for a specific resource (Outlook, SharePoint, Graph API). Lifetime: 60-90 minutes (default, configurable via token lifetime policies). The access token is what the application presents to the resource server to prove authorisation. When it expires, the application uses the refresh token to obtain a new one — silently, without user interaction.

Session Cookie. Stored in the browser after web-based authentication. The session cookie maintains the user’s authenticated state in the browser. It functions similarly to a refresh token for web applications — the browser presents the cookie to obtain new access tokens.

The token replay attack vector

In an AiTM attack, the proxy captures the session cookie (and potentially the refresh token) after the user completes MFA. The attacker then:

1. Imports the session cookie into their own browser (or uses the refresh token via API).
2. The browser/API presents the cookie/token to Entra ID.
3. Entra ID validates the token — it is legitimate, issued after successful MFA.
4. Entra ID issues a new access token for the requested resource.
5. The attacker accesses the resource (Outlook, SharePoint, etc.) using the new access token.

The critical point: The attacker never authenticates. They never provide a password. They never complete MFA. They present a token that already passed all of those checks. From Entra ID’s perspective, this is a legitimate session continuation — not a new sign-in.

Why password reset does not revoke tokens

This is the most misunderstood aspect of M365 token security.

When you reset a user’s password, Entra ID invalidates the password — future authentication attempts with the old password fail. But existing tokens are NOT immediately invalidated. The refresh token remains valid because it was issued before the password change and has its own independent lifetime.

The access token (60-90 minutes) continues to work until it expires naturally. After expiry, the application attempts to use the refresh token to get a new access token. Under standard configuration (without CAE strict mode), this renewal succeeds — because the refresh token is still valid.

The result: An attacker with a stolen refresh token retains access for up to 90 days after a password reset — unless the refresh token is explicitly revoked.

Explicit revocation: Revoke-MgUserSignInSession -UserId "user@northgateeng.com" invalidates all refresh tokens for the user. After revocation, the next time an application tries to use the refresh token to obtain a new access token, it fails — and the user (or attacker) must re-authenticate. Since the password is now reset and the attacker does not know the new password, re-authentication fails for the attacker.

The gap: Between token revocation and access token expiry (up to 90 minutes), the attacker’s current access token continues to work. This is the “revocation gap” — the period where the attacker has access despite revocation. CAE (subsection 14.7) addresses this gap.

Token lifetimes reference

What this means for investigation

When investigating a potential token replay incident, you must determine:

1. Which token type is the attacker using? Refresh token (API-based access, visible in AADNonInteractiveUserSignInLogs) or session cookie (browser-based access, visible in SigninLogs as interactive sign-in without MFA prompt)?

2. When was the token issued? The original authentication timestamp tells you when the compromise occurred — which may be days or weeks before the current activity.

3. Has the token been revoked? If tokens were revoked but the attacker still has access, either: the revocation failed, the attacker obtained a new token (re-compromise), or the attacker is using an access token within the revocation gap.

4. Is CAE enforced? With CAE strict mode, critical events (password change, account disable, IP change) trigger near-immediate token revocation — closing the gap. Without CAE, the attacker retains access until the access token expires naturally.

Subsection artifact: The token lifetimes reference table and the 4-question investigation framework. These are the first sections of your token investigation playbook.

Knowledge check