Microsoft 365 Users Targeted in Device Code Phishing Attacks
Summary:
Proofpoint Threat Research has identified an increase in phishing campaigns that leverage the OAuth 2.0 device authorization grant flow to compromise Microsoft 365 (M365) accounts. While this technique is not new, researchers noted a significant shift toward widespread, high-volume campaigns starting in September 2025. The attack typically begins with a phishing lure, often delivered via email buttons, hyperlinked text, or QR codes, that initiates a legitimate Microsoft device authorization process. Targets are socially engineered into entering a "One-Time Password", which is actually a dynamically generated device code, into Microsoft’s official verification URL. Once the user enters the code and approves the request, the threat actor receives an access token, granting them full control over the account for data exfiltration, lateral movement, or further account takeover activities.
The activity is being driven by both financially motivated cybercriminals and state-aligned advanced persistent threats (APTs). Specifically, the threat actor TA2723 has been observed using tools like SquarePhish2 and the Graphish kit to automate and scale these attacks. Additionally, a Russia-aligned group tracked as UNK_AcademicFlare has been using this method to target government, military, and think-tank entities. This group often employs "benign outreach" to build rapport with targets before sending a link to a Cloudflare Worker URL that spoofs a OneDrive login. The rise of these campaigns is largely attributed to the availability of refined red-team tools on GitHub and hacking forums, which help attackers overcome the short-lived nature of device codes and bypass traditional multi-factor authentication.
Security Officer Comments:
The pivot toward device code phishing represents a sophisticated evolution in "adversary-in-the-middle" (AiTM) tactics. By leveraging a legitimate Microsoft authentication flow designed for devices with limited input capabilities (like smart TVs or IoT devices), attackers can bypass modern security controls such as FIDO2-based MFA and conditional access policies that don't specifically account for this flow. This technique is particularly effective because the final interaction occurs on a legitimate Microsoft domain, which significantly reduces user suspicion and bypasses many automated URL reputation scanners.
The involvement of state-aligned actors like UNK_AcademicFlare highlights a broader trend where espionage groups are adopting "password-less" phishing techniques to maintain persistent access to high-value targets. The use of Cloudflare Workers to host landing pages further complicates detection, as these services often have a high reputation and can bypass basic domain-age or reputation-based filters. For CTI analysts, the emergence of the Graphish kit and updated versions of SquarePhish suggests that the barrier to entry for executing complex OAuth-based attacks is lowering. Organizations should treat any "device code" or "OTP" request that appears during a standard web-based login as a high-fidelity indicator of a phishing attempt, as legitimate M365 web logins rarely require this specific flow.
Suggested Corrections:
Block device code flow where possible
The strongest mitigation is to create a Conditional Access policy using the Authentication Flows condition to block device code flow for all users. Conditional Access policies can first be deployed in a report only mode, or the ‘Policy impact’ viewed over historic sign in log records, to determine the impact for an environment.
If blocking device code flow completely is not feasible, Conditional Access can be used to create an allow-list approach based on accepted use cases. For example, only enabling device code authentication for approved users, operating systems, or IP ranges such as using ‘Named locations’.
Require compliant or joined devices
If organizations use device registration or Intune, Conditional access policies requiring that sign ins originate from a compliant or registered device will protect users from device code phishing. This should be deployed as a defense in depth strategy, as there will likely be exclusions from this requirement, when compared with a dedicated device code flow policy.
Enhance user awareness regarding device code phishing attacks
Traditional phishing awareness often emphasizes checking URLs for legitimacy. This approach does not effectively address device code phishing, where users are prompted to enter a device code on the trusted Microsoft portal. User training should include guidance on not entering device codes received from untrusted sources.
Link(s):
https://www.helpnetsecurity.com/2025/12/18/microsoft-365-device-code-phishing/
Proofpoint Threat Research has identified an increase in phishing campaigns that leverage the OAuth 2.0 device authorization grant flow to compromise Microsoft 365 (M365) accounts. While this technique is not new, researchers noted a significant shift toward widespread, high-volume campaigns starting in September 2025. The attack typically begins with a phishing lure, often delivered via email buttons, hyperlinked text, or QR codes, that initiates a legitimate Microsoft device authorization process. Targets are socially engineered into entering a "One-Time Password", which is actually a dynamically generated device code, into Microsoft’s official verification URL. Once the user enters the code and approves the request, the threat actor receives an access token, granting them full control over the account for data exfiltration, lateral movement, or further account takeover activities.
The activity is being driven by both financially motivated cybercriminals and state-aligned advanced persistent threats (APTs). Specifically, the threat actor TA2723 has been observed using tools like SquarePhish2 and the Graphish kit to automate and scale these attacks. Additionally, a Russia-aligned group tracked as UNK_AcademicFlare has been using this method to target government, military, and think-tank entities. This group often employs "benign outreach" to build rapport with targets before sending a link to a Cloudflare Worker URL that spoofs a OneDrive login. The rise of these campaigns is largely attributed to the availability of refined red-team tools on GitHub and hacking forums, which help attackers overcome the short-lived nature of device codes and bypass traditional multi-factor authentication.
Security Officer Comments:
The pivot toward device code phishing represents a sophisticated evolution in "adversary-in-the-middle" (AiTM) tactics. By leveraging a legitimate Microsoft authentication flow designed for devices with limited input capabilities (like smart TVs or IoT devices), attackers can bypass modern security controls such as FIDO2-based MFA and conditional access policies that don't specifically account for this flow. This technique is particularly effective because the final interaction occurs on a legitimate Microsoft domain, which significantly reduces user suspicion and bypasses many automated URL reputation scanners.
The involvement of state-aligned actors like UNK_AcademicFlare highlights a broader trend where espionage groups are adopting "password-less" phishing techniques to maintain persistent access to high-value targets. The use of Cloudflare Workers to host landing pages further complicates detection, as these services often have a high reputation and can bypass basic domain-age or reputation-based filters. For CTI analysts, the emergence of the Graphish kit and updated versions of SquarePhish suggests that the barrier to entry for executing complex OAuth-based attacks is lowering. Organizations should treat any "device code" or "OTP" request that appears during a standard web-based login as a high-fidelity indicator of a phishing attempt, as legitimate M365 web logins rarely require this specific flow.
Suggested Corrections:
Block device code flow where possible
The strongest mitigation is to create a Conditional Access policy using the Authentication Flows condition to block device code flow for all users. Conditional Access policies can first be deployed in a report only mode, or the ‘Policy impact’ viewed over historic sign in log records, to determine the impact for an environment.
If blocking device code flow completely is not feasible, Conditional Access can be used to create an allow-list approach based on accepted use cases. For example, only enabling device code authentication for approved users, operating systems, or IP ranges such as using ‘Named locations’.
Require compliant or joined devices
If organizations use device registration or Intune, Conditional access policies requiring that sign ins originate from a compliant or registered device will protect users from device code phishing. This should be deployed as a defense in depth strategy, as there will likely be exclusions from this requirement, when compared with a dedicated device code flow policy.
Enhance user awareness regarding device code phishing attacks
Traditional phishing awareness often emphasizes checking URLs for legitimacy. This approach does not effectively address device code phishing, where users are prompted to enter a device code on the trusted Microsoft portal. User training should include guidance on not entering device codes received from untrusted sources.
Link(s):
https://www.helpnetsecurity.com/2025/12/18/microsoft-365-device-code-phishing/