When checking the URL isn’t enough: phishing via the Microsoft identity platform | Securelist Solutions for: Home Products Small Business 1-50 employees Medium Business 51-999 employees Enterprise 1000+ employees by Kaspersky CompanyAccount Get In Touch Dark mode off English Russian Spanish Brazil Solutions Internet of Things & Embedded Security Learn More Industrial Cybersecurity Learn More Fraud Prevention Learn More KasperskyOS-based solutions Learn More Other solutions Kaspersky for Security Operations Center Kaspersky IoT Infrastructure Security Kaspersky Secure Remote Workspace Industries National Cybersecurity Learn More Industrial Cybersecurity Learn More Finance Services Cybersecurity Learn More Healthcare Cybersecurity Learn More Transportation Cybersecurity Learn More Retail Cybersecurity Learn More Other Industries Telecom Cybersecurity View all Products Kaspersky Next NEW! Learn More Kaspersky XDR Learn More Kaspersky Endpoint Security for Business Learn More Kaspersky EDR Expert Learn More Kaspersky EDR Optimum Learn More Kaspersky Anti Targeted Attack Platform Learn More Kaspersky Hybrid Cloud Security Learn More Kaspersky SD-WAN Learn More Kaspersky Industrial CyberSecurity Learn More Kaspersky Container Security Learn More Other Products Kaspersky Security for Internet Gateway Kaspersky Embedded Systems Security Kaspersky IoT Infrastructure Security Kaspersky Secure Remote Workspace Kaspersky Security for Mail Server View All Services Kaspersky Cybersecurity Services Learn More Kaspersky Security Awareness Learn More Kaspersky Premium Support Learn More Kaspersky Threat Intelligence Learn More Kaspersky Managed Detection and Response Learn More Kaspersky Compromise Assessment Learn More Kaspersky SOC Consulting Learn More Other Services Kaspersky Professional Services Kaspersky Incident Response Kaspersky Cybersecurity Training View All Resource Center Case Studies White Papers Datasheets Technologies MITRE ATT&CK About Us Transparency Corporate News Press Center Careers Sponsorship Policy Blog Contacts GDPR Subscribe --> Dark mode off Login --> Securelist menu English Russian Spanish Brazil Existing Customers Personal My Kaspersky Renew your product Update your product Customer support Business KSOS portal Kaspersky Business Hub Technical Support Knowledge Base Renew License Home Products Trials&Update Resource Center Business Kaspersky Next Small Business (1-50 employees) Medium Business (51-999 employees) Enterprise (1000+ employees) Securelist Threats Financial threats Mobile threats Web threats Secure environment (IoT) Vulnerabilities and exploits Spam and Phishing Industrial threats Categories APT reports Incidents Research Malware reports Spam and phishing reports Publications Kaspersky Security Bulletin Archive All Tags APT Logbook Webinars Statistics Encyclopedia Threats descriptions KSB 2021 About Us Company Transparency Corporate News Press Center Careers Sponsorships Policy Blog Contacts Partners Find a Partner Partner Program Content menu Close Subscribe Threat Response by Kaspersky Dark mode off Threats Threats APT (Targeted attacks) Secure environment (IoT) Mobile threats Financial threats Spam and phishing Industrial threats Web threats Vulnerabilities and exploits All threats Categories Categories APT reports Malware descriptions Security Bulletin Malware reports Spam and phishing reports Security technologies Research Publications All categories Other sections Threat Response All tags Webinars APT Logbook Statistics Encyclopedia Threats descriptions KSB 2025 Kaspersky ICS CERT Spam and phishing When checking the URL isn’t enough: a Device Code Phishing attack via a Microsoft website Spam and phishing 06 Jul 2026 minute read Roman Dedenok Table of Contents Core steps of Device Authorization Grant Analysis of a Device Code Phishing attack Adaptation of the attack method How to defend against Device Code Phishing attacks Authors Roman Dedenok 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 , which supports an OAuth 2.0 specification known as the Device Authorization Grant . 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://login.microsoftonline.com/{tenant}/oauth2/v2.0/devicecode ; hence, an attack scenario exploiting this mechanism is called Device Code Phishing. In 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. Core steps of Device Authorization Grant 1. Requesting the authorization code When 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://login.microsoftonline.com/{tenant}/oauth2/v2.0/devicecode . This request includes the client_id (the unique identifier of the app registered in Microsoft Entra ID / Azure AD) and the scope (the requested access permissions). In response, the application receives several parameters: device_code (a secret code for internal use), user_code (a short code displayed to the end-user), verification_uri (the login URL the user needs to visit), expires_in (the code’s lifespan), and interval (how frequently the app should poll the server). 2. Displaying the code to the user The device displays both the user_code and the verification_uri to the user, instructing them to complete authentication on another device. For instance, a smart TV will display the code and URL — often rendering the verification_uri as a QR code — so the user can access it via their smartphone. 3. Entering the code and confirming access By scanning the QR code with a smartphone camera or manually typing out the address, the user navigates to the verification_uri (such as https://microsoft.com/devicelogin ) and enters the user_code . 4. Polling the server The device (smart TV) begins polling the server to check the authorization status — essentially verifying whether the user has approved the access request. It does this by sending a POST request to the token endpoint: https://login.microsoftonline.com/{tenant}/oauth2/v2.0/token . The request passes the grant_type parameter with the value urn:ietf:params:oauth:grant-type:device_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 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 (keep waiting) or slow_down (reduce the polling frequency). 5. Issuing access tokens Once the user successfully approves the application’s request, the server responds to the application by issuing an access_token (to access the data), a refresh_token (to renew access later), an id_token (containing user profile details like name and email), along with several other service parameters. 6. Automatic access renewal The device (our smart TV) uses the refresh_token to silently renew the access_token without requiring any further user interaction. When the current access_token expires (typically after 1 hour), the device automatically sends a token refresh request containing the refresh_token to the token endpoint. It then receives a fresh pair of access and refresh tokens, ensuring the user remains authenticated seamlessly. 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 . Let’s use a real-world example to break down this attack vector. Analysis of a Device Code Phishing attack The phishing email 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. 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. PDF file with a malicious link 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. 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. The phishing page 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://login.microsoftonline.com/{tenant}/oauth2/v2.0/devicecode , as detailed in the workflow above. The one-time code 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 ), where they were prompted to paste and enter the code. Official Microsoft authentication page 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. Adaptation of the attack method 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. The Brazilian phishing variant Translated from Portuguese: “Hello! Your order has just been processed, and the confirmation has been sent to you in PDF format. Please see the details below. OPEN / DOWNLOAD PDF A new quote is attached to this email. Please let me know if you need any further assistance.”   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. The proxy link routes through the legitimate Cacoo.com domain before redirecting to the phishing site Translated from Portuguese: Request confirmation Status Code = Success DOWNLOAD OR VIEW THE DOCUMENT Important note: Log in to the account that received this message to securely authenticate the document.   Clicking the link routed the user back to the familiar landing page displaying the one-time code. Landing page displaying the code From there, the potential victim was once again redirected to the official Microsoft portal to complete the Device Authorization Grant authentication process. Official Microsoft page prompting for the user code How to defend against Device Code Phishing attacks As our research demonstrates, threat actors don’t always rely on harvesting credentials or deploying malware to access sensitive data — 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. Recommendations for users If you did not personally initiate a login request on an external device using the Microsoft Device Authorization Grant, do not approve the authorization request. Never enter an authorization code received via unexpected emails or messages, even if the provided link points directly to an official Microsoft domain. Threat actors frequently leverage open redirects on legitimate domains, appending parameters like redirect_uri , return_url , or next after the question mark (?) to point to a malicious destination. Before clicking any link, hover your cursor over it to inspect both the primary domain and any suspicious redirect parameters. Once the page loads, verify that the final URL actually matches the expected asset — this is the absolute minimum requirement before entering corporate credentials. We strongly advise enterprise teams to evaluate the business necessity of the Device Code Flow within their corporate infrastructure. If this authentication mechanism is not required for daily operations, it should be disabled globally via Conditional Access policies within Microsoft Entra ID. Additionally, security teams should set up dedicated monitoring for DeviceCodeSignIn events, strictly e nforce device compliance states, and configure alerts for anomalous sign-in behavior originating from unusual locations. To establish a comprehensive defense against Device Code Phishing attacks, organizations should deploy robust email security solutions capable of securing both corporate and personal messages. Microsoft Phishing Phishing websites QR-codes OAuth When checking the URL isn’t enough: a Device Code Phishing attack via a Microsoft website Your email address will not be published. Required fields are marked * Name * Email * Captcha validation failed. Please confirm you are not a robot and try again. Cancel Δ This site uses Akismet to reduce spam. Learn how your comment data is processed. Table of Contents Core steps of Device Authorization Grant Analysis of a Device Code Phishing attack Adaptation of the attack method How to defend against Device Code Phishing attacks From the same authors “Legitimate” phishing: how attackers weaponize Amazon SES to bypass email security The evolving landscape of email phishing attacks: how threat actors are reusing and refining established techniques Phishing attacks leveraging HTML code inside SVG files When spear phishing met mass phishing QR codes in email phishing In the same category When spear phishing met mass phishing Message board scams QR codes in email phishing Phishing with hacked sites Email crypto phishing scams: stealing from hot and cold crypto wallets Latest Posts SOC, TI and IR posts Missed incidents, persistent threats, and response gaps: Insights from compromise assessment projects Victor Sergeev Amged Wageh Publications OpenClaw: risks for the users and how to mitigate them Kaspersky APT reports ToddyCat: your hidden email assistant. Part 2 Andrey Gunkin GReAT research The Gentlemen are knocking: сustom backdoors and evolving tactics Fatih Şensoy Maher Yamout Latest Webinars Cyberthreat talks 11 Jun 2026, 5:00pm 43 min The dark side of mobile: Threats targeting Android & iOS Fabio Assolini Tatyana Shishkova Dmitry Kalinin Cyberthreat talks 25 Jun 2026, 5:00pm 29 min Securing the pipeline: 2026 supply chain threats Victoria Vlasova Yaroslav Kikel Technologies and services 02 Jul 2026, 5:00pm 68 min Missed incidents: Compromise Assessment insights Victor Sergeev Amged Wageh Technologies and services 02 Jun 2026, 5:00pm 60 min AI meets cybersecurity: Powering the next digital move Vladislav Tushkanov Oleg Gorobets Anton Rusakov-Rudenko Reports ToddyCat: your hidden email assistant. Part 2 An in-depth analysis of Umbrij, a new tool used by the ToddyCat APT group to compromise corporate email communications in Gmail. The attack targeted OAuth authorization tokens, allowing threat actors to gain access to Google services. Cloud Atlas activity in the second half of 2025 and early 2026: new tools and a new payload Cloud Atlas attacks the public sector and diplomatic structures of Russia and Belarus, using ReverseSocks, SSH, and Tor for persistence in infected systems and its new tool, PowerCloud. Kimsuky targets organizations with PebbleDash-based tools Kaspersky researchers analyze a range of new PebbleDash-based tools used in recent Kimsuky campaigns and reveal their connection to the AppleSeed malware cluster. OceanLotus suspected of using PyPI to deliver ZiChatBot malware Kaspersky researchers uncovered malicious wheel packages in PyPI that targeted both Windows and Linux and contained a dropper delivering malware dubbed ZiChatBot. We attribute this activity to OceanLotus APT. Subscribe to our weekly e-mails The hottest research right in your inbox Email (Required) Captcha (Required) I agree to provide my email address to “AO Kaspersky Lab” to receive information about new posts on the site. I understand that I can withdraw this consent at any time via e-mail by clicking the “unsubscribe” link that I find at the bottom of any e-mail sent to me for the purposes mentioned above. Subscribe Δ Threats Threats APT (Targeted attacks) Secure environment (IoT) Mobile threats Financial threats Spam and phishing Industrial threats Web threats Vulnerabilities and exploits All threats Categories Categories APT reports Malware descriptions Security Bulletin Malware reports Spam and phishing reports Security technologies Research Publications All categories Other sections Threat Response All tags Webinars APT Logbook Statistics Encyclopedia Threats descriptions KSB 2025 Kaspersky ICS CERT © 2026 AO Kaspersky Lab. All Rights Reserved. Registered trademarks and service marks are the property of their respective owners. Privacy Policy Terms of use License Agreement Cookies

📌 来源: Kaspersky Securelist | 📅 2026-07-06