OAuth 2.0 Device Authorization Grant (RFC 8628) supports devices that cannot use browser-based authentication. One device waits while the other completes authorization via a verification link. Probably the most common example is a smart TV YouTube app that prompts to visit https://www.google.com/device on another device and enter a short code like G3XK-9Q7L.

Attackers exploit the RFC 8628 flow by controlling the device that polls for authorization. They use public APIs to generate device_code and user_code pairs, then trick victims into entering those codes at legitimate sites like microsoft.com/devicelogin. The token endpoint delivers access and refresh tokens to the attacker, not the victim. Since the victim signs in on a real Microsoft page, there are no suspicious URLs or TLS errors. The weakness is in the OAuth process itself.

This research examines several device code phishing setups identified via Netlas, focusing on shared HTML and behavioral patterns. Captured HTTP responses show a template-based design: client-side JavaScript opens an SSE connection to /auth/stream, receives a live device_code and login URL from the backend, and displays the code to the victim. We compare front-end setups across SharePoint, OneDrive, and DocuSign phishing sites to identify common structures and link these to real artifacts and known device code phishing techniques.

1. Threat Landscape and Commoditization

The 2025 DBIR and related credential-stuffing research show that credential abuse is still a major way attackers gain access. 22% of breaches involve compromised credentials, and 19% of SSO authentication attempts are credential-stuffing attempts. Device code phishing does not replace credential theft; it adds another path for attackers to obtain reusable tokens and device-level trust.

Attackers target OAuth tokens and sometimes Primary Refresh Tokens, exploiting identity as the security boundary. In practice, this means credential and token phishing should be addressed together, with detection and controls designed to stop both password misuse and OAuth/PRT abuse.

1.1. Adoption Timeline - Nation State to PhaaS

Microsoft’s Storm-2372 shows that this Russia-aligned group has used device code phishing since at least mid-2024, targeting governments, NGOs, and critical infrastructure. The lures were personalized and sent through email, WhatsApp, Signal, and Teams. Attackers chose these channels to match how each target organization communicates.

Volexity confirms that multiple Russian-aligned groups adopted similar Microsoft device code abuse, with real-time coordination to ensure codes are redeemed within the approximately 15-minute validity window — a behavior indicating deliberate operational scripting of the expiry constraint.

A recent Microsoft report describes a different operational posture altogether: device code generation triggered at click time, automated status polling, and AI-generated lures pushed through delivery pipelines at scale. Attacker sessions in that campaign consistently came from unmanaged cloud-hosted endpoints — Railway.com and DigitalOcean ranges — pointing to infrastructure built for scale rather than targeted manual operations. Push Security’s recent analysis reflects the same trend: device code phishing attempts against M365 tenants increased noticeably year-over-year.

1.2. EvilTokens as Commoditization Event

EvilTokens marks the shift from bespoke device code phishing to a commodity service. Distributed via Telegram, it provides affiliates with self-hosted phishing landing page templates and shared backend infrastructure via a REST API. Affiliates call /api/device/start to initiate a session and poll /api/device/status/<SESSION_ID> for results.

Beyond token acquisition, EvilTokens provides token-to-cookie conversion, BEC-oriented automation, and AI-assisted email generation, enabling financially motivated actors to quickly weaponize compromised M365 mailboxes. With these kits, technical barriers are gone. Any actor with Telegram access and a target M365 tenant can run the full kill chain using prebuilt infrastructure.

2. Attack Mechanics and Kill Chain

The OAuth 2.0 device authorization grant (RFC 8628) issues a device_code and user_code, a verification URI, expiry, and polling interval. The client displays the user_code and URL, then polls the token endpoint until the user authorizes or the code expires. Cloud identity providers follow this pattern, issuing codes via /devicecode and tokens via /token, usually with a 15-minute expiry.

    sequenceDiagram
	    autonumber
	    participant Device as Device/Client
	    participant Auth as Authorization<br>Server
	    participant User as User on<br>Browser-Capable<br>Device
	    participant API as Resource API
	
	    Device->>Auth: POST /devicecode with client_id and scope
	    Auth-->>Device: device_code, user_code, verification_uri, expires_in, interval
	    Device-->>User: Show verification_uri and user_code
	    loop Until user authorizes or code expires
	        Device->>Auth: POST /token with device_code
	        Auth-->>Device: authorization_pending or slow_down
	    end
	    User->>Auth: Visit verification_uri
	    User->>Auth: Enter user_code and authenticate
	    User->>Auth: Approve requested access
	    Device->>Auth: POST /token with device_code
	    Auth-->>Device: access_token and optional refresh_token
	    Device->>API: Use access_token

Device code phishing exploits the separation between the client that requests access and the user who approves it. Attackers call the device authorization endpoint with a valid client_id and target scopes like offline_access, get a device_code and user_code, and trick the victim into entering the code at a real verification URL. After the victim signs in and completes MFA, the attacker’s client polls the token endpoint and receives access and refresh tokens. The phishing page never handles the password or MFA code. If the victim is already signed in, entering the code and confirming is often all that is needed, making this technique effective even against phishing-resistant controls.

The 15-minute expiry forces attackers to generate codes on demand and automate status polling, handled in kits via backend APIs and push mechanisms. Captured access_tokens give immediate API access. refresh_tokens with offline_access allow re-authentication as long as the token is valid. Actors use Authentication Broker client IDs to get refresh tokens for device registration and PRT issuance, escalating from account access to device-level persistence.

2.1. Adversary Kill Chain (MITRE ATT&CK Mapped)

The following techniques represent the observed patterns across documented device code phishing campaigns and commercial kits.

• Reconnaissance - Tenant and account validation [T1589.002]

Pre-attack reconnaissance in documented campaigns includes querying the GetCredentialType endpoint and related Azure AD enumeration paths to confirm whether target email addresses exist in a tenant and to profile their authentication methods before lures are sent. This provides low-noise account discovery without generating sign-in log events.

• Resource Development - Web services and PaaS infrastructure [T1583.006]

Documented campaigns host token-handling backends and phishing landers on PaaS and web service platforms such as Cloudflare Workers and Railway, exploiting trusted cloud IP ranges and temporary subdomains to evade reputation-based blocking.

• Initial Access - Targeted phishing lures [T1566.002]

Entry is via email or messaging app lures impersonating document shares, meeting invitations, or HR and finance workflows, delivered as links that direct victims to attacker-controlled landing pages. Recent campaigns incorporate AI-generated lure content personalized to the victim role and organizational context.

• Credential Access - user_code entry and cross-platform token theft [T1528]

The adversary obtains OAuth tokens when the victim enters the attacker-generated user_code on a legitimate verification endpoint, such as microsoft.com/devicelogin, and authorizes the request. The same RFC 8628 mechanism applies to other providers: GitHub’s /login/device/code and /login/oauth/access_token endpoints are equally vulnerable.

• Defense Evasion - OAuth token replay [T1550.001]

Captured access and refresh tokens are replayed against cloud APIs and services to access resources without re-authenticating, bypassing credential checks entirely.

• Persistence - Abuse of valid cloud account [T1078.004]

Following successful token capture, the threat actor operates within the victim tenant as a legitimate cloud account holder accessing services such as SharePoint and OneDrive as the victim user. Because all activity originates from valid credentials, it blends with normal user behavior and evades controls that rely on credential anomalies.

• Persistence - Device registration and PRT issuance [T1098.005]

Threat actors use Authentication Broker client IDs to obtain refresh tokens suitable for device registration and PRT issuance, adding an attacker-controlled device identity to the victim tenant.

• Collection - Remote mailbox access via cloud API [T1114.002]

Post-compromise collection consistently involves Microsoft Graph API calls to enumerate mailboxes and extract messages filtered for finance, payment, or policy-relevant content.

• Impact - Business email compromise and financial theft [T1657]

Commercial device code phishing kits use compromised mailboxes to identify active payment threads, generate AI-assisted reply-chain messages, and redirect payments.

Book Your Netlas Demo

Chat with our team to explore how the Netlas platform can support your security research and threat analysis.

3. Case Studies - Adversary Infrastructure Hunting via Netlas

The following case studies show how device code phishing infrastructure can be identified from internet-facing HTTP artifacts rather than victim-side telemetry. Each example starts with a Netlas query, then follows the observable frontend behavior, SSE backend relationship, and pivot points that link related hosts into a shared kit cluster.

3.1. Case Study 1 — 195.177.94[.]36 (SharePoint-Themed Phishing)

Figure 1. Netlas query results for SharePoint-themed device code phishing hosts

The below-mentioned initial Netlas query returned 195.177.94[.]36:443/b4638c9dccaab.

http.body:"microsoft.com/devicelogin" AND http.title:"sharepoint"

Figure 2. VirusTotal detection score for 195.177.94[.]36

Figure 3. Live SharePoint-themed device code phishing landing page on 195.177.94[.]36

The page impersonates a Microsoft SharePoint internal site and a fake “Shared Document” PDF card.

Figure 4. Embedded SSE backend connection in the phishing page source

On load, the script opens:

EventSource(auths.mpconstruction[.]cc/auth/stream)

The page contains no device code in the HTML; it waits for the backend to push one. Once received, the SSE code event payload (d.code, d.url) populates the verification box - GGTLEM8FG in the above captured instance, and activates the “Copy code” and “Open Document” buttons.

Figure 5. Legitimate Microsoft device login endpoint opened from the phishing page

The victim is instructed to copy the code and click the “Open Document”, which opens a pop-up to the attacker-supplied microsoft.com/devicelogin.

The backend polls Microsoft’s token endpoint independently. Upon sign-in completion, it fires a success event: the SSE stream closes, and a confirmation is shown. The backend holds the authenticated token; the victim sees nothing unusual. Code, login URL, and completion state all originate from auths.mpconstruction[.]cc.

3.2. Case Study 2: 185.214.10[.]56 (OneDrive / HR Device Code Phishing)

Figure 6. Refined Netlas query for broad device code phishing infrastructure discovery

Revised the query to target the generic “verification code” device code phishing template.

http.body:"microsoft.com/devicelogin" AND http.body:"verification code"

Figure 7. HR-themed OneDrive device code phishing page

• The discovered host impersonates a Microsoft OneDrive document share - “HR Department shared a document with you”, a Q1 Financial Report 2026 PDF card. robots: noindex,nofollow,noarchive suppresses crawler and archive indexing.
• On load, a full-screen overlay blocks the page while the script opens a new EventSource('/auth/stream') - no external backend hostname is exposed in the front-end code. The HTML contains only a {{CODE}} placeholder; the SSE code event pushes a verification code (d.code) and a Microsoft login URL (d.url) from the backend. d.code is injected into all elements matched by SELECTORS.code (#userCode, [data-portal="code"], [class*="code"], [id*="code"]), replacing the placeholder. The screenshot above confirms a live, fully resolved code (CWVMKY39U) in both the verification box and the step-by-step instructions on the page.
• On the code event, all a[href*="devicelogin"] and a[href="#"] anchors are rewritten to call window.openLogin();return false;, routing victims to d.url - a live login.microsoftonline[.]com device auth endpoint. The static data-href fallback embedded into the HTML (AM38HYR75) is fully overridden at runtime by the backend-supplied URL.

Figure 8. DOM analysis showing access granted state for 185.214.10[.]56

• The backend polls Microsoft’s token endpoint independently. Upon sign-in completion, it fires a success event: the SSE stream closes, and a “Document access granted” panel is shown. The backend retains the authenticated token; the victim sees a clean confirmation and no further indication of compromise.

Pivoting on the page title (“HR Department shared a document with you”) using the query below surfaced 2 additional hosts.

http.title:"HR Department shared a document with you"

Figure 9. HTTP title pivot results for related HR-themed phishing pages

Figure 10. VirusTotal detection score for 216.250.255[.]238

Figure 11. VirusTotal detection score for otqjypanl[.]top

Both hosts had 0/94 detection score on VirusTotal at the time of analysis, but had the same characteristics that we observed in our initial case studies, with a few differences in SSE Backend (doc.loadingdocuments[.]com in 216.250.255[.]238) and success behavior (216.250.255[.]238 redirects to office[.]com).

Notably, all the results identified by the above Netlas query shared the same URI path b4638c9dccaab across different IPs and a domain name.

Figure 12. URI pivot results for the b4638c9dccaab path

A URI-based pivot was performed to explore the scope of the cluster:

The query returned 2 additional hosts: 151.242.63[.]36 (VT: 0/94 VT score) and 209.141.37[.]219 (VT: 2/94 Score). Both showed a low VirusTotal detection rate at the time of analysis and presented the same underlying kit architecture as we analyzed above.

Figure 13. DocuSign-themed device code phishing infrastructure

3.3. Observed Cluster Comparison

• 195.177.94[.]36

  • Phishing theme: SharePoint.
  • C2 / SSE backend: auths.mpconstruction[.]cc (external).
  • Placeholder: none observed.
  • Fallback: yes.
  • Success behavior: shows #successBox.

• 185.214.10[.]56

  • Phishing theme: OneDrive HR.
  • C2 / SSE backend: same-origin /auth/stream.
  • Placeholder: {{CODE}}.
  • Fallback: no (final).
  • Success behavior: shows #successBox.

• 216.250.255[.]238

  • Phishing theme: OneDrive HR.
  • C2 / SSE backend: doc.loadingdocuments[.]com (external).
  • Placeholder: none observed.
  • Fallback: yes.
  • Success behavior: redirects to office[.]com.

• otqjypanl[.]top

  • Phishing theme: OneDrive HR.
  • C2 / SSE backend: same-origin /auth/stream.
  • Placeholder: {{CODE}}.
  • Fallback: no (final).
  • Success behavior: shows #successBox.

• 209.141.37[.]219

  • Phishing theme: OneDrive HR.
  • C2 / SSE backend: auths.amiripat[.]store (external).
  • Placeholder: none observed.
  • Fallback: yes.
  • Success behavior: redirects to office[.]com.

• 151.242.63[.]36

  • Phishing theme: DocuSign.
  • C2 / SSE backend: same-origin /auth/stream.
  • Placeholder: {{CODE}}.
  • Fallback: no (final).
  • Success behavior: shows UI without redirect.

3.4. Proactive Infrastructure Hunting via Netlas

Reactive detection, waiting for deviceCode sign-ins in Entra logs, means a user has already interacted with the flow. Proactive infrastructure hunting moves detection earlier. By querying internet-wide scan data before campaigns reach users, defenders can identify active device code phishing infrastructure, extract indicators, and feed them into blocklists and detection rules.

Netlas supports this approach by indexing HTTP response bodies across the internet. This enables searches based on frontend patterns like embedded DOM elements or API paths exposed by device code phishing kits. These patterns persist across domain changes and rebranding.

Across the analyzed infrastructures, recurring patterns include:

• Server-exposed endpoints such as /auth/stream (SSE-based delivery).
• Backend API paths like /api/device/*, /generate, /flow-status or URI path patterns.
• Client-side constructs such as EventSource, verification code placeholders, and device code login instructions.
• Custom request headers (e.g., X-Antibot-Token, X-Tenant-Secret) observed in some variants.

Hunting based on these patterns enables clustering of related infrastructure and reduces reliance on short-lived domains or IP indicators.

3.5. Netlas Hunt Queries to Explore

The following queries can serve as a starting point for hunting for device code phishing infrastructure.

Query 1: Combines the SSE endpoint (used for real-time device code injection) with the Microsoft device login fallback URL.

http.body:"/auth/stream" AND http.body:"microsoft.com/devicelogin"

Query 2: Identifies the DocuSign device code phishing variants.

http.title:"DocuSign - Verify to Sign" AND http.body:"/auth/stream"

Query 3: Identifies device code phishing infrastructure impersonating the Microsoft security verification portal.

http.title:"Microsoft Security Verification" AND http.body:"microsoft.com/devicelogin"

4. Detection and Response Strategies

Since authentication occurs on legitimate Microsoft infrastructure, identity logs are the primary detection surface.

Monitor in Entra ID SignInLogs:

• authenticationProtocol equals deviceCode.
• Rare or previously unseen ClientAppId / AppDisplayName for the tenant.

Correlate with NonInteractiveUserSignInLogs:

• OriginalTransferMethod equals deviceCodeFlow.
• Match on AppId, UserPrincipalName, and time proximity to the initial deviceCode sign-in.

High-value Detection Scenarios:

• Device code sign-in for privileged users using a rare or new ClientAppId.
• Spike in deviceCode events across the tenant, especially with new ClientAppId values or anomalous IP/ASN.
• Device registration within a short time window after a deviceCode sign-in for the same principal.
• Sign-in anomalies:
  • New geolocation or ASN.
  • Cloud-hosted or anonymized infrastructure.
  • Deviation from user baseline (device, browser, location).

4.1. Network Detection

Microsoft device authentication endpoints use HTTPS. Without TLS inspection, visibility is limited. Detection relies on TLS inspection, referrer analysis, or endpoint telemetry.

Where TLS inspection or endpoint telemetry is available, monitor for non-Microsoft hosts:

Without TLS inspection:

• Use threat intelligence to identify and block malicious infrastructure.
• Monitor outbound connections to low-reputation or newly observed domains.

Email gateway and proxy log monitoring:

login.microsoftonline.com/common/oauth2/deviceauth
microsoft.com/devicelogin
aka.ms/devicelogin

Focus on anomalous access patterns, not the URLs themselves.

4.2. Incident Response

Treat confirmed device code compromise as token theft + MFA bypass.

Contain:

• Revoke all active sessions (revokeSignInSessions) and force device sign-out to invalidate PRTs.
• Disable device code flow for affected principals via Conditional Access immediately.

Clean:

• Revoke OAuth app consents for affected accounts, prioritizing broker-style and deviceCode client IDs.
• Remove device registrations within the suspicious sign-in window; audit for PRT-receiving devices.

Triage:

• Review inbox rules, sent items, and Graph API audit logs for forwarding rules, finance-targeted searches (payroll, invoice, wire transfer), and bulk deletion events.

Forensics:

• Preserve the Entra sign-in logs, OAuth records, device registration events, and mailbox audit trails.
• Extract and operationalize indicators, such as ClientAppId values and backend domains, and API paths (/auth/stream, /api/device/start, /generate, /flow-status), into blocklists and SIEM detections.

Post-incident:

• Restrict or disable device code flows where not required.
• Enforce conditional access controls: Token protection, Continuous Access Evaluation (CAE), compliant/managed device requirement for sensitive access.
• Deploy persistent detection for device code sign-ins and subsequent token activity.

5. Conclusion

Device code phishing has shifted from a nation-state operation to off-the-shelf PhaaS. Since 2024, the technique has worked against hardened M365 tenants. By 2026, platforms like EvilTokens delivered the same capability through affiliate landing pages, shared OAuth backends, and automated post-auth flows. The hosts analyzed here (195.177.94[.]36 and 185.214.10[.]56) show the pattern: thin frontends display a code and redirect to real Microsoft authentication, while the attacker backend handles device code generation and token collection.

The core issue is in the protocol design. RFC 8628 separates the client requesting access from the user approving it. No misconfiguration is needed, and standard MFA, URL filtering, and TLS inspection do not block it. One successful flow gives the attacker access and refresh tokens. Using the Authentication Broker client ID turns this into a Primary Refresh Token and device-level persistence, with no further user action.

This is not limited to Microsoft. Any platform using the device grant is exposed. GitHub is already confirmed. Three trends will keep this surface active:

• AI automation cuts the cost of crafting personalized lures and orchestrating code delivery within the 15-minute expiry window.
• Cross-platform exposure is real. The same RFC 8628 abuse also works against GitHub, and any OAuth provider that implements the device grant is vulnerable.
• Kit development now mirrors AiTM PhaaS. Anti-bot controls and better secret hygiene make domain or IP blocklists less effective. Hunting on stable API paths and identity telemetry outlasts IoC-based detection.

Blocking device code flow via Conditional Access is the only way to eliminate this vector where there is no legitimate use case. Where blocking is not possible, the minimum set is Token Protection, Continuous Access Evaluation, compliant device enforcement, and identity-based detection on deviceCode sign-ins, unusual ClientAppId values, and device registrations after device code authentication.

I can show you how deep the Internet really goes

Discover exposed assets, infrastructure links, and threat surfaces across the global Internet.