TL;DR: EvilTokens productizes Microsoft 365 compromise by abusing Device Code OAuth, replaying refresh tokens for up to 90 days, and using LLaMA to turn inboxes into BEC intelligence, according to Abnormal AI. The real lesson is that MFA success does not equal session safety when token replay and conditional access gaps remain open.
NHIMG editorial — based on content published by Abnormal AI: EvilTokens and Microsoft device code phishing analysis
By the numbers:
- 64% of valid secrets leaked in 2022 are still valid and exploitable today, proving that detection alone is not enough without automated revocation.
- AI-related credential leaks surged 81.5% year-over-year in 2025, with the surrounding AI infrastructure leaking 5x faster than core LLM providers.
Questions worth separating out
Q: How should security teams stop device code phishing in Microsoft 365 environments?
A: Start by disabling device code authentication everywhere it is not explicitly needed, then allow it only for approved headless devices through tightly scoped Conditional Access.
Q: Why do successful MFA prompts not prevent OAuth token abuse?
A: Because MFA proves a user completed authentication, not that the resulting token will stay bound to a trusted device or safe session.
Q: What breaks when defenders focus only on phishing pages instead of token replay?
A: They miss the real compromise path.
Practitioner guidance
- Disable device code authentication where it is not required Use Conditional Access to block the device code flow for standard users, and allow it only for approved headless-device scenarios with explicit business justification.
- Tighten token revocation and session evaluation Pair Continuous Access Evaluation with rapid revocation playbooks so refresh tokens cannot keep a compromised mailbox alive for days.
- Constrain named locations and cloud relay sources Block or challenge authentication from known relay infrastructure and suspicious PaaS ranges, then review whether legitimate workloads still need those paths.
What's in the full article
Abnormal AI's full analysis covers the operational detail this post intentionally leaves for the source:
- The full attack-chain walk-through, including the device code flow sequence and token exchange mechanics.
- Infrastructure indicators such as Railway ranges, Cloudflare worker patterns, and self-hosted backend details.
- MailVault admin-panel behaviour, including send-as-target capability, directory enumeration, and keyword alerting.
- The specific mitigations and conditional access logic used to disrupt the campaign.
👉 Read Abnormal AI's analysis of EvilTokens and Microsoft device code phishing →
Device code phishing and token replay: what IAM teams miss?
Explore further
Device-code authentication assumes the user interaction and the token recipient are aligned. That assumption fails when the code is collected by an attacker-controlled workflow and the resulting OAuth grant is replayed elsewhere. The programme implication is that phishing controls built around fake-login detection do not address the actual trust boundary being abused.
Mailbox compromise is increasingly a session-governance problem, not a password-reset problem. Teams that still optimise only for phishing detection will miss the attack class where authentication is legitimate but the resulting token is not. The programme shift is toward policy control, token revocation, and mailbox telemetry that can detect automated abuse after login.
A question worth separating out:
Q: Who is accountable when compromised mailbox tokens are reused for business email compromise?
A: Accountability sits across identity operations, email security, and incident response because the failure spans authentication policy, token governance, and message abuse. Teams should define ownership for Conditional Access policy, token revocation, and mailbox monitoring before an incident, so containment does not stall when access abuse begins.
👉 Read our full editorial: EvilTokens shows how device code phishing bypasses MFA