The Bottom Line: So-called “consent phishing” circumvents modern security controls by exploiting the intuitive acceptance of OAuth consent screens. Unlike classic password phishing, these attacks generate no suspicious login events and are invisible to MFA and SIEMs, since authentication proceeds legitimately.
The phishing-as-a-service platform EvilTokens compromised more than 340 Microsoft 365 organizations across five countries in February 2026. The attackers use a sophisticated method: users are directed to a seemingly legitimate login page where they complete their multi-factor authentication (MFA) and unwittingly hand over their refresh tokens to the attackers.
The attack pattern is insidious: victims receive a message asking them to enter a short code at microsoft.com/devicelogin and complete their regular MFA challenge. They believe they have completed a routine login verification. In reality, they have given the attacker a valid refresh token that accesses mailbox, drive, calendar and contacts, and remains valid for weeks or months according to the tenant’s policy.
What makes this method particularly dangerous: the attacker never needs the password, does not trigger an MFA prompt, and creates no suspicious login event. The OAuth consent screen has become habitual – users now click through them routinely, just as they once did with cookie banners. Every AI agent, every productivity integration, and every browser extension with SaaS connectivity presents such consent screens. The volume of legitimate requests far exceeds the security awareness of average users.
The fundamental problem: MFA cannot block such tokens because authentication actually took place legitimately at the real identity provider. The issued token is correctly signed by the system and refreshable. Even password rotations do not invalidate already granted permissions – only explicit revocation or conditional access policies that enforce re-consent close this gap. This reveals a structural problem: while organizations have built their security at the boundary of authentication, this attack vector operates below that layer, in the OAuth consent layer.