For most enterprises, multi-factor authentication is the answer to credential theft. It is not unreasonable to think this. MFA, deployed widely, has materially reduced the success rate of standard credential-based attacks. The attack class that drove a decade of breach reporting — credential stuffing against externally-exposed authentication — is now, in well-defended organisations, mostly defeated.
What this masks is that the attacks that succeed against modern enterprises increasingly do not need to defeat MFA. They steal the session that comes after MFA.
This is the quiet shift that is currently driving a non-trivial proportion of enterprise breaches. The mechanics are unspectacular but consequential, and the defensive response that most organisations have configured does not address them.
How session hijacking actually works
When a user authenticates to a modern web application — Microsoft 365, Salesforce, Workday, an internal SSO portal — the authentication exchange produces a session token. The token is stored in the user’s browser, typically as a cookie or in browser storage, and it is presented with subsequent requests to prove that the user has already authenticated. This is, in normal operation, a security feature: it prevents users from re-entering credentials and re-completing MFA on every page load.
The token is also, from an attacker’s perspective, a fully-authenticated bearer credential. Whoever holds the token is the user, for the lifetime of the session, with the MFA requirement already satisfied.
Modern attack toolkits — Evilginx, Modlishka, Muraena, and a long tail of derivatives — proxy the legitimate authentication flow. The user visits what they believe is the legitimate Microsoft 365 login page (the URL is convincing; the rendering is identical because it is being proxied from the real site). They enter their credentials. They complete MFA. The legitimate site issues a session token. The attacker captures it.
The user lands in their genuine inbox. Nothing visibly went wrong. The attacker now holds a session token and can access the same account, with the same authenticated state, until the token expires or is explicitly revoked.
The attack is fast — the entire credential-and-session-capture sequence completes in seconds. It is also, by design, invisible to the legitimate authentication logs. From the identity provider’s perspective, a successful authentication occurred. Everything that follows looks like normal session activity.
Why traditional defences miss this
The detection logic that most organisations have configured around authentication catches things that look like authentication anomalies — impossible travel, unfamiliar locations, sign-ins from suspicious IPs. Session hijacking attacks bypass these because the authentication itself was legitimate, completed by the genuine user, from a normal location, on a normal device.
The attack manifests, if it manifests at all, in the use of the session — usually from a different IP address than the one the session was issued to. But session use from a new IP is common in modern enterprise environments (mobile users, VPN switching, home-office transitions) and the false positive rate of “session used from new IP” alerts is high enough that most organisations either don’t generate them or aggressively suppress them.
The attacks that have been most successful in 2025 and Q1 2026 are characterised by their use of the session being patient and disciplined. Attackers wait. They observe the user’s normal patterns. They access mailboxes, not data archives. They search for specific information rather than bulk-extracting. They blend.
By the time anomalous use is detected, the data exfiltration has typically already happened.
What actually works
The defensive response that addresses this attack class operates at the session layer rather than the authentication layer. Three categories of control are emerging as effective.
Token binding. Modern authentication standards (FIDO2, the Token Binding RFC, browser-bound credentials) cryptographically tie the session token to the device that completed authentication. A token captured from a proxy cannot be replayed from the attacker’s machine because the cryptographic binding does not match. Adoption is growing but is not universal — many enterprise applications still issue device-independent tokens.
Continuous identity verification. Rather than treating authentication as a single event, this approach continuously evaluates session legitimacy based on user behaviour, device posture, network context, and anomaly signals. A session token alone is not sufficient to access sensitive resources; the platform re-verifies trust at the resource level. Beyond Guard, which we deploy for clients, sits in this space — providing the continuous verification layer that turns the binary “authenticated/unauthenticated” model into a continuous trust score.
Browser-layer security. The browser is where the session token lives, and where the proxy attack ultimately captures it. Enterprise browser security platforms — SURF Security is what we deploy — provide visibility and control at the browser layer, detecting the session capture flow itself rather than waiting for downstream symptoms. The browser becomes a security telemetry source rather than an opaque execution environment.
These three categories are complementary rather than competing. Token binding addresses the cryptographic exposure. Continuous verification addresses the use of stolen tokens. Browser security addresses the capture mechanism.
The harder problem: organisational ownership
The technical controls are deployable. The organisational obstacle is that session security spans authentication, application security, network security, and endpoint security, and most enterprises do not have a team with a clear mandate across all of these. Identity teams own MFA. Application teams own session token configuration. Network teams own the egress traffic that adversary toolkits ride on. Endpoint teams own browser configuration. None of them, by themselves, can address the attack class.
The organisations that have made progress have explicitly chartered an “identity threat response” function — small, cross-functional, with the authority to make decisions across the traditional team boundaries. The function does not need to be large. Two to four people in a 5,000-employee enterprise is typical. What matters is the authority to act across boundaries.
Without that authority, session hijacking remains a risk that everyone agrees is real, that several teams partially address, and that no one has visibility into end-to-end. That is the configuration that makes the attack class succeed.
What to do this quarter
The most useful first step is honest visibility. Most organisations cannot answer the question: “for our top ten most-targeted accounts, what was the source IP of every session in the last 30 days, and how does that distribution compare to the source IP of authentication events?” The data exists in identity provider logs and SIEM platforms; the analysis is rarely set up.
The output of that analysis is usually clarifying. It will surface either evidence of session anomalies that warrant deeper investigation, or confirmation that the current detection logic is leaving the question unanswered.
Either way, the productive question — “do we have visibility into session-layer threats” — gets answered. From there, the defensive investments follow naturally.
The era of MFA-as-the-answer is ending. The era of session-layer security is beginning. The organisations that recognise this early will be substantially better-positioned for the threat landscape that 2026 is producing.
Mellivor advises enterprise teams on identity threat detection and response, deploying Beyond Guard for continuous zero-trust verification and SURF Security for enterprise browser protection. To assess your session-layer exposure, contact our advisory team.
