Topic starter
27/06/2026 1:46 pm
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.
Editorial analysis by NHI Mgmt Group, based on content published by Abnormal AI: “EvilTokens: Turning OAuth Device Codes into Full-Scale BEC Operations”.
Key questions
Q: What breaks when device-code phishing is allowed in a Microsoft tenant?
A: The control break is that a legitimate user login can still produce attacker-owned tokens.
Q: Why do refresh tokens create persistent access after MFA has succeeded?
A: Refresh tokens are designed to mint new access tokens without prompting the user again.
Q: How can security teams tell whether token replay controls are actually working?
A: They should look for fast revocation of suspicious sessions, short-lived token reuse windows, and conditional access policies that block repeated exchanges from untrusted infrastructure.
Practitioner guidance
- Disable device code authentication where it is not required Remove this OAuth flow through Conditional Access for environments that do not need headless-device sign-in, so the attacker loses the code-based entry path entirely.
- Treat refresh tokens as governed credentials Review token issuance, reuse, and revocation behaviour alongside passwords and MFA, because captured refresh tokens can preserve mailbox access after the initial sign-in.
- Shorten the time between token compromise and revocation Enable continuous access evaluation and confirm that policy enforcement reaches active sessions quickly enough to interrupt replay before persistence is established.
Bottom line: Device code phishing can bypass the assumptions many teams make about MFA because the victim authenticates on a real Microsoft page, not a fake one.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
This topic was modified 3 days ago by NHI Mgmt Group
27/06/2026 3:12 pm
MFA completion is not an access-ending event: This case shows that successful authentication can still produce attacker-controlled sessions when the resulting token chain is the real target. The governance mistake is treating MFA as the control boundary instead of one step in a larger authorisation and session-risk model. IAM teams need to evaluate whether their sign-in controls actually govern the post-authentication state, not just the login event.
A few things that frame the scale:
- Security researchers tracked consent phishing campaigns affecting 900 tenants and 3,000 user accounts in 2025.
A question worth separating out:
Q: What should teams do when a compromised email account is detected?
A: Teams should move immediately from detection to containment. That usually means logging the user out, terminating active sessions, forcing password resets, and adding the user to watchlists that can trigger endpoint containment or reauthentication. The response should be coordinated across identity, email, and endpoint controls so the attacker loses both access and persistence.
👉 Read our full editorial: EvilTokens shows how device code phishing bypasses MFA
This post was modified 3 days ago by NHI Mgmt Group