Device Code Phishing and the Weaponization of OAuth Authentication

In the winter of 2025, a diplomat working on Ukraine policy received a message on Signal from someone claiming to be a senior official at the Ukrainian Ministry of Defence. The conversation was warm, collegial, urgent. After a few exchanges, the “official” suggested they move to Element, a secure messaging platform, for a sensitive discussion. An email arrived shortly after — what appeared to be an invitation to join a private chatroom. The diplomat clicked the link. It led to a familiar Microsoft login page. They entered a short alphanumeric code they’d been given, typed their password, approved the push notification on their phone, and went back to their day. They had just handed their entire Microsoft 365 account — email, OneDrive files, Teams conversations, everything — to Russian intelligence. Within minutes, automated scripts were downloading every document from their cloud storage. The diplomat had no idea anything was wrong. The login page was real. The multi-factor authentication was real. The only thing that was fake was the reason they were asked to log in.

This is device code phishing, and it has become one of the most dangerous identity-based attacks in modern cybersecurity. What makes it uniquely devastating is that it doesn’t rely on fake websites, stolen passwords, or intercepted text messages. It weaponizes a legitimate feature of the internet’s authentication infrastructure — one originally designed for smart televisions and printers — and turns unsuspecting users into willing accomplices in their own compromise.

A Protocol Designed for Televisions, Weaponized Against Governments

To understand why this attack works so well, you need to understand the technology it exploits. In August 2019, the Internet Engineering Task Force published RFC 8628, a technical standard called the OAuth 2.0 Device Authorization Grant. It solved a mundane problem: how do you log in to an app on a device that doesn’t have a proper keyboard or web browser — like a smart TV, a digital picture frame, or a command-line developer tool?

The answer was elegant. When you try to sign in on such a device, it shows you two things: a short website address (like microsoft.com/devicelogin) and a brief alphanumeric code (something like WDJB-MJHT). You walk over to your phone or laptop, open that website in a browser, type in the code, and log in normally with your username, password, and whatever multi-factor authentication your organization requires. Meanwhile, the original device quietly polls the authentication server every five seconds, asking: “Has the user finished logging in yet?” The moment you complete authentication on your phone, the device receives its tokens, and you’re signed in.

The system has three key components. The user code is short and human-readable — typically eight characters, designed to be easy to type on any keyboard. The device code is a long, opaque string used only by the machine to poll for tokens. And both expire quickly — Microsoft sets a 15-minute window — creating a built-in time limit that was meant to be a security feature. The design assumed that the person typing the code would always be the person who initiated the login on the device. Nobody anticipated that an attacker on another continent could generate the code, send it to a victim, and let the victim authenticate on their behalf.

Yet that is precisely what happens. The RFC’s own authors, in section 5.4 of the standard, acknowledged the theoretical risk of “remote phishing” — an attacker initiating the flow and tricking a user into completing it. They noted that short code lifetimes would limit the attack’s viability for codes sent over email or text message. What they didn’t foresee was the sophistication of modern social engineering: nation-state operatives building rapport over encrypted messaging apps, criminal gangs conducting coordinated voice phishing calls, and automated toolkits generating fresh codes in real time. The 15-minute expiry window, it turns out, is more than enough time.

How a Phone Call Steals Your Identity

The attack unfolds with deceptive simplicity. An attacker — whether a Russian intelligence operative or a financially motivated criminal — begins by sending a request to Microsoft’s authentication servers using the identity of a legitimate Microsoft application. Microsoft’s system doesn’t know or care that the request is malicious; it simply generates a fresh user code and device code, exactly as designed. The attacker now has 15 minutes to get someone to authenticate on their behalf.

What happens next depends on the attacker’s sophistication. The most elaborate campaigns, like those attributed to Russia-aligned group Storm-2372, begin weeks in advance. Operatives pose as prominent figures — diplomats, academics, government officials — and initiate conversations on WhatsApp, Signal, or Microsoft Teams. They build genuine-seeming professional rapport. When the moment is right, they send what appears to be a Microsoft Teams meeting invitation. The device code is disguised as the meeting’s join code. The victim, expecting a legitimate call, visits microsoft.com/devicelogin, enters the code, and logs in normally. They complete their multi-factor authentication — the push notification, the fingerprint scan, whatever their organization requires — because the login page is entirely genuine. It is Microsoft’s real infrastructure. There is nothing to detect, no URL to flag, no fake domain to spot.

Other campaigns are more direct. The ShinyHunters extortion gang, tracked by Google’s Mandiant division as UNC6040, took a brutally efficient approach: they simply called people on the phone. Posing as IT support staff addressing a nonexistent connectivity issue, they talked employees at companies including Google, Cisco, and Qantas through entering a device code on a legitimate authentication page. No phishing email was needed. No malicious link existed. Just a human voice, a plausible pretext, and an eight-character code. Ransom demands that followed ranged from 4 to 20 bitcoin — roughly $260,000 to $1.3 million at 2025 prices.

The financially motivated group TA2723 took a more traditional approach at massive scale. In October 2025, they blasted out emails with subject lines referencing amended salary documents and employer benefit reports. Recipients who clicked through landed on professionally designed websites, localised with their employer’s branding, where they were prompted to enter their email address. A popup then displayed a device code, described as a “one-time password for secure authentication,” along with instructions to visit Microsoft’s device login page. Proofpoint researchers determined TA2723 was using two different toolkits — SquarePhish2 for one campaign wave and the Graphish phishing kit for another — rotating tools to evade detection.

What makes this fundamentally different from traditional phishing is the role of multi-factor authentication. In a conventional credential-stealing attack, MFA is a barrier. The attacker might capture your password from a fake login page, but they still need your second factor — your phone, your fingerprint, your hardware key. Device code phishing neutralises this entirely. The victim completes their own MFA on the real Microsoft domain, and the resulting authenticated session is delivered straight to the attacker. As one Volexity researcher noted, many traditional sources of evidence and detection — both for the user and for network defenders — are simply not present. There is no malicious link. There is no suspicious attachment. Everything is real.

The 90-Day Skeleton Key

When a victim completes authentication, two tokens are delivered to the attacker: an access token (valid for about an hour) and a refresh token (valid for 90 days). The access token is the immediate prize, granting the attacker the ability to read emails, download files, and search through data. But the refresh token is the real treasure. Each time it’s used to request a new access token, Microsoft issues a fresh refresh token with a new 90-day window. This rolling expiry means that as long as an attacker uses the token at least once every 90 days, they maintain access indefinitely — a persistent backdoor that survives password changes unless the organization explicitly revokes all tokens for the compromised account.

This alone would be serious. But a largely undocumented Microsoft feature makes it catastrophic.

FOCI — the Family of Client IDs — is a mechanism built into Microsoft Entra ID (formerly Azure Active Directory) that groups certain first-party Microsoft applications into a “family.” Applications in this family share a special type of refresh token called a Family Refresh Token, or FRT. In practice, this means a token obtained for one Microsoft application can be silently exchanged for access to any other application in the family — no additional authentication required.

The family is large. SecureWorks researchers have identified more than 20 member applications, including Azure CLI, Microsoft Teams, Outlook, OneDrive, Microsoft Office, Microsoft Edge, Power BI, Microsoft Planner, and even Microsoft Authenticator itself. When an attacker captures a refresh token from a device code phishing attack using any of these applications’ client IDs, they receive an FRT that grants access to the entire portfolio. A single phishing interaction gives them the ability to read every email, download every file, search every Teams conversation, and even manage Azure cloud infrastructure — all through legitimate Microsoft APIs that generate minimal suspicious activity in security logs.

Microsoft has confirmed through a vulnerability submission that FOCI is an intentional feature, designed to provide seamless single sign-on across Microsoft’s mobile applications. But its security implications are profound. When SecureWorks presented their research at the TROOPERS 2022 security conference, they demonstrated that a token stolen from a command-line tool could silently pivot to full access across email, messaging, and cloud storage — without triggering any additional consent prompts or authentication challenges. Microsoft declined to publish the official list of FOCI member applications, stating only that it changes frequently.

From Academic Curiosity to Nation-State Weapon

The timeline of device code phishing’s evolution tells the story of a security community that saw the danger coming but couldn’t prevent it.

The weaponisation concept was first publicly documented on October 13, 2020, when Finnish security researcher Dr. Nestori Syynimaa published a blog post introducing the technique for compromising Office 365 accounts. Dr. Syynimaa, creator of the AADInternals security toolkit and now a Principal Identity Security Researcher at Microsoft’s own Threat Intelligence Centre, demonstrated the complete attack chain: generating a device code, embedding it in a phishing email, and capturing tokens that included the FOCI designation — meaning a single successful phish unlocked access across the entire Microsoft ecosystem. His proof of concept used the Microsoft Office client ID, and the response from Microsoft’s servers confirmed the token was a Family Refresh Token.

For nearly two years, the technique remained largely academic — known to red teamers and penetration testers but not widely exploited in the wild. In 2022, Dell SecureWorks (now Secureworks) released SquarePhish, an open-source tool that automated the entire attack chain, combining QR code delivery with the device code flow. Researchers Kam Talebzadeh and Nevada Romsdahl demonstrated it at Black Hat USA 2022. The same year, SecureWorks published their FOCI research at the ICEIS academic conference, formally documenting how Family Refresh Tokens enabled cross-application lateral movement. Other tools followed — TokenTactics, a PowerShell module for token manipulation; PhishInSuits, which integrated SMS-based delivery via Twilio; and eventually SquarePhish2, a rewritten, more automated version with a web-based operator dashboard and automatic victim redirection.

The tipping point came in early 2025. In January, threat intelligence firm Volexity identified multiple Russian threat groups simultaneously conducting device code phishing campaigns against Microsoft 365 accounts. On February 13, 2025, both Microsoft and Volexity published detailed advisories on the same day — Microsoft naming the threat actor Storm-2372 and Volexity documenting three additional clusters they tracked as CozyLarch (assessed with medium confidence to overlap with APT29/Midnight Blizzard), UTA0304, and UTA0307.

Storm-2372’s campaign had been running since August 2024, targeting government agencies, NGOs, defence contractors, telecommunications companies, health organizations, universities, and energy firms across Europe, North America, Africa, and the Middle East. Microsoft described the campaign as active and successful. Within a day of the advisory’s publication, Storm-2372 adapted: they shifted to using the Microsoft Authentication Broker client ID, which enabled them not just to steal tokens but to register attacker-controlled devices directly in the victim’s Entra ID tenant and obtain Primary Refresh Tokens — Microsoft’s master single sign-on credential that grants access to every application a user can reach.

The convergence of state and criminal actors accelerated through the rest of 2025. By September, Proofpoint observed what they called a shift from limited, targeted attacks to widespread campaigns — a development they described as highly unusual. China-based espionage group Storm-1249 was discovered using device code phishing with generic lures about taxes and civil service. Russia-aligned UNK_AcademicFlare was targeting think-tank researchers and Ukrainian government officials through patient, weeks-long rapport-building operations conducted from compromised military email accounts. And in July 2025, a Golang-based device code phishing automation tool appeared for sale on a Russian-language hacking forum for $1,200 — before being released for free a week later.

What Happens After the Code Is Entered

The moment tokens arrive in an attacker’s hands, a methodical post-compromise playbook begins. Storm-2372 operatives were documented using the Microsoft Graph API to search compromised mailboxes for keywords including “username,” “password,” “admin,” “credentials,” “secret,” “ministry,” and “gov” — hunting for stored credentials, VPN configurations, and sensitive government communications. Tools like GraphRunner and TokenTactics automate this process, dumping hundreds of emails and their attachments in seconds.

From a single compromised account, attackers fan outward. Storm-2372 sent internal device code phishing emails from compromised accounts to colleagues within the same organization, with innocuous subject lines like “Document to review.” Because these messages came from a trusted internal address, success rates were high. Each new compromise expanded the attacker’s footprint.

For persistence, attackers register malicious OAuth applications in the victim’s Entra ID tenant, add their own credentials to existing applications via the Graph API, or — in the most sophisticated operations — use tools like ROADtx to register devices and mint Primary Refresh Tokens that satisfy even Conditional Access policies requiring managed devices. Some attackers have been observed registering Windows Hello for Business credentials on compromised accounts, creating passwordless authentication methods that persist through password resets and comply with the strictest MFA policies.

The ShinyHunters group demonstrated how this translates to real-world damage. After compromising Microsoft Entra accounts through voice phishing and device code flow, they pivoted through single sign-on integrations to access Salesforce, Google Workspace, Dropbox, Adobe, SAP, Slack, Zendesk, and Atlassian — essentially every enterprise application linked to the victim’s identity. In their Salesforce campaigns, they exfiltrated customer relationship management data from an estimated 760 Salesforce instances, claiming access to 1.5 billion data records. Affected companies included cybersecurity firms Cloudflare, Zscaler, Tenable, CyberArk, BeyondTrust, and — in a particularly ironic twist — Proofpoint itself, the very firm that researches phishing attacks for a living.

The Belgrade Conference That Never Was

Among the most elaborate documented campaigns was one attributed to the Russian-linked group UTA0355, which Volexity exposed in December 2025. The attackers created professional fake websites mimicking real European security events — the Belgrade Security Conference scheduled for November 2025 and the Brussels Indo-Pacific Dialogue. They registered convincing domains, built polished registration pages, and initiated rapport-building outreach via email and WhatsApp to government officials, think-tank researchers, and policy analysts who would plausibly attend such events.

In one case, a victim went through what appeared to be a conference registration process that funnelled them through a Microsoft device code authentication flow. After the victim authenticated, the attacker — still communicating via WhatsApp — asked them to send back the full browser URL under the pretext of finalizing their registration. That URL contained an OAuth authorization code, giving the attacker an additional authentication pathway. The intruder then registered a new device in the victim’s Entra ID tenant, naming it identically to one of the victim’s legitimate devices, and began accessing files through proxy networks geolocated to match the victim’s actual location — making the activity nearly invisible in security logs.

Red team firm Praetorian quantified just how effective these attacks can be in controlled settings: when conducting device code phishing via phone calls to software developers, they achieved a greater than 90 percent success rate. In one engagement against a Fortune 50 company, they used captured GitHub tokens to move laterally through the organization’s continuous integration environment and ultimately compromised their root Amazon Web Services account. The entire chain began with an eight-digit code and a phone call.

Finding the Needle: How Defenders Hunt for Device Code Attacks

Detecting device code phishing is challenging precisely because the authentication itself is legitimate. But it is not invisible. In Microsoft Entra ID sign-in logs, device code flow authentication leaves a distinctive fingerprint: the authenticationProtocol field is set to “deviceCode.” For subsequent token refreshes from sessions originally authenticated via device code, the originalTransferMethod field reads “deviceCodeFlow” — even when the authentication protocol field itself is no longer populated.

Security teams can query these logs using KQL (Kusto Query Language) in Microsoft Sentinel or similar platforms, filtering for successful device code authentications and cross-referencing them against expected usage patterns. The critical detection pattern is geographic anomaly correlation: when a user authenticates from their normal location but the resulting tokens are used from a completely different IP address or country — a variant of the “impossible travel” detection that security analysts have long used for credential theft.

However, significant blind spots remain. Dr. Syynimaa’s original research demonstrated that access tokens obtained using refresh tokens do not always appear in sign-in logs, creating gaps in forensic visibility. Non-interactive sign-ins — which FOCI-based token exchanges produce — appear in a separate log tab that many organizations overlook. And sophisticated actors like Storm-2372 use regionally appropriate proxies to make their token usage appear geographically consistent with the victim, specifically to evade impossible-travel detection.

For forensic investigators responding to a confirmed compromise, the MailItemsAccessed event in Microsoft 365’s Unified Audit Logs is essential. This telemetry records every instance of email data access, regardless of protocol, and includes the client IP address and session identifier — enabling investigators to distinguish attacker access from legitimate user activity. It was this logging capability that CISA credited with detecting sophisticated APT activity in its 2023 advisory on Chinese threat actors targeting U.S. government agencies.

Shutting the Door: What Organizations Can Do Now

The single most effective defence is brutally simple: block device code flow entirely using Conditional Access policies in Microsoft Entra ID. Since Microsoft introduced the Authentication Flows condition in Conditional Access, administrators can create a policy that blocks device code flow for all users, with targeted exceptions for legitimate use cases like Teams Rooms devices or command-line tools. Microsoft’s own guidance states that organizations should get as close as possible to a unilateral block on device code flow.

Recognizing the severity of the threat, Microsoft announced on February 20, 2025 — exactly one week after publishing the Storm-2372 advisory — that it would begin rolling out Microsoft-managed Conditional Access policies that block device code flow by default for any tenant that hasn’t used it in the past 25 days. These policies, part of the broader Secure Future Initiative launched in the wake of the Midnight Blizzard breach, deploy initially in report-only mode with a 45-day grace period before automatic enforcement. Yet Wiz’s telemetry found that fewer than half of Microsoft’s customers enforce Conditional Access policies blocking device code authentication, with only 0.3 per cent of all device code authentication attempts actually stopped by a block rule.

For organizations that must permit device code flow for specific applications, the recommended approach combines multiple layers. They should restrict the flow to named network locations — that is, trusted corporate IP ranges — only. They should require device compliance, though defenders should note that attackers who can register devices in Entra ID may satisfy this requirement. They should limit the maximum number of device registrations per user, since Microsoft’s defaults allow up to 50 Entra ID registrations and 15 Intune enrolments — numbers that should be reduced significantly. They should enable Continuous Access Evaluation (CAE), which allows near-real-time token revocation when critical events like password resets occur. And they should monitor sign-in logs aggressively for the deviceCode authentication protocol.

When a compromise is confirmed, incident response must be immediate and thorough. Revoking all refresh tokens for affected users is the critical first step — a password reset alone does not invalidate already-issued bearer tokens. Responders must also check for attacker-registered devices in the tenant, review and remove suspicious OAuth application consents, verify that no new MFA methods were added to the account, search for attacker-created inbox forwarding rules, and assess the scope of data exposure through MailItemsAccessed logs.

User education remains important, but it requires a fundamental shift in framing. Traditional phishing awareness — “check the URL,” “look for the padlock,” “don’t enter credentials on unfamiliar sites” — is useless against device code phishing, where every URL is legitimate, and every login page is real. The new teaching must centre on what researchers call the principle of initiation: if you didn’t start the login process yourself, don’t complete it for someone else. Any unsolicited request to visit a login page and enter a code — whether it arrives by email, text, Teams message, Signal, WhatsApp, or phone call — should be treated as hostile until proven otherwise.

The Industrialization of Identity Compromise

The trajectory of device code phishing mirrors a pattern cybersecurity professionals have seen before: a novel technique is documented by researchers, demonstrated by penetration testers, adopted by nation-state operators, and eventually industrialized by criminal enterprises with off-the-shelf toolkits that require no technical expertise. The progression from Dr. Syynimaa’s 2020 blog post to SquarePhish in 2022 to Graphish’s free distribution on criminal forums in 2025 compressed this lifecycle into five years.

What distinguishes device code phishing from previous identity attacks is its exploitation of trust itself. Every component of the attack — the login page, the authentication server, the MFA challenge, the token infrastructure — is genuine. The only deception occurs in the social layer: convincing a human being to type eight characters into a legitimate website. No malware is delivered. No vulnerability is exploited. No fake infrastructure is needed. The attack succeeds because a protocol designed to make life easier for smart TV owners operates on a single assumption that attackers have learned to violate: that the person entering the code is the person who requested it.

The technique has now been adopted by actors spanning the full spectrum from Russian and Chinese intelligence services to financially motivated criminal gangs operating phishing-as-a-service platforms. The barrier to entry continues to fall. SquarePhish2’s web-based dashboard makes launching a campaign as straightforward as filling out a form. Graphish, freely available on criminal forums, was explicitly designed to be accessible to low-skilled threat actors. The automation tool sold on the Exploit.in forum in July 2025 for $1,200 was given away for free within a week.

The fundamental challenge ahead is architectural. Device code flow exists because input-constrained devices are real, and they need a way to authenticate. Eliminating the protocol entirely would break legitimate workflows across millions of IoT devices, developer tools, and shared-space computing systems. The solution lies in making the flow opt-in rather than opt-out, restricting it to verified devices and trusted networks, and ensuring that users always understand exactly what they’re authorizing when they enter a code. Microsoft’s February 2025 managed policies represent a meaningful step in this direction, but with fewer than half of tenants enforcing blocks, the gap between the available defence and its adoption remains vast.

For the diplomat who entered that code after a conversation on Signal, the full scope of the compromise may never be publicly known. But the lesson their experience teaches is universal and unsettling: in an era where identity is the new perimeter, the most dangerous attacks don’t break through your defences. They politely ask you to hold the door open — and you do, because everything looks exactly the way it should.