Session hijacking exposes the IAM gap left after MFA succeeds

At a glance

What this is: This is an analysis of session hijacking and its role in post-authentication compromise, with a focus on token theft, bearer credentials, and SaaS lateral movement.

Why it matters: It matters to IAM and NHI practitioners because token-based sessions are non-human identity artifacts that can outlive authentication controls and expand blast radius across integrated systems.

By the numbers:

• Session hijacking attacks increased 127% year-over-year in 2026, according to Obsidian Security.
• 87% of successful cyberattacks in 2024 involved session hijacking after valid MFA logins, according to Obsidian Security.
• SpyCloud recovered over 17 billion stolen cookie records from the dark web in 2024, according to SpyCloud.

👉 Read Obsidian Security's analysis of session hijacking and SaaS token theft

Context

Session hijacking is the theft of an active authenticated session, usually through cookies, OAuth tokens, or refresh tokens, rather than the password that created it. For IAM and NHI governance, that matters because the control point shifts from login to the token that keeps the application trusting the user after login has already succeeded.

The article frames a familiar enterprise weakness: authentication can be strong while session handling remains weak. In practice, that leaves a gap between MFA success and ongoing access control, especially in SaaS environments where tokens and OAuth connections behave like reusable NHI credentials. The baseline described here is typical for modern SaaS stacks, not an edge case.

Key questions

Q: How can security teams reduce the risk of session hijacking in SaaS environments?

A: Security teams should combine short token lifetimes with continuous session monitoring, conditional access, and strict OAuth scope management. MFA is still necessary, but it is not sufficient once a session token has been issued. The goal is to make stolen tokens less reusable and to detect abnormal behaviour quickly enough to revoke them before lateral movement spreads.

Q: Why does MFA not stop session hijacking?

A: MFA protects the login event, not the token created after login succeeds. If an attacker steals that token through phishing, malware, or browser compromise, the application treats the attacker as already authenticated. The control gap is therefore post-authentication, which means session visibility and token governance have to sit alongside MFA.

Q: What is the difference between credential theft and session hijacking?

A: Credential theft targets usernames and passwords before authentication. Session hijacking targets the authenticated token after login, so the attacker bypasses the sign-in step entirely. In practice, session hijacking is often harder to spot because the activity can look like normal user behaviour until the token is revoked or expires.

Q: Should organisations treat OAuth tokens as privileged identities?

A: Yes. OAuth tokens can grant broad and persistent access across SaaS applications, so they should be governed like privileged non-human identities. That means inventorying them, limiting scopes, rotating or revoking them when risk changes, and monitoring their behaviour for anomalies. If the token can act independently, it deserves identity-grade controls.

Technical breakdown

Bearer tokens and session replay in SaaS environments

Modern web apps often use bearer tokens such as session cookies, OAuth access tokens, and refresh tokens to preserve authenticated state. A bearer token proves possession, not identity, so the application accepts it from any device or browser that presents it. Once stolen, the token can be replayed until it expires or is revoked. That is why MFA can succeed and the attacker can still operate as the victim. In SaaS environments, the same token model often extends across integrations, which makes token theft an identity problem, not just a session problem.

Practical implication: Treat active tokens as privileged credentials and monitor them with the same discipline used for secrets and service account keys.

How adversary-in-the-middle phishing steals post-authentication tokens

Adversary-in-the-middle phishing proxies the real login page and captures the session artifact after the victim completes MFA. The attacker does not need the password once the browser has handed over an authenticated token. This technique is effective because the victim sees a legitimate login flow while the attacker receives the token in the middle. The same pattern can also work with browser cookie theft or XSS when a malicious script runs inside the user context. The core failure is that authentication was verified, but the token was not bound tightly enough to the device or context.

Practical implication: Require conditional access, device signals, and token binding where available so stolen tokens are harder to reuse elsewhere.

SaaS-to-SaaS lateral movement through OAuth connections

Session hijacking becomes more dangerous when the compromised account has OAuth connections to other services. Those integrations can inherit broad permissions, so the attacker can move from one app into another without triggering a new login challenge. The initial token becomes a bridge into downstream systems, data repositories, and administrative workflows. This is why session hijacking often looks like normal business activity until the attacker starts touching unusual resources. In NHI terms, the session is only the starting point, and the connected OAuth graph determines the blast radius.

Practical implication: Inventory every OAuth connection and constrain scopes so one stolen session cannot cascade across your SaaS estate.

Threat narrative

Attacker objective: The attacker aims to turn one valid session into broad, low-friction access across connected cloud applications while avoiding authentication alerts.

1. Entry occurs when the attacker steals a bearer session token through info-stealer malware, AiTM phishing, XSS, or network interception.
2. Escalation follows when the attacker replays the token and inherits the authenticated user's permissions without needing the password or MFA.
3. Impact occurs when the attacker uses connected OAuth permissions to move laterally across SaaS applications and exfiltrate data or alter account settings.

Breaches seen in the wild

• Salesloft OAuth token breach — hackers stole OAuth tokens to access Salesforce data via Salesloft.
• Dropbox Sign breach — compromised Dropbox Sign service account exposed API keys and OAuth tokens.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Session hijacking is an NHI governance problem, not only an authentication problem. Once a bearer token exists, it becomes a non-human identity artifact that can be reused outside the original login flow. That means MFA can be working exactly as designed while the actual access path remains exposed. Practitioners should govern sessions as a live identity layer, not a byproduct of sign-in.

Bearer-token trust creates an identity blast radius that many IAM programs still under-model. When a session token can unlock downstream SaaS integrations, the real risk is not one account but the web of trusted connections behind it. This is why session monitoring, OAuth scope control, and integration inventory belong together. Teams should measure blast radius by connected access, not by user count alone.

Ephemeral access does not eliminate trust debt if the token itself is reusable. Short-lived tokens reduce exposure, but they do not solve device compromise, token replay, or weak binding to context. The operational question is whether a stolen token can be used elsewhere before revocation or expiry. Practitioners should treat token lifetime as only one control in a broader session-risk model.

Identity controls must move from static login assurance to continuous session assurance. Traditional IAM assumes the important decision happens at authentication, but session hijacking proves the more relevant decision is whether the session still looks trustworthy after login. Behavioural analytics, device posture, and abnormal-access detection now belong inside the access decision loop. Security teams should align session controls with zero-trust expectations rather than legacy sign-on assumptions.

From our research:

• Only 1.5 out of 10 organisations are highly confident in their ability to secure NHIs, compared to nearly 1 in 4 for securing human identities, according to The State of Non-Human Identity Security.
• Lack of credential rotation is cited as the top cause of NHI-related attacks by 45% of organisations, according to the same report.
• For a broader map of the problem space, see Top 10 NHI Issues for the control failures that most often turn token exposure into breach conditions.

What this signals

Session governance is now part of NHI governance. If a token can be replayed after authentication, then the identity program has to monitor the session as an active credential, not a passive artifact. In practice, that means ownership, logging, revocation, and behavioural alerts need to be defined for sessions in the same way they are for service accounts and API keys.

The management implication is clear: teams that still draw the line at login are managing yesterday's threat model. With 85% of organisations lacking full visibility into third-party vendors connected via OAuth apps, according to The State of Non-Human Identity Security, the hidden risk sits in the integration layer as much as in the endpoint.

For practitioners, the next phase is to connect session analytics to zero-trust decisions and third-party app governance. If token replay can cross SaaS boundaries, then policy has to follow the connection graph, not just the user directory. That is where the operational control surface is expanding fastest.

For practitioners

• Implement continuous session monitoring Track new device logins, unusual geographies, concurrent sessions, and abnormal data access so token replay is visible before exfiltration expands.
• Constrain OAuth scope and integration trust Review every connected SaaS integration, remove unnecessary write or admin scopes, and revoke stale third-party connections that could widen blast radius.
• Bind access to context and device signals Use conditional access, device posture checks, and step-up controls for sensitive actions so a stolen session token is less reusable.
• Shorten token lifetime and revoke aggressively Reduce session duration where business risk allows, and automate revocation when anomalous behaviour or suspicious token reuse appears.

Key takeaways

• Session hijacking turns post-authentication tokens into high-value non-human identities that MFA alone cannot contain.
• The real exposure is often the integration graph, where one stolen session can inherit access across connected SaaS systems.
• Security teams should shift from static login protection to continuous session assurance, token governance, and scope control.

Key terms

• Session Hijacking: Session hijacking is the theft and reuse of an authenticated session token, cookie, or refresh token after login has already succeeded. The attacker does not need the original password once the bearer credential is captured, which makes the compromise harder to detect with login-focused controls.
• Bearer Token: A bearer token is a credential that grants access to whoever holds it, rather than proving the holder's underlying identity. In SaaS environments, bearer tokens can function like reusable keys, so theft or replay often creates immediate access until the token expires or is revoked.
• OAuth Integration: An OAuth integration is a delegated trust relationship between applications that allows one service to access another on behalf of a user or workload. These connections can carry broad permissions, so compromise of one token can extend access across multiple systems and increase the blast radius.
• Session Replay: Session replay is the act of using a stolen authenticated token in a different browser, device, or context to impersonate the original user. It works because the application trusts possession of the token, making contextual monitoring and revocation essential defenses.

Deepen your knowledge

Session hijacking, token replay, and SaaS session governance are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building controls for bearer tokens and OAuth-connected systems, it is a practical place to start.

This post draws on content published by Obsidian Security: Session Hijacking: How It Works and How to Stop It. Read the original.