Device Code Phishing + Vishing: How Attackers Compromise Microsoft Entra Accounts Using Legit Login Pages

Attackers are leaning into a nasty (and effective) social-engineering pattern: push the user onto a legitimate Microsoft page and still walk away with valid tokens.

This is commonly referred to as device code phishing, and recent campaigns combine it with vishing (voice phishing) to increase speed and compliance.

TL;DR

Attackers abuse the OAuth 2.0 Device Authorization flow (“device code flow”) to trick employees into approving a real sign-in at microsoft.com/devicelogin. The user may complete MFA successfully—because the login is real—yet the attacker receives valid tokens (often refresh tokens) for the session they initiated. Defend by restricting device code flow where possible, hardening Conditional Access, moving to phishing-resistant MFA, tightening OAuth app/consent governance, and monitoring for device code sign-ins and anomalous token usage.

1) What is “device code phishing” (and why it’s different)

Device code phishing doesn’t look like classic credential phishing:

  • There may be no attacker-hosted login page.
  • The user may type a code into a real Microsoft domain.
  • MFA may be completed “successfully.”
  • Yet the attacker ends up authenticated via tokens.

The trick is simple: the attacker initiates a device code login for their client/device, then convinces the user to complete the authorization. In practice, the user is logging the attacker’s “device” into the organization.

Recent reporting describes threat actors targeting Microsoft Entra accounts using device code flow combined with vishing, often leveraging legitimate Microsoft OAuth client identifiers in the process.

2) How the OAuth 2.0 Device Authorization flow works (plain-English)

The OAuth Device Authorization Grant (RFC 8628) exists for devices that can’t easily do interactive browser sign-ins (smart TVs, conference room systems, printers, etc.). Microsoft supports it for the Microsoft identity platform.

A simplified walkthrough:

  1. Client requests a pairing code from the identity provider, providing a client_id and scopes.
  2. The identity provider returns:
    • a user_code (short, for humans)
    • a device_code (long, for the client)
    • a verification URL (commonly pointing the user to a Microsoft page like microsoft.com/devicelogin)
    • an expiration time
  3. User opens the verification URL and enters the user_code, then signs in and completes MFA if required.
  4. Client polls the token endpoint using the device_code until the user completes authentication.
  5. Once approved, the identity provider issues tokens (access token and often a refresh token).

Why MFA can “work” and you still lose

From Entra’s perspective, the user authenticated and approved a login session for a device/app. If the attacker started the device flow and the user completes it, the attacker’s client receives tokens because the user authorized that session.

It’s not a “bypass” in the classic technical sense—it’s a human-in-the-loop authorization attack.

3) Why attackers love device code + vishing

This technique removes a lot of friction that defenders are used to:

  • No phishing infrastructure: fewer attacker domains/pages to take down.
  • Legitimate UX: users see real Microsoft sign-in flows, so “check the URL” training can fail.
  • Token payoff: refresh tokens can outlive the moment of compromise.
  • Phone pressure: a live caller can create urgency, answer doubts, and keep the victim moving.

4) Common attack chain (device code + vishing)

A typical chain looks like:

  1. Target selection: roles with high-value access (IT/helpdesk, finance, execs, admins).
  2. Attacker initiates device code flow using an OAuth client ID.
  3. Vishing call: the attacker uses a pretext (“security verification,” “account recovery,” “suspicious sign-in”) to get the user onto microsoft.com/devicelogin and to enter a code.
  4. User signs in + MFA: the user completes prompts, often under time pressure.
  5. Attacker receives tokens and uses them to access Microsoft 365 and potentially downstream SSO apps.
  6. Post-compromise actions: mailbox access, SharePoint/OneDrive exfiltration, Graph-based enumeration, and—if privileges allow—persistence mechanisms.

5) Who’s being targeted (and why)

This works best against organizations where:

  • employees are trained to “follow IT instructions” quickly,
  • there’s heavy reliance on Entra SSO as a “master key,”
  • roles exist where one account yields broad data access.

6) What to monitor: logs, signals, and “tells”

You want coverage for:

  1. the device code sign-in event, and
  2. post-auth activity enabled by token possession.

A) Entra sign-in logs (device code events)

Watch for:

  • device code sign-ins for users who never use device code flow,
  • device code sign-ins outside normal hours,
  • device code sign-ins followed by rapid Exchange/SharePoint/Graph activity,
  • unusual IP/geography patterns (especially for the token usage that follows).

B) App/client signals

Even when campaigns use legitimate Microsoft client IDs, you can still look for:

  • new/unusual client_id values showing up in your tenant,
  • application names that don’t match the user’s job function,
  • spikes of the same client across many users in a short time.

C) Conditional Access / risk signals

If you use Entra ID Protection/risk-based controls, correlate:

  • unfamiliar sign-in properties,
  • atypical travel/impossible travel,
  • sessions that pass MFA once then show continued access without additional prompts.

D) Downstream service activity

Watch for:

  • high-volume downloads,
  • unusual mailbox access patterns,
  • suspicious inbox rules/forwarding rules,
  • unexpected Graph API usage.

7) Detections you can implement (high-signal logic)

You don’t need perfect parsing on day one. Start with high-confidence correlations:

  • Device code sign-in + new country/IP within 15–60 minutes
  • Device code sign-in + burst of Graph/Exchange/SharePoint activity
  • Device code sign-in by privileged roles
  • Same OAuth client used across multiple users in a short window
  • Device code sign-in + user report of “Microsoft/IT support” calling them

If you have Microsoft Sentinel (or another SIEM), turn these into analytic rules and hunting queries.

8) Mitigations that actually reduce risk

1) Restrict or disable device code flow where you don’t need it

If your org doesn’t have a strong business requirement, block device code flow. It’s one of the cleanest mitigations because it removes the attacker’s main mechanism.

2) Conditional Access hardening for device-code scenarios

If you must allow it, scope it tightly:

  • allow only for specific users/groups,
  • restrict to trusted locations/devices where feasible,
  • require phishing-resistant MFA for sensitive access,
  • block high-risk geographies/IP ranges (where business permits).

3) MFA hardening (reduce human-approval risk)

Move away from approval-only patterns:

  • prioritize phishing-resistant MFA (FIDO2/passkeys/cert-based) for admins and sensitive roles,
  • enable number matching / extra context where supported,
  • reduce push fatigue patterns.

4) OAuth governance + consent controls

Even if attackers use legit clients, OAuth governance matters:

  • restrict user consent and require admin approval for risky scopes,
  • monitor new grants and high-privilege delegated permissions,
  • audit enterprise apps regularly.

5) Update training: “legit URL” is not proof of legitimacy

Training should explicitly say:

  • “A real Microsoft URL doesn’t mean the request is legitimate.”
  • “Never enter a device login code because someone asked on a call.”
  • “If IT calls you, hang up and call back via a known internal number.”

9) Incident response: what to do if you suspect device code compromise

1) Contain

  • revoke sessions / refresh tokens,
  • reset password (even if they may not have it),
  • re-register MFA if compromise is suspected,
  • remove suspicious authentication methods.

2) Scope

Review:

  • Entra sign-in logs around the event (user, app/client, IPs),
  • mailbox access and forwarding/inbox rules,
  • SharePoint/OneDrive downloads,
  • SSO app access,
  • any privilege escalation attempts.

3) Eradicate persistence + harden

  • check for new OAuth grants/service principals with risky permissions,
  • confirm Conditional Access policies weren’t tampered,
  • roll out device code restrictions and stronger MFA for high-risk roles.

What to do today (checklist)

  • Decide if device code flow is needed; if not, block tenant-wide.
  • If needed, scope to specific groups + Conditional Access constraints.
  • Alert on device code auth events, especially for privileged users.
  • Correlate device code events with post-auth M365/Graph activity.
  • Tighten OAuth consent policies and monitor grants.
  • Prioritize phishing-resistant MFA for admins/sensitive roles.
  • Update awareness training + helpdesk “call-back” procedure.
  • Document an IR runbook for device code/vishing.

Sources