You followed the rules. You use a password manager. Every password is unique, random, 16 characters minimum. You enabled two-factor authentication everywhere that offers it. You ignored every phishing email that tried to trick you into typing your credentials into a fake login page.

You did everything right. And attackers just found a way to break into your Microsoft account without touching your password at all.

This isn't a vulnerability. It's not a bug Microsoft can patch. It's worse than that — it's attackers using Microsoft's real login system exactly the way Microsoft designed it, just redirecting the outcome to themselves instead of you. Your password never gets stolen because they never needed it in the first place.

Here's what everyone thinks authentication is: you type your username and password, maybe a six-digit code from your phone, and you're in. The password is the thing being protected. Steal the password, steal the account.

That hasn't been true for years.

What actually happens when you log into most modern systems is this: you prove who you are to the login system (that's the password part), and then the login system hands your browser a token — a digital object that says "this person is authenticated." That token is what actually gets you into the account. Every request you make after login is validated by showing that token, not by re-entering your password.

The new attack — called EvilTokens — works by tricking you into logging in through the real Microsoft login page, then stealing the token that Microsoft generates after you successfully authenticate. You're logging in legitimately. Microsoft's systems see nothing wrong. But the token that's supposed to grant you access gets quietly handed to someone else.

From Microsoft's perspective, the login worked. From your perspective, nothing happened — the page didn't load, or it threw an error, and you move on with your day. From the attacker's perspective, they now have a valid token that grants full access to your account. No password required. No phishing detection triggered. No fake login page that security training taught you to spot.

For the last decade, the security industry has been screaming about passwords. Passwords are weak. Passwords get reused. Passwords get phished. Every company with a security budget invested in password managers, multi-factor authentication, passwordless login, biometric verification — anything to move away from passwords as the weak point.

And it worked. Passwords are more protected now than they've ever been. Credential-stuffing attacks are harder. Phishing pages get flagged faster. Users are better trained.

But all of that effort has pushed attackers to the next step in the authentication chain: the token. Because once you're past the login screen, your access is controlled by a piece of data your browser stores and presents automatically. That data is less protected than your password ever was. Your password manager doesn't guard it. Your MFA app doesn't see it. Your security training never mentioned it.

And unlike passwords, tokens are designed to be passed around. They're meant to move between systems, to be presented automatically, to work without user interaction. That design makes them extraordinarily useful. It also makes them extraordinarily easy to steal once an attacker gets you to generate one.

This is the part where most security advice falls apart, because the honest answer is: if the attack is sophisticated enough, and the platform doesn't detect it, there's no user-side behavior that stops it 100% of the time. But there are things that make you harder to target.

1. Log out of everything when you're done. Tokens expire when sessions end. If you don't stay logged in, there's no long-lived token sitting in your browser waiting to be stolen.

2. If a login fails or behaves strangely, assume someone tried. The EvilTokens attack often results in a failed page load or an error after you authenticate. If that happens, immediately change your password and revoke all active sessions in your account settings. Microsoft, Google, and most platforms have a "sign out everywhere" option.

3. Check your account's active sessions regularly. Most platforms show you where you're currently logged in. If you see a device or location you don't recognize, kill it. Don't wait to investigate — revoke first, ask questions later.

4. Be suspicious of login links, even when they look legitimate. The EvilTokens attack works by sending you to the real Microsoft login page — but with a redirect parameter that sends the token somewhere else after you authenticate. If you receive an email or message asking you to log in, go directly to the site yourself instead of clicking the link.

5. Enable device-based conditional access if your platform offers it. Some enterprise systems can require logins to come from recognized devices. This doesn't stop the token from being stolen, but it does stop it from being used on the attacker's machine.

I learned about post-authentication risk the hard way — not from an EvilTokens attack, but from something simpler that taught me the same lesson.

A few years back, I was doing an assessment for a large retail organization. Their MFA rollout was textbook. Authenticator apps, strong password policy, the works. On paper, their authentication stack was solid.

During the engagement, I pulled their conditional access logs and found something nobody had flagged: a handful of accounts were generating valid session tokens from two geographic locations within minutes of each other. The users' passwords were fine. MFA had passed every time. But the tokens were being replayed from IPs in Eastern Europe.

These weren't sophisticated attackers. They'd gotten the tokens through a basic adversary-in-the-middle proxy — nothing close to what EvilTokens does. But the core problem was identical: once the token exists, the password is irrelevant. The authentication event already happened. The token is the access.

What surprised me wasn't the technique. It was how long it had been happening. Months. Because all of the alerting was built around credential events — bad passwords, MFA failures, suspicious login attempts. Nobody had built monitoring around token usage anomalies. The login looked clean every time because it was clean. The theft happened after. Keep in mind that this was a few years ago where organizations were only looking at the front door where user authentication happened. Today organizations should be looking at every request, validate every request. Zero trust.

That engagement is why I get frustrated when organizations treat MFA as a finish line. It's not. It's the start of a different attack surface — one most teams aren't watching.

The EvilTokens campaign is a sophisticated version of the same principle. The vector is newer. The outcome is the same: an authenticated session that belongs to someone else, and logs that show nothing wrong.

If your org isn't monitoring for token replay — concurrent sessions from impossible locations, tokens used outside registered device profiles, session lifetimes that exceed your policy — you're flying blind after the login screen. The password was never what they were after.

Have you ever logged into something successfully, then had the page fail to load or throw an error — and later discovered someone tried to access your account? Reply and share what happened.

Identity Decoded publishes every week at identity-decoded.com