OAuth Device Code Phishing: Stealing Sessions Without Touching a Password

Fri, 04 Sep 2026 00:00:00 +0000

Introduction

A user logs into the real microsoft.com, completes MFA, and just like this, his account is compromised. How ? He had typed in a code sent to him moments earlier. No fake login page, no stolen password, no MFA bypass exploit. Here is how it works, what it looked like across two real incidents contained by Senthorus SOC, detection patterns included, and what actually stops it.

What Is OAuth Device Code Phishing

OAuth 2.0’s device authorization grant (RFC 8628) exists for devices that cannot easily open a browser or type a password. Smart TVs, CLI tools, printers. The flow: the app requests a short code, shows it to the user, and asks them to enter it at a separate URL on a device that can browse, such as their phone. Microsoft first documented attackers abusing this at scale in February 2025, attributing the campaign to a threat actor it tracks as Storm-2372.

The technique itself isn’t new, but how often it’s being abused is. According to a Cloud Security Alliance research note, device code phishing pages targeting Microsoft 365 organizations surged 37.5x within about six weeks in early 2026, driven largely by the commercial EvilTokens phishing-as-a-service kit.

Attackers abuse this by generating a real device code, then pushing it inside usual phishing vectors (Teams, email, WhatsApp…). The victim enters the code on the actual Microsoft login page. Their session gets authenticated. The attacker’s polling script, sitting on the other end of that same flow, receives the access and refresh tokens directly.

Credentials never change hands, and MFA isn’t bypassed. The victim completes it themselves, on the attacker’s behalf. That’s why the technique slips past awareness training built around spotting fake login pages.

Two Real Incidents

Senthorus SOC detected and contained two of these incidents this past month, across two separate client tenants.

Case 1. The lure was a single email, subject line dressed up as an internal HR update. It carried a link to a compromised WordPress site hosting a device code phishing page. The victim entered the code. Within the same minute, the attacker’s infrastructure had a valid session and used it to register four rogue devices in a burst, roughly one every five seconds. All four came back as Workplace-registered, not joined, the Bring Your Own Device style path that needs nothing beyond a token to complete. Minutes later, the same session made multiple Microsoft Graph API calls, checking the account, pulling mailbox folders, then requesting a batch of recent inbox messages. Scripted mailbox harvesting, not manual browsing.

Case 2 followed the same device code flow, with Workplace-registered devices spun up in rapid sequence, three of them, ten to twenty seconds apart, following the exact same naming convention as Case 1: username, tenant domain, a short hex string, then -p01, -p02 for each additional device. The registration calls themselves came from a scripted OData client, not a browser. The session then went on to make similar Microsoft Graph API calls as in Case 1.

Why Device Registration, Why Multiple Devices

Registering a device isn’t a side effect of the attack, it’s the actual objective once the initial token lands. According to Microsoft’s original writeup on Storm-2372, using the Microsoft Authentication Broker client ID during the device code exchange gets the attacker a refresh token that can be traded for a second token scoped to the device registration service. That second token is what registers an attacker controlled device inside Entra ID. From there, the same refresh token combined with the new device identity is enough to request a Primary Refresh Token (PRT), a high-value Entra ID token.

A PRT is indeed worth more than the original stolen token. It grants seamless single sign-on across every Entra ID connected application without further prompts, and it survives a password reset in most configurations. Sekoia’s analysis of the EvilTokens kit confirms this as the mechanism that lets an attacker authenticate as the victim across Microsoft 365 with no further credential or MFA prompt appearing on either end.

Why register several devices rather than one ? That part is less documented. Neither Microsoft’s advisory nor the public EvilTokens research spells out a specific reason for registering more than one device per compromise. An important note is that in both incidents observed, the registrations happened in a tight burst. It is probably a redundancy measure: if a defender catches and disables one rogue device, any others left standing can still be used to request a fresh PRT. Disabling the first device found is not enough. Every device registered in the compromise window has to go.

The Same Kit, Twice

Line the two cases up and the overlap stops looking like a coincidence. Same device naming template, right down to the -p0X suffix pattern. Same Workplace-registered trust type. Same scripted, non-browser user agents driving the registration calls. And the two attacker IPs sat on the same ISP.

That points to both incidents running on the same phishing-as-a-service kit. The behavior matches EvilTokens: harvest a device code token, register an additional device with it, then request a PRT for persistent access. Whether this is EvilTokens itself or a fork isn’t confirmed, but the technique is a clean match. Both attacker IPs also traced back to GHOSTnet GmbH, a German hosting provider with an active abuse reporting presence on public phishing tracking services.

The pattern to watch for, either way: a device code sign-in event, followed within seconds or minutes by multiple new device registrations, followed by Graph API calls that don’t match the user’s normal behavior.

Remediation

Revoke sessions explicitly. This is the step that actually invalidates the refresh tokens.
Disable or remove every rogue registered device.
Reset the password and MFA methods too, as hygiene, but treat it as a secondary step, not the fix. If an existing MFA method shows a changed last-authenticated timestamp with no new method added, verify with the actual user that it was them, not the attacker riding an already-registered method.
Pull mailbox rules for anything routing internal security or admin senders to Deleted Items or an obscure folder. That’s a common way attackers hide the notifications that would otherwise tip off the victim.
Check delegated and shared mailbox access, not just the primary inbox. Persistence sometimes shows up as access to a resource the user wouldn’t normally touch.
Apply Conditional Access named location blocking to cut off the attacker’s infrastructure, and check whether the same source IP or ASN appears against any other account.

Prevention

MFA doesn’t help here. The victim completes it themselves, on the attacker’s behalf. Domain-reputation and phishing-page blocking can stop the initial lure, but the authentication itself happens on login.microsoftonline.com, a domain no defense should block.

If your org has no legitimate use for the device code flow, block it outright with a Conditional Access authentication flow policy.
Alert specifically on device code sign-in log entries. Don’t rely on generic risky sign-in detections to catch this.
Watch for Microsoft Authentication Broker client ID usage paired with new device registrations. This combination is a strong signal.
Hunt for device display names following a predictable template: username + tenant domain + short hex string, especially with sequential -p01, -p02 suffixes appearing seconds apart. Query provided below.

Hunt Burst Device Registration by Naming Pattern (Device Code Phishing Indicator)

The following KQL query detects multiple devices registered by the same user within a short time window, with display names matching a scripted naming template (username-domain-hex, optionally suffixed -p01/-p02), a pattern consistent with automated device registration following device code phishing observed in real incidents.

AuditLogs
| where TimeGenerated > ago(30d)
| where OperationName in ("Add device", "Register device")
| extend Actor = tostring(InitiatedBy.user.userPrincipalName)
| extend Target = TargetResources[0]
| extend DeviceId = tostring(Target.id)
| mv-expand Prop = Target.modifiedProperties
| where tostring(Prop.displayName) == "DisplayName"
| extend DeviceName = tostring(parse_json(tostring(Prop.newValue))[0])
| where DeviceName matches regex @"^[a-z0-9]+(-[a-z0-9]+)*-[0-9a-f]{6,10}(-p\d{2})?$"
| extend BaseName = extract(@"^(.*?)(-p\d{2})?$", 1, DeviceName)
| summarize DeviceCount = dcount(DeviceId),
Devices = make_set(DeviceName),
FirstSeen = min(TimeGenerated),
LastSeen = max(TimeGenerated)
by Actor, BaseName
| extend BurstSeconds = datetime_diff('second', LastSeen, FirstSeen)
| where DeviceCount >= 2 and BurstSeconds <= 120
| order by BurstSeconds asc

Conclusion

Device code phishing works precisely because it doesn’t look like phishing. There’s no domain to spoof, no certificate to fake, just a legitimate feature used the way it was designed to achieve malicious goals. Two incidents a few weeks apart, running on what looks like the same kit, is not a coincidence, it’s a pattern worth detecting and raising awareness about.

Charles Matrand on Senthorus Blog