Attacks on sessions and tokens
Techniques that skip the login and go straight for what it produces: stolen cookies, replayed access tokens, and refresh credentials that outlive a password reset.
Why this control fails
A session token that satisfied MFA at issuance carries that assurance for as long as it is valid, and most identity providers do not check that the presenter is the same browser or device that logged in. Infostealer malware lifts cookies and tokens from the endpoint in bulk, and adversary-in-the-middle kits capture them live during a real login, so the attacker inherits a session that already passed every policy check. A password reset alone does not revoke a live refresh token unless the identity provider is explicitly configured to invalidate it, which is why "we rotated the password" is not the same statement as "we ended the session."
What security people should do
- Sender-constrain access and refresh tokens with DPoP or mutual TLS so a stolen token is unusable from a different client.
- Shorten access token lifetimes and pair refresh token rotation with reuse detection, so a replayed refresh token revokes the whole chain.
- Make password reset and MFA re-enrollment revoke every existing session and refresh token for that identity, not just future logins.
- Bind cookies to device signals where the platform supports it, and alert on a session presented from a new device with no matching re-authentication.
Techniques in this category
- Attacker-in-the-middle phishing proxyA reverse proxy sits between the user and the real login page, relays every step of authentication including MFA, and keeps the session cookie the successful login produces.WidespreadHard to detect
- Device code phishingThe victim enters a code on Microsoft's own login page and approves a real prompt. The attacker requested that code from a second device and walks away with access and refresh tokens.WidespreadHard to detect
- Primary Refresh Token theftCode already running in a signed-in Windows session can drive the device's own Windows Hello key to obtain a Primary Refresh Token, no PIN prompt, no admin rights, no CVE required.EmergingHard to detect
- Refresh token abuseA refresh token exists to let an app get new access tokens without bothering the user again. Stolen, it lets an attacker do the same thing indefinitely, surviving password resets along the way.WidespreadHard to detect
- Session cookie theftA session cookie is a bearer credential that proves nothing beyond possession. Whoever copies it inherits the logged-in session, skipping the password and the MFA challenge that produced it.WidespreadHard to detect
- Token replay against an unbound endpointA 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
- Cross-tenant token confusionA broker sitting between users and a shared backend fails to keep sessions apart, so a token supplied by one caller gets used to serve a different caller's later request, with no attack step beyond timing.EmergingHard to detect
- Scope escalation through delegationA chain of services each meant to narrow a token's authority instead widens it, because one hop in the delegation path trusts the scope a caller claims rather than the scope it was actually issued.EmergingHard to detect
- Infostealer credential harvestingCommodity malware on an endpoint reads whatever the browser and OS have stored in the clear or under a key the same machine already holds, then ships it to a marketplace where the credentials outlive the machine they came from.WidespreadHard to detect