Your MFA Code Won't Stop This One: Session-Token Theft Explained

You did everything right. You turned on multi-factor authentication across the company. You told everyone to use the app, not the text message. You felt good about it. So when a finance manager forwarded a Microsoft login page that looked exactly like the real one, entered her password, and typed in the six-digit code from her authenticator, she assumed she was safe. The MFA prompt approved. The page loaded. Nothing looked wrong.

An attacker was already inside her account. Not because they guessed her password. Because they never needed it.

This is the part of modern phishing that most small and mid-sized business owners have never heard of, and it is the reason “we have MFA” is no longer the end of the security conversation. It is the start of it.

What actually happened

The old model of phishing was simple. Trick someone into typing their password on a fake page, collect the password, log in later. MFA broke that model. Even with the password, the attacker got stuck at the code.

So the attack changed. Today’s phishing kits do not sit between you and a fake page. They sit between you and the real one. The technique is called adversary-in-the-middle. Microsoft Threat Intelligence documented a campaign where the attacker stood up a page that mimicked the real sign-in screen, and when the victim entered their credentials there, the attacker used them to authenticate to the genuine service and complete the MFA step. The login succeeds. And at that moment the service hands back a session token, the small piece of data your browser stores so it does not ask you to log in again on every click.

The attacker steals that token. Microsoft describes this as session cookie theft, and it lets the attacker replay the stolen cookie to access the account while bypassing the multifactor requirement, because from the service’s point of view, that session already passed MFA. The code did its job. It just did it for the wrong person.

CISA makes the same point, noting that not all MFA technologies provide equal protection and that authenticator codes, SMS codes, and push notifications are all vulnerable to common MFA bypass attacks. The tools to run these attacks are not exotic, and the technique is well enough understood that Microsoft has published detection and mitigation guidance for it.

Why this hits growth-stage businesses harder

If you are a company somewhere between 25 and 300 people, adopting new tools quickly, you are exactly the profile these kits are built for. You moved to Microsoft 365 or Google Workspace. You added a dozen SaaS apps. Your team logs in constantly, from laptops, phones, home networks, coffee shops. Every one of those logins mints a session token. Every token is a potential key.

Here is the uncomfortable part. The MFA you deployed, the authenticator app and the push notification, is a real improvement over passwords alone, but it is not phishing-resistant. The person approving the prompt has no way to tell they are approving it for an attacker’s page instead of the real site. Their eyes cannot see the difference. The URL is one character off. The lock icon is green. Everything feels normal.

And this matters more, not less, as your team adopts AI tools. The accounts that connect to your email, your documents, your customer data, and now your AI assistants are the highest-value targets in your business. A stolen session token on an admin account is not a password reset problem. It is an attacker reading everything, sending mail as your executive, and pivoting into connected systems, all while your MFA logs show a clean, successful login.

We help clients adopt AI safely because we already understand their people, systems, data, security posture, and operational risk. That same principle applies here. You cannot protect what you have not mapped, and most businesses have never mapped which accounts, if hijacked mid-session, would do the most damage.

What to do this month

You do not need to panic, and you do not need to rip out your current MFA. You need to layer the right protections on the accounts that matter most. Here is the order we recommend.

1. Identify your highest-risk accounts first. Global admins, finance, executives, anyone with access to customer or patient data. These get the strongest protection. Not everyone needs a hardware key on day one, but these people do.

2. Move those accounts to phishing-resistant MFA. This means FIDO2 security keys or passkeys. Unlike app codes, these methods are cryptographically bound to the real website’s address. A FIDO2 key simply will not authenticate to an attacker’s lookalike domain, because the domain does not match. The attack breaks. CISA points organizations toward FIDO for exactly this reason.

3. Shorten session lifetimes and enforce conditional access. A stolen token is only useful while it is valid. Tightening session timeouts and requiring reauthentication for sensitive actions shrinks the attacker’s window. Conditional access policies can also flag or block logins from unusual locations, devices, or impossible-travel patterns.

4. Turn on token protection where your platform supports it. Microsoft Entra offers token protection that binds a session token to the specific device it was issued to, so a stolen cookie replayed from an attacker’s machine is rejected. Check whether your licensing includes it and turn it on.

5. Train your team on the new reality. The old advice was “check for the padlock and don’t reuse passwords.” The new advice is “even if you passed MFA, an unexpected login page you reached from an email or a search ad deserves suspicion.” Report it. Do not assume the code saved you.

None of this requires you to become a security engineer. It requires someone to look at your environment, rank your accounts by risk, and turn the right dials in the right order.

Common Questions

Does this mean my MFA is useless? No. App-based MFA still stops the overwhelming majority of automated attacks and credential-stuffing attempts. It is not useless. It is just not sufficient on its own for your highest-risk accounts, because the code can be captured and used by an attacker in the moment. Keep it, and add phishing-resistant methods on top for the accounts that matter most.

What makes FIDO2 and passkeys different? They are cryptographically tied to the exact web address you are logging into. A code from an app can be typed into any page, including a fake one. A FIDO2 key checks the actual domain before it responds, so it refuses to authenticate to a lookalike. That single property is what breaks the attack.

How do attackers steal the token if my password was never exposed? Your password is exposed, just not in the way people expect. You type it into a page that looks genuine, the attacker uses it to sign in to the real service on your behalf, and the service issues a session token proving that login succeeded. The attacker captures that token. From then on they replay it and skip login entirely.

Is this an AI-driven attack? The core technique is not AI, but AI is making the lure side far more convincing. AI-generated phishing emails, fake login pages, and voice or video impersonation make it easier to get someone to that page in the first place. The delivery is getting smarter while the token theft stays the same.

centrexIT has been the IT and cybersecurity partner for businesses across the western U.S. since 2002. If your team has MFA turned on but nobody has checked whether your highest-risk accounts are actually phishing-resistant, that gap is worth closing before someone finds it for you. Take the 2-Minute Cybersecurity Assessment: https://centrexit.com/assessment/cybersecurity/

Sources

• Attackers stand up a page mimicking the real sign-in screen, use the captured credentials to authenticate to the genuine service, and steal the resulting session cookie: Microsoft Threat Intelligence, “From cookie theft to BEC: Attackers use AiTM phishing sites as entry point to further financial fraud” (2023), https://www.microsoft.com/en-us/security/blog/2023/06/08/detecting-and-mitigating-a-multi-stage-aitm-phishing-and-bec-campaign/
• A stolen session cookie can be replayed to access an account while bypassing the multifactor authentication requirement: Microsoft Threat Intelligence, “From cookie theft to BEC: Attackers use AiTM phishing sites as entry point to further financial fraud” (2023), https://www.microsoft.com/en-us/security/blog/2023/06/08/detecting-and-mitigating-a-multi-stage-aitm-phishing-and-bec-campaign/
• Authenticator codes, SMS codes, and push notifications are vulnerable to common MFA bypass attacks, and FIDO is the phishing-resistant alternative: CISA, “Phishing-Resistant Multi-Factor Authentication Success Story: USDA’s Fast IDentity Online (FIDO) Implementation”, https://www.cisa.gov/resources-tools/resources/phishing-resistant-multi-factor-authentication-mfa-success-story-usdas-fast-identity-online-fido