Session hijacking exposes the IAM gap left after MFA succeeds

At a glance

What this is: This article explains how session hijacking works after authentication succeeds and why stolen bearer tokens let attackers bypass MFA, inherit permissions, and move across SaaS applications.

Why it matters: IAM and SaaS security teams need to treat session tokens, OAuth connections, and behavioural detection as first-class controls because login success does not mean session integrity.

By the numbers:

• Session hijacking 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 Obsidian Security.
• Session cookie theft via adversary-in-the-middle phishing accounts for 15% of all phishing attacks, according to Obsidian Security.

Context

Session hijacking is a post-authentication identity attack, not a login attack. The attacker steals the active session token, cookie, or refresh token and uses it as proof of identity inside the application.

For IAM programmes, the problem is that MFA can succeed and still leave a fully usable bearer token behind. That shifts the control question from how users authenticate to how sessions, tokens, and OAuth connections are governed after authentication.

In SaaS environments, that distinction matters because one compromised session can inherit access through linked applications, service connections, and API-driven trust paths. The article’s core finding is that authentication is necessary, but no longer sufficient.

Key questions

Q: What breaks when attackers can steal MFA session tokens?

A: MFA stops being the control point once the attacker has a valid token or cookie. The real failure is that the session is trusted after authentication, so the attacker can reuse access without reentering credentials. Organisations need to treat token replay as an identity event, not just an endpoint or phishing problem.

Q: Why do session hijacking attacks remain effective in SaaS environments?

A: SaaS environments fragment activity across many tools, so a valid session can move through applications without a single unified security checkpoint. Attackers exploit that fragmentation by reusing trusted sessions and blending into normal user behaviour. The risk rises when identity teams can see authentication but not what happens after it.

Q: What are the signs that SaaS session hijacking may be underway?

A: Common signs include unusual activity from an otherwise valid session, access from unfamiliar devices or locations, unexpected creation of new sessions, and actions that do not match the user’s normal behavior. Security teams should also watch for token reuse across applications after a successful MFA event, since that pattern often points to hijacked credentials rather than a fresh login.

Q: What should incident response teams do when a SaaS session is compromised?

A: Incident response should remove every persistence vector, not only the IdP session. That means revoking application sessions and tokens, resetting compromised credentials, and checking for new MFA devices, email addresses, or phone numbers attached to the account. Teams should also reduce session timeouts where possible to limit the reach of future session hijacking.

Technical breakdown

Bearer tokens turn session theft into instant reuse

Most SaaS applications treat OAuth access tokens, refresh tokens, and browser cookies as bearer credentials. That means the application authorises whoever presents the token, not whoever originally authenticated. Once an attacker steals the token, they can replay it from a different browser or device and appear as the legitimate user until expiry or revocation. This is why session hijacking bypasses MFA: the authentication event already happened, and the token becomes the durable proof of that event. In practice, the risk is not only theft but token portability across devices, browsers, and networks.

Practical implication: treat session and token custody as part of identity control, not just login security.

Token capture usually happens after the user has logged in

The common capture paths are info-stealer malware, adversary-in-the-middle phishing, cross-site scripting, and network interception. Each one targets the browser or the traffic path after the user has already satisfied password and MFA checks. That timing matters because the attacker is not defeating the factor challenge. They are stealing the artefact that the successful challenge creates. This is why static authentication signals often miss the attack entirely: from the application’s perspective, the login was valid and the session looks ordinary until the token is reused elsewhere.

Practical implication: monitor browser, token, and session behaviour for theft indicators that appear only after successful login.

OAuth trust chains expand the blast radius

Session hijacking becomes materially worse when the stolen session is tied to OAuth integrations and connected SaaS applications. Those integrations often grant delegated permissions that extend beyond the original app, allowing the attacker to move from one compromised session into downstream systems without triggering a new authentication challenge. The security problem is inherited authority, not just stolen access. A single valid session can therefore unlock customer data, admin functions, or connected workflows across multiple services if the organisation has not governed scopes, integrations, and session visibility as one control surface.

Practical implication: govern OAuth scopes and connected applications as an extension of the session security model.

Threat narrative

Attacker objective: The attacker wants authenticated SaaS access that survives MFA and opens the path to data theft, account takeover, and lateral movement across connected applications.

1. Entry occurs when attackers steal a live session token through malware, AiTM phishing, XSS, or network interception after the user has authenticated.
2. Credential access is achieved by capturing the bearer token, cookie, or refresh token that proves the session rather than the password itself.
3. Escalation follows when the attacker replays the token and inherits the user’s authenticated state, permissions, and connected SaaS access.
4. Impact occurs when the attacker uses the trusted session to exfiltrate data, modify settings, or move laterally into linked applications and downstream systems.

Breaches seen in the wild

• Dropbox Sign breach 2024: A compromised back-end service account gave attackers Dropbox Sign customer data, including API keys, OAuth tokens and MFA information.
• Salesloft OAuth token breach: hackers stole OAuth tokens to access Salesforce data via Salesloft.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Session governance is now the control boundary that follows authentication. MFA reduces credential reuse, but it does not govern the token that survives the login. That means IAM teams have been treating the wrong artefact as the endpoint of trust, and the practical conclusion is that sessions must be governed with the same seriousness as initial authentication.

Bearer-token portability is the real blast-radius multiplier. A stolen session token behaves like a transferable key, so the attacker inherits the session’s privileges, not just its account label. In SaaS environments, that inherited authority can cascade through OAuth connections and API-linked services, which is why session theft is an access-governance problem as much as a detection problem.

Continuous behavioural controls are now a core identity requirement, not an optional SOC add-on. Static login checks cannot distinguish a valid session from a stolen one once authentication succeeds. The field needs stronger session governance, token observability, and anomalous-use detection because post-authentication abuse is now a mainstream identity threat path.

OAuth connection sprawl creates identity debt that outlives the original login event. The more integrations a user has authorised, the more places a stolen session can travel without friction. That makes connected application inventory, scope review, and session-level telemetry part of identity lifecycle governance, not separate cloud hygiene tasks.

Continuous session governance should be treated as a named control gap. The article exposes a gap between authentication success and token oversight that many IAM programmes still leave unmanaged. The implication is not simply to add more alerts, but to recognise that the identity trust model ends only when the session does.

From our research library:

• 1 in 3 organisations encountered suspicious AI agent activity in 2025, and 99.4% experienced a SaaS or AI ecosystem incident.

What this signals

Continuous session governance is the missing layer in many IAM programmes. Authentication controls answer who logged in, but they do not answer what that session can do after it starts. Security teams now need to treat session state, token custody, and connected-app trust as one governance problem rather than separate operational tasks.

OAuth integrations should be reviewed as part of identity lifecycle, not as peripheral app connectors. A stolen session can inherit the permissions of every linked application, which turns unmanaged integrations into blast-radius multipliers. The practical shift is to inventory trust paths with the same discipline used for privileged access and offboarding.

For practitioners

• Audit session-token exposure paths Review where browser cookies, access tokens, and refresh tokens can be stolen through malware, AiTM phishing, XSS, or unencrypted transport, then rank the applications by blast radius.
• Add behavioural session monitoring Alert on new-device logins, unusual geolocation, impossible travel, concurrent sessions, and unexpected data access patterns that appear after valid authentication.
• Inventory OAuth-connected applications Map every SaaS integration, the scopes it holds, and the downstream systems it can reach so a hijacked session does not become an inherited-access event.
• Reduce token lifetime where business allows Shorten access and refresh token windows, and ensure revocation is fast enough to end replay before attackers can use the stolen token across connected apps.
• Test for post-authentication abuse paths Run simulations that assume MFA succeeds and then verify whether your controls detect token replay, session reuse, and SaaS-to-SaaS movement.

Key takeaways

• Session hijacking exploits the gap between successful login and token governance, which is why MFA can be bypassed without defeating the authentication challenge.
• The attack matters because bearer tokens can carry inherited permissions across SaaS integrations, expanding a single compromise into wider application access.
• Teams reduce the risk by monitoring session behaviour, inventorying OAuth trust paths, and shortening the lifetime of tokens that can be replayed.

Key terms

• Session Hijacking: Session hijacking is the takeover of an authenticated session after the original login has completed. The attacker does not need to know the password if they can use the active session token, which is why session monitoring and revocation are essential controls in SaaS identity governance.
• Bearer Token: A bearer token is a credential that grants access to whoever possesses it, without requiring strong proof that the holder is the intended client. In NHI environments, that makes theft and replay the main risk, especially when tokens are long-lived, broadly scoped, or stored in local files.
• Identity Trust Chain: The sequence of trust decisions that connects a message, user, application, model, tool, and credential into one working path. When any link is weak, an attacker can move from content manipulation to access abuse without needing a separate breach at each layer.
• Session Governance: The practice of binding access to a specific task, time window, and execution context, then revoking it when the work is done. For non-human identities, session governance matters because tokens and delegated permissions often persist longer than the action they were created to support.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.