Attackers are increasingly bypassing traditional defenses by exploiting legitimate authentication flows instead of breaking in. Microsoft’s disclosure of the EvilToken campaign highlights how threat actors are using device code phishing and OAuth tokens to gain direct access to Microsoft 365 (M365) environments without stealing passwords or triggering typical security controls.
Summary of the EvilToken campaign
- The EvilToken campaign targets Microsoft 365 using device code phishing to generate valid OAuth tokens.
- Sophisticated attackers don’t steal passwords anymore. Instead, they trick users into granting access through legitimate login flows.
- Once inside, attackers operate with trusted access via Microsoft Graph. Because MFA is satisfied by the victim during the attack, it provides no detection signal and post-compromise activity appears normal in logs.
- This reflects a broader shift toward identity- and token-based SaaS attacks.
- Defending against these threats requires visibility into authentication methods, token usage, and post-login activity (not just login security).
What is the EvilToken Microsoft attack?
The EvilToken campaign is an active phishing operation targeting Microsoft 365 accounts using device code authentication.
Unlike traditional phishing, this attack does not steal passwords. Instead, it tricks users into completing a legitimate authentication flow that grants the attacker access.
Here’s how the EvilToken campaign works (the attack chain):
- Targeting and reconnaissance: Threat actors focus on high-value users, such as finance, executive, or administrative roles.
- Phishing lure: Users receive a message prompting them to authenticate, often framed as a legitimate request or urgent task. Generative AI was used to create hyper-personalized messages tailored to the victim’s role, like RFPs, invoices, or workflows.
- Device code authentication flow: The user is directed to a real Microsoft login page and enters a device code provided by the attacker.
- User approval: The user completes the authentication process, believing it is legitimate.
- Token issuance: Microsoft issues a valid OAuth token to the attacker’s session, not the user’s device.
- Post-compromise activity: With that token, attackers can access email and files via Microsoft Graph API, create inbox rules to hide activity, search for sensitive financial or executive communications, and register new devices and generate persistent tokens within minutes
Because the victim completes a legitimate Microsoft authentication flow, MFA is fully satisfied. The attacker’s subsequent activity uses a valid token and appears normal in logs.
Device code phishing definition
An attack technique that abuses the OAuth device authorization flow to grant the attacker persistent access tokens (not to the victim’s own session) and take over victim accounts. Unlike traditional credential phishing, this method is particularly dangerous because the stolen tokens remain valid even if the victim later resets their password or credentials.
What does this mean for security teams?
The EvilToken campaign is not an isolated incident. It reflects a consistent and growing pattern in SaaS attacks. Attackers are no longer trying to break in.
They are:
- Logging in with valid access
- Leveraging tokens
- Operating entirely within trusted SaaS environments
This shift introduces several important realities:
- Identity is now the primary attack surface: Compromise happens at the authentication layer, not the infrastructure layer.
- Tokens are the new persistence mechanism: OAuth tokens allow attackers to maintain access without repeated logins or password reuse.
- Post-authentication activity is where risk lives: Once inside, attackers can move laterally, access sensitive data, and blend in with normal behavior.
- Native features are being weaponized: Device code authentication and OAuth flows are designed for usability but can be exploited when not properly controlled.
- Combined with AI-generated lures and dynamic code generation (to exploit the full 15-minute window of token validity) , this campaign shifted from manual scripts to a fully automated, AI-driven attack chain.
The broader pattern is clear: If an attacker has valid access, traditional security controls are often insufficient.
What should security teams do?
Security teams should think about response in two layers: containment and continuous risk reduction.
Immediate actions: Contain active risk
Start by reducing active exposure:
- Restrict or disable device code authentication where not required
- Block device code authentication flow via Conditional Access for users who do not require it. This is the primary preventive control for this attack class. Phishing-resistant MFA (passkeys, FIDO keys) reduces risk from credential phishing but does not prevent device code flow abuse.
- Revoke active sessions and invalidate refresh tokens if compromise is suspected
- Reset credentials for impacted or high-risk users
Monitor for:
- Suspicious inbox rules
- Abnormal Microsoft Graph API activity
- Unexpected device registrations
These steps help contain active threats but don’t address the root issue.
Strategic actions: Reduce SaaS attack surface over time
To prevent recurrence, organizations need to focus on how access is granted, used, and extended across SaaS environments.
| 1. Validate identity and access continuously | Understand: → Who has access (including non-human identities) → How they authenticated (OAuth, device code, SSO) → Whether access aligns with least privilege |
| 2. Monitor post-authentication behavior | Look beyond login events and focus on: → Token usage patterns → API activity tied to data access → Changes to configurations or permissions |
| 3. Control OAuth and application access | OAuth integrations introduce significant risk: → Audit connected applications and their scopes → Remove unused or overly permissive integrations → Restrict user consent where appropriate |
| 4. Prioritize risk, not noise | Shift from alert-driven security to risk-based prioritization: → Focus on high-impact identity + access combinations → Identify activity tied to sensitive data → Reduce exposure based on business context |
This is where many organizations struggle. Visibility exists, but context is missing.
What should AppOmni customers do?
AppOmni Scout, our threat hunting team, has identified both attempted and successful EvilToken device code phishing activity across Microsoft 365 environments. Your response should depend on whether access was granted.
| Scenario | What It Means | What To Do |
| Attempted phishing (no token issued) | Users were targeted, but no successful authentication occurred. The risk of follow-up attempts remains. | → Educate affected users on device code phishing → Restrict/disable device code authentication where possible → Review recent auth activity for device code usage → Tighten access policies |
| ⚠️ Confirmed compromise (token issued) | Attackers obtained valid OAuth tokens and may have active access to M365 services. | → Revoke sessions and invalidate tokens immediately → Force reauthentication → Remove unauthorized devices and inbox rules. → Audit for new MFA/authenticator app registrations → Investigate Graph API activity for data access |
Use AppOmni to investigate and reduce risk
AppOmni helps teams quickly understand exposure and take action:
- Identify token-based access: Detect device code and OAuth activity, and flag anomalous sessions
- Monitor post-authentication behavior: Track API usage, data access, and persistence techniques
- Assess OAuth and app risk: Review integrations, scopes, and unnecessary access
- Prioritize remediation: Focus on the highest-impact risks and reduce exposure efficiently
The playbook is the same. The scale is new.
The EvilToken campaign highlights the evolution of a proven attack approach. The playbook hasn’t changed: attackers use valid access to move through SaaS environments.
What has changed is the scale. Automation, AI-driven scripts, and interconnected SaaS ecosystems are amplifying both impact and reach.
For security teams, this shifts the priority. Securing the login is no longer enough. You need visibility into what happens after (across identities, tokens, and integrations).
Attackers don’t need to break in anymore. They just need the right access.
Want to understand your exposure to token-based attacks? Run a SaaS Risk Assessment with AppOmni to gain clear, actionable insight into your SaaS security posture.
