How Attackers Take Over Microsoft 365 Accounts (and How to Stop It)

Phishing isn’t just “click a fake login page” anymore. Threat actors are increasingly abusing a legitimate Microsoft sign-in workflow—the OAuth device code flow—to trick users into granting access to their Microsoft 365 accounts. This method is showing up across both state-aligned espionage campaigns and high-volume criminal credential theft, which means it’s not niche; it’s becoming a repeatable playbook.

The result is simple and dangerous: the attacker doesn’t need your password if they can convince you to approve the wrong sign-in and hand them valid tokens.

What Is Device Code Phishing?

The device code flow exists for situations where a device can’t easily complete a normal browser login (think TVs, conference room devices, command-line sign-ins, or input-constrained hardware). Instead, the user is asked to go to a trusted Microsoft sign-in page and enter a short code to complete authentication.

Device code phishing flips that legitimate workflow into a social engineering trap: the attacker generates a real device code request and convinces the user to enter it—granting the attacker access through valid authentication tokens.

How the Attack Works (Step-by-Step)

A lure arrives via email, chat, or a QR code—often disguised as a document share, voicemail notification, HR file, or meeting invite.

The user clicks and lands on an attacker-controlled page that looks believable (often branded to the target organization).

The page instructs the user to “securely authenticate” by entering a provided code on a legitimate Microsoft device login page.

The user enters the code on Microsoft’s real site, believing it’s part of an expected sign-in.

Microsoft issues valid tokens—but the attacker receives/uses them, enabling M365 account access without the user ever typing a password into a fake site.

Why This Works So Well

The login page is legitimate. Traditional user training (“check the URL”) fails when users are told to authenticate on a real Microsoft domain.

It’s token-based access. Once tokens are issued, attackers can access services the user can access (email, SharePoint/OneDrive, Teams, and more).

It scales. Criminal actors can productize this workflow into kits, while state actors use it in targeted, high-trust social engineering.

Who’s Using Device Code Phishing

Recent reporting and research show a mix of state-linked and financially motivated actors adopting the same approach. Some campaigns use purpose-built tooling and phishing kits designed to operationalize device code attacks at scale, while others rely on patient rapport-building before sending a “meeting” or “document” lure.

The common thread: once M365 access is obtained, attackers can pivot into inbox harvesting, internal phishing, data collection, and follow-on compromise.

What Happens After Compromise

Once an attacker has access to an M365 account, common next steps include:

Mailbox and file discovery (finding sensitive conversations, invoices, wire instructions, credentials, or password resets)

Internal phishing from a trusted account (moving laterally through the organization)

Data exfiltration from mail, SharePoint, and OneDrive

Persistence through token refresh, app consent abuse, or adding attacker-controlled devices (depending on tenant controls)

This is why device code phishing is not “just phishing.” It’s often an identity compromise that becomes a business compromise.

Defensive Controls That Actually Reduce Risk

1) Block device code flow where you can

If your organization doesn’t need device code authentication, blocking it removes the attacker’s favorite path.

2) If you must allow it, restrict it aggressively

Use Conditional Access to limit device code flow by:

approved users/groups

trusted locations / named locations

compliant devices

tighter session controls

3) Require strong identity posture

Enforce modern authentication

Reduce reliance on weaker MFA methods where possible

Apply sign-in risk policies and monitor risky sign-ins

4) Govern OAuth app access and consent

Device code phishing often ends with users approving access for an application. That makes OAuth governance critical:

restrict who can consent to apps

review app registrations and permissions

monitor unusual consent prompts and new/rare applications

5) Update user training for this exact technique

Most awareness programs still teach URL inspection as the primary defense. Device code phishing bypasses that. Training must explicitly warn users:

never enter a device code received from email/chat/QR

verify the app being authorized and why it’s needed

treat unexpected “secure authentication” prompts as hostile

Detection Signals to Watch in Microsoft 365

You can’t defend what you don’t see. Minimum visibility for device-code-style attacks includes:

sign-in activity anomalies (new geographies, impossible travel, unusual clients)

spikes in authentication prompts for a user or department

unexpected OAuth grants/app authorizations

suspicious mailbox behavior (new forwarding rules, mass read activity, unusual Graph access patterns)

How InfoSight Helps: M365 Security Assessment

InfoSight’s Microsoft 365 Security Assessment is designed to answer one question: is your tenant configured to resist modern identity attacks like device code phishing?

Typical outcomes include:

verification of Conditional Access coverage and gaps

review of device code flow exposure and authentication flows

MFA and sign-in risk policy validation

OAuth/app consent governance review

logging/visibility readiness for incident response

a prioritized remediation plan mapped to practical risk reduction

Find out if your Microsoft 365 environment is vulnerable to real-world attacks—review our M365 Security Assessment and book a 15-minute call.

FAQ's

Can MFA stop device code phishing?
Not reliably. This technique abuses a legitimate authentication flow and can result in valid tokens even when MFA is enabled, depending on how the approval happens and what controls are in place.

Is this a Microsoft vulnerability?
No. It’s an abuse of a legitimate OAuth workflow. The weakness is the social engineering and policy/configuration exposure—not a software bug.

What’s the fastest mitigation?
Block device code flow where possible. If you can’t, heavily restrict it and tighten app consent/OAuth governance.