OAuth device-code phishing → M365 access without a fake page

§ Context

Assumed environment: target tenant allows the device-code flow (default for many client apps). Victim is willing to enter a short code on a legitimate Microsoft URL.

§ Steps

1. 01
   Send code + URL to victimInitial Access

   T1566— Phishing
2. 02
   Victim enters code on microsoft.com/deviceloginExecution

   T1204— User Execution
3. 03
   Refresh-token rotation for long-term accessCredential Access

   M365-TOKEN-EXFIL— AAD Token Cache Exfil
4. 04
   Receive access + refresh tokensCredential Access

   M365-TOKEN-EXFIL— AAD Token Cache Exfil
5. 05
   Query Graph for mail / drive / usersCollection

   M365-EWS-EXFIL— Exchange Web Services (EWS) Exfil
6. 06
   POST to /devicecode endpointInitial Access

   PH-OAUTH-DEVCODE— OAuth Device-Code Phishing

§ References

• T1566Phishing
• T1204User Execution

§ Frequently asked

What is the "OAuth device-code phishing → M365 access without a fake page" attack path?

Initiate a device-code flow against login.microsoftonline.com; send the code + url to the victim via email or chat. Once they enter it, attacker gets access + refresh tokens. It chains 6 steps drawn from real-world offensive-security techniques.

What starting position does this attack require?

The first step is Send code + URL to victim (T1566) — a initial access primitive. Assumed environment: target tenant allows the device-code flow (default for many client apps).

What is the final impact of this kill-chain?

The final step lands on POST to /devicecode endpoint (PH-OAUTH-DEVCODE), which falls under Initial Access. From here, an operator typically pivots into post-exploitation or maintains persistence.

How can defenders detect or prevent this attack?

Detection and prevention vary per step. Refer to each linked MITRE ATT&CK entry under "References" — every technique on that page lists defensive controls, detection telemetry, and known threat-actor usage.

§ Related dossiers

• Shared techniques3

  Compromised vendor mailbox → reply-chain phishing → client compromise

  Take over a vendor / partner mailbox via AITM phishing. Reply to an existing thread with a malicious link — trust transferred from the genuine prior conversation defeats most user training.

• Shared techniques2

  Malicious MCP server → silent supply chain for agent tools

  User installs an MCP server marketed as a useful integration. Every subsequent agent session has the rogue server in scope — its tools log prompts, exfil files, or inject responses to bias the agent.

• Shared techniques2

  FIDO2 caBLE hybrid → phone authenticator hijack

  Attacker phishing site shows the legitimate FIDO2 QR. Victim scans with their phone authenticator. The link completes the WebAuthn ceremony in the attacker's browser — they're now signed in as the victim.

• Shared techniques2

  OneNote .one attachment → embedded payload → C2

  OneNote .one file with a friendly 'Double-click to view' overlay hides an embedded HTA / VBS / EXE. Effective initial access vector after Microsoft blocked internet macros in 2022.

• Shared techniques2

  Header smuggling → gateway sees vendor, mailbox sees attacker

  Crafted RFC-edge headers cause SPF/DMARC to validate against one From while Outlook renders the other — slips past Microsoft Defender / Proofpoint and lands as a 'verified' message.

• Shared techniques2

  Malicious browser extension → cookie harvest → ATO

  Publish a useful-looking extension (ad-blocker / PDF reader). It quietly reads cookies + localStorage from sensitive sites and ships them to the attacker.