Device Code Phishing Is Eating MFA. Behavioral Detection Is the Backstop.
Token theft and consent-grant abuse sidestep the second factor entirely. Defenders are leaning on anomaly detection because the login looks legitimate.
MFA was supposed to end credential phishing. It didn't.
Attackers stopped trying to steal passwords and started stealing sessions. Device Code phishing is the cleanest example: 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. The phishing kit doesn't proxy anything. There is 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.
Adversary-in-the-middle (AiTM) frameworks like Evilginx still dominate the broader phishing market, and they also defeat most MFA by relaying the session cookie after the user completes the challenge. Token theft via infostealers — a separate but related problem — produces the same outcome: a session that passes conditional access on the first hop.
The operational consequence is that prevention controls keyed on "did MFA fire?" are not enough. The MFA fired. The user approved it. The session is real. What's anomalous is everything that happens after.
This is where behavioral analytics earn their keep, at least in theory. The detection surface shifts from authentication events to post-auth telemetry: 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 are new individually. Stitching them together fast enough to interrupt a session before the attacker pivots to persistence is the actual problem.
A few practical notes for blue teams looking at this category honestly:
- Device Code flow can be disabled or restricted via Conditional Access in Entra ID. If you don't have a business need for it, turn it off. 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-auth prompts.
- Phishing-resistant authenticators (FIDO2, certificate-based auth) defeat AiTM proxy attacks but do not, by themselves, defeat consent phishing or device code phishing. The user is still the weak link in the approval step.
- App consent governance is underrated. Most tenants still allow user-level consent to third-party OAuth apps by default.
Vendors pitching AI-driven UEBA will tell you 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, and ask how the model behaves when the attacker takes it slow.
The attack class isn't going away. The patch is partly technical, partly policy, and mostly about admitting that "MFA enabled" stopped being a meaningful security posture statement somewhere around 2022.
