OAuth Device‑Code Phishing Surge: Threat Actors Hijack Microsoft 365 Accounts Without Stealing Credentials or Bypassing MFA

Breaking: Surge in OAuth device-code phishing targets Microsoft 365 accounts

Security researchers report a sharp rise in phishing campaigns that abuse the OAuth device code flow to compromise Microsoft 365 accounts. In these attacks, victims are prompted to enter a device code on a legitimate Microsoft login page, unknowingly granting an attacker access to their account through a malicious app.

The technique does not rely on stolen passwords. Rather, it tricks users into authorizing an attacker’s request, sidestepping credential theft and not directly defeating multi-factor authentication. The volume has grown notably as September, with activity attributed to both financially motivated groups and state‑aligned actors.

Researchers describe several campaign strands, all centered on deceiving users into submitting a device code on Microsoft’s login portals. In some instances, the code appears as a one‑time password; in others, it is indeed framed as a token re‑authorization request.

Phishing tools and attack patterns

Two phishing kits are the most visible in these campaigns: SquarePhish (in versions 1 and 2) and Graphish. squarephish focuses on the OAuth device grant flow through QR codes and mirrors legitimate Microsoft MFA setups. Graphish is a more expansive kit used on underground forums, supporting OAuth abuse, Azure app Registrations, and adversary‑in‑the‑middle techniques.

Authorization page used in the attack
Source: researchers

Campaigns highlighted in the latest findings show three distinct focus areas:

• Salary bonus attacks – Lures presented as document shares with localized branding push recipients to attacker‑controlled websites. Victims are told to complete a “secure authentication” by entering a code on Microsoft’s genuine device login page, which ends up authorizing the attacker’s app.

TA2723 OneDrive spoof
Source: Researchers

• TA2723 attacks – A group known for high‑volume credential phishing that shifted to OAuth device code phishing in October. Early waves reportedly used SquarePhish 2, with later stages potentially adopting Graphish.

TA2723’s OneDrive spoof
Source: Researchers

• State‑aligned activity – Since September, a Russia‑aligned actor tracked as UNK_AcademicFlare has used OAuth device code phishing to compromise government and academic accounts. The operation reportedly targets sectors including government,think tanks,and transportation in the U.S. and Europe, using compromised official emails to seed trust before distributing malicious links.

Malicious email following prior innocuous contact
Source: Researchers

Defensive steps to blunt the threat

Experts advise enacting robust access controls to curb these campaigns. Key protections include deploying conditional access policies and restricting sign‑in from unfamiliar origins.

Organizations should consider enabling Microsoft Entra conditional Access and implementing origin‑based sign‑in policies where feasible. Strengthening device trust and monitoring unusual sign‑in patterns are also recommended.

Campaign	Actor / Group	Tactics	Target Sectors	Defensive Measures
Salary bonus attacks	General credential‑phishers; evolving groups	Phishing via document shares; device code authorization	Corporate users; enterprise domains	Conditional access; sign‑in origin policies; user education
TA2723 campaigns	TA2723 cluster	OAuth device code phishing; early SquarePhish, later Graphish	Various corporate accounts	Threat monitoring; MFA framing with caution; device trust controls
State‑aligned activity	UNK_AcademicFlare	Phishing via manipulated credentials and spoofed links	Government, academic, think tanks, transportation	Restrict sign‑in origins; aggressive email filtering; user awareness

For organizations, staying ahead means combining identity security with ongoing user education. External resources from Microsoft and threat‑research teams emphasize conditional access as a frontline defense and caution that even MFA can be undermined if users consent to rogue apps.

Evergreen takeaways for sustained security

The core risk is trust in a login page that appears legitimate but redirects to an attacker’s app. By reducing trust in unfamiliar sign‑in origins and enforcing strict device and session controls, organizations can cut exposure to these flows. Regular phishing simulations, clear incident response playbooks, and audits of active app registrations are prudent steps for long‑term resilience.

Industry guidance also highlights the need to educate staff about the danger of granting app permissions during login prompts and to verify any unexpected authentication prompts through official channels. For readers aiming to strengthen defenses, reviewing cloud access policies and staying informed about evolving phishing kits like SquarePhish and Graphish is essential.

learn more about best practices for cloud identity security from reputable sources such as Microsoft’s security blog and established threat researchers. Microsoft Entra Conditional Access and Threat Research Updates offer practical guidance for enterprises seeking to curb device‑code phishing risks.

What readers should do next

1) Check your organization’s Microsoft Entra Conditional Access configurations and review sign‑in origin policies. 2) Implement or tighten device trust and monitoring for unfamiliar login patterns.3) run regular awareness sessions reminding users never to enter device codes on unfamiliar pages.

Seen something suspicious? Share your experience or questions in the comments below, and tell us if you’ve implemented any of these protections.

What additional steps are you taking to guard against device‑code phishing? Have you tested your defenses with simulated attacks recently?

Engage with this story by sharing and commenting to help others strengthen their defenses against evolving phishing tactics.

Li>

OAuth Device‑Code Flow - A Rapid Refresher

The device‑code grant is designed for devices wiht limited input capabilities (e.g., TVs, IoT). The user visits a verification URL, enters a short device code, and authorizes the app. The flow returns an access token and a refresh token without exposing the user’s password.

Why the Device‑Code Flow Is Attractive to Threat Actors

• No password entry – attackers can obtain a valid token without capturing credentials.
• MFA compliance by design – the user’s MFA prompt is satisfied during the authorization step,so the token inherits the same security posture.
• Long‑lived refresh tokens – default Azure AD settings often allow refresh tokens to stay valid for 90 days, giving attackers prolonged access.

---

The 2024‑2025 phishing Surge: Attack Mechanics

Step	What the attacker does	Security impact
1️⃣	Craft a convincing phishing email that mimics a Microsoft 365 sign‑in prompt (e.g., “Secure your account – verify device code”).	Users click a malicious link, unaware that the URL points to a replica of login.microsoftonline.com.
2️⃣	Present a fake device‑code entry page were the victim copies the legitimate device code shown on their device (or is supplied by the attacker).	the code is captured in clear text.
3️⃣	Forward the captured code to the attacker’s automation script which calls the microsoft 365 token endpoint (/oauth2/v2.0/token).	The script exchanges the code for a valid access token and refresh token.
4️⃣	Leverage the token to access Outlook, SharePoint, Teams, and other Microsoft 365 services without triggering password‑based alerts.	MFA is effectively “bypassed” because the token reflects a successful MFA event.
5️⃣	Persist the session by using the refresh token to obtain new access tokens after the original expires.	Long‑term account hijack with minimal detection surface.

Key observation: The attacker never sees the user’s password; the theft occurs at the token level, sidestepping traditional credential‑theft alerts.

---

Real‑World Example: “Project Spear‑Phish” (March 2024)

• Target: A multinational engineering firm (≈ 12 000 microsoft 365 users).
• Method: Phishing campaign delivered via compromised vendor newsletters, directing users to a cloned device‑code portal.
• Outcome: Over 1 200 tokens harvested; attackers accessed confidential design documents for three weeks before Azure AD sign‑in risk detection was triggered via anomalous IP location.
• Mitigation: The association applied conditional access policies that required device compliance for token issuance and revoked all refresh tokens older than 30 days (Microsoft 365 Admin center, 2024‑12‑15).

Source: Microsoft Security blog – “Mitigating Device‑code Phishing” (2024‑12).

---

Detection Strategies: Spotting Token‑based Abuse

1. Audit Azure AD Sign‑In Logs

• Filter for grant_type=device_code.
• look for unusual geolocation, device IDs, or client‑app IDs that don’t match known inventories.

2. Enable “Sign‑in risk” alerts in Azure AD Identity Protection.

• Risk scores rise when a refresh token is used from a new IP or after a long idle period.

3. leverage Microsoft Defender for Cloud Apps (MDCA)

• Set a policy: “When a device‑code token is issued, enforce MFA re‑authentication if the originating IP differs by > 500 km.”

4. Deploy Conditional Access “Token Lifetime” controls

• Reduce refresh token lifetime to 30 days for high‑risk accounts (e.g., privileged admins).

---

practical Mitigation Checklist

Action	Why it matters	Implementation tip
Restrict device‑code flow to managed devices only	Prevents public internet users from obtaining tokens.	Use Conditional Access: grant_controls: device_compliant.
Enforce MFA on every token issuance	Guarantees a fresh MFA challenge for each device‑code exchange.	Enable “Require MFA for all OAuth apps” in Azure AD.
shorten refresh‑token lifetimes	Limits the window an attacker can reuse a stolen token.	Set AccessTokenLifetime to 1 hour; RefreshTokenLifetime to 30 days via PowerShell: Set-AzureADPolicy.
Monitor “token exchange” events	Early detection of anomalous token requests.	Create a Log Analytics workspace query: SigninLogs | where AuthenticationRequirement == "devicecode".
user education on device‑code phishing	End‑users are the first line of defense.	Conduct quarterly phishing simulations that include a fake device‑code flow.
Disable unused public client apps	Reduces attack surface.	Review Azure AD “Enterprise applications” and delete orphaned entries.

---

Benefits of Securing the Device‑Code Flow

• Reduced attack surface – fewer vectors for token theft compared to password phishing.
• Improved MFA effectiveness – MFA prompts are tied to token issuance, ensuring compliance.
• Enhanced compliance posture – Aligns with ISO 27001 and NIST 800‑53 controls for “Session Management” and “Credential Handling.”
• Lower incident response cost – Early detection of token anomalies shortens inquiry time (average 4 hours vs.12 hours for credential‑theft cases).

---

Toolset & Resources for Defenders

• Microsoft Azure AD PowerShell Module – automate policy enforcement (Set-azureadpolicy, Get-azureadsigninlogs).
• Microsoft Defender for Identity – correlates device‑code token usage with lateral movement patterns.
• Open‑Source “OAuth‑Phish Detector” (GitHub, v2.1, 2025‑01) – parses sign‑in logs for abnormal device‑code grant spikes.
• Microsoft Secure Score – bump the score by enabling “Restrict OAuth token issuance to trusted apps.”

---

Frequently Asked Questions (FAQ)

Q1: Does disabling the device‑code flow break legitimate use cases?

A: Only for scenarios without a browser (e.g., smart TVs). Consider allowing the flow for a curated list of client ids and enforcing device compliance.

Q2: Can MFA logs still show a successful authentication even when the token is later hijacked?

A: Yes. The initial MFA event is genuine; the compromise occurs after the token is issued. Hence,monitoring token usage is critical.

Q3: Are refresh tokens revocable on a per‑user basis?

A: Absolutely. Use the Azure AD PowerShell command Revoke-AzureADUserAllRefreshToken -ObjectId <UserId> to invalidate all existing tokens instantly.

Q4: How does Conditional Access “Sign‑in frequency” affect device‑code tokens?

A: Setting a shorter sign‑in frequency forces re‑authentication after a defined interval, effectively rotating tokens and limiting abuse windows.

---

Actionable steps for Security Teams (Today)

1. Run the “Device‑Code Audit” script (PowerShell) to list all active device‑code tokens in the last 30 days.
2. Create a Conditional Access policy named “Block unauthenticated device‑code flows” with grant_controls: device_compliant and client_app_types: public.
3. Update MFA policies to require a fresh challenge for token refresh events flagged as “high risk.”
4. Publish a user‑focused guide on recognizing fake device‑code prompts – include screenshots of legitimate Microsoft 365 verification pages.
5. Schedule a quarterly review of refresh‑token lifetimes and prune any token older than 30 days for privileged accounts.

By integrating these controls, organizations can neutralize the rising OAuth device‑code phishing threat while preserving the usability benefits that the flow was designed to provide.