Microsoft 365 EvilToken campaign: why this threat matters now
The Microsoft 365 EvilToken campaign is a fast-moving phishing campaign built around OAuth token abuse, not simple password theft. That detail matters. In these attacks, the user signs in through a real Microsoft flow, completes MFA themselves, and ends up giving the attacker a valid OAuth token. Microsoft has warned that this activity is compromising hundreds of organisations daily, with 10 to 15 distinct campaigns launching every 24 hours since mid-March 2026.
That is what makes this one feel different. If you are used to spotting fake login pages, password sprays, or odd MFA prompts, EvilToken changes the script. The attacker does not always need your password. They need you to complete a legitimate device code login flow that hands access to their session.
What is EvilToken phishing?
EvilToken phishing is a form of device code phishing that abuses Microsoft OAuth flows. Instead of stealing credentials directly, the attacker generates a device code, tricks the victim into entering it at the legitimate Microsoft device login page, and waits for Microsoft to issue access tokens and refresh tokens to the attacker-controlled session.
In plain English, the attacker gets you to finish a real login for them.
This technique works because device code authentication was designed for devices with limited input, like smart TVs or shared devices. That design is useful in normal cases. In the wrong hands, it becomes a clean path to account access.
AppOmni reported both attempted and successful EvilToken incidents across Microsoft 365 environments. Huntress also tied large parts of this ecosystem to Railway-hosted infrastructure and an EvilTokens phishing-as-a-service setup that appears to scale quickly.
How the Microsoft 365 EvilToken campaign works
Here is the simple version of the attack chain:
- The attacker sends a phishing lure tied to something urgent or normal-looking, like an invoice, RFP, secure document, or workflow task.
- The victim clicks through and is told to continue with Microsoft.
- The victim is prompted to enter a device code at the real Microsoft device login page.
- The victim signs in and completes MFA.
- Microsoft issues a valid OAuth token to the attacker session that initiated the device flow.
- The attacker uses that token to access Microsoft 365 services through normal APIs, often with little friction.
Some campaigns appear highly automated. AppOmni noted dynamic code generation that helps attackers exploit the 15-minute device code window. Huntress also observed large-scale infrastructure patterns, token harvesting behavior, and signs of automation across delivery pages, redirect chains, and user-agent choices.
Why OAuth token phishing is harder to detect than password phishing
A lot of security teams still think in terms of stolen passwords. This campaign does not fit that old model.
Because the victim completes the legitimate Microsoft authentication flow and MFA themselves, the resulting activity can look normal in logs. You may not see the classic signs of credential theft. Instead, you may see valid access, normal-looking token use, and API calls that blend into business activity.
That creates three big problems:
- Identity becomes the main attack surface.
- Tokens become the persistence mechanism.
- Risk continues after authentication, not just at login.
That last point is the one I keep coming back to. Many teams invest heavily in stopping bad logins, but less time watching what happens after a valid login succeeds.
Who is being targeted?
The reported targeting centers on high-value users, especially:
- Finance teams
- Executive users
- Administrative staff
- Users with access to sensitive communications, approvals, contracts, and payment workflows
The phishing messages are often tailored with generative AI. That helps attackers produce lures around invoices, requests for proposals, shared files, DocuSign-style approvals, business agreements, and internal workflow tasks. Huntress noted wide lure diversity, which suggests attackers can produce convincing messages at scale without repeating the same obvious template.
What attackers do after they get access tokens
Once attackers have valid Microsoft 365 access tokens, they can act like a logged-in user. Common post-authentication activity includes:
- Using Microsoft Graph API to search email and files
- Reading sensitive communications
- Creating inbox rules to hide messages or forward mail
- Registering new devices to extend access
- Adding or changing authentication methods
- Maintaining access through refresh tokens
Huntress noted refresh tokens may remain valid for up to 90 days in some cases. That is a long time if no one notices. Even if you revoke sessions, existing in-flight access tokens may still remain usable for a short period unless Continuous Access Evaluation is enabled.
Signs your Microsoft 365 tenant may be affected
If you manage Microsoft 365, watch for these indicators:
- Device code authentication activity from users who do not normally use it
- Suspicious inbox rules, especially hidden forwarding or delete rules
- Abnormal Microsoft Graph API activity
- Unexpected device registrations
- New authenticator app or MFA registrations
- Login activity tied to unusual infrastructure or IP ranges
- Non-interactive sign-ins that do not fit the user's normal behavior
In some reported cases, attackers used infrastructure that looked clean from a reputation point of view. That means domain blocking alone is not enough. You need to review identity telemetry and token behavior.
What to do right now if you want to reduce risk
If your users do not need device code authentication, block it.
That is the clearest preventive step in the reporting on this campaign. Use Conditional Access to restrict or disable device code authentication for users and roles that do not require it.
Then take these steps:
- Review which users truly need device code flow
- Restrict device code authentication to approved identities only
- Audit connected OAuth applications and their scopes
- Remove unused or overly permissive app integrations
- Restrict user consent where appropriate
- Require compliant devices for Exchange Online and SharePoint when possible
- Enable Continuous Access Evaluation to shorten token revocation time
- Train users on device code phishing, not just fake login pages
One important note: phishing-resistant MFA such as passkeys or FIDO keys helps against credential phishing, but it does not fully stop device code flow abuse. That is a key point from the reporting and an easy one to miss.
What to do if you suspect an attempted phish
If the user saw the lure but did not complete the device code login, your focus is containment and review.
Do this:
- Educate the user on what happened
- Review recent authentication activity for device code usage
- Tighten Conditional Access policies
- Watch for suspicious follow-up attempts
- Check whether similar users received the same lure
This is the best moment to shut the door before a valid token is issued.
What to do if compromise is confirmed
If a valid OAuth token was issued to an attacker, move quickly.
Recommended response steps:
- Revoke active sessions
- Invalidate refresh tokens
- Force reauthentication
- Reset credentials for affected or high-risk users
- Remove unauthorised devices
- Delete malicious inbox rules
- Audit for new authenticator app or MFA registrations
- Review Microsoft Graph API activity for data access
- Check for permission or configuration changes
- Investigate related users, shared mailboxes, and admin roles
If you have strong logging, map the timeline from first device code event to token use, device registration, inbox-rule creation, and API access. That will help you understand scope.
How to build a longer-term defense against EvilToken phishing
The bigger lesson from this campaign is simple: you cannot stop at login security.
To lower long-term risk, focus on how access is granted, used, and extended.
1. Validate identity and access continuously
Review who has access, how they authenticated, whether least privilege still makes sense, and whether non-human identities are being monitored.
2. Monitor post-authentication behavior
Track token usage patterns, Graph API calls, permission changes, and unusual data access. A valid login should not automatically mean trusted activity.
3. Control OAuth and app access
Audit app consent, scopes, and integrations. Remove anything stale, overpowered, or unnecessary.
4. Prioritise high-impact users
Finance, executives, admins, and privileged users need stronger controls and closer monitoring because they offer the biggest payoff to attackers.
5. Use business context
Not every alert matters equally. Focus first on identities tied to sensitive data, financial workflows, approvals, legal communications, and executive mailboxes.
Why this campaign is a bigger shift in SaaS attacks
AppOmni framed EvilToken as part of a broader change in SaaS security. That framing makes sense.
Attackers are moving away from noisy infrastructure attacks and toward identity-centered abuse. They use native SaaS features, real authentication flows, valid tokens, and built-in APIs. In other words, they are using the platform the way it was designed, just for the wrong purpose.
That is why traditional controls can fall short. If the attacker already has valid access, perimeter thinking does not help much.
FAQ
What is the Microsoft 365 EvilToken campaign?
The Microsoft 365 EvilToken campaign is an OAuth token phishing campaign that uses device code authentication to trick users into completing a legitimate Microsoft sign-in flow. Once the user approves the request, the attacker receives valid access tokens for Microsoft 365.
How does OAuth token phishing work in Microsoft 365?
In these attacks, the attacker starts a device code login session, sends the code to the victim through a phishing lure, and asks the victim to enter it at Microsoft's real device login page. The victim signs in and completes MFA, and Microsoft then issues tokens to the attacker session.
Can MFA stop EvilToken phishing?
Not by itself. In this attack, the victim completes MFA as part of the legitimate flow. That means the attacker still gets valid tokens. Phishing-resistant MFA helps against password theft, but it does not fully prevent device code abuse.
Why are hundreds of organisations being hit daily?
Microsoft reported that hundreds of organisations are compromised daily and that 10 to 15 related campaigns launch every 24 hours. Automation, AI-generated lures, fast infrastructure deployment, and legitimate Microsoft authentication flows all help attackers scale this tactic.
What should you do first if you suspect compromise?
Start by revoking active sessions, invalidating refresh tokens, and forcing reauthentication. Then review inbox rules, device registrations, Microsoft Graph API activity, and any changes to MFA methods or connected applications.
Should you disable device code authentication?
If your users do not need it, yes. Restricting or disabling device code authentication through Conditional Access is one of the most effective preventive steps for this attack class.
Final takeaway
The Microsoft 365 EvilToken campaign hits hundreds daily because it turns a real Microsoft login into an attack path. No fake password page is required. No stolen password is required. The attacker just needs your user to complete a legitimate device code flow that grants a valid OAuth token.
If you run Microsoft 365 in 2026, now is a good time to review device code authentication, tighten Conditional Access, audit OAuth apps, and watch what happens after login, not just before it.
