A 37x Surge That Most Security Teams Haven't Heard Of
Device code phishing attacks have surged more than 37 times in 2025, according to reporting from BleepingComputer. The technique is not new, but the explosion in ready-made attack kits circulating online has turned what was once a niche, technically demanding attack into something any moderately capable threat actor can run at scale. The reason this matters is straightforward: device code phishing bypasses two of the most common defences organisations rely on. It sidesteps multi-factor authentication. And because it does not involve a malicious link in the traditional sense, it evades most email security filters. Businesses that believe MFA alone makes them safe from phishing need to reassess that assumption now.
What Is Device Code Phishing and How Does It Work?
To understand the threat, you need a brief grounding in OAuth 2.0 Device Authorization Grant flow. This is a legitimate authentication mechanism designed for devices that cannot easily display a browser, such as smart TVs, printers, or IoT hardware. When you sign into a streaming service on your television, you are likely using this flow: the device gives you a short code, you visit a URL on your phone or laptop, enter the code, and the device gains access. Attackers have turned this mechanism against its users. Here is how the attack unfolds in practice: An attacker initiates a device authorisation request against a legitimate identity provider, such as Microsoft or Google. They receive a genuine user code and a verification URL. They then send that code to a target, typically via email, Teams message, or SMS, dressed up as a routine IT notification, a security alert, or a software activation prompt. The target visits the legitimate verification URL (which is real and trusted), enters the code, and authenticates. At that moment, the attacker's session receives a valid access token and refresh token. They are now inside the account, with no stolen password and no MFA prompt of their own to clear. The access token grants the attacker persistent access to email, files, calendars, and connected cloud services. Because the token can be refreshed, simply changing the account password after the fact may not revoke access immediately if the token has already been issued and cached.
- The attacker never needs to know the victim's password
- MFA is completed by the victim themselves, unknowingly authorising the attacker's session
- The verification URL is genuine, so link-scanning tools flag nothing suspicious
- Refresh tokens can maintain access even after the victim changes their password
- Access extends to any service connected to the compromised identity provider
Why Attack Kits Have Changed the Threat Level
Until recently, executing a device code phishing attack required meaningful technical knowledge of OAuth flows, token handling, and session management. The barrier kept this technique in the hands of more sophisticated actors, including state-sponsored groups. That barrier has collapsed. Ready-to-use phishing kits that automate the entire attack chain are now circulating on criminal forums and Telegram channels. These kits handle the OAuth request, generate the user code, construct convincing lure messages, and capture the resulting tokens, all with minimal configuration. The skill floor has dropped dramatically. This is the same pattern seen with ransomware-as-a-service: once sophisticated tooling becomes commoditised, attack volumes spike. The 37x increase in device code phishing observed in 2025 reflects exactly this dynamic. The technique itself has not changed. What changed is that anyone with a forum account and a target list can now run it.
Who Is Being Targeted and What Are the Consequences?
Device code phishing is particularly effective against Microsoft 365 and Azure environments, which are the dominant productivity platforms for UK businesses and widely used across New Zealand and Australia. Any organisation running Teams, SharePoint, Exchange Online, or Azure-connected applications is a potential target. The lures being used in active campaigns include fake IT helpdesk messages asking users to re-authenticate, Microsoft Teams notifications prompting device verification, and fabricated security alerts claiming unusual sign-in activity that require the user to confirm their identity. Business email compromise (BEC) is the most immediate downstream consequence. Once an attacker holds a valid session token for a senior finance or executive account, they can read historical emails to understand payment processes, impersonate the account owner to redirect transfers, and exfiltrate sensitive documents from SharePoint or OneDrive. Beyond BEC, compromised identity tokens provide lateral movement opportunities across any application in the organisation's Microsoft or Google ecosystem. A single successful device code phish can unravel an entire cloud environment. For regulated businesses, the consequences extend further. A compromised Microsoft 365 tenant that results in data exposure triggers notification obligations under the UK GDPR and, for New Zealand organisations, the Privacy Act 2020.
Why Standard Defences Fall Short Against This Attack
The uncomfortable reality is that most organisations' email security investments were not built to catch this. Traditional phishing detection looks for malicious URLs, suspicious attachments, and spoofed sender domains. Device code phishing uses none of these vectors in the expected way. The URL the victim clicks is genuinely owned by Microsoft or Google. The sender may be a compromised internal account. There is no payload to scan. MFA, the standard recommendation for phishing resistance, provides no protection here either. The victim completes MFA as part of the normal authentication flow. They are the ones verifying their identity. The attacker is simply the beneficiary of that verification. Conditional access policies can help if they are configured to restrict device code flows to managed, compliant devices. However, many organisations have not implemented this restriction, often because the setting requires deliberate configuration and can disrupt legitimate use cases if applied without testing. Hadrian's continuous attack surface monitoring can identify Microsoft 365 misconfigurations of exactly this kind, surfacing gaps before an attacker finds them. If your Azure conditional access policies are not actively blocking unauthorised device code flows, that is an exploitable exposure in your environment right now.
What a Layered Defence Actually Looks Like
Stopping device code phishing requires several controls working together, because no single tool handles this attack vector end to end. First, conditional access policies in Microsoft Entra ID (formerly Azure AD) should be configured to block or restrict the device code grant flow. Microsoft provides specific policy settings that prevent this flow from being initiated except on managed devices. If you do not have this in place, it is the highest priority change you can make today. Second, phishing-resistant MFA methods matter. FIDO2 security keys and certificate-based authentication bind the authentication to the physical device and cannot be redirected to an attacker's session in the way that SMS or app-based MFA can. Microsoft calls this 'phishing-resistant MFA' for exactly this reason. Third, security awareness training must evolve. Users need to understand that a legitimate-looking Microsoft verification page is not proof that a request is safe. Any unexpected prompt to enter a code, particularly one that arrived via email or Teams from someone they did not expect, should be treated as suspicious. Fourth, threat detection needs to look for the right signals. Impossible travel events, token replays from unexpected IP addresses, and access patterns inconsistent with normal user behaviour are the indicators device code phishing leaves behind. These require a detection layer with visibility across identity events, not just endpoint telemetry.
How to Protect Your Business From Device Code Phishing
For UK organisations running Microsoft 365, Coro provides unified protection across email, cloud applications, and endpoints from a single platform. Critically, Coro includes cloud application security that monitors Microsoft 365 and connected SaaS environments for anomalous access patterns, including the kind of token-based access that device code phishing produces. Rather than relying solely on perimeter controls, Coro watches what happens after authentication, where this attack does its damage. Unusual session activity, access from unexpected locations, and atypical data access patterns all trigger alerts. You can explore Coro's capabilities at /products/coro. For organisations in New Zealand and Australia, ESET's endpoint protection provides the foundational layer, and pairing it with identity-aware monitoring for Microsoft 365 environments is the critical addition given this threat. More information is available at /products/eset. Across both markets, Hadrian's continuous attack surface management is directly relevant here. Hadrian scans your external and cloud-facing attack surface for misconfigurations, including Azure conditional access gaps that leave device code flows unrestricted. Finding those gaps before an attacker does is precisely what continuous pen testing is designed for. See /products/hadrian. For organisations concerned about what happens if a phishing attack succeeds and an attacker begins exfiltrating data from a compromised cloud account, BlackFog's anti data exfiltration technology adds a final containment layer, preventing unauthorised data movement even when credentials have been compromised. Details at /products/blackfog. If you are unsure whether your current controls adequately address this attack vector, the right starting point is an honest assessment of your exposure. Check your data exfiltration risk in under two minutes at /data-exfiltration-risk, or contact the Kyanite Blue team directly at /contact to discuss your Microsoft 365 security posture. Device code phishing is no longer an edge case. The 37x surge in 2025 makes that clear.
Frequently Asked Questions
Does multi-factor authentication protect against device code phishing?
No. Device code phishing bypasses MFA because the victim completes the authentication challenge themselves, unknowingly authorising the attacker's session. The attacker never needs to pass an MFA prompt directly. Only phishing-resistant MFA methods such as FIDO2 security keys, combined with conditional access policies that block the device code OAuth flow, provide reliable protection.
How do attackers use device code phishing to access Microsoft 365 accounts?
Attackers initiate a legitimate OAuth 2.0 device authorisation request, receive a user code, then send that code to a target disguised as an IT or security notification. When the victim enters the code at the genuine Microsoft verification page and authenticates, the attacker's session receives a valid access token granting persistent access to email, files, and connected cloud services without ever knowing the victim's password.
What is the best way to block device code phishing in Microsoft 365?
The most effective technical control is a conditional access policy in Microsoft Entra ID that blocks or restricts the device code grant flow to managed, compliant devices only. Combined with phishing-resistant MFA such as FIDO2 keys, ongoing monitoring for anomalous token-based access in the Microsoft 365 environment, and regular attack surface scanning for misconfigurations, organisations can substantially reduce their exposure to this attack technique.