Device Code Phishing Hits 340+ Organisations — Block OAuth Device Flow in Microsoft 365 Today

What Is Device Code Phishing?

Device code authentication is a legitimate Microsoft feature designed for devices that don't have a browser or keyboard — think smart TVs, IoT sensors, and conference room displays. Instead of typing a password directly, the device shows a short code and tells you to visit microsoft.com/devicelogin on another device, enter the code, and authenticate there.

Attackers have weaponised this flow. Instead of a device generating the code, the attacker generates it and sends it to the victim via a phishing email. When the victim enters the code and authenticates (including completing MFA), the attacker receives the resulting OAuth tokens and gains full access to the victim's Microsoft 365 account.

This technique was first observed in mid-2024 as a Russian state-sponsored campaign tracked by Microsoft as Storm-2372. In February 2026, a Phishing-as-a-Service platform called EvilTokens appeared on Telegram, making this attack available to anyone willing to pay. The result: 340+ confirmed compromises across five countries, with Australia among the hardest hit.

How the Attack Works Step by Step

Understanding the attack chain is important because it explains why traditional defences fail and why the Conditional Access block is the only reliable countermeasure.

1. Phishing Email Arrives The victim receives an email using familiar lures: DocuSign signature requests, voicemail notifications, construction bid documents, or Microsoft Forms. These are crafted to look routine and urgent.
2. Legitimate Redirect Services Hide the Malicious URL The phishing link is wrapped inside legitimate URL redirect services from Cisco (Secure Email), Trend Micro, and Mimecast. Because these are trusted domains, spam filters and email gateways pass them through.
3. Multi-Hop Redirect Chain Clicking the link triggers a chain of redirects through compromised websites, then to Cloudflare Workers, then to Vercel, before finally landing on the attacker's page. Each hop makes detection harder.
4. Attacker Landing Page Displays a Device Code The landing page shows a pre-generated Microsoft device code and instructs the victim to visit microsoft.com/devicelogin and enter it. This is the real Microsoft site — not a fake.
5. Victim Authenticates and Completes MFA The victim enters the code on the genuine Microsoft login page, types their password, and completes their normal MFA challenge (push notification, authenticator code, whatever they use). They believe they are authorising a legitimate action.
6. Attacker Receives OAuth Tokens Behind the scenes, the attacker's infrastructure (hosted on Railway.com PaaS) is polling Microsoft's device code endpoint. The moment the victim completes authentication, the attacker receives OAuth access and refresh tokens for that user's account.
7. Persistent Access — Survives Password Reset The attacker now has refresh tokens that persist even if the victim changes their password. The attacker can access email, files, Teams, SharePoint — everything the victim can access — until the tokens are explicitly revoked.

Why MFA Does Not Help

This is the critical point that makes device code phishing different from traditional credential theft.

Why Password Resets Don't Help Either

When an account is compromised via device code phishing, the attacker holds OAuth refresh tokens. These tokens are independent of the user's password. Changing the password does not invalidate existing tokens. The attacker maintains access until you explicitly revoke all refresh tokens via the Entra admin portal or PowerShell.

Not sure if your environment is blocking device code flow? Contact AyeTech or call 02 9188 8000 — we can check your Conditional Access policies in minutes.

Who Is Being Targeted in Australia

The EvilTokens campaign is not targeting a single industry. Based on reporting from Huntress and the Cloud Security Alliance, the following Australian sectors have been targeted:

Additional sectors include financial services, non-profits, real estate, and manufacturing. The breadth of targeting indicates this is an opportunistic, volume-based campaign — not a precision operation aimed at a specific industry.

If you run Microsoft 365, you are a potential target regardless of your sector or size.

Indicators of Compromise to Hunt For

If you want to determine whether your environment has already been targeted or compromised, look for these indicators in your Entra sign-in logs and email gateway logs.

The spoofed iOS user-agent is particularly useful for detection. An authentication request claiming to come from iPhone OS 18_7 running Version/26.3 of Safari is fabricated — that version of iOS does not exist. If you see this in your sign-in logs, investigate immediately.

How AyeTech Responded — Blocked Across All Managed Tenants

1. Threat Intelligence Detection AyeTech's security team monitors threat intelligence feeds, vendor advisories, and industry reporting continuously. The EvilTokens device code phishing campaign was flagged as a priority threat as soon as Huntress published their analysis.
2. Immediate Conditional Access Deployment We deployed the device code flow block via Conditional Access across all managed Microsoft 365 tenants. The policy was rolled out within hours of the threat being confirmed — before any known phishing email from this campaign reached our managed environments.
3. Sign-In Log Audit We ran the KQL detection query across every managed tenant, reviewing 30 days of sign-in logs for any device code authentication from suspicious sources. No compromise indicators were found in any AyeTech-managed environment.
4. Client Communication Every managed client was notified of the threat and the protective action taken. Clients received a clear explanation of the attack, why MFA does not prevent it, and confirmation that their environment was already protected.

Result: All AyeTech-managed Microsoft 365 tenants had device code flow blocked before any client was impacted by this campaign.

Why This Matters for Self-Managed Environments

If you are managing your own Microsoft 365 environment:

• You may not monitor threat intelligence feeds that would alert you to this campaign
• You may not know that device code flow exists, let alone that it needs to be blocked
• You may not have the Entra ID licensing or expertise to configure Conditional Access policies
• You may not know how to audit sign-in logs for compromise indicators
• You may already be compromised and not know it — because the attacker is using legitimate tokens that look like normal activity

This is why managed IT exists. The difference between a managed and self-managed environment in this scenario is the difference between being protected before the attack arrives and discovering the breach weeks later when a BEC payment goes to the wrong bank account.

What Needs to Happen to Protect Your Business

Blocking this attack requires multiple coordinated actions across your Microsoft 365 environment. This is not a single setting you can toggle — it requires Entra ID expertise, the right licensing, and the tools to verify it was done correctly.

1. Block Device Code Flow in Conditional Access A specific Conditional Access policy must be configured in Entra ID to block the device code authentication flow for all users. This is the kill switch that prevents the attack entirely. It requires Entra ID P1 licensing and knowledge of how authentication flows, exclusion groups, and break-glass accounts interact. Get it wrong and you lock out legitimate users. Miss an exclusion and you leave a gap.
2. Audit 30 Days of Sign-In Logs for Compromise Even after deploying the block, you need to check whether device code authentication has already been used in your environment. This means querying Entra sign-in logs with specific filters for the deviceCode authentication protocol, cross-referencing against known attacker IP ranges, and interpreting the results. Most businesses do not have Microsoft Sentinel or Log Analytics configured to run these queries.
3. Revoke Tokens for Any Compromised Accounts If compromise is detected, resetting the password is not enough — OAuth refresh tokens must be explicitly revoked. Then you need to audit mail forwarding rules, check for malicious OAuth app consents, review newly registered devices, and inspect inbox rules the attacker may have created to hide their activity. Missing any of these steps means the attacker retains access or leaves behind a backdoor.
4. Harden Email Filtering Against Redirect Abuse The phishing emails in this campaign bypass email security by wrapping malicious URLs inside legitimate redirect services from well-known vendors. Your email gateway configuration needs to be reviewed to ensure these redirect chains are detected and blocked, not trusted.
5. Verify Microsoft-Managed Policies Microsoft may have auto-deployed a managed Conditional Access policy under the Secure Future Initiative — but it may be set to "Report-only" mode, which logs events without actually blocking them. This needs to be checked and enforced.

Why You Cannot Do This Alone

Device code phishing is a perfect example of why self-managing Microsoft 365 is a risk most businesses cannot afford. Consider what happened in this scenario:

This campaign hit 340+ organisations. The ones that were protected had IT providers watching the threat landscape and deploying countermeasures before the phishing emails arrived. The ones that were compromised were managing their own environments and had no idea this attack vector existed.

What AyeTech Does for Every Managed M365 Tenant

• 24/7 threat intelligence monitoring: We track new attack techniques as they emerge and deploy countermeasures proactively — not after the first compromise
• Conditional Access management: We configure and maintain security policies across all managed tenants, ensuring legacy authentication flows, risky sign-in behaviours, and known attack vectors are blocked
• Sign-in log monitoring: We continuously audit authentication logs for suspicious activity, including device code flow abuse, impossible travel, and token replay from cloud infrastructure IPs
• Incident response: If a compromise is detected, we execute token revocation, mail rule audits, OAuth consent reviews, and full account remediation immediately
• Email security hardening: We configure and maintain email filtering policies to detect and block phishing campaigns, including the redirect chain techniques used in this attack

The cost of managed IT is a fraction of a single successful BEC incident. The cost of not having it is discovering that an attacker has been reading your email for three weeks and has already redirected a $64,000 payment.