Session hijacking: why MFA alone doesn't stop it, and what does

Session hijacking is when an attacker steals a signed-in session instead of a password. Real-time phishing kits and infostealer malware capture the session cookie or token after the user has already completed MFA, so the attacker walks straight in. Phishing-resistant MFA, device-bound sessions, and fast session revocation are what stop it.

What is session hijacking?

Every time an end user signs in to Microsoft 365, Google Workspace, or a SaaS app, the service hands the browser a session cookie or token. It's a digital wristband that says "this person already proved who they are." For the next hours, days, or even weeks, the app checks the wristband instead of asking for the end user's password and MFA again.

Session hijacking is stealing that wristband. Whoever holds it is treated as the real user, from any browser, without a password prompt, and without an MFA challenge. The attacker doesn't need to defeat the user's login. They wait until the user logs in, then take what the login produced.

That's why session theft has become the attacker's shortcut around MFA. MFA protects the moment of sign-in. A stolen session skips that moment entirely.

How do attackers steal sessions?

There are two main routes, and they work very differently.

1. Real-time phishing kits. Security teams call this adversary-in-the-middle phishing. The attacker's page sits between the victim and the real sign-in page, passing everything through in both directions. The victim sees their real login screen, enters their password, approves the MFA prompt, and lands in their real inbox. Meanwhile, the kit keeps a copy of the session cookie that the real service just issued.

These kits are sold as a service, which is why they're everywhere. Microsoft reported that one kit, Tycoon2FA, powered campaigns sending tens of millions of phishing messages reaching over 500,000 organizations each month, with access sold from about $120 for 10 days. Microsoft and Europol disrupted it in March 2026, and CrowdStrike reported it was back to its earlier volume within days. Taking down one kit doesn't take down the business model.

2. Infostealer malware. If an infostealer runs on a device, through a ClickFix page, a fake AI installer, or a cracked app, it copies the browser's saved passwords and live session cookies and sends them to the attacker. No phishing page required. In September 2026, Okta analyzed one leaked infostealer dataset from 5,871 infected machines. Thousands of the Google and Microsoft session tokens in it had not yet expired when the data was released, alongside tokens for AI services.

Other routes are growing too. Malicious browser extensions with broad permissions can read session data from inside the browser. And consent and device-code phishing trick users into granting an attacker's app its own tokens, which skips the cookie step entirely.

Why doesn't MFA stop session hijacking?

Most MFA protects the login, not the session. Once you approve the prompt, the service issues a session, and that session is what the attackers take.

The type of MFA matters for the phishing route, though:

• Codes, push approvals, and SMS can be relayed. A real-time phishing kit simply passes the code or the approval through to the real site. CISA lists app codes, push with number matching, and SMS as vulnerable to phishing. Number matching helps against push fatigue, but not against a relay.
• Passkeys and security keys can't be relayed. They're tied to the real website's identity, so the browser won't use them on a fake one. Google's passkey documentation puts it simply: passkeys "work only on their registered websites and apps." CISA describes FIDO/WebAuthn as the only widely available phishing-resistant MFA.

The infostealer route is different. It steals the session after a legitimate login on the user's own device, so no type of MFA stops it on its own. That needs the session itself to be harder to steal or reuse, which is where newer controls come in.

None of this means MFA is pointless. It still blocks the huge volume of attacks that rely on a stolen password alone. It just isn't the finish line anymore.

What are the warning signs?

Session hijacking is quiet by design, so the signs show up in two places: what users notice at sign-in, and what admins see afterward.

What users can spot:

• The address bar doesn't match. A Microsoft or Google sign-in page on any domain other than the real one is a fake, however perfect it looks.
• A sign-in you didn't expect. Being asked to sign in again right after clicking a link in an email or document deserves a second look.
• An MFA prompt the user didn't start. This must be denied and reported to IT.

What admins should watch for:

• The same session in two places. Microsoft's guidance on cookie theft flags a single session that signs in from one country and then shows activity from another.
• Unusual sign-in details. An unfamiliar ISP, country, city, or anonymizing service for a user who normally works from one office.
• New inbox rules. Rules that mark mail as read, move it to an obscure folder, or archive it, often aimed at the domain of a company the attacker plans to defraud.
• Searches for money. Mailbox activity focused on payment-related threads, and sudden deletions from Sent Items.

Speed matters. In one 2022 campaign Microsoft investigated, the attacker started payment fraud as little as five minutes after stealing the session.

How can MSPs defend against session hijacking?

No single control closes all routes, so build layers. Roughly in order of impact for a typical small business client:

1. Move to phishing-resistant MFA. Passkeys, security keys, and Windows Hello for Business can't be relayed by a phishing kit. Start with admins, finance, and executives, then expand, and use conditional access to require them so attackers can't fall back to a weaker method.
2. Require managed, compliant devices. Conditional access rules are checked when a session is used, not just at sign-in. Microsoft notes that a policy requiring a compliant device or a trusted network can block an attacker replaying a stolen cookie from their own machine.
3. Bind sessions to the device where you can. Microsoft Entra's token protection ties sign-in tokens to the device they were issued to. It's generally available for native apps, such as those connecting to Exchange Online, SharePoint, and Teams. Browser support is still in preview and limited to Azure management apps, so it doesn't yet cover Outlook on the web. Google Chrome's Device Bound Session Credentials ties browser cookies to the device's hardware. It reached public availability on Windows in Chrome 146, with macOS to follow, and each website has to add support.
4. Stop infostealers before they run. The defenses from ClickFix apply here: restrict the command line for end users who don't need it, use application control and endpoint detection, and facilitate end users with a safe way to get the software they need.
5. Control browser extensions. An allowlist keeps over-permissioned and malicious extensions out of the browser where sessions live.
6. Block phishing pages before they load. Email link scanning and web filtering that blocks known phishing and lookalike sign-in domains cut off the relay route early.
7. Detect and revoke fast. Turn on alerts for session anomalies and new inbox rules, and make sure every technician knows how to revoke a user's sessions in each client's tenant.

For most clients, layers 1, 2, and 7 deliver the biggest gain for the least effort. The others matter more with increased sensitivity and risk.

What should you do when a session is hijacked?

Act as if the attacker is in the account right now, because they probably are.

1. Block sign-in. Disable the account or block sign-in first, so nothing new can be issued while you work.
2. Revoke every session and token. Sign the end user out everywhere in Microsoft 365 or Google Workspace. In Microsoft Entra, access tokens typically last 60 to 90 minutes and can keep working until they expire, and apps that keep their own sessions need to be signed out separately.
3. Reset the password and review MFA methods. In a phishing-kit attack, the attacker has the password too. Remove any MFA method or device the user doesn't recognize.
4. Clean up what the attacker set up. Delete suspicious inbox rules and forwarding, remove apps the user didn't approve, and check whether the account picked up any new admin roles.
5. Look for fraud. Check Sent Items and deleted mail for payment requests or changed bank details. If any went out, warn the recipients directly by phone.
6. Find the source. If there was no phishing email, check the user's device for an infostealer before you give the account back. Otherwise the attacker simply steals the new session too.

FAQ

What is session hijacking?

Stealing the session cookie or token a service issues after someone signs in, then using it to act as that person without a password or MFA prompt.

Can session hijacking bypass MFA?

Yes. Most MFA protects the sign-in, and session hijacking steals what the sign-in produces. Real-time phishing kits capture the session as the user completes MFA, and infostealers copy sessions straight from the device.

Do passkeys stop session hijacking?

They stop the phishing-kit route, because a passkey only works on the real website it was created for. They don't stop an infostealer from copying a session from an infected device. That needs device-bound sessions, device compliance checks, and fast revocation.

What is adversary-in-the-middle phishing?

A phishing technique where the attacker's page relays everything between the victim and the real sign-in page. The victim completes a real login, including MFA, and the attacker keeps a copy of the resulting session.

Does a password reset end a hijacked session?

Not reliably. Microsoft's own documentation shows some session cookies survive a password change. Revoke all sessions and tokens as well, and check apps that manage their own sessions.

How quickly do attackers use a stolen session?

It can be within minutes. In one 2022 campaign Microsoft documented, payment fraud started as little as five minutes after the session was stolen.

Keep reading

For more on how attacks start in the browser, see how ClickFix and fake AI installers work, and our pages on credential theft prevention and phishing protection.

Sources

• CISA, Implementing Phishing-Resistant MFA
• Microsoft Security, From cookie theft to BEC: attackers use AiTM phishing sites as entry point to further financial fraud, July 2022
• Microsoft Security, Inside Tycoon2FA: how a leading AiTM phishing kit operated at scale, March 2026
• CrowdStrike, Tycoon2FA phishing-as-a-service platform persists following takedown, March 2026
• Okta Threat Intelligence, Signing in without actually signing in, September 2026, summarized by the Cloud Security Alliance
• Google, Passkeys developer documentation and Protecting cookies with Device Bound Session Credentials
• Microsoft Learn, Token protection in Conditional Access, Access tokens, Session cookie theft alert, Revoke user access, and refresh token revocation