Security1 publisher2 min readPublished
Device code phishing collects tokens from a sign-in page that is genuinely Microsoft's
The OAuth device authorization grant was built for smart TVs and printers. Kits such as EvilTokens use it to get victims to approve an attacker's sign-in on a page that really is Microsoft's, MFA included.
The Watch · Security desk
What happened
- The attacker starts the sign-in, social-engineers the resulting code to a victim, and the attacker's waiting device receives authentication tokens once the victim enters the code and approves.
- Multifactor authentication can be cleared and the attack still works, because the victim may complete the MFA check themselves while approving the attacker's session.
- Inspecting the URL does not expose the fraud, since the victim lands on the provider's own verification page, such as microsoft.com/devicelogin for a Microsoft account.
Compiled by The WatchSomething wrong?How this is made
Why it matters
- exposure The tokens inherit whatever the attacker's app asked for, so one approval can reach mail, files and contacts rather than the single document the pretext described.
- constraint Awareness training has one artifact left to work with, the origin of the code, because every other element the user sees checks out as legitimate.
- decision Administrators now have to decide whether the device authorization path needs to be reachable at all in estates where no browserless device uses it.
Of the five steps Malwarebytes lays out, one contains anything false: the message that hands the victim the code. The sign-in request the attacker starts is a real request, the code is issued by the identity provider, and the verification page is the provider's own [3][8]. The multifactor prompt the victim clears is a real prompt for a real session, just not the victim's session [7]. "The page is real and the code works", Malwarebytes wrote [18].
That leaves provenance as the only test available at the screen, and Malwarebytes writes the question out: did the code appear in an app or on a device you were trying to sign in to, or were you given it to open a document, join a meeting, or pass a security check [12]. Answering it requires the user to remember what they themselves started. Some approval screens name the app requesting access and some do not [9], so on the screens that do not, there is nothing to compare the pretext against.
The grant exists for hardware that cannot easily display a login screen, which Malwarebytes lists as smart TVs, printers, conference-room equipment and some command-line tools [2]. An estate where none of those sign in this way still has the authorization path enabled and gains nothing from it [17]. The Malwarebytes post is aimed at account holders; tenant-side policy is outside its scope.
Malwarebytes names EvilTokens as a phishing kit with device code phishing as a feature [11]. Kit support matters because the attacker's half of the flow is timing work: the code is short-lived, and the attacker's device has to be waiting when the victim approves [3][5]. The pretexts the post lists are the ordinary collaboration ones, a fake Teams invite, a document-sharing request, an invitation to a "secure" chat [4].
What the tokens reach depends on the app and the permissions granted, from a single service up to email, files and contacts [10]. Malwarebytes' advice after an approval is to check recent account activity, connected apps and devices, sign out everywhere, and change the password [14]. Every one of those steps runs after the attacker already holds tokens that work without the password [15].
What to watch
- Whether identity providers move the device authorization grant to default-off or admin-scoped, so the flow has to be turned on for the devices that need it.
- Whether approval screens start naming the requesting app in every case, which is the one on-screen detail Malwarebytes says is inconsistent today.
- Feature lists and pricing for EvilTokens, which would show whether device code support is now standard in commodity phishing kits.