{"id":120350,"date":"2026-07-06T09:00:43","date_gmt":"2026-07-06T09:00:43","guid":{"rendered":"https:\/\/2.zoppoz.workers.dev:443\/https\/kasperskycontenthub.com\/securelist\/?p=120350"},"modified":"2026-07-17T13:49:18","modified_gmt":"2026-07-17T13:49:18","slug":"microsoft-device-code-phishing-attack","status":"publish","type":"post","link":"https:\/\/2.zoppoz.workers.dev:443\/https\/securelist.com\/microsoft-device-code-phishing-attack\/120350\/","title":{"rendered":"When checking the URL isn’t enough: a Device Code Phishing attack via a Microsoft website"},"content":{"rendered":"

One of the most common pieces of anti-phishing advice is to double-check the website’s domain name before providing your credentials. Typically, a fraudulent domain stands out to the trained eye, differing from the official URL by at least a few characters. Recently, however, we encountered a campaign where attackers instruct victims to input data directly into a legitimate, trusted corporate site: the Microsoft Identity Platform<\/a>, which supports an OAuth 2.0 specification known as the Device Authorization Grant<\/a>.<\/p>\n

This specific protocol extension was designed to simplify the login experience for smart TVs, IoT hardware, printers, and other input-constrained devices that lack a full browser or keyboard. It allows users to use a nearby smartphone or PC for authorizing these devices to access their accounts. To complete the process, the user enters a one-time code on a designated authentication page. The Microsoft Identity Platform returns this code along with a link to enter it in response to a request to https:\/\/2.zoppoz.workers.dev:443\/https\/login.microsoftonline.com\/{tenant}\/oauth2\/v2.0\/devicecode<\/code>; hence, an attack scenario exploiting this mechanism is called Device Code Phishing.
\nIn this post, we break down how the Device Authorization Grant specification (also known as the Device Authorization Grant Flow or Device Code Flow) works, analyze real-world attacks leveraging this technology, and outline effective strategies to defend against Device Code Phishing.<\/p>\n

Core steps of Device Authorization Grant<\/h2>\n

1. Requesting the authorization code
\n<\/strong>
\nWhen a user launches an app on a client device, such as a streaming app on a Smart TV, the app detects that it is unauthenticated and sends a POST request to https:\/\/2.zoppoz.workers.dev:443\/https\/login.microsoftonline.com\/{tenant}\/oauth2\/v2.0\/devicecode<\/code>. This request includes the client_id<\/code> (the unique identifier of the app registered in Microsoft Entra ID \/ Azure AD) and the scope<\/code> (the requested access permissions). In response, the application receives several parameters: device_code<\/code> (a secret code for internal use), user_code<\/code> (a short code displayed to the end-user), verification_uri<\/code> (the login URL the user needs to visit), expires_in<\/code> (the code’s lifespan), and interval<\/code> (how frequently the app should poll the server).<\/p>\n

2. Displaying the code to the user<\/strong><\/p>\n

The device displays both the user_code<\/code> and the verification_uri<\/code> to the user, instructing them to complete authentication on another device. For instance, a smart TV will display the code and URL\u00a0\u2014 often rendering the verification_uri as a QR code\u00a0\u2014 so the user can access it via their smartphone.<\/p>\n

3. Entering the code and confirming access
\n<\/strong>
\nBy scanning the QR code with a smartphone camera or manually typing out the address, the user navigates to the verification_uri<\/code> (such as https:\/\/2.zoppoz.workers.dev:443\/https\/microsoft.com\/devicelogin<\/a>) and enters the user_code<\/code>.<\/code><\/p>\n

4. Polling the server
\n<\/strong>
\nThe device (smart TV) begins polling the server to check the authorization status\u00a0\u2014 essentially verifying whether the user has approved the access request. It does this by sending a POST request to the token endpoint: https:\/\/2.zoppoz.workers.dev:443\/https\/login.microsoftonline.com\/{tenant}\/oauth2\/v2.0\/token<\/code>. The request passes the grant_type parameter with the value urn:ietf:params:oauth:grant-type:device_code<\/code>, indicating the use of the Device Authorization Grant method. This signals to the authorization server exactly which authentication method is being used to request access tokens. The server waits for the user to enter the user_code<\/code> on their secondary device and approve access to their resources or data. Until that approval happens, the server responds with an error code like authorization_pending<\/code> (keep waiting) or slow_down<\/code> (reduce the polling frequency).<\/p>\n

5. Issuing access tokens<\/strong><\/p>\n

Once the user successfully approves the application’s request, the server responds to the application by issuing an access_token<\/code> (to access the data), a refresh_token<\/code> (to renew access later), an id_token<\/code> (containing user profile details like name and email), along with several other service parameters.<\/p>\n

6. Automatic access renewal<\/strong><\/p>\n

The device (our smart TV) uses the refresh_token<\/code> to silently renew the access_token<\/code> without requiring any further user interaction. When the current access_token<\/code> expires (typically after 1 hour), the device automatically sends a token refresh request containing the refresh_token<\/code> to the token endpoint. It then receives a fresh pair of access and refresh tokens, ensuring the user remains authenticated seamlessly.<\/p>\n

While this workflow is truly convenient for input-constrained devices, attackers can abuse it to hijack user accounts and maintain persistent access for extended periods using the issued refresh_token<\/code>. Let’s use a real-world example to break down this attack vector.<\/p>\n

Analysis of a Device Code Phishing attack<\/h2>\n
\"The<\/a>

The phishing email<\/p><\/div>\n

In a phishing campaign we observed spanning from early April to mid-May 2026, the initial email was styled as a notice from a law firm. Attached to the email was a password-protected PDF file.<\/p>\n

\"\"<\/a><\/p>\n

Once the victim opened the PDF and entered the password, they were presented with a landing page listing several documents. However, viewing these documents required clicking a provided link.<\/p>\n

\"PDF<\/a>

PDF file with a malicious link<\/p><\/div>\n

A close look at the target URL reveals that instead of pointing to a typical, easily recognizable phishing domain, it actually points to a legitimate Microsoft address. However, the URL parameters are configured to redirect the user to a phishing resource.<\/p>\n

\"\"<\/a><\/p>\n

The link within the document does not keep the user on the Microsoft platform; instead, it immediately redirects them to a phishing page designed to mimic a corporate legal portal.<\/p>\n

\"\"<\/a>

The phishing page<\/p><\/div>\n

Interestingly, the landing page featured multiple CAPTCHAs, presumably deployed to filter out security crawlers. Once past these hurdles, the user was routed to a final page that instructed them to copy a one-time code. This code was the user_code that the attacker’s server-side application had already fetched by querying https:\/\/2.zoppoz.workers.dev:443\/https\/login.microsoftonline.com\/{tenant}\/oauth2\/v2.0\/devicecode<\/code>, as detailed in the workflow above.<\/p>\n

\"\"<\/a>

The one-time code<\/p><\/div>\n

\n

The one-time codeClicking the displayed one-time code automatically copied it to the clipboard while simultaneously redirecting the user to Microsoft’s actual, legitimate authentication page (verification_uri<\/code>), where they were prompted to paste and enter the code.<\/p>\n

\"Official<\/a>

Official Microsoft authentication page<\/p><\/div>\n

Once the user entered the code, it kicked off the Device Authorization Grant flow described earlier. The unsuspecting victim then completed the full MFA process directly on Microsoft’s official page. As soon as authentication succeeded, the attacker harvested the session’s access_token, refresh_token, and id_token. This enabled them to read and send emails from the victim’s mailbox, exfiltrate files from OneDrive, and access Teams conversations.<\/p>\n

Adaptation of the attack method<\/h2>\n

This phishing campaign was limited in scope and spanned slightly more than a month. However, the threat actor continues to actively leverage this method, adapting it to target specific geographic regions. We’ve recently detected slightly modified Device Code Phishing campaigns shifting their focus toward users in Brazil, among others.<\/p>\n

\"The<\/a>

The Brazilian phishing variant<\/p><\/div>\n

\nTranslated from Portuguese:<\/summary>\n

“Hello!<\/em>
\nYour order has just been processed, and the confirmation has been sent to you in PDF format. Please see the details below.<\/em>
\nOPEN \/ DOWNLOAD PDF<\/em>
\nA new quote is attached to this email.<\/em>
\nPlease let me know if you need any further assistance.”<\/em><\/p>\n<\/details>\n

\u00a0 Unlike the previous campaign, this email did not include a malicious PDF attachment. Instead, it embedded a link pointing to cacoo.com, a legitimate online diagramming platform owned by Nulab. Just as before, this trusted domain served as an open redirect to steer the user toward the phishing infrastructure.<\/p>\n

\n

The proxy link routes through the legitimate Cacoo.com domain before redirecting to the phishing site<\/p>\n

\nTranslated from Portuguese:<\/summary>\n

Request confirmation<\/em>
\nStatus Code = Success<\/em>
\nDOWNLOAD OR VIEW THE DOCUMENT<\/em>
\nImportant note: Log in to the account that received this message to securely authenticate the document.<\/em><\/p>\n<\/details>\n

Clicking the link routed the user back to the familiar landing page displaying the one-time code.<\/p>\n

\"\"<\/a>

Landing page displaying the code<\/p><\/div>\n

From there, the potential victim was once again redirected to the official Microsoft portal to complete the Device Authorization Grant authentication process.<\/p>\n

\"Official<\/a>

Official Microsoft page prompting for the user code<\/p><\/div>\n

How to defend against Device Code Phishing attacks<\/h2>\n

As our research demonstrates, threat actors don’t always rely on harvesting credentials or deploying malware to access sensitive data\u00a0\u2014 they can just as easily weaponize legitimate tools. Therefore, users must exercise vigilance not only when visiting suspicious sites, but also when navigating official platforms like Microsoft or Cacoo.com.<\/p>\n

Recommendations for users<\/p>\n