MFA is still worth using, but token theft means organizations must stop treating one approved prompt as proof of safety. EvilTokens-style attacks, along with other adversary-in-the-middle phishing kits, can steal session cookies after a user completes MFA, letting attackers skip the next login challenge.
TLDR: EvilTokens MFA attacks show how attackers can bypass weak MFA by stealing tokens after a real login. For example, a finance employee may enter credentials and approve a push prompt on a fake Microsoft 365 page, while the attacker silently captures the session cookie and opens the mailbox minutes later. In many incident reports involving phishing-resistant MFA gaps, token replay turns a 30-second mistake into days of inbox access. Security teams should focus on phishing-resistant MFA, token binding, sign-in anomaly detection, and fast session revocation.
What EvilTokens MFA attacks are
EvilTokens refers to attacks that target authentication tokens, not just passwords. The attacker does not always need to know the password forever. They only need enough access to capture a valid session token after the victim completes login.
This commonly happens through an adversary-in-the-middle phishing flow. A fake login page sits between the victim and the real service. The victim sees a normal-looking sign-in screen. The real service receives the credentials and MFA response. The attacker receives the authenticated session token.
The catch is that everything can feel normal to the user. The login works. The MFA prompt arrives. The dashboard loads. Nothing screams “breach.” That quiet success is exactly why these attacks are so irritating for defenders.
How attackers bypass MFA without “breaking” it
Most EvilTokens-style attacks do not crack MFA cryptography. They abuse timing, trust, and session handling. Common techniques include:
- Adversary-in-the-middle phishing: The attacker proxies traffic between the victim and the real service, then captures the session cookie after MFA succeeds.
- Token replay: A stolen cookie or bearer token is reused from another browser, device, or location to access the account.
- Push fatigue: The user receives repeated MFA prompts until they approve one just to stop the noise.
- Consent phishing: A malicious app asks for OAuth permissions, giving attackers access without needing the user’s password again.
- Help desk social engineering: Attackers trick support staff into resetting MFA or enrolling a new device.
- Malware-assisted theft: Infected endpoints steal browser cookies, refresh tokens, and saved credentials.
Honestly, it feels like some admin portals still make defenders work too hard. A session may remain valid for hours by default, and revoking it can take longer than anyone wants during an active incident.
Why token theft is risky
A stolen session token can act like a temporary master key. If valid, it may let an attacker read email, download files, create forwarding rules, register persistence, or access connected SaaS apps.
The risk grows when systems allow long-lived sessions. Refresh tokens are even worse. They can issue new access tokens without requiring the user to sign in again. If device checks are weak, the attacker may keep coming back.
Cloud email is a frequent target. Once inside a mailbox, attackers can search for invoices, password resets, contracts, and internal chats. They can hijack conversations. They can send believable payment-change messages. A single stolen token can become a full business email compromise case.
Warning signs security teams should watch
Detection works best when identity, endpoint, email, and SaaS logs are viewed together. No single alert catches every case. Strong signals include:
- Impossible travel: A login from London followed by activity from another country within minutes.
- New device fingerprints: A valid session appears from an unfamiliar browser, operating system, or IP range.
- MFA completed, then odd behavior: The user passes MFA, but immediately creates inbox rules or downloads many files.
- Multiple failed phishing sessions: Several users visit the same suspicious domain near the same time.
- OAuth permission changes: A new app receives mail, file, or directory access.
- Session reuse from hosting providers: Access comes from VPS networks, VPN exits, or anonymizing services.
- Mailbox rule creation: New rules hide replies, forward mail, or move security alerts to obscure folders.
Defensive measures that reduce token theft
The strongest answer is phishing-resistant MFA. FIDO2 security keys, passkeys with strong device binding, and certificate-based authentication make token theft far harder than SMS, email codes, or basic push approvals.
Organizations should also shorten session lifetimes for risky apps. They should require reauthentication for sensitive actions, such as payment changes, MFA enrollment, app consent, and mailbox forwarding. Conditional access should check device compliance, location, risk score, and user behavior.
Defenders should consider these controls:
- Use FIDO2 or passkeys for admins, finance teams, executives, and high-risk users.
- Disable legacy authentication wherever possible, since it often skips modern MFA controls.
- Bind sessions to trusted devices and block access from unmanaged endpoints for sensitive systems.
- Limit persistent sessions and apply stricter rules after password resets or suspicious sign-ins.
- Monitor OAuth grants and require admin approval for high-risk permissions.
- Train users on real phishing flows, including fake MFA pages and unexpected consent screens.
- Harden help desk processes with callback checks, manager approval, and identity proofing for MFA changes.
- Automate token revocation when high-confidence alerts fire.
Incident response steps after suspected token theft
Speed matters. Password resets alone may not remove an active session. The response team should revoke refresh tokens, terminate sessions, remove malicious OAuth apps, check inbox rules, and inspect recent sign-ins.
They should also review endpoint health. If malware stole cookies from the browser, resetting cloud sessions will not be enough. The infected machine may hand over fresh tokens again after the user logs back in.
A practical response plan includes:
- Disable risky sessions and revoke refresh tokens.
- Reset the password if credential theft is likely.
- Remove unknown MFA devices and suspicious OAuth grants.
- Search email rules, forwarding settings, and sent mail.
- Review file downloads and shared links.
- Scan the endpoint for malware and browser theft tools.
- Preserve logs for legal, insurance, and recovery teams.
FAQ
Can MFA still stop attackers?
Yes. MFA blocks many password-based attacks. The problem is that weaker MFA can be bypassed through phishing, push abuse, or token theft. Phishing-resistant MFA gives much better protection.
What is the difference between a password and a token?
A password proves identity during login. A token proves that login already happened. If an attacker steals a valid token, they may not need the password for that session.
Are SMS codes safe enough?
SMS is better than no MFA, but it is weaker than app-based number matching, passkeys, or hardware security keys. SMS can be phished, intercepted, or abused through SIM-swap attacks.
What should an organization do first?
It should protect high-risk users with FIDO2 keys or passkeys, block legacy authentication, monitor risky sign-ins, and prepare a fast token revocation process.
How can users spot an EvilTokens-style phishing page?
They should check the domain, avoid links from unexpected emails, watch for unusual consent screens, and report MFA prompts they did not initiate. A login that “works” can still be malicious if the site was fake.