The Token Is the Key: How OAuth Device Code Phishing Renders MFA Irrelevant

A wave of phishing attacks is currently bypassing Microsoft 365 MFA without intercepting a single one-time passcode, without spoofing any Microsoft domain, and without stealing any credentials at all. The attack abuses a legitimate Microsoft authentication protocol — and the system behaves exactly as designed the entire time.

In February 2026, KnowBe4 Threat Labs published findings on an active phishing campaign that had been observed since December 2025, with over 44% of its victims located in the United States and primary targeting concentrated in tech, manufacturing, and financial services. The campaign is not novel in a purely academic sense — Proofpoint had been tracking the underlying technique since at least January 2025, and Sophos researchers documented the theoretical attack surface as far back as 2021. What is notable is the scale, the automation, and the range of threat actors now deploying it. By September 2025, according to Proofpoint, widespread use of this technique had become "highly unusual" in the volume they were observing. By December, both financially motivated criminals and nation-state groups were running it in parallel.

The technique is called OAuth Device Code Phishing. It abuses the OAuth 2.0 Device Authorization Grant flow — a standard defined in RFC 8628 — to trick a target into handing an attacker a valid access token for their Microsoft 365 account. No password is captured. No MFA code is intercepted in transit. The user's authentication against Microsoft succeeds completely and legitimately. The only problem is that the token issued at the end of that authentication goes to the attacker's registered application, not the user's own session. By the time the victim closes the browser, the attacker has persistent access to their Outlook, Teams, OneDrive, and SharePoint — and that access will survive a password reset.

The Protocol That Made This Possible

To understand the attack, you need to understand why the Device Authorization Grant flow exists at all. RFC 8628, published by the IETF in 2019, was designed to solve a specific UX problem: how do you authenticate an app running on a device that doesn't have a convenient input interface? The canonical example is a smart TV or a Roku player. You want to link your Netflix account to the device, but typing a password with a TV remote is painful. The solution: the device generates a short alphanumeric code and tells you to go to a verification URL on your phone or computer, enter the code, and authorize the device. The TV polls the authorization server in the background until the code is validated, at which point it receives an access token.

Microsoft implements this flow for Microsoft 365 through https://microsoft.com/devicelogin. You navigate there, enter an eight-character code, authenticate with your credentials and MFA, and the device waiting on the other end receives its OAuth access token. This is the entirely legitimate flow. Hundreds of millions of devices use some variant of it every day.

The attack weaponizes this design. The attacker, not a TV manufacturer, generates the device code. The attacker then socially engineers the target into navigating to microsoft.com/devicelogin and entering that code. The target authenticates — successfully, against a real Microsoft domain, completing their real MFA challenge — and the attacker's application receives the resulting token.

The access token grants immediate access. The refresh token is the more dangerous artifact — it can be used to obtain new access tokens repeatedly, long after the original session would have expired. Depending on the application's configured token lifetime and whether Continuous Access Evaluation (CAE) is active in the tenant, that refresh token can persist for weeks or months. A forced password reset does not revoke an existing refresh token unless the administrator explicitly revokes the session in Entra ID.

Continuous Access Evaluation (CAE) is worth understanding in this context because it is sometimes cited as a mitigating control. CAE allows Microsoft 365 services to receive near-real-time signals from Entra ID about account state changes — such as a password reset or a revocation event — and act on those signals immediately rather than waiting for the access token to expire. When CAE is enabled and both the client application and the resource service support it, access token lifetimes can be extended to up to 28 hours because the service can revoke them on demand. However, CAE only helps if you know you have been compromised and take explicit revocation action. CAE does not detect the initial token theft, does not prevent token issuance, and does not limit refresh token lifetime. It accelerates the effect of an administrator-initiated revocation — it does not substitute for it.

The Attack Chain, Step by Step

KnowBe4 Threat Labs documented the active campaign's kill chain in five distinct phases. Understanding each transition point is important because each one is where detection or disruption is theoretically possible — and where it fails in practice.

Phase 1: App Registration and Code Generation

The attacker registers an application in Azure Active Directory (now Entra ID) or leverages an existing client ID extracted from a publicly available or compromised application registration. They call Microsoft's device authorization endpoint to obtain a user_code / device_code pair. Codes are short-lived by default — typically 15 minutes — which historically limited the scalability of this technique. Modern tooling solves this problem by automating rapid re-generation.

# Initiating the device code flow — the attacker-side request
POST https://login.microsoftonline.com/{tenant}/oauth2/v2.0/devicecode
Content-Type: application/x-www-form-urlencoded

client_id={attacker_app_client_id}
&scope=https://graph.microsoft.com/.default offline_access

# Response includes:
# user_code     — what the victim will be asked to enter
# device_code   — what the attacker polls with
# expires_in    — seconds until the code expires (typically 900)
# interval      — polling interval in seconds

Phase 2: Lure Delivery

The victim receives a phishing email. Lures vary significantly across observed campaigns. KnowBe4's documented campaign used business-themed lures directing victims to what appeared to be a secure document portal. Proofpoint documented TA2723 using salary and benefits-themed lures — subject lines like "OCTOBER_SALARY_AMENDED" — impersonating shared OneDrive documents. UNK_AcademicFlare, a suspected Russian state actor, engaged in extended rapport-building via benign emails before sending the phishing link, increasing the likelihood of compliance. Some campaigns deliver the code via QR code rather than a clickable link, bypassing URL-scanning controls in secure email gateways.

Phase 3: Attacker-Controlled Landing Page

The victim is directed to a page designed to look like an M365 login or document portal. This page prompts the victim for their email address and then presents them with the attacker's user_code, framed as a "secure authentication code" or "one-time verification token." The instructions direct the user to navigate to Microsoft's device login portal and enter it. From the victim's perspective, they are completing what looks like a standard MFA or re-authentication step. The page is hosted on attacker-controlled infrastructure but may leverage legitimate CDN services, Cloudflare Workers, or Azure-hosted URLs to pass link-reputation checks.

Phase 4: Victim Authenticates on Legitimate Microsoft Infrastructure

This is the key phase. The victim navigates to https://microsoft.com/devicelogin — a real, fully legitimate Microsoft domain with a valid certificate — enters the attacker's code, and then completes their normal authentication flow, including their MFA challenge. From the user's perspective, and from the perspective of any security control inspecting network traffic or browser activity, everything looks completely normal. There is no spoofed login page. There is no anomalous domain. The Microsoft sign-in UI is genuine.

"The attack requires the actor to own a domain name and register an SSL certificate to enhance the credibility of the phishing site. By registering an application in Azure and extracting a valid client ID, they can trigger OAuth-based phishing flows that present users with authentic system prompts requesting access to their Microsoft accounts." — Proofpoint Threat Research, December 2025

Phase 5: Token Theft and Persistent Access

The moment the victim completes authentication, Microsoft's identity platform issues a valid access token to the application identified by the client ID in the original request — the attacker's application. The attacker's polling loop detects the successful grant and captures both the access token and the refresh token. These tokens grant read/write/send access to the victim's email, calendar, and files across Outlook, Teams, OneDrive, and SharePoint, as well as any other scopes the attacker requested in Phase 1. The attacker now has persistent, authenticated access that survives password resets unless the administrator explicitly revokes refresh tokens in Entra ID.

# Attacker polls for the token after victim authenticates
POST https://login.microsoftonline.com/{tenant}/oauth2/v2.0/token
Content-Type: application/x-www-form-urlencoded

grant_type=urn:ietf:params:oauth:grant-type:device_code
&client_id={attacker_app_client_id}
&device_code={device_code_from_phase_1}

# On success, response contains:
# access_token   — immediate bearer token for Graph API calls
# refresh_token  — long-lived token for obtaining new access tokens
# expires_in     — access token lifetime in seconds

The Tooling: SquarePhish, Graphish, and the Industrialization of OAuth Abuse

The reason this technique surged in late 2025 is not because it was discovered — it was known and documented. The reason is tooling. Two specific tools resolved the key operational constraints that had previously limited device code phishing to targeted, high-skill operations.

SquarePhish and SquarePhish2

SquarePhish is a publicly available red-team tool, originally released for legitimate penetration testing, that automates the OAuth 2.0 device authorization grant workflow. It handles device code generation, QR code embedding, and polling — significantly reducing the operator skill required. SquarePhish2, a subsequent iteration, addressed the short code expiry window by automating rapid re-generation when codes expired before victims could respond, enabling campaigns to scale beyond the original 15-minute window constraint. The tool also incorporates QR codes to route victims, which helps evade URL-based scanning controls in secure email gateways.

Graphish

Graphish is a more capable kit that emerged on vetted criminal forums and represents a significant capability step up. According to Proofpoint researchers, it supports OAuth abuse via Azure App Registrations, adversary-in-the-middle attack flows, and reverse proxy configurations. It leverages legitimate Azure infrastructure to generate convincing phishing pages. Critically, it is designed to be accessible to low-skill operators — lowering the barrier to entry for financially motivated actors who would not otherwise have the identity protocol expertise to run this attack manually. It automates the attacker-side infrastructure that previously required bespoke development.

"The tool is designed to be user-friendly and does not require advanced technical expertise, lowering the barrier for entry and enabling even low-skilled threat actors to conduct sophisticated phishing campaigns." — Proofpoint Threat Research, December 2025

The combination of SquarePhish2 for the phishing delivery layer and Graphish for the infrastructure and token-handling layer means that an attacker with minimal identity protocol knowledge can now run campaigns that, until recently, were the exclusive domain of nation-state operators. Some campaigns also incorporate Tycoon, a Phishing-as-a-Service platform capable of proxying authentication pages and intercepting session tokens in real time, adding an adversary-in-the-middle layer on top of the device code flow.

Who Is Running These Campaigns

The breadth of threat actors now deploying this technique is one of the most significant aspects of the current surge. This is no longer a technique associated exclusively with sophisticated nation-state operations — it has been fully commoditized.

TA2723 (Financially Motivated)

TA2723 is a high-volume, financially motivated phishing actor previously best known for spoofing Microsoft OneDrive, LinkedIn, and DocuSign in credential harvesting campaigns. Beginning in October 2025, Proofpoint observed TA2723 pivoting to device code phishing, using salary and employment-themed lures. One wave used subject lines containing "OCTOBER_SALARY_AMENDED" and "Salary Bonus + Employer Benefits Reports 25," presenting recipients with what appeared to be shared payroll documents. The shift from credential harvesting to token theft is significant — it suggests that the criminal community has recognized that token-based access is more persistent and more valuable than raw credentials, which can be invalidated by a password change.

UNK_AcademicFlare (Russia-Aligned)

UNK_AcademicFlare is a suspected Russian state-aligned threat actor that Proofpoint began tracking as conducting device code phishing at scale from at least September 2025. The group's operational style is notably patient: it conducts extended rapport-building via benign, legitimate-seeming emails before introducing any malicious payload. It uses compromised email accounts from government and military organizations to send lures that appear to come from trusted sources. Target sectors include government agencies, think tanks, higher education, and transportation infrastructure across the United States and Europe. The group has also spoofed OneDrive links via Cloudflare Worker URLs and created fake conference registration sites to deliver device codes.

Storm-2372

Microsoft's own threat intelligence team has tracked activity under the Storm-2372 cluster that overlaps significantly with UNK_AcademicFlare's TTPs. This cluster is assessed as Russia-aligned and has targeted NGOs, government entities, and defense-adjacent organizations. The consistent use of device code phishing across these clusters suggests either shared tooling, shared tradecraft through underground forums, or both.

Why MFA Fails Here — and What That Actually Means

This is the part that requires the most precise thinking. MFA does not fail in the attack in any technical sense. The victim's MFA challenge is presented by Microsoft and completed against Microsoft's real infrastructure. The authentication succeeds. The MFA did exactly what it was designed to do — it verified that the person entering their credentials is the legitimate account owner. The problem is that MFA was designed to protect credential-based authentication flows, not token issuance flows where the token recipient is determined by the client ID in the request rather than by who is sitting at the keyboard.

Traditional phishing attempts to capture credentials and replay them — and MFA blocks that because the time-based OTP has expired or the push notification was not approved. Adversary-in-the-middle phishing (via tools like Evilginx) attempts to proxy the authentication in real time and steal the resulting session cookie — and MFA does not block that either, which is a known limitation. Device code phishing doesn't need to proxy anything or capture anything in transit. It simply waits for the legitimate authentication event to complete and receives the token that Microsoft issues as a result.

"Unlike traditional phishing, which relies on lookalike domains or email spoofing, this method operates entirely within Microsoft's ecosystem, bypassing security measures and user skepticism by leveraging native M365 infrastructure to deliver phishing lures that appear authentic." — KnowBe4 Threat Labs, February 2026

The conceptual shift this requires for defenders is significant. For more than a decade, the standard guidance has been "enable MFA and you are protected against phishing." That guidance was never entirely accurate — AiTM attacks have existed for years — but it was accurate enough to be useful for credential-based attacks, which remained the dominant form. Device code phishing, now weaponized at scale, represents a genuine shift in the attack surface. The question is no longer just "did the user authenticate?" but "who received the token that authentication produced?"

Detection: What the Forensics Look Like

Detection is genuinely difficult for this attack because so much of the activity is legitimate. The victim navigates to a real Microsoft domain. Microsoft issues a real token. The attacker's application appears in the tenant's OAuth consent log like any other application. However, there are several signals that, looked at together, indicate compromise.

Entra ID Sign-In Logs

Device code authentications appear in Entra ID (Azure AD) sign-in logs with an authentication method of "Device code flow." Under normal circumstances in most organizations, device code sign-ins are rare and typically associated with specific known use cases (shared kiosks, conference room devices, specific line-of-business apps). A sudden spike in device code sign-ins, or device code sign-ins from users who have no known device-constrained use case, should trigger investigation. Sign-in logs can be queried directly in the Entra portal or via the Microsoft Graph API.

# KQL query for Entra ID — hunting device code sign-in events in Sentinel
SigninLogs
| where AuthenticationProtocol == "deviceCode"
   or ClientAppUsed == "Device Code Flow"
| project TimeGenerated, UserPrincipalName, IPAddress,
          Location, AppDisplayName, ConditionalAccessStatus, RiskLevelDuringSignIn
| order by TimeGenerated desc

OAuth Application Consent Logs

When a victim completes the device code flow, the attacker's application receives consent and appears in the tenant's enterprise application list. Auditing recently consented OAuth applications — particularly those consented by non-administrative users and those requesting broad scopes like Mail.ReadWrite, Files.ReadWrite.All, or offline_access — will surface suspicious grants. The Microsoft 365 Admin Center under Azure Active Directory > Enterprise Applications > Activity > Sign-ins and Consent allows filtering by recent consent events.

# PowerShell — list recently consented OAuth apps with broad scopes
Connect-MgGraph -Scopes "Application.Read.All", "AuditLog.Read.All"

Get-MgServicePrincipal -All | Where-Object {
    $_.Tags -contains "WindowsAzureActiveDirectoryIntegratedApp"
} | Select-Object DisplayName, AppId, CreatedDateTime | 
Sort-Object CreatedDateTime -Descending | 
Select-Object -First 50

Anomalous Token Usage Patterns

After token theft, attacker activity against the Microsoft Graph API — reading email, downloading files, accessing calendar data — will appear in unified audit logs attributed to the legitimate user. Look for Graph API access from IP addresses or geographic locations inconsistent with the user's normal patterns, particularly if those accesses occur via application-based authentication rather than interactive sign-in. Microsoft Defender for Cloud Apps (formerly MCAS) can be configured to alert on anomalous OAuth application activity and unusual data access patterns.

# KQL — hunt for Graph API activity from newly consented apps in the last 7 days
# Correlates recent OAuth consent grants with subsequent API activity
let recentApps = MicrosoftGraphActivityLogs
    | where TimeGenerated > ago(7d)
    | where RequestMethod in ("GET", "POST", "PATCH")
    | where RequestUri has_any ("mail", "messages", "files", "driveItem", "calendars")
    | summarize FirstSeen=min(TimeGenerated), RequestCount=count() 
        by AppId, UserId = tostring(UserId), IPAddress = tostring(IPAddress)
    | where FirstSeen > ago(2d); // apps that appeared in last 48 hours
AuditLogs
| where TimeGenerated > ago(7d)
| where OperationName == "Consent to application"
| extend AppId = tostring(TargetResources[0].id)
| join kind=inner recentApps on AppId
| project ConsentTime=TimeGenerated, AppId, UserId, IPAddress, RequestCount
| order by ConsentTime desc

Defense: What Actually Works

The good news is that there are technically sound mitigations available. The bad news is that the most effective one — disabling the device code flow entirely — will break legitimate use cases for some organizations, and the others require discipline in implementation and monitoring.

Disable the Device Code Flow via Conditional Access Authentication Flows

For organizations that do not have a legitimate need for the device code flow, the cleanest mitigation is to block it at the Conditional Access policy level using the Authentication Flows condition, introduced in Entra ID in 2024. This eliminates the attack surface completely. The correct mechanism is a Conditional Access policy targeting the Device code flow authentication flow — not an authorization policy parameter, which has no such control. This can be configured in the Entra portal under Protection > Conditional Access > Authentication flows, or via the Microsoft Graph API.

# PowerShell — block device code flow tenant-wide via Conditional Access
# Requires Microsoft.Graph.Identity.SignIns module and a P1/P2 license

Connect-MgGraph -Scopes "Policy.Read.All", "Policy.ReadWrite.ConditionalAccess"

# Build the Conditional Access policy body
$policyBody = @{
    displayName     = "Block - Device Code Flow"
    state           = "enabled"
    conditions      = @{
        authenticationFlows = @{
            transferMethods = "deviceCodeFlow"
        }
        users = @{
            includeUsers = @("All")
        }
    }
    grantControls   = @{
        operator        = "OR"
        builtInControls = @("block")
    }
}

New-MgIdentityConditionalAccessPolicy -BodyParameter $policyBody

Note that Conditional Access Authentication Flows policies require an Entra ID P1 or P2 license. If the device code flow is needed for specific devices or scenarios, scope the blocking policy by user group or named location rather than applying it tenant-wide. A blanket block is the safest posture; a targeted exclusion for known legitimate use cases is preferable to leaving the flow open across the entire tenant.

Configure Token Lifetime Policies to Limit Persistence

By default, Microsoft issues refresh tokens with a sliding window lifetime of 90 days for confidential client apps and 24 hours for public clients, with a maximum lifetime of 365 days if continuously used. For organizations that cannot immediately block the device code flow, reducing the refresh token lifetime for OAuth apps limits how long a stolen token remains useful. Token Lifetime Policies are configured via the Microsoft Graph API and can be scoped to specific service principals.

# PowerShell — create a restrictive token lifetime policy and assign to a service principal
Connect-MgGraph -Scopes "Policy.ReadWrite.ApplicationConfiguration", "Application.ReadWrite.All"

# Create a policy with a short refresh token lifetime (e.g. 1 day)
$policyBody = @{
    definition = @(
        '{"TokenLifetimePolicy":{"Version":1,"MaxInactiveTime":"01:00:00","MaxAgeMultiFactor":"01:00:00","MaxAgeSingleFactor":"01:00:00"}}'
    )
    displayName = "Short-Lived Token Policy"
    isOrganizationDefault = $false
}

$policy = New-MgPolicyTokenLifetimePolicy -BodyParameter $policyBody

# Assign to a specific service principal (app object ID)
New-MgServicePrincipalTokenLifetimePolicyByRef `
    -ServicePrincipalId "" `
    -OdataId "https://graph.microsoft.com/v1.0/policies/tokenLifetimePolicies/$($policy.Id)"

Note that token lifetime policies cannot be applied to refresh tokens for interactive user sessions when Conditional Access is in use — in those cases, sign-in frequency policies in Conditional Access provide the equivalent control and should be used in parallel.

For organizations that may have already been hit, or as an ongoing hygiene practice, regularly audit consented OAuth applications. Revoke any application that cannot be attributed to a known, authorized use case. Pay particular attention to apps requesting offline_access (which grants refresh token issuance) combined with broad Mail, Files, or Directory scopes.

# PowerShell — revoke all tokens for a compromised user account
Connect-MgGraph -Scopes "User.ReadWrite.All"

# Revoke all refresh tokens for the user
Revoke-MgUserSignInSession -UserId "[email protected]"

# Also remove the specific OAuth grant
Get-MgUserOauth2PermissionGrant -UserId "[email protected]" |
    ForEach-Object {
        Remove-MgOauth2PermissionGrant -OAuth2PermissionGrantId $_.Id
    }

Restrict User Consent to Limit OAuth App Attack Surface

Device code phishing requires a victim to consent to the attacker's registered application. By default in many tenants, users can consent to apps requesting low-risk permissions without administrator approval. Tightening consent settings so that all OAuth application consent requires administrator review is one of the highest-leverage preventive controls for this attack class. This is configured in Entra ID under Enterprise Applications > Consent and permissions > User consent settings.

# PowerShell — require admin consent for all OAuth app requests
Connect-MgGraph -Scopes "Policy.ReadWrite.Authorization"

# Set consent policy to require admin approval for all apps
Update-MgPolicyAuthorizationPolicy -PermissionGrantPolicyIdsAssignedToDefaultUserRole @()

# Verify
Get-MgPolicyAuthorizationPolicy | 
    Select-Object -ExpandProperty PermissionGrantPolicyIdsAssignedToDefaultUserRole

Setting this to an empty array disables user consent entirely and routes all application consent requests through the admin consent workflow. This is the most restrictive posture. A balanced alternative is to allow user consent only for verified publisher apps requesting low-risk permissions, which is the ManagePermissionGrantsForSelf.microsoft-user-default-low built-in policy.

Conditional Access policies that evaluate sign-in risk using Microsoft Entra ID Protection can automatically block or challenge high-risk sign-in events, including anomalous device code authentications. Enabling the "Block legacy authentication" and "Require phishing-resistant MFA" policies in tandem adds defense-in-depth, though these do not specifically block device code flow on their own.

Deploy Microsoft Defender for Cloud Apps for OAuth Monitoring

Defender for Cloud Apps (MDCA) provides OAuth app governance capabilities that can flag applications requesting sensitive permissions, alert on anomalous API activity from newly consented apps, and enable administrators to mark specific OAuth apps as approved or banned across the tenant. The "App governance" add-on specifically focuses on OAuth application behavior and can detect unusual data access patterns post-compromise.

User Awareness — with Honest Expectations

Telling users to "never enter a code at microsoft.com/devicelogin unless you initiated the action yourself" is technically correct guidance. The problem is that this attack is specifically designed to create the impression that the user is the one initiating the action — the phishing lure presents the device code as a security verification step the user needs to take. Awareness training remains valuable, but it is a last line of defense here, not a primary control. The primary controls are technical: block or restrict the flow, monitor consent logs, and revoke tokens aggressively when compromise is suspected.

Key Takeaways

1. MFA does not prevent this attack. The victim's MFA challenge completes successfully on real Microsoft infrastructure. Token issuance is the attack surface, not authentication itself. Organizations that have treated MFA as a complete phishing defense need to revise that posture.
2. The device code flow is the specific technical lever. Blocking it via a Conditional Access Authentication Flows policy eliminates the attack surface for organizations that don't need it. Many enterprise tenants do not require it and can safely block it. Note that this requires an Entra ID P1 or P2 license — tenants without it should prioritize token monitoring and OAuth consent auditing as compensating controls.
3. Refresh tokens outlast password resets. A compromised user changing their password does not revoke an attacker's refresh token. Incident response for this attack must include explicit token revocation via Revoke-MgUserSignInSession and removal of the consented OAuth application.
4. The attack has been fully commoditized. SquarePhish2 and Graphish have put this capability in the hands of low-skill financially motivated actors, not just nation-state operators. The threat landscape for any M365 tenant is now broader than it was 12 months ago.
5. Detection requires looking at the right logs. Standard email security controls, MFA logs, and password audit logs will not surface this attack. OAuth consent logs and device code sign-in events in Entra ID are the relevant signals. If you are not monitoring these, you are likely not detecting active compromises.

The broader pattern here is one that security teams should expect to see continue. As FIDO2-based phishing-resistant MFA becomes more widely adopted and traditional credential phishing becomes less viable, attackers will increasingly pivot to abusing authentication flows rather than authentication credentials. Proofpoint's assessment states that abuse of OAuth authentication flows will continue to grow precisely in correlation with stronger MFA adoption — because the stronger the credential protection, the more valuable the token that gets issued after that credential protection is satisfied. The token is the target. Act accordingly.