🔑 IAM

AI-Powered Device Code Phishing Bypasses MFA at Hundreds of Organisations

A sophisticated phishing campaign is abusing the OAuth device authorisation flow to hijack Microsoft 365 access tokens while victims complete entirely genuine MFA challenges. Hundreds of organisations have been compromised. FIDO2 passkeys block this attack; push notifications, TOTP, and SMS codes do not. Organisations should block the device code grant in Conditional Access immediately.

5 min read
#phishing#mfa-bypass#oauth#device-code-flow#microsoft-365#identity#access-token#fido2#entra-id#ai-phishing

An active phishing campaign, analysed by Microsoft Threat Intelligence and Proofpoint, is compromising Microsoft 365 accounts at hundreds of organisations by exploiting the OAuth 2.0 device authorisation grant flow. The attack is particularly effective because the victim completes a fully legitimate Microsoft authentication process — entering their own credentials and satisfying their configured MFA challenge — without realising they are confirming an attacker’s session. AI-generated lure content is enabling personalised spear-phishing at industrial scale, accelerating the campaign significantly since March 2026.

How Device Code Phishing Works

The OAuth device authorisation grant was designed for a legitimate purpose: authenticating devices without a browser interface — smart TVs, printers, CLI tools, and IoT endpoints that cannot host a full interactive login flow. In the standard flow, the device generates a user code and instructs the user to visit microsoft.com/devicelogin, enter the code, and authenticate to link their account to the device. The device polls Microsoft’s authorisation server until the user completes the authentication step.

Attackers have weaponised this flow directly. The attacker initiates a device authorisation request themselves, obtaining a user_code from Microsoft’s server. They then deliver a phishing message to the target — a convincing Teams notification, a DocuSign-style document-sharing alert, or a LinkedIn direct message — directing the victim to microsoft.com/devicelogin with instructions to enter the attacker’s device code to “verify their account” or “access the shared document.”

The victim navigates to the genuine Microsoft portal. They enter the attacker’s code. They sign in with their own credentials. They approve the MFA challenge — whether a push notification, a TOTP code, or an SMS OTP. Microsoft then issues a valid OAuth access token and refresh token to the attacker’s waiting polling session. The entire transaction occurs on legitimate Microsoft infrastructure. No credential is intercepted, no proxy is involved, and no MFA token is captured. The attacker simply receives an authorised token from Microsoft directly.

Why Standard MFA Offers No Protection

The critical point is that in this attack, MFA is not bypassed — it is completed legitimately by the victim. The victim is genuinely authenticating. The MFA challenge is real, delivered by Microsoft, and correctly answered. The problem is that the MFA challenge validates the user, not the session the user believes they are authorising.

This means the following MFA methods provide no protection against device code phishing:

  • SMS OTP — the code is delivered by Microsoft and entered correctly by the victim
  • Authenticator app push notifications — the push prompt is genuine and the victim approves it
  • TOTP codes (Google Authenticator, Microsoft Authenticator, hardware tokens in TOTP mode) — a valid code is entered
  • Yubikey in OTP mode — the OTP is generated and accepted correctly

The only controls that block this attack:

  • FIDO2 / WebAuthn passkeys — authentication is cryptographically bound to both the origin URL and the physical authenticator device. The device code flow cannot satisfy a FIDO2 challenge because it lacks the correct relying party binding context. FIDO2 is the definitive technical control.
  • Certificate-based authentication (CBA) — similarly bound to device identity in a way that cannot be satisfied via the device code flow.
  • Conditional Access policies blocking the device code grant — Microsoft Entra ID supports Conditional Access conditions on authentication flows, allowing organisations to block or restrict the device authorisation grant entirely for user populations that do not require it.

AI-Amplified Scale

Microsoft’s threat intelligence team attributes the recent acceleration of this campaign to AI-generated lure content. The phishing messages observed are personalised to the target’s organisation, role, and visible professional activity — referencing plausible internal document names, mimicking the communication style of known colleagues, and impersonating internal IT or compliance workflows.

This personalisation, generated at scale by large language models from information scraped from LinkedIn, corporate websites, and previously leaked data, produces substantially higher click-through rates than generic phishing templates. Proofpoint notes that campaign infrastructure is rotating frequently to evade detection, with attacker-controlled device code requests cycling across multiple tenant IDs to circumvent rate-limiting.

Tokens obtained via this method grant access to Microsoft 365 email, SharePoint, Teams messages, OneDrive files, and — critically — can be used to register persistent OAuth application grants that survive password resets. Several confirmed intrusions have proceeded from token theft to persistent OAuth application registration within minutes of the initial compromise.

  • Migrate privileged accounts to FIDO2 passkeys immediately. Accounts with access to email, SharePoint, Teams, finance systems, HR data, and administrative functions should be migrated to phishing-resistant authentication. This is the definitive technical control and removes the attack surface entirely for enrolled accounts.
  • Block the device code grant in Conditional Access. In Microsoft Entra ID, create a Conditional Access policy targeting all users with the condition set to “Authentication flow: Device code flow” → Block. Audit your environment first for any legitimate use of device code flow (IoT devices, kiosk applications, CLI tooling) and create exemption groups for those workloads before enabling the block.
  • Audit existing OAuth application consents. Attackers who have already obtained tokens may have registered persistent OAuth applications. In Entra ID, review enterprise application consents for recently added applications with broad scopes — particularly Mail.ReadWrite, Files.ReadWrite.All, Contacts.Read, and offline_access grants added in the past 60 days.
  • Alert on device code flow sign-in events. In Microsoft Entra ID sign-in logs, filter authentication events by grant type “Device code”. In most enterprise environments, these events are rare; any user without a documented IoT or non-browser device use case appearing in these logs warrants review.
  • Train users with a specific recognition signal. A legitimate service will only direct a user to microsoft.com/devicelogin if that user initiated a device setup. If you did not start a device registration process, do not enter any code. This is the human-layer control while technical mitigations are deployed.
  • Deploy Microsoft Entra ID Protection and configure risk-based Conditional Access requiring re-authentication or blocking high-risk sessions, including anomalous device code flow authentication from unfamiliar locations.