The campaign ran “spanning from early April to mid-May 2026,” and its notable innovation was not a forged domain but the use of a legitimate Microsoft authentication endpoint to trick victims into approving access.
How the Microsoft Identity Platform’s Device Authorization Grant works
The Device Authorization Grant — often called the Device Code Flow — exists to let input-constrained devices (smart TVs, IoT hardware, printers) obtain access without a full keyboard or browser. In practice an unauthenticated app posts to https://login.microsoftonline.com/{{tenant}}/oauth2/v2.0/devicecode with its client_id and requested scope. The authorization server returns a device_code (secret), a short user_code (displayed to the end user), a verification_uri (the page the user must visit), expires_in, and an interval for polling.
The device shows the user_code and verification_uri (often as a QR code). The user navigates to the verification_uri (for example https://microsoft.com/devicelogin), enters the user_code and completes multi-factor authentication there. Meanwhile the device polls the token endpoint (https://login.microsoftonline.com/{{tenant}}/oauth2/v2.0/token) with grant_type set to urn:ietf:params:oauth:grant-type:device_code. When approved, the server issues an access_token, refresh_token and id_token. The device may later use the refresh_token to silently renew access.
Anatomy of the April–May 2026 Device Code Phishing campaign
The attackers began with emails styled as notices from a law firm. In the first observed variant the email contained a password‑protected PDF. After entering the PDF password the recipient saw a landing page listing documents and a link to “view” them. That link pointed to a legitimate Microsoft address, but its URL parameters redirected users to attacker infrastructure.
The attacker’s server had already requested a device_code from Microsoft and collected the resulting user_code. The phishing landing page — gated with multiple CAPTCHAs to filter crawlers — displayed that one-time user_code. Clicking the displayed code copied it to the victim’s clipboard and immediately redirected the user to Microsoft’s real verification page where they were asked to paste the code and finish authentication. Once the user completed MFA on Microsoft’s official page, the attacker harvested the session’s access_token, refresh_token and id_token, enabling email access, OneDrive exfiltration and Teams access.
Adaptation: the Brazilian variant and the role of legitimate open redirects
The threat actor adapted the method geographically. In a Brazilian variant the phishing email (translated) read: “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.” This version did not use an attached PDF; instead it embedded a link to cacoo.com — a legitimate diagramming platform — which served as an open redirect into the attacker’s landing page.
As before, the redirected landing page presented the one-time code and then routed the user back to Microsoft’s verification page to complete the Device Authorization Grant flow. The common thread: legitimate domains and open redirects were used to make the transition to a malicious flow appear trustworthy.
Recommended mitigations for users and enterprise defenders
The source offers concrete, actionable steps:
- Users: If you did not initiate a Device Code login on a separate device, do not approve the authorization request and never enter an authorization code received via unexpected email or message, even when the link points to an official Microsoft domain.
- Link hygiene: Threat actors favour open redirects using parameters like redirect_uri, return_url or next. Before clicking, hover to inspect the primary domain and any redirect parameters; once a page loads, verify the final URL matches the expected asset before entering credentials.
- Enterprises: Evaluate whether the Device Code Flow is required for business operations. If not, disable it globally via Conditional Access policies within Microsoft Entra ID. Enable monitoring for DeviceCodeSignIn events, enforce device compliance states, and configure alerts for anomalous sign-in behavior from unusual locations.
- Email security: Deploy robust email protection capable of securing corporate and personal messages, since the campaigns began with deceptive emails and either attachments or links that led into the flow.
What this means for enterprise teams, technologists, and end users
- Enterprise teams should reassess the business need for Device Code Flow and apply Conditional Access controls in Microsoft Entra ID where possible; they should also add DeviceCodeSignIn to their monitoring and alerting rules.
- Technologists and security operators must watch for traffic patterns tied to open redirects and anomalous DeviceCodeSignIn events, and enforce device compliance policies to limit token issuance risks.
- End users need to treat unexpected one-time codes as potential lures: do not paste codes received through email or unfamiliar sites into an official authentication portal unless you started the device login yourself.
The key takeaway is simple and uncomfortable: attackers can weaponize legitimate authentication flows and trusted domains, not just fake login pages. Organizations that cannot justify the Device Authorization Grant in daily operations should disable it; those that need it must instrument monitoring and controls to detect phished approvals and long-lived refresh_token abuse.
Source: https://securelist.com/microsoft-device-code-phishing-attack/120350/
