Device Code Phishing Is Eating MFA. Behavioral Detection Is the Backstop.

Key points

• Device Code phishing hands attackers a valid OAuth token without exposing a fake login page, so the identity provider sees a normal, successful authentication.
• Adversary-in-the-middle frameworks like Evilginx defeat most MFA by capturing the session cookie after the user completes the challenge.
• Phishing-resistant authenticators (FIDO2, certificate-based auth) block AiTM proxy attacks but leave consent phishing and device code phishing intact.
• Detection shifts to post-authentication behavior: impossible travel, mailbox rule creation, OAuth consent grants, and anomalous Graph API patterns.
• Device Code flow can be blocked outright via Conditional Access in Entra ID for tenants with no business need for it.

What does Device Code phishing actually do?

The victim is socially engineered into completing a legitimate OAuth device authorization flow on the attacker's behalf, handing over a valid access and refresh token without typing a credential on a hostile page. No proxy, no fake login screen to fingerprint. From the identity provider's perspective, the user authenticated correctly and approved the request. That's the part defenders keep underestimating: the session is real.

We've tracked this technique across nine Device Code phishing stories since 19 June 2026, including the Kali365 toolkit the FBI flagged in May, a subscription-priced service that abuses OAuth device-code flows to lift session tokens and walk straight past MFA.

AiTM frameworks still dominate the broader phishing market, relaying the session cookie after the user completes the MFA challenge. Token theft via infostealers produces the same outcome: a session that passes conditional access on the first hop.

Should you worry if MFA is already enabled?

Yes. Prevention controls keyed on whether MFA fired are not sufficient when the MFA fired legitimately and the user approved it. What's anomalous is everything after authentication: impossible-travel signals, unusual mailbox rule creation, OAuth app consent grants to unfamiliar publishers, mass file access in SharePoint or OneDrive, and anomalous Graph API call patterns. None of these signals are new individually. Stitching them together fast enough to interrupt a session before the attacker reaches persistence is the real problem.

Behavioral analytics are the right tool for that surface, at least in theory. Vendors pitching AI-driven UEBA will claim their models catch this within minutes. Treat those claims the way you'd treat any detection claim: ask for the false-positive rate, ask what telemetry is required, ask how the model behaves when the attacker moves slowly.

What can defenders do right now?

Four concrete controls for blue teams:

• Device Code flow can be disabled or restricted via Conditional Access in Entra ID. If there's no business need for it, block it. Microsoft's guidance on blocking the authentication flow is the primary reference.
• Token lifetimes matter. Shorter refresh-token windows reduce the value of a stolen session, at the cost of more re-authentication prompts.
• Phishing-resistant authenticators defeat AiTM proxy attacks but do not stop consent phishing or device code phishing on their own. The user is still the weak link at the approval step.
• App consent governance is underrated. Most tenants still allow user-level consent to third-party OAuth apps by default.

What to watch next?

"MFA enabled" stopped being a meaningful security posture statement around 2022. The fix is partly technical, partly policy, and mostly about admitting that. The attack surface is the approval step itself, and no credential control patches that. Watch whether Microsoft tightens default consent settings across commercial tenants; that single policy change would do more for most organizations than another layer of detection tooling.