A sharp rise in OAuth device code phishing campaigns designed to exploit Microsoft 365 and other cloud platforms is forcing security leaders to re-think enterprise trust.
Account takeover is no longer about cracking weak passwords, it’s about hijacking trusted workflows that look and feel legitimate, even in environments where multi-factor authentication (MFA) is already switched on.
Account takeover used to be about stealing passwords. Now it means weaponising the everyday workflows your users rely on and using them to obtain long‑lived tokens that make an attacker indistinguishable from a legitimate employee.
These attacks are explicitly engineered for organisations that have already enabled MFA, which is shifting the battlefront from credential theft to abuse of consent and identity workflows.
Microsoft reportsroughly 600 million identity-based attacks against its customers every single day, detected via Microsoft Entra data, with billions of phishing e-mails globally now focused on compromising identities rather than just endpoints.
Ourown monitoring observed more than 50 000 OAuth device code phishing campaigns between March and May 2026, signalling a rapid and widespread adoption of this technique among cyber criminals.
Here’s how it works. Attackers register malicious OAuth applications and initiate legitimate device authorisation flows on Microsoft infrastructure. They send users convincing e-mails that appear to come from trusted brands, including Microsoft, DocuSign and even Mimecast itself, asking them to authenticate a device or access a document using a code.
Organisations should treat identity workflows and consent prompts as critical security controls, not background noise.
When victims follow the instructions and enter that code on the real Microsoft device login page, they complete the MFA challenge themselves and unknowingly grant the attacker’s app persistent access to their account.
From the platform’s side, everything looks normal. The real user has logged into a genuine Microsoft page, passed MFA and authorised an application. But the attacker now holds a long‑lived OAuth token that lets them act as that user. No password needed ever again.
Learning from first-hand experience
Mimecast’s researchers have seen attackers mimicking the company’s own device enrolment experience, displaying fake Mimecast branding and a “Get Authentication Code” button that refreshes the page and reveals a code directly in the browser.
In reality, Mimecast’s legitimate device enrolment process never shows codes on a webpage. Codes are delivered via e-mail and entered into a dedicated verification field. By shifting the code into the browser and tying it to a familiar security brand, adversaries exploit user expectations about how secure workflows should behave.
Once an attacker holds the token, the impact can be extensive. Attackers can read and send e-mail, access documents, manipulate collaboration tools and exfiltrate data, often without triggering traditional credential‑based alerts. The access is technically authorised, so many legacy controls simply treat the activity as routine.
No single control covers the full lifecycle of these attacks. Pre‑click link inspection might miss obfuscated URL chains and redirects. MFA is bypassed because the user completes the challenge on a genuine site. Behavioural tools might flag the odd activity, but usually in isolation. The result is that account takeover can unfold in plain sight.
The answer lies in connecting these fragmented signals into a unified view.
You need a platform that can join the dots. From the e-mail that delivered the device code, to the browser session that followed multiple redirects, to the consent that was granted to a suspicious app, and finally to the behavioural anomalies and data movements that happen afterwards. Without that end‑to‑end visibility, you’re simply relying on luck.
AI adds layers of complexity
Tools such as EvilTokens now let low‑skill actors launch large‑scale phishing campaigns that blend into everyday collaboration traffic, further blurring the line between normal and malicious behaviour.
As organisations embrace AI‑driven productivity, they’re also increasing the number of applications and workflows that users are asked to trust. If you don’t have strong governance over which apps can request consent, how those consents are monitored, and how anomalies are escalated, you’re effectively expanding the attack surface with every new integration.
Organisations should treat identity workflows and consent prompts as critical security controls, not background noise.
This means combining advanced, pre‑click inspection of URLs, real‑time protection around credential and consent events, post‑compromise behavioural analytics, and data exfiltration monitoring into a single, coordinated defence.
Attackers have realised they don’t need to break in when they can persuade users to open the door using the same trusted processes they rely on to get work done. It’s time to admit the account takeover playbook has changed. The only appropriate defence depends on us changing how we think about enterprise trust to work protected.
Practical steps security teams can take now
While device-code phishing is not a vulnerability that can be patched, the following controls could shrink the window between an employee being tricked and detection.
Restrict or disable the device code flow: Most organisations have no legitimate business need for OAuth's device authorisation grant, which was built for input-constrained devices like smart TVs. Consider disabling it via conditional access authentication flow policies, or restrict it to specific trusted device types and named employees.
Lock down consent to verified publishers: Turn off user consent for unmanaged or unverified third-party apps and require admin approval for anything outside a pre-vetted allow list. This closes the exact loophole attackers try to exploit by persuading an employee to grant consent directly, rather than stealing a password.
Alert on new and unusual OAuth grants: Stand up monitoring (or a SIEM/XDR rule) that flags newly registered app consents, especially those requesting broad mail, file, or Graph API permissions, or approved outside business hours. Long-lived tokens are the payoff for attackers, so catching the grant itself, not just downstream activity, is the highest-leverage detection point.
Share
