More than 12,000 Microsoft inboxes opened without a stolen password. According to the Microsoft Security Blog, EvilTokens PhaaS socially engineered workforce users to enter a live attacker-generated device code on Microsoft’s legitimate device-login page, complete normal sign-in including MFA, and unknowingly authorize the threat actor’s session so OAuth access and refresh tokens issued to the attacker’s polling client. From February 2026 until disruption on 22 September 2026, that kit hit over 10,000 organizations, roughly 97% of them enterprise domains, with persistent mailbox access, malicious inbox rules, Graph reconnaissance, and AI-assisted BEC targeting. Public reporting does not establish per-organization victim counts, total financial loss, or named primary victim organizations.
Victims finished real microsoft.com MFA and still lost the session
EvilTokens did not proxy a fake password form. It abused the legitimate OAuth 2.0 device authorization grant, the flow built for limited-input devices, against ordinary workforce Microsoft 365 users.
The kit generated a live device code, presented copy-and-continue UX under one of 44 phishing themes, and steered the user to the official microsoft.com device-login endpoint. During the roughly 15-minute window, attacker-controlled Node.js polling nodes watched status. When the user entered the code and completed whatever MFA the tenant required (push, TOTP, or another method the org already enforced), Microsoft issued tokens to the client that had requested the code. That client belonged to the operator, not the victim.
Microsoft’s own phrasing is blunt. "When the user enters the code, they unknowingly authorize the threat actor’s session, granting access to the account without exposing credentials." No password left a fake page. No OTP seed was scraped from a reverse proxy. Authentication had already succeeded on the real identity provider before the theft mattered.
That is why framing this as an MFA "bypass" fails. There was nothing left to challenge at the login form. The user willingly finished a real ceremony. The transferable prize was the bearer material that followed: access tokens, refresh tokens, and in some cases paths that led toward a Primary Refresh Token for longer cloud persistence.
The same device-code coaching pattern showed up earlier against government and defense tenants in the Midnight Blizzard device-code campaign. EvilTokens industrialized it as phishing-as-a-service. Microsoft tracks the operators under Storm-2992. The kit sold on Telegram for about $1,500 up front plus $500 per month, turning a protocol convenience into a subscription product.
| Control in place | What reporting shows | Why it did not save the mailbox |
|---|---|---|
| Tenant MFA at sign-in | User completed real microsoft.com MFA | Tokens issued after success to attacker client |
| Password not phished | No credential harvest from a fake form | OAuth grant never needed the password again |
| Phishing-resistant login factor | User still approved the real device code | Willing completion authorizes the polling client |
| Long-lived cloud sessions | Refresh tokens auto-renewed access | Ceremony was already over |
How EvilTokens productized the device grant
Microsoft’s Digital Crimes Unit, working with Health-ISAC, SpyCloud, and law enforcement (including UK arrests), disclosed and disrupted EvilTokens infrastructure on 22 September 2026. By then the platform had been live since February 2026. In April 2026, Microsoft was already tracking aligned activity that used short-lived automated polling nodes for device-code generation and post-compromise work.
The commercial shape matters as much as the protocol abuse. Affiliates did not need to build an AiTM reverse proxy or steal OTP seeds. They needed lures good enough to make a workforce user type a code and finish the real page. Themes rotated across dozens of templates. Highest observed victim activity concentrations sat in the United States, Canada, the United Kingdom, Australia, India, and France. Industries in the mix included wholesale distribution, construction, financial services, real estate, higher education, and healthcare.
Once tokens arrived, the kit’s post-access features did the quiet work. Operators read mail, mapped Microsoft Graph, and ran AI-assisted inbox analysis to pick BEC targets. Microsoft states that stolen tokens were used for email exfiltration and persistence, "often through the creation of malicious inbox rules that conceal communications." Some cases went further and registered new devices for longer-lived access. Admin-oriented detection features inside the kit helped operators notice when a tenant started to push back.
SSO and federation made every stolen session louder. A Microsoft 365 cloud token is not a single-app cookie in practice. Mail, files, Graph APIs, and whatever else trusts the same identity plane become reachable without a fresh interactive login. Classic SSO auto-sign-on collides with zero-trust language here: one proof, many doors, and the proof already sat with the wrong party.
Public reporting does not establish that every victim saw PRT issuance. Public reporting also does not establish that disruption permanently ends kit clones. The protocol remains. The commercial incentive remains.
What defenders actually had left after the tokens existed
At the moment of issuance, MFA had already done its job on the legitimate page. Stronger login cryptography does not retract a refresh token the user just authorized to someone else’s client. Closing the path is not a second prompt. It is refusing the grant shape and killing sessions fast when suspicion appears.
Microsoft’s published guidance matches that reality. Block or disable device code flow through Conditional Access wherever the organization does not truly need it, with tight exceptions only for cases such as Teams device resource accounts. Revoke sessions and tokens on suspicion. Prefer phishing-resistant MFA and monitoring as layered hygiene, not as a story that a willing device-code approval becomes harmless.
Token lifetime is not a substitute for that block. Shortening lifetimes forces re-theft or re-use sooner. It does not prevent the first successful grant. If the operator registers their own authenticator or device during the window of access, lifetime limits stop mattering for the new legitimate factor they now hold.
Residual truth for operators reading incident notes: fooling a user into completing a real device-code approval is a social-engineering problem against a still-enabled grant. Planting malware on an already-logged-in PC to scrape memory is a different and harder problem. EvilTokens scaled the first path. Revoke, Conditional Access blocks on device code flow, and strict device enrollment policy are the controls that address what this kit actually sold. Login MFA, including phishing-resistant methods at the passwordless ceremony, does not undo tokens already issued after a user willingly finishes real Microsoft authentication.
If you want to skip the attack details and go straight to what can stop this class of device-code OAuth theft, read the related article on mfa2point0.com: prevent Microsoft 365 device code flow phishing and speed token revocation.
FAQ
Did EvilTokens steal passwords or one-time codes from a fake login page?
No. EvilTokens did not harvest passwords or OTP seeds from a spoofed Microsoft login form. According to Microsoft’s Unmasking EvilTokens disclosure, victims entered an attacker-supplied device code on the real microsoft.com device-login page, completed normal sign-in including MFA, and OAuth access and refresh tokens were issued to the attacker’s polling client instead of remaining only with the user.
Why didn’t finishing MFA stop EvilTokens from reading mail?
Finishing MFA on the legitimate Microsoft page is exactly when the OAuth device authorization grant can issue tokens. In the EvilTokens campaign those tokens went to Storm-2992’s client. MFA had already succeeded at issuance, so it could not undo mailbox, Graph, or refresh-token abuse that followed. The failure was authorizing the wrong client through a still-enabled device code flow, not failing a push or TOTP challenge on a proxy page.
How big was the EvilTokens victim set?
According to Microsoft Threat Intelligence reporting on the Microsoft Security Blog, EvilTokens compromised more than 12,000 Microsoft accounts and inboxes across over 10,000 organizations worldwide after emerging in February 2026, with disruption disclosed on 22 September 2026. Roughly 97% of victim domains were enterprise. Public reporting does not establish exact counts per organization or total financial loss.
Is this the same attack as AiTM reverse-proxy phishing?
No. A typical AiTM kit sits between the user and the identity provider, relays password and live MFA responses, and steals a session from a proxied ceremony. EvilTokens coached users onto the real device-login endpoint and abused the OAuth 2.0 device authorization grant so Microsoft issued tokens directly to the attacker’s polling client. Both end in stolen cloud sessions. Only one requires a fake login origin.
What should IT managers disable first after reading the EvilTokens disclosure?
Microsoft recommends blocking device code flow wherever possible through Conditional Access, with narrow exceptions only where the business truly needs it. Pair that with rapid session and token revocation on suspicion, review of newly registered devices and malicious inbox rules, and monitoring for Graph and mailbox anomalies. Phishing-resistant MFA remains useful hygiene at interactive login. It does not, by itself, stop a user who willingly completes a real device-code approval while the flow stays enabled.
