Skip to content
Start with Identity
Join free
SWI-T010 · Session and tokens

Token replay against an unbound endpoint

A token that is not bound to the client, session, or challenge that requested it can be lifted once and replayed anywhere the check for binding is missing, no matter how it was strengthened.

WidespreadHard to detect
First observed: 2020ATT&CK T1550.004 ↗ATT&CK T1550.001 ↗

How it works

Token replay against an unbound endpoint is an attacker presenting a valid session cookie, SAML assertion, OAuth token or WebAuthn assertion that they copied, to an endpoint that only asks "is this token valid?" and never "is this the party it was issued to?". Most of these artifacts are bearer tokens unless something binds them to the client, device or key that requested it; without that binding, whoever holds a copy is accepted as the original requester.

The attack has four steps.

  1. Obtain the token. From an appliance memory leak, an infostealer, an adversary-in-the-middle proxy that captures the session after MFA, a phished OAuth grant, or a log or HAR file that recorded it.
  2. Move it to attacker infrastructure. Import it into a browser, script or API client on a host the attacker controls.
  3. Present it. Signature, expiry and audience all pass, because the token is genuine. No MFA prompt appears, because authentication already happened.
  4. Extend. Redeem refresh tokens and register new MFA methods or devices so access outlives the token.

Citrix Bleed (CVE-2023-4966) is the clearest public example of step 1 as a product bug: a buffer over-read on NetScaler ADC and Gateway returned memory containing live session tokens to an unauthenticated caller, who replayed them with no password and no MFA. NetScaler released fixed builds on October 10, 2023. Keycloak's SAML broker accepted a replayed assertion and let an attacker hijack a session (CVE-2026-18967), even though the SAML 2.0 Web Browser SSO profile says the service provider "MUST ensure that bearer assertions are not replayed" by keeping the set of used assertion IDs until NotOnOrAfter passes. In the 2026 "Pass-the-Passkey" research, Windows wrote WebAuthn assertions to event logs in cleartext (CVE-2026-34348), and Dirk-jan Mollema found that Entra ID's WebAuthn challenge, valid for five minutes, "is not bound to a session, a user or even a tenant", so a challenge requested on one host can be signed on another and redeemed there.

Why it works

Strengthening the credential does nothing if the endpoint that accepts the resulting token never checks who is presenting it. The token minted after a passkey login is usually as replayable as one minted after a password. The control assumption that fails is that "authenticated once" means "the same party for the rest of the session". Binding is the property that closes the gap, and it is often missing because the protocol made it optional (OAuth bearer tokens, browser cookies), the implementation skipped a required check (the SAML replay cache), or a bug leaked tokens through a path no binding check anticipated.

That is why these incidents report MFA as "bypassed" when it worked as designed. Appliance flaws that hand out an authenticated session sit next to the MFA blind zone: there is no login step for MFA to protect. And when the token comes from an AiTM relay or device code phishing, the victim completed a real login, so the theft is a talk-past attack and the replay its payoff.

How to detect it

  • Entra ID Protection risk detections. anomalousToken flags tokens with an unusual lifetime or played from an unfamiliar location, and covers session and refresh tokens. Microsoft warns of false positives at low and medium risk. unfamiliarFeatures on a non-interactive sign-in "deserves increased scrutiny due to the risk of token replay attacks." attackerinTheMiddle fires when a session is linked to a malicious reverse proxy. The first two need Entra ID P2; the AiTM detection needs Microsoft 365 E5 with EMS E5.
  • Entra sign-in logs. In AADNonInteractiveUserSignInLogs, look for token redemptions from hosting ASNs or scripted user agents. Huntress's 2026 campaign showed node and bare Mozilla/5.0 user agents making OAuth2:Token requests, error 50133 (SsoArtifactRevoked) when a revoked session was replayed, and 53003 (BlockedByConditionalAccess) when policy stopped a valid credential.
  • Token Protection status. Where Token Protection runs in report-only mode, the TokenProtectionStatusDetails field records signInSessionStatus as bound or unbound, with codes such as 1002 (no device state).
  • Okta System Log. With Identity Threat Protection, user.session.context.change records a change of IP, device or session context within a session, policy.auth_reevaluate.fail records a session that failed policy re-evaluation, and user.session.end records the resulting Universal Logout.
  • Sessions with no matching login, from a new IP or ASN, especially after a token-leaking appliance flaw is disclosed.

Be honest about the limits: legitimate token use from new places (mobile networks, VPNs, browser sync) is constant, and attackers pick residential proxies and current browser user agents to blend in. The strongest signal is the combination of a new source with no corresponding login, followed by persistence actions such as device or MFA registration.

How to stop it

  1. Bind tokens to a key the client holds. DPoP (RFC 9449) binds a token to a public key at issuance and makes every request carry a fresh proof with the method, URI and an access token hash; mutual TLS (RFC 8705) binds it to a client certificate. For browsers, Device Bound Session Credentials tie the cookie to a hardware-held key. In Microsoft Entra ID, require Token Protection in Conditional Access for supported native apps on Windows, macOS and iOS, and pair it with policies that block unknown platforms, since attackers can claim a platform the policy does not cover.
  2. Enforce replay checks the protocol already requires. SAML service providers need a replay cache keyed on assertion ID until NotOnOrAfter. DPoP servers should track jti values and issue server nonces. WebAuthn relying parties should bind challenges to the session that requested them.
  3. Patch edge appliances and kill every session. After the Citrix Bleed fix, NetScaler told customers to run kill aaa session -all, kill icaconnection -all and related commands, because a patched box still honors tokens leaked before the patch.
  4. Revoke on signal, not on schedule. Wire risk detections and CAEP events to session revocation, and revoke refresh tokens (not just reset passwords) after any suspected theft.
  5. Shorten session and refresh token lifetimes. This narrows the window; it does not close it.

Seen in the wild

Sources

Related identity CVEs and breaches

Last reviewed By SWI Community TeamSuggest a correctionHow we research

In the Identity Breach Database

Real incidents in our sourced breach database where this technique was used.

Browse the full database

Seeing this technique used differently, or have a detection rule that works better? Email community@startwithidentity.com. See all briefs in the technique catalog, or volunteer as a CVE Analyst.
Mapped to MITRE ATT&CK where a technique ID exists. Independent, community-driven analysis, not a substitute for the ATT&CK knowledge base. See the disclaimer.