How device code phishing gives scammers access to your account

1. Executive summary

Device code phishing has moved from a niche red-team technique to a commodity capability in 2026, and the phishing kits that carry it are sold as a service. The attack abuses the OAuth 2.0 Device Authorization Grant, a legitimate sign-in flow for input-constrained devices, so the victim enters a real code on a real Microsoft page and approves the attacker's session; MFA does not stop it because the victim completes the MFA prompt themselves. For EMEA financial services the exposure is Microsoft 365 and Entra ID account takeover, with the attacker holding access and refresh tokens that survive a password change. There is no CVE to patch and no vendor fix: the controls are conditional access policy, token revocation, and detection of device code authentications that no managed device requested. No CVSS score, severity rating or CISA KEV entry applies to this item; the verified reference data resolved no CVE for it.

2. Regulatory framing

No specific DORA/NIS2 article is directly engaged by this item.

The item describes a technique and a class of phishing kits. It reports no incident at a named entity, no third-party provider failure and no supply chain compromise, so none of the articles in the regulatory reference has a trigger here that is distinctive to this item. If a client suffers account takeover through this route, the incident classification and reporting assessment runs on the facts of that event, not on this advisory.

3. Technical analysis & attack chain

Device code phishing abuses the OAuth 2.0 Device Authorization Grant, a flow built for devices that cannot render a browser or accept typed credentials: smart TVs, printers, conference room equipment, IoT hardware and some command line tools. Kaspersky GReAT documents the protocol in detail; Malwarebytes describes the same attack from the victim's side. The two accounts agree on the sequence.

The attacker's client starts the flow with a POST request to https://login.microsoftonline.com/{tenant}/oauth2/v2.0/devicecode, carrying a client_id (the identifier of an app registered in Microsoft Entra ID) and a scope (the permissions requested). Microsoft's Identity Platform answers with a device_code (a secret the client keeps), a user_code (the short code shown to the human), a verification_uri (the page the human must visit), an expires_in value, and an interval that sets how often the client may poll.

The attacker passes the user_code to the victim through social engineering: a fake Teams meeting invitation, a document sharing request, an invitation to a password-protected meeting or a "secure" chatroom, or a demand to pass a security check. The victim opens the genuine verification page, https://microsoft.com/devicelogin, and enters the code. Nothing on that page is fraudulent, which is why checking the domain does not help.

While the victim is deciding, the attacker's client polls https://login.microsoftonline.com/{tenant}/oauth2/v2.0/token with grant_type set to urn:ietf:params:oauth:grant-type:device_code. Until the victim approves, the server answers authorization_pending or slow_down. Once the victim approves, the server returns an access_token, a refresh_token and an id_token containing profile details such as name and email. The refresh token is the durable part: it renews access without the password. Kaspersky's write-up is truncated at the point where it describes that automatic renewal, so the exact lifetime behaviour is not stated in the material available here.

MFA does not break the chain. The victim completes the MFA prompt as part of approving the attacker's sign-in, so the second factor is satisfied by the person being attacked. What the attacker can reach afterwards depends on the scope and the app: it may be a single service, or mail, files, contacts and other services. Some approval screens name the requesting app; others do not.

Two phishing kits are named in the material. Malwarebytes states that device code phishing is a feature of EvilTokens. The Hacker News reports that the Greatness phishing-as-a-service toolkit has added device code phishing support alongside its existing adversary-in-the-middle credential capability; the quoted text is truncated mid-sentence, so the full capability set is not available here. Both claims are single-sourced and should be verified before they are used in blocking decisions.

Scale claims rest on headlines rather than published methodology. Dark Reading's headline reports device code phishing up 1,500% in 2026 with vishing doubling; The Hacker News headline calls it the fastest-growing threat of 2026; Huntress says it is tracking an evolving wave against Microsoft 365 sign-in flows. None of the three supplies a measurement method, sample size or time window in the material provided, so treat the percentages as directional only.

No threat actor is named in any of the sources, and no MITRE ATT&CK profile is available for this item. Any attribution would be unconfirmed.

4. Mitigation & containment

P1 (within 24 hours)

• Block the device code flow for the general user population with a Conditional Access authentication flows policy, and allow it only for named accounts that need it (conference room devices, CLI tooling, kiosk apps). This is the control that removes the attack path.
• Revoke refresh tokens and force re-authentication for any account that approved a device code sign-in it did not start. Malwarebytes' guidance to affected users is to check recent activity, connected apps and devices, sign out everywhere and change the password; at tenant level, revoking the refresh token is what ends the attacker's session.
• Hunt Entra ID sign-in logs for device code authentications over the past 30 days. For each hit, check whether the user has a managed device or registered app that would legitimately request one, and check the source IP and user agent.

P2 (within 72 hours)

• Review enterprise applications and OAuth consent grants for anything unrecognised and remove it. A device code approval creates an app consent record.
• Restrict user consent to apps so a compromised account cannot grant new permissions.
• Shorten refresh token lifetime and enable continuous access evaluation where the tenant supports it, to cut the window between approval and detection.
• Alert on requests to microsoft.com/devicelogin and to the /oauth2/v2.0/devicecode endpoint from clients that are not managed devices, in web proxy or firewall logs.
• Check for mailbox rules, forwarding and delegate permissions created after any suspected approval.

P3 (within 7 days)

• Add the device code lure to phishing simulation and awareness material, using the specific tell: a code you were given to open a document, join a meeting or pass a security check is not a code your own device displayed.
• Add device code approval to the account takeover playbook, with token revocation as the first step rather than a password reset alone.
• Where the tenant has no device code use case at all, block the flow tenant-wide and revisit only on a documented business requirement.

5. Indicators of compromise

No atomic indicators of compromise are available in the source material. No hashes, domains, IP addresses, file paths or filenames are given in any of the sources. The endpoints named in this advisory (microsoft.com/devicelogin, login.microsoftonline.com/{tenant}/oauth2/v2.0/devicecode, login.microsoftonline.com/{tenant}/oauth2/v2.0/token) are legitimate Microsoft infrastructure and are not indicators; they are listed here so that detection can be built around their use.

The sources describe observable behaviours rather than atomic indicators.

Behavioural indicators

6. Detection

No file-level artefacts (hashes, filenames, mutexes, registry keys, command-line flags) appear in the sources, so no YARA rule is emitted. The usable material is network and authentication behaviour, which the Sigma rule below covers.

title: Microsoft Device Code Authentication Endpoint Access
id: 8f2c1a44-7b6e-4d21-9c3a-0e5d7a1b6f90
status: experimental
description: Detects HTTP requests to the Microsoft OAuth 2.0 device authorization endpoint and the device login verification page. Both are legitimate Microsoft endpoints used by smart TVs, printers, conference room equipment and CLI tools, so a match is a hunting signal, not a verdict. Correlate with the requesting client, the user, and whether that user has a device code use case.
references:

  - https://securelist.com/microsoft-device-code-phishing-attack/120350/
  - https://www.malwarebytes.com/blog/how-to/2026/09/how-device-code-phishing-gives-scammers-access-to-your-account
author: Adverse Trace
date: 2026-09-23
logsource:
  category: proxy
detection:
  selection_devicecode:
    cs-uri|contains: '/oauth2/v2.0/devicecode'
  selection_devicelogin:
    cs-uri|contains: 'microsoft.com/devicelogin'
  condition: selection_devicecode or selection_devicelogin
falsepositives:

  - Legitimate device code sign-ins from smart TVs, printers, conference room equipment and command line tools
level: informational

If the tenant ships Entra ID sign-in logs to the SIEM, run the same hunt against the authentication protocol field for device code sign-ins and correlate with device registration state. Field naming depends on the connector and is not specified in the sources, so map it to the local schema before deployment.

7. Sources

• Malwarebytes, "How device code phishing gives scammers access to your account", https://www.malwarebytes.com/blog/how-to/2026/09/how-device-code-phishing-gives-scammers-access-to-your-account, 2026-09-23.
• Securelist (Kaspersky GReAT), "When checking the URL isn't enough: a Device Code Phishing attack via a Microsoft website", https://securelist.com/microsoft-device-code-phishing-attack/120350/, date not stated.
• Huntress, "We Need to Talk About Device Code Phishing", https://www.huntress.com/blog/tradecraft-tuesday-device-code-phishing-explained, date not stated.
• Huntress, "Device Code Phishing Keeps Evolving. Here's What to Watch For", https://www.huntress.com/blog/device-code-phishing-evolving-threats, date not stated.
• The Hacker News, "6 Reasons Why Device Code Phishing is the Fastest-Growing Threat of 2026", https://thehackernews.com/2026/07/6-reasons-why-device-code-phishing-is.html, 2026-07.
• The Hacker News, "Greatness PhaaS Adds Device Code Phishing to Bypass MFA and Steal Tokens", https://thehackernews.com/2026/08/greatness-phaas-adds-device-code.html, 2026-08.
• Dark Reading, "Device Code Phishing Up 1,500% in 2026; Vishing Doubles", https://www.darkreading.com/cybersecurity-analytics/device-code-phishing-vishing-doubles, date not stated.

8. Adverse Trace position

Adverse Trace assesses this as a high-impact, low-complexity technique rather than a vulnerability: there is no CVE, no CVSS score and no CISA KEV entry for this item, and the verified reference data resolved none. The client impact for EMEA financial services is account takeover in Microsoft 365 and Entra ID estates where device code flow is enabled for the general population, with the attacker holding a refresh token that survives a password change; the second factor does not help because the victim supplies it. The scale figures circulating (1,500% growth, fastest-growing threat of 2026) come from headlines without published methodology and we do not treat them as measured. We will add the device code authentication hunt to our monitoring guidance for Microsoft 365 clients, track the EvilTokens and Greatness kit capabilities as they are reported, and reissue this note if a named actor or a measured dataset emerges. Clients who cannot block the flow outright should put token revocation and consent review ahead of user awareness alone.

Read the original source →

Published via PulseTrace — Adverse Trace threat intelligence.