As reported by Dark Reading, Microsoft this week seized 50 websites and disabled over 150 domains tied to EvilTokens, a phishing-as-a-service (PhaaS) operation targeting Microsoft 365 credentials. The disruption is welcome, but the underlying technique deserves more attention than the takedown itself.

Threat Alert: The EvilTokens playbook exploited OAuth 2.0 Device Authorization Grant (RFC 8628) — a flow Microsoft documents for IoT, smart TVs, and headless systems that lack a keyboard or browser for interactive sign-in.

Why Device Code Phishing Is Hard to Stop

The EvilTokens playbook exploited OAuth 2.0 Device Authorization Grant (RFC 8628) — a flow Microsoft documents for IoT, smart TVs, and headless systems that lack a keyboard or browser for interactive sign-in. In a legitimate scenario, a user is shown a short alphanumeric code and directed to https://microsoft.com/devicelogin to complete authentication.

Attackers weaponize this by sending users a Microsoft-branded prompt — typically inside an email, Teams message, or fake MFA notification — instructing them to open the legitimate device login page and enter a code the attacker controls. The victim authenticates against Microsoft's real infrastructure, completes MFA, and unknowingly authorizes the attacker's OAuth session. No spoofed login form, no credential capture, no MFA bypass tooling — the abuse lives entirely inside Microsoft's supported authentication surface.

Device code phishing is one of the few techniques where following the user's MFA prompt to its legitimate destination is the attack. Traditional URL reputation and brand-protection tooling provide little value here.

Who Is Most Exposed

Organizations at elevated risk include those that:

Why Device Code Phishing Is Hard to Stop
Have not disabled device code flow for users or service principals that do not require it
Permit legacy or non-browser authentication without conditional access restrictions
Allow broad OAuth app consent without admin pre-approval policies
Lack monitoring for the deviceCode authentication method in Azure AD / Entra ID sign-in logs
Have large frontline or contractor populations unfamiliar with legitimate device code scenarios

Education, healthcare, and state/local government tenants — frequent M365 customers with large non-technical user bases — are consistently over-represented in EvilTokens-style victim telemetry.

The PhaaS Angle Matters More Than the Domains

Seizing 150 domains disrupts the current affiliate infrastructure, but the underlying PhaaS model means operators will rebuild within days. We have observed this pattern repeatedly with modmail, Bullies, and similar operators: takedowns buy defenders a window of reduced volume, not a permanent solution. The strategic value of these legal actions is in attrition of operator cash flow and intelligence collection, not elimination of the threat.

More importantly, the existence of a turnkey platform lowers the skill threshold for adversaries who would otherwise lack the capability to deploy device code phishing at scale. This democratization is the real story — mid-tier criminal groups can now run what was once an advanced, credential-theft-resistant technique.

Shield53 Recommendations

Defenders should treat the post-disruption window as a deadline for hardening, not a return to baseline:

  • Audit device code flow usage. Query Entra ID sign-in logs for authenticationProtocol: deviceCode over the past 90 days. Identify which users and apps legitimately require it and disable the flow tenant-wide where not needed.
  • Apply conditional access. Require compliant device, hybrid Azure AD join, or managed device state for any non-interactive auth. Block device code grants originating from non-managed devices or untrusted locations.
  • Tighten OAuth app consent. Enable admin consent workflow for new app registrations. Audit and remove previously consented applications, especially any with Mail.Read, Files.ReadWrite.All, or User.Read.All scopes.
  • User training. Update phishing awareness programs to cover device code scenarios explicitly — users should only enter codes on devices they personally initiated sign-in for, and should never enter a code provided in an email, chat, or MFA prompt.
  • Detection rules. Alert on (1) device code sign-ins from new geographies or ASNs, (2) rapid OAuth token issuance following a device code grant, (3) spike in deviceCode authentication volume per user or per tenant.

The EvilTokens disruption will be measured in weeks of reduced phishing volume, not a permanent fix. Defenders who treat device code flow as a controllable attack surface — rather than a Microsoft problem to be solved by takedowns — will be the ones whose tenants stop appearing in next quarter's breach reports.