Your 2FA isn't safe: how session hijacking (pass-the-cookie) works and how to stop it
Your account has a strong password. It has 2FA turned on. And an attacker can still walk straight in without either of them. The trick is called session hijacking, also known as pass-the-cookie or token theft. In the on
Your account has a strong password. It has 2FA turned on. And an attacker can still walk straight in without either of them.
The trick is called session hijacking, also known as pass-the-cookie or token theft. In the one-minute video above I show it on two of my own test accounts, in two browsers, with nothing more than the browser's own developer tools. This post explains what is happening and, more importantly, how to defend against it.
For learning only. Never use this against accounts that are not yours.
Why the password and the 2FA code don't matter here
When you sign in, the site checks your password and your 2FA code once. Then it hands your browser a session cookie: a long random value that says "this browser already proved who it is". Every page you open after that sends the cookie, and the site lets you in without asking again.
Think of a wristband at a theme park. You show your ticket once at the gate, you get the wristband, and from then on every ride just looks at the wristband.
So whoever holds the wristband is you, as far as the site is concerned. If an attacker copies that one cookie value into their own browser, they skip the login page, the password and the 2FA prompt entirely.
What the demo shows
-
Victim browser: signed in normally (password + 2FA). In DevTools, under Application → Cookies, there is a cookie called
sessionid. - Copy: the attacker copies that one value.
-
Attacker browser: a different browser, signed in to a different account. The attacker opens the same cookie screen and pastes the victim's value over their own
sessionid. - Refresh: the page reloads, and the attacker is now inside the victim's account. No password typed, no code asked.
In the demo I copy and paste the value by hand so you can see it move. In real attacks nobody sits at your keyboard: the cookie is stolen by infostealer malware, a malicious browser extension, an adversary-in-the-middle phishing page (a fake login page that relays your real sign-in and keeps the cookie), or simply a shared computer someone forgot to log out of.
The session in the video was revoked right after recording, so the value on screen is useless.
How to stay safe
For everyone
- Log out on shared computers. Closing the tab is not logging out. The cookie stays valid until the session ends.
- Sign out of all sessions often. Most services (Microsoft, Google, Instagram, Facebook) have a "log out of all devices" button. Use it after travel, after using someone else's PC, or whenever something feels off. It kills every copied cookie at once.
- Treat browser extensions and "cracked" software as malware risks. Infostealers are the number one source of stolen session cookies today.
For Microsoft Entra ID admins
- Revoke sessions when an account is suspected. Resetting the password alone is not enough: revoke the user's sessions too, so existing tokens stop working. Microsoft's guide: Revoke user access in Microsoft Entra ID.
- Turn on token protection with Conditional Access. Token protection binds sign-in tokens to the device they were issued to, so a token copied to another device is rejected. See Token protection in Conditional Access (check the supported apps and platforms first, and start in report-only mode).
- Prefer phishing-resistant MFA (passkeys, FIDO2, Windows Hello for Business). They stop the fake-login-page variant of this attack, because the sign-in only works on the real site.
- Have a playbook ready. Microsoft's token theft playbook walks through detection and response step by step.
The one thing to remember
2FA protects the login. Session hijacking skips the login. Protect the session too: log out, revoke, and bind tokens to devices.
Sources
- Microsoft Learn: Revoke user access in Microsoft Entra ID
- Microsoft Learn: Token protection in Conditional Access
- Microsoft Learn: Token theft playbook
Thanks for reading! I'm Cuong, and on CD Security Lab I rebuild real Microsoft security cases in a safe lab and explain them simply. Follow along:
- ▶️ YouTube (daily Shorts + explainers): CD Security Lab
- 💼 LinkedIn: Cuong Do
- 📘 Facebook: CD Security Lab
- 📸 Instagram: @cdsecuritylab
- 📝 More posts like this: Dev.to
Got a question about your own tenant? Drop it in the comments.
Originally published by Dev.to Security. Aggregated on AIWithGhost for educational purposes — full credit and traffic to the original publisher.