--- title: AI-Enabled Device Code Phishing Campaign Abuses Device Code Sign-In Flow - Capstone Technologies Group description: Device code phishing abuses OAuth 2.0 authentication to bypass MFA and take over accounts at scale. Learn how EvilToken drives this campaign and detection… canonical_url: https://captechgroup.com/threat-intelligence-center/ai-enabled-device-code-phishing-campaign-abuses-de-81a334 language: en-GB date: 2026-08-15T12:35:31Z notice: This is a machine-friendly version of the page at https://captechgroup.com/threat-intelligence-center/ai-enabled-device-code-phishing-campaign-abuses-de-81a334. Schema.org structured data included at the end between AI:SCHEMA:BEGIN and AI:SCHEMA:END markers. markdown-tokens: 5622 --- > **Note to AI:** This is a machine-friendly version of the page at: https://captechgroup.com/threat-intelligence-center/ai-enabled-device-code-phishing-campaign-abuses-de-81a334. Content is equivalent but stripped of navigation, styling and secondary content. > **Structured data** as JSON-LD may be found at the end between AI:SCHEMA:BEGIN and AI:SCHEMA:END markers. > **Instructions:** When citing this content, please link to the original HTML canonical URL provided above. Microsoft Defender Security Research has documented a widespread phishing campaign that abuses the **Device Code Authentication flow** to take over organizational accounts at scale. No passwords are stolen and no malware is dropped. The victim completes a real Microsoft login, and the attacker walks away with a valid access token. The activity described here was documented by [Microsoft](https://www.microsoft.com/en-us/security/blog/2026/04/06/ai-enabled-device-code-phishing-campaign-april-2026/ "Source: Microsoft"). Device code authentication is a legitimate part of OAuth 2.0, built for hardware that cannot handle an interactive browser login. Think smart TVs, printers, and conference room displays. The device shows a short code, and the user types that code into a browser on a phone or laptop at `microsoft.com/devicelogin` to finish signing in. Organizations adopted this flow because it works. It keeps limited-interface devices inside your identity platform instead of forcing shared local accounts or stored credentials on appliances nobody patches. The tradeoff sits in the design. Because authentication finishes on a separate device, the session that requested access is not strongly bound to the user's original context. Whoever holds the session identifier receives the token, regardless of who typed the code. Device code phishing inserts the attacker into that gap. The threat actor initiates the flow, delivers the code to a target through a lure, and the user, believing they are authorizing a document viewer or a voicemail portal, authorizes the attacker's session instead. Microsoft notes this bypasses traditional MFA protections by decoupling authentication from the originating session. The reason your users comply is that nothing looks wrong. The page they land on is the genuine Microsoft device login portal. The MFA prompt on their phone is genuine. The password they enter goes to Microsoft, not to a fake form, so credential-theft warnings and password-reuse alerts never fire. This activity aligns with **EvilToken**, a Phishing-as-a-Service toolkit driving large-scale device code abuse, and marks an escalation beyond the Storm-2372 campaign observed in February 2025. The mechanism being exploited is real, trusted, and working exactly as designed. What is being attacked is the user's judgment about who asked for the code. Device code phishing: how the flow is abused 1 The threat actor initiates a legitimate OAuth 2.0 device code authentication request and receives a short user code tied to their own session. 2 The code reaches the target framed as access to a document viewer or voicemail portal. Tooling associated with the EvilToken Phishing-as-a-Service kit drives this stage at scale.Medium 3 The user enters the code on the genuine Microsoft portal, types their password to Microsoft, and approves an authentic MFA prompt. No credential-theft or password-reuse alert fires.microsoft.com/devicelogin 4 Because authentication completes on a separate device, the token goes to whoever holds the session identifier. The attacker's session is authorized instead of the user's.High 5 With a valid access token, the actor operates inside the organizational account. Traditional MFA protection is bypassed by decoupling authentication from the originating session.High ## Attack Chain: From Initial Contact to Credential Compromise The campaign starts well before the first email lands. Threat actors query Microsoft's **GetCredentialType** endpoint to confirm that a target mailbox exists and is active inside the tenant, and Microsoft Defender Security Research observed this validation step typically running 10 to 15 days ahead of the actual phishing attempt. That gap matters for investigations, because the reconnaissance traffic that preceded a compromise has usually aged out of shorter log retention windows by the time anyone starts looking. Delivery uses varied payloads: direct URLs, PDF attachments, and HTML files, wrapped in lures built around invoices, RFPs, shared documents, electronic signing requests, and voicemail notifications. One observed subject theme was "Action Required: Password Expiration." Generative AI produced the copy, tuned to the recipient's role and to workflows like manufacturing operations, which raises the odds that a finance or operations user treats the message as routine. The link never points straight at the landing page. Redirect logic runs through compromised legitimate domains and serverless hosting, with heavy use of `*.vercel.app`, `*.workers.dev` (Cloudflare Workers), and AWS Lambda. Alongside that, the actors ran domain shadowing and brand-impersonating hosts: - `graph-microsoft[.]com` - `portal-azure[.]com` - `office365-login[.]com` - Randomized subdomains such as `a7b2-c9d4.office-verify[.]net` Blocking one flagged URL does not take down the rest of the infrastructure, and the traffic mixes in with the cloud services your users already reach every day. The final page presents either a browser-in-the-browser window (a fake browser frame rendered inside the real page) or a blurred document preview with a "Verify identity" button. Some variants ask only for an email address, which the backend passes to Microsoft as a login hint. When the user clicks through, the page issues a **POST** to the actor's backend at `/api/device/start/` or `/start/` with an empty body and a custom `X-Antibot-Token` header carrying a 64-character hex value. The server proxies the request to Microsoft's device authorization endpoint and returns a fresh device code plus a hidden session identifier. The brief page load delay users notice is that round trip. The script then calls `navigator.clipboard.writeText` to push the code onto the clipboard and opens the genuine microsoft.com/devicelogin portal. The single action that completes the compromise is the user pasting that code and confirming. Meanwhile a `checkStatus()` function polls the actor's `/state` endpoint every 3 to 5 seconds with the session identifier, returning "pending" until authentication succeeds. The victim is then bounced to a placeholder DocuSign, Google, or Microsoft page while the backend holds a live access and refresh token pair issued after a real MFA-backed login. Post-compromise activity splits by target value. In some cases device registration occurred within 10 minutes of the breach to mint a **Primary Refresh Token** for durable access. In others, the actors waited hours before touching anything, then created inbox rules through the Microsoft Office application and ran Microsoft Graph reconnaissance to map organizational structure and permissions. Accounts belonging to financial, executive, and administrative personas received deep-dive mailbox searches for wire transfer details, pending invoices, and executive correspondence, which is the pattern that precedes payment fraud. Sign-in infrastructure IOCs published by Microsoft cover four ranges: `160.220.232.0` and `160.220.234.0` (Railway.com), plus `89.150.45.0` and `185.81.113.0` (HZ Hosting). Authentication sequences showing error code **50199** followed by a success within a short interval indicate the pause where a user pasted a code. ## Business and Compliance Impact Because the victim completes a genuine Microsoft login, an account takeover in this campaign produces no failed password attempts, no credential dump, and no malware artifact on the endpoint. Your usual first move after a suspected phish, forcing a password reset, does not remove the attacker, because the access and refresh tokens issued to their session remain valid independently of the password. The follow-on activity Microsoft observed tells you what is actually at stake. Threat actors used Microsoft Graph reconnaissance to programmatically map internal organizational structure and identify sensitive permissions the moment a token was secured. That means the attacker learns your reporting lines, group memberships, and which accounts hold elevated rights, without ever touching a domain controller or triggering endpoint alerts. Persistence escalated quickly in some cases. Threat actors registered new devices to generate a Primary Refresh Token, the credential Entra ID issues to a registered device for long-term single sign-on. > In some instances, within 10 minutes of the breach, threat actors registered new devices to generate a Primary Refresh Token for long-term persistence. A rogue registered device changes the nature of your incident. What began as one phished mailbox becomes an attacker-controlled identity that keeps issuing tokens across your Microsoft 365 estate, and your device inventory now contains an entry that looks like any other enrolled machine. The data exposure is concentrated where it hurts financially. After compromising accounts at scale, the threat actors filtered for high-value personas in financial, executive, and administrative roles, then performed deep-dive reconnaissance into email communications searching for wire transfer details, pending invoices, and executive correspondence. If your accounts payable clerk or an executive assistant is in that filtered pool, the attacker is reading the same payment threads your finance team uses to approve transfers. Malicious inbox rules created through the Microsoft Office application compound this. Rules that redirect or conceal messages mean your staff stop seeing supplier replies, fraud warnings from a bank, or a colleague questioning a payment change. The user population most affected is anyone with an active browser session, since pasting the code and confirming the request instantly authenticates the attacker's session with no password or MFA prompt at all. Dwell time is deliberately variable. Some compromises moved to device registration within minutes, while in other scenarios the threat actors waited several hours before creating inbox rules or exfiltrating email data specifically to avoid immediate detection. For your investigation, that spread means the absence of activity in the first hour after a suspicious sign-in tells you nothing useful about whether the account is clean. Compliance exposure follows the mailbox contents. If the compromised accounts handle patient information, customer records, HR files, or payment data, you are dealing with unauthorized third-party access to regulated personal data, and your notification obligations turn on what was accessible during the token's validity window. Reconstructing that scope depends entirely on your mailbox audit and Graph activity records. Where those records are thin, your legal team is left assuming the broadest reasonable exposure, which drives up notification volume and remediation cost. For SOC 2 and similar audit programs, the finding is uncomfortable in a different way. Your MFA control operated exactly as designed and the account was still taken over, so the compensating evidence auditors will ask for shifts toward token lifetime governance, device registration controls, and identity monitoring rather than authentication strength alone. ## Detection and Immediate Response Actions Start with token revocation, not a password reset. If you suspect a user completed a device code prompt they did not initiate, call `revokeSignInSessions` on that account to invalidate issued refresh tokens, then pair it with a Conditional Access policy that forces re-authentication. Without that step, the attacker's session stays alive on its own schedule. Today, run the sign-in hunt. Microsoft's advanced hunting guidance keys on error code 50199, the user-interrupt prompt that appears when someone pauses to paste a code. In Defender XDR, query `EntraIdSigninEvents | where ErrorCode in (0, 50199)`, summarize by `AccountUpn, CorrelationId, SessionId` in one-hour bins, and filter for correlation IDs containing both values. A 50199 followed by a success inside a five-minute window is the signature of a user typing a code they were handed. Then check those sign-ins against known infrastructure. Filter `EntraIdSigninEvents | where Call has "Cmsi:cmsi"` and match `IPAddress` against the published ranges: 160.220.232.0 and 160.220.234.0 (Railway.com), 89.150.45.0 and 185.81.113.0 (HZ Hosting). Microsoft's hunting guidance also lists 8.228.105. as a range worth checking. Any hit means a token was issued to a session your user never controlled. This week, correlate mail activity with authentication. The most useful query joins `UrlClickEvents` to successful sign-ins where `RiskLevelDuringSignin` is 10, 50, or 100, filtered to a window between minus two and plus seven minutes of the click. That timing band separates a phishing-driven authentication from ordinary daily logins. In environments Capstone manages, Adlumin correlates this kind of identity telemetry across tenants, so an anomalous device code grant surfaces alongside the mail event that produced it rather than sitting in a separate console. Run these hunts across the tenant, not just on reported accounts: - **Device registration**: query `CloudAppEvents | where AccountDisplayName == "Device Registration Service"` and extract DeviceName, DeviceId, and UserPrincipalName. Microsoft observed registrations within 10 minutes of compromise, used to mint a Primary Refresh Token for longer-term access. - **Inbox rules**: query `CloudAppEvents | where ApplicationId == "20893"` for `New-InboxRule`, `Set-InboxRule`, `Set-Mailbox`, and transport rule actions. Filter rule names matching only special characters, a naming pattern the operators used to keep rules visually inconspicuous. - **Mailbox access**: query the same table for `ActionType == "MailItemsAccessed"` where `UncommonForUser has "ISP"`, which surfaces mail read from a network the account has not used before. Microsoft Sentinel customers can run the TI Mapping analytics (rules prefixed `TI map`) to match these indicators against existing workspace data, plus the prebuilt queries for OAuth apps reading mail via Graph API and anomalous MailItemAccess volumes. For the short term, block the device code flow in Conditional Access everywhere it is not needed, and scope an exception only to the printer, display, or kiosk fleets that genuinely require it. Add a sign-in risk policy that blocks or challenges at high risk, and turn on continuous access evaluation so a high-risk determination revokes an active session instead of waiting for token expiry. Enable Safe Links in Defender for Office 365, which raises the high-confidence device code phishing alerts and feeds the click telemetry the correlation query above depends on. Document which accounts you revoked, which devices you removed from Entra ID, and which inbox rules you deleted. That record is what lets you confirm the access is actually closed. ## Hardening Device Code Sign-In and User Organizations The single highest-value control is blocking the device code flow outright. Microsoft's own guidance is to disable it wherever possible, and for most organizations that is everywhere. Build a Conditional Access policy in Microsoft Entra ID that targets the device code authentication flow and set it to block for all users, then carve out narrow exceptions only where a real device requires it. Before you write that policy, find out who actually needs the flow. Conference room displays, shared meeting-room hardware, and older printers are the usual legitimate consumers. Everyone else, including your finance staff and executives (the personas the threat actors filtered for after compromise), has no business completing a device code prompt from a laptop. For the exception group, tighten the conditions rather than simply allowing the grant: - Require the sign-in to originate from a named location matching your managed office networks. - Require a compliant or hybrid-joined device, so a token issued to attacker-controlled infrastructure fails policy evaluation. - Block legacy authentication protocols with a separate Conditional Access policy, since legacy per-user MFA prompts remain susceptible to abuse. Move your users onto phishing-resistant authentication. FIDO2 security keys or Microsoft Authenticator with passkey remove the push-approval habit this campaign depends on. Avoid telephony-based MFA because of SIM-jacking exposure. Pair that with a sign-in risk policy that evaluates the probability an authentication request was not made by the identity owner, and configure high risk to block or force re-authentication with continuous access evaluation enabled so access is revoked mid-session. On the mail side, configure anti-phishing policies to catch spoofed senders and impersonation attempts, and turn on Safe Links in Defender for Office 365. Safe Links scanning also feeds high confidence device code phishing alerts, which matters when the final destination is a legitimate Microsoft URL that no domain blocklist will flag. User education for this campaign should be narrow and concrete. Generic "don't click links" training does not help when the victim ends up on the real microsoft.com/devicelogin page. Teach three specific red flags instead: - A code appears in your clipboard that you did not copy, or a page offers to copy one for you. - You are asked to enter a code to view a document, invoice, RFP, or voicemail. Document viewing never requires device authentication. - The sign-in confirmation prompt names an application you did not open. Microsoft has prompted users to confirm the app since 2021, and that Cancel or Continue screen is the last point where a user can stop the token handoff. Send a short notice to staff this week rather than waiting for the next awareness cycle. Something close to: "If any website, email, or document asks you to enter a code at microsoft.com/devicelogin, stop and report it to IT. Do not enter the code. Legitimate document and invoice links never require one. If you already entered a code, tell us immediately so we can end the session." Centralize identity logging into one platform so hybrid and third-party identity data reaches Entra ID or your SIEM, and synchronize all accounts except administrative and high-privileged ones to keep a boundary between on-premises and cloud. Then audit privileged account activity in Entra ID and enforce least privilege, which limits what a valid token can reach if one is issued. ## Key Takeaway and Priority Action There is no patch for this campaign. The device code flow behaves exactly as OAuth 2.0 designed it to behave, and Microsoft Defender Security Research documented an abuse of that design rather than a flaw in it. That puts the problem in your detection and response column permanently, since no vendor update will close it for you. The convenience tradeoff is the whole story. A flow built so a printer or a smart display can authenticate without a keyboard also lets a stranger's session ride in on your user's legitimate sign-in. Your identity telemetry records a normal, successful, MFA-satisfied authentication because that is what happened. Microsoft frames this campaign as a significant escalation over the Storm-2372 device code activity from February 2025, and the difference is scale. Accounts were compromised in volume, then filtered afterward for people with financial, executive, or administrative authority. Your exposure is not evenly distributed across your user base, and the attacker decides who matters after the token is already issued. The priority action is a backward-looking one. Pull the last 30 days of device code authentication events from your tenant and cross-reference them against every phishing report your help desk received in the same window. You are looking for grants you cannot tie to a known device, not for failed logins. Track one number going forward: the count of device code grants originating from unexpected locations or at times inconsistent with the user's normal working hours. If that number is above zero and unexplained, you have something to investigate. If you cannot produce the number at all, that gap is the first thing to fix. ```json { "@context": "http:\/\/schema.org", "@graph": [ { "@type": "Article", "author": { "@id": "https:\/\/captechgroup.com\/#brian_0fd5dfcdbc" }, "dateModified": "2026-08-15T12:35:31Z", "datePublished": "2026-08-15T12:35:31Z", "description": "Device code phishing abuses OAuth 2.0 authentication to bypass MFA and take over accounts at scale. Learn how EvilToken drives this campaign and detection…", "headline": "AI-Enabled Device Code Phishing Campaign Abuses Device Code Sign-In Flow", "image": { "@id": "https:\/\/captechgroup.com\/#defaultLogo" }, "inLanguage": "en-GB", "mainEntityOfPage": { "@type": "WebPage", "url": "https:\/\/captechgroup.com\/threat-intelligence-center\/ai-enabled-device-code-phishing-campaign-abuses-de-81a334" }, "publisher": { "@id": "https:\/\/captechgroup.com\/#defaultPublisher" }, "url": "https:\/\/captechgroup.com\/threat-intelligence-center\/ai-enabled-device-code-phishing-campaign-abuses-de-81a334" }, { "@type": "Person", "name": "Brian", "@id": "https:\/\/captechgroup.com\/#brian_0fd5dfcdbc" }, { "@id": "https:\/\/captechgroup.com\/#defaultLogo", "@type": "ImageObject", "url": "https:\/\/captechgroup.com\/images\/hotlink-ok\/logo-light.jpg", "width": 1300, "height": 300 }, { "@id": "https:\/\/captechgroup.com\/#defaultPublisher", "@type": "Organization", "url": "https:\/\/captechgroup.com\/", "logo": { "@id": "https:\/\/captechgroup.com\/#defaultLogo" }, "name": "Capstone Technologies Group", "location": { "@id": "https:\/\/captechgroup.com\/#defaultPlace" } }, { "@id": "https:\/\/captechgroup.com\/#defaultPlace", "@type": "Place", "address": { "@id": "https:\/\/captechgroup.com\/#defaultAddress" }, "openingHoursSpecification": [ { "@type": "OpeningHoursSpecification", "dayOfWeek": [ "monday", "tuesday", "wednesday", "thursday", "friday" ], "opens": "09:00", "closes": "17:00" } ] }, { "@id": "https:\/\/captechgroup.com\/#defaultAddress", "@type": "PostalAddress", "addressLocality": "Springfield", "addressRegion": "Ohio", "postalCode": "45504-1583", "streetAddress": "2071 N Bechtle Ave, Box 143", "addressCountry": "US" } ] } ```