In February 2026, a phishing-as-a-service (PhaaS) platform called EvilTokens went live. Within five weeks, it had compromised more than 340 Microsoft 365 organizations across five countries.Â
The targets of the platform received a message asking them to enter a short code at microsoft.com/devicelogin and complete their normal MFA challenge, then walked away believing they had verified a routine sign-in. They had actually handed the operator a valid refresh token scoped to their mailbox, drive, calendar, and contacts, with the lifespan of a tenant policy rather than a session.
The operator never needed a password, never tripped an MFA prompt, and never produced a sign-in event that looked like an intrusion. The attack succeeded because the OAuth consent screen has become an instinctive click, and the controls built to stop credential phishing do not look at the consent layer.
Security researchers call the resulting condition consent phishing or OAuth grant abuse. The phishing click that mattered last decade handed over a password. The phishing click that matters now hands over a refresh token, and it sits structurally below the identity controls most organizations still treat as the perimeter.
Why MFA Cannot See an OAuth Grant
A credential phish hands over a username and password that has to be replayed somewhere, and most identity stacks now demand a second factor at the replay. Even adversary-in-the-middle (AiTM) kits produce a session cookie tied to a sign-in event that the SIEM correlates against geography, device, and travel patterns.
 |
| Figure 1: Credential phishing leaves a sign-in trail the SIEM can correlate. |
An OAuth grant produces no replayed credentials. The user authenticates on the legitimate identity provider, finishes the MFA challenge on the legitimate domain, and clicks Accept. The token the attacker walks away with is the system working as designed. It is signed by the identity provider, scoped to whatever the user agreed to, and refreshable. MFA cannot block it because MFA has already happened.
 |
| Figure 2: An OAuth grant leaves no replay, just a refreshable token. |
The other problem is that refresh tokens then extend the window. The tokens EvilTokens issued survived password resets and remained valid for weeks or months, depending on the tenant configuration. Rotating the password did not invalidate the grant. Only explicit revocation, or a conditional access policy that demanded re-consent, closed it.
How Consent Got Normalized
This attack vector has existed since OAuth became standard. What changed is the environment it operates in. Users have been trained to click through consent screens at the rate they once clicked through cookie banners. Every AI agent installs Surface One. Every productivity integration surfaces one. Every browser extension that touches a SaaS account surfaces one. The volume of legitimate consent that a knowledge worker sees in a month exceeds anything that existed when the original OAuth…
Source link
Disclaimer
We strive to uphold the highest ethical standards in all of our reporting and coverage. We blogs.grocliq.com want to be transparent with our readers about any potential conflicts of interest that may arise in our work. It’s possible that some of the investors we feature may have connections to other businesses, including competitors or companies we write about. However, we want to assure our readers that this will not have any impact on the integrity or impartiality of our reporting. We are committed to delivering accurate, unbiased news and information to our audience, and we will continue to uphold our ethics and principles in all of our work. Thank you for your trust and support.
Website Upgradation is going on for any glitch kindly connect at [email protected]
