Device Code Phishing: How OAuth Token Theft Bypasses MFA (and How to Detect It)

Device code phishing is an attack where the adversary starts a legitimate OAuth device-code sign-in, then tricks the victim into entering the attacker's code on the real Microsoft login page. The victim authenticates normally, MFA included, but the access token lands in the attacker's session. No fake page, no stolen password, no malware.

That last sentence is the whole problem. Every phishing control you have built in the last decade assumes there is something fake to catch: a lookalike domain, a credential harvesting form, a malicious attachment. Device code phishing uses none of them. The victim types a code into microsoft.com/devicelogin, a page your security awareness training has spent years telling them to trust.

Why a stolen token beats a stolen password

Start with what the attacker actually walks away with. Not a password. An OAuth access token, and usually a refresh token alongside it. MITRE ATT&CK tracks this as Steal Application Access Token, and the technique page is blunt about why it matters: a token grants access to resources without any further knowledge of the user's credentials.

Here is the part that surprises people the first time they work one of these incidents. The victim completes multi-factor authentication correctly. They get the real prompt, they approve it on their real phone, and the identity provider is satisfied. The MFA bypass is not a bypass of the challenge; it is a redirection of the reward. The token issued after that successful challenge goes to whoever initiated the flow, and the attacker initiated it.

From that point on, the token is self-sufficient. Every subsequent API call the attacker makes rides on it with no password and no second factor. If the flow requested the offline_access scope, the attacker also holds a refresh token, which mints new access tokens on demand. Reset the user's password and nothing happens. The refresh token does not care. It keeps working until it expires or someone revokes it, and most tenants revoke nothing until an incident forces the question.

Two roads to the same token

T1528 covers two distinct social engineering paths, and it pays to keep them separate in your head because they leave different log trails.

The first is consent phishing. The attacker registers their own OAuth application and dresses it up as something trustworthy. When APT28 ran this play against Gmail and Yahoo users, the rogue apps carried names like "Google Defender" and "McAfee Email Protection." The app requests delegated permissions, typically Mail.Read, Files.ReadWrite.All, and offline_access, and the victim is asked to click Accept on the identity provider's genuine consent screen. Nothing in the URL bar is wrong. The page is real. The permissions grant is real. The only lie is who is behind the application, which is exactly why Microsoft maintains dedicated guidance on consent phishing: the consent screen displays every permission, but users accept because a legitimate provider hosts the prompt.

The second is device code phishing. No rogue app registration at all. The attacker abuses the OAuth 2.0 device authorization grant, a flow built for input-constrained devices like smart TVs and conference room hardware that cannot render a browser login. The attacker requests a device code from Microsoft's own endpoint, receives a short user code, and then needs one thing: a human willing to type that code into the legitimate device login page while signed in as themselves.

Both roads end in the same place. The attacker holds a token issued to a session they control, and everything downstream looks like the user.

The Teams invite that was never a meeting

The clearest picture of the device code path in production comes from Storm-2372, a suspected Russia-aligned nation-state actor whose campaign Microsoft documented in February 2025 and traced back to August 2024. Targets spanned government, NGOs, IT and technology, defense, telecom, health, higher education, and energy across Europe, North America, Africa, and the Middle East.

Walk through it from both chairs.

The victim receives what looks like a Microsoft Teams meeting invitation. Storm-2372 often built rapport first over WhatsApp, Signal, or Teams itself, posing as someone relevant to the target before the invite ever arrived. The lure delivery is classic phishing; it is everything after the click that is unusual. The invite presents a code, framed as a meeting ID, and instructions to enter it at microsoft.com/devicelogin to join. The victim opens the page. It is genuinely Microsoft. The certificate is valid, the branding is right, and their browser may already be signed in. They type the code, approve the MFA prompt, and see a success message. No meeting starts, which most people write off as a broken link.

Meanwhile the attacker's side has been polling the token endpoint since they generated that code. The moment the victim authenticates, Microsoft issues the access and refresh tokens into the attacker's polling session. Done. Total malware deployed: zero.

Storm-2372's post-compromise activity shows what a token is worth. The actor used Microsoft Graph to keyword-search the compromised mailbox for terms like password, admin, credentials, secret, and gov, then exfiltrated the matching mail. They also sent fresh device code lures from the victim's own mailbox to internal contacts, which converts one compromised account into a beachhead with built-in credibility.

Then it got worse. In a February 14, 2025 update, Microsoft reported Storm-2372 shifting to the client ID of the Microsoft Authentication Broker. That specific client can request a refresh token usable against the device registration service, which let the actor register an attacker-controlled device in Entra ID and obtain a Primary Refresh Token. A PRT is the crown jewel of Windows cloud authentication. At that point the attacker does not just have a session; they have a device the tenant trusts.

The technique has since gone downmarket. Proofpoint's research on the evolution of device code phishing documents the shift from a niche red team trick to a commodity, with phishing-as-a-service kits such as EvilTokens and Tycoon selling ready-made attack chains. The kits also fixed the technique's one operational weakness: device codes expire after about 15 minutes, so early campaigns died when victims read email slowly. Modern kits generate the code on demand, at the moment the victim clicks the link. The window opens when the victim is ready, not when the attacker sent the message.

What it looks like in your logs

This attack is loud in exactly one place: cloud identity logs. If you know the signals, the Entra sign-in and audit logs give you a clean detection surface.

For the device code path:

Sign-in logs where AuthenticationProtocol equals deviceCode. Most users never touch this flow in their working lives. A first-ever device code sign-in from an account, especially a non-technical one, deserves a look on its own. If your organization has no conference hardware or CLI tooling that uses the flow, any occurrence is worth triage.

Error code 50199 followed by a successful sign-in. Microsoft's own hunting guidance keys on this pair: an interaction_required event (ResultType 50199) and then a ResultType 0 success for the same user within about five minutes. That gap is the human pause, the victim reading the lure and typing the attacker's code. Correlate the two and you have a behavioral signature for the moment of compromise, not just the aftermath.

New device registrations near anomalous token activity. The PRT variant shows up as a Device Registration Service event in CloudAppEvents close in time to suspicious sign-ins. A brand new device appearing minutes after an account's first device code authentication is not a coincidence.

For the consent phishing path, the evidence sits in the Entra audit log instead:

"Consent to application," "Add delegated permission grant," and "Add app role assignment to service principal." Filter these against app registration age. A grant flowing to an application registered in the last 30 days, requesting Mail.Read or offline_access, is your review queue. Legitimate new apps exist, but the combination of young app, mail scope, and offline_access is the consent phishing profile.

Admin consent to an unverified app is the highest-priority signal you have. An app with no verified publisher badge receiving admin consent skips the per-user consent screen for the entire tenant. One click by one administrator grants the attacker every user's mailbox at once. Page someone.

Also watch geography. Storm-2372 used proxies regionally appropriate to their targets specifically to blunt impossible-travel detections. Location anomalies help; their absence proves nothing.

Why your EDR stays silent

There is no payload in this attack. No binary to hash, no process tree to walk, no C2 beacon for network sensors to flag. The only "infrastructure" the victim touches is Microsoft's own login endpoint, which no proxy category on earth will block.

After the token is issued, the attacker replays it against Microsoft Graph and other APIs, which ATT&CK classifies as Use Alternate Authentication Material. Every one of those requests carries valid authentication for a real user, so downstream systems file the activity under Valid Accounts. Your endpoint agent sees nothing because nothing executes on an endpoint. Your email gateway saw a meeting invite with no attachment and a link to microsoft.com. Every tool built to find malicious executables is looking at the wrong layer.

This is the core lesson for a SOC analyst: device code phishing is an identity attack, and identity attacks are only visible in identity telemetry. If Entra sign-in and audit logs are not in your SIEM, you are not merely missing detections. You are blind to the entire technique class.

Containing it

Response has a nuance that burns teams who move fast and check nothing.

Revoking sessions via the Graph revokeSignInSessions call kills the refresh tokens, and that is the right first move. But newer Microsoft guidance from the EvilTokens era spells out the catch: revocation often invalidates only the refresh tokens, while access tokens already issued stay valid until they expire, up to an hour. For sixty minutes after your "containment," the attacker can keep reading mail on the token they already hold. If the account matters, temporarily disable it. Disabling is disruptive and that is the point; it is the only lever that slams the door now rather than at the token's leisure.

For the consent phishing variant, revoke the malicious application's permission grants and delete its service principal from the tenant, then audit what the app touched while it had access.

Hardening, in priority order:

1. Block device code flow with Conditional Access wherever the business does not need it, which for most tenants is nearly everywhere. Where a real use case exists, scope an allowlist by user, platform, or named location. Run report-only mode first and you will likely find the flow is barely used.
2. Deploy phishing-resistant MFA. FIDO2 keys and passkeys bind authentication to the origin, which removes the "user completes a legitimate prompt for an attacker's session" primitive that this whole technique depends on.
3. Restrict user consent to verified publishers and low-risk permissions, and route everything else through an admin consent workflow with reviewers who actually read the scope list.
4. Restrict device registration so the Authentication Broker PRT path has nowhere to land.
5. Update your awareness training. URL inspection does not cover this attack. The rule users need is simpler: a code you received from someone else never goes into a device login page. There is no legitimate workflow where a meeting requires one.

Practice the detection before you need it

Reading about the 50199-to-success correlation is one thing. Pulling it out of a sign-in log stream while a fake IT support chat is still open in the victim's Teams client is another. The reflex you want is reaching for identity logs first when an alert smells like account takeover, and reflexes come from reps, not reading.

SOCSimulator has a hands-on lab built around Steal Application Access Token where you work the technique with realistic sign-in telemetry, the same deviceCode protocol fields and audit operations covered above. If OAuth abuse is a gap in your investigation skills, that is a concrete place to close it.

Attackers turned this from a red team trick into a phishing-as-a-service product in under two years. The detection fits in one correlation rule over your Entra sign-in logs, provided those logs reach your SIEM in the first place. Check that they do before you need them.