Device code phishing turns Microsoft login flows into token theft

At a glance

What this is: This is an analysis of device code phishing and how attackers turn legitimate Microsoft login flows into token-based account takeover.

Why it matters: It matters because IAM, PAM, and NHI teams need correlated detection and containment logic, not isolated authentication checks, to stop persistence after compromise.

By the numbers:

• With Microsoft 365 now exceeding 450 million paid commercial seats, attackers have a massive incentive to target the authentication flows that keep employees connected across email, files, collaboration, and identity.

👉 Read Abnormal AI's analysis of device code phishing and token theft

Context

Device code phishing is a form of token theft that abuses a legitimate Microsoft login flow rather than breaking the login page itself. The user sees a real sign-in experience, enters a code, and completes MFA, while the attacker receives access and refresh tokens tied to the attacker's own session.

For identity teams, the governance problem is not whether authentication succeeded, but whether the resulting session can be trusted and revoked fast enough. In Microsoft 365 environments, that pushes detection and response beyond the login event and into session control, mailbox behavior, and account containment.

Key questions

Q: How should security teams handle device code phishing in Microsoft 365?

A: Treat device code phishing as token theft, not as a simple login anomaly. Restrict the flow where possible, monitor for suspicious sign-in patterns, and build containment steps that include session revocation and account disablement. Password reset alone is not enough if refresh tokens remain valid.

Q: Why do password resets sometimes fail to stop Microsoft 365 compromise?

A: Password resets can fail because the attacker may already hold valid refresh tokens. If those tokens are not explicitly revoked, the attacker can keep accessing mail, files, and identity-linked services even after the password changes. Containment has to address the session, not only the credential.

Q: What should teams look for after a suspicious Microsoft login?

A: Look for the behaviour that follows the login, not the login itself. Rogue MFA registration, mailbox rule creation, security settings access, and unusual post-compromise activity are stronger indicators that the account is actively controlled by an attacker.

Q: Who is accountable when token-based account takeover succeeds?

A: Accountability sits with the team responsible for authentication policy, token revocation, and incident containment across identity and email systems. If the programme cannot revoke sessions quickly, it has accepted a persistence risk that password management alone cannot solve.

Technical breakdown

How device code phishing binds a victim to an attacker session

Device code phishing starts when the attacker requests a Microsoft device login code and ties it to their own session. The victim is then lured to a real Microsoft login page, enters the code, and completes sign-in and MFA. Because the attack uses a legitimate flow, the authentication event can look normal in isolation. The key weakness is that the code, not the user, anchors the attacker session from the beginning, which turns successful authentication into token issuance for the wrong party.

Practical implication: inspect device-code authentication separately from ordinary sign-in success and treat the code origin as a control point.

Why refresh tokens outlive password reset

Once the attacker receives access and refresh tokens, the compromise can persist beyond a password reset if the tokens are not explicitly revoked. That is why password change alone is not a complete containment action in Microsoft 365. The attacker does not need repeated interactive logins if the refresh token remains valid, and follow-on actions such as mailbox rule creation or rogue MFA registration can extend access. In practice, the session becomes the durable asset, not the password.

Practical implication: make explicit token revocation and account disablement part of containment, not optional follow-up.

Correlating identity, email, and post-compromise signals

Device code phishing is difficult because each individual event can be explainable. A login may appear to come from a plausible location through VPN use, a Microsoft page may be genuine, and MFA may have been completed. The useful signal emerges only when defenders correlate sign-in behaviour with mailbox rules, security settings changes, and unusual post-login activity. This is a classic example of why identity telemetry alone is insufficient when the attacker is working through a legitimate authentication path.

Practical implication: build correlation rules across identity, email, and post-compromise activity rather than reviewing sign-ins as isolated events.

Threat narrative

Attacker objective: The attacker wants durable Microsoft 365 account access through refresh tokens and post-compromise persistence rather than a single stolen password.

1. Entry occurs when the attacker initiates a device login request and uses a phishing lure that sends the victim to a real Microsoft login page tied to the attacker's session.
2. Credential access follows when the victim enters the device code, completes sign-in and MFA, and the attacker receives access and refresh tokens that can survive a password reset.
3. Impact appears when the attacker uses persistent token-based access to create rogue MFA registration, mailbox rules, and continued account control until explicit revocation occurs.

Breaches seen in the wild

• Salesloft OAuth token breach — hackers stole OAuth tokens to access Salesforce data via Salesloft.
• Internet Archive breach — unsecured GitLab authentication tokens exposed 31M Internet Archive accounts.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Device code phishing is a session-trust failure, not a password failure. The attack works because defenders still over-weight authentication success as evidence of legitimacy. In reality, the victim can complete a genuine Microsoft login while the attacker captures the resulting session artefacts, which means the control problem has moved from password protection to session authenticity and revocation. Practitioners should treat successful sign-in as an input to correlation, not as proof of safety.

Refresh-token persistence creates an identity blast radius that outlives the original lure. Once tokens are issued, password resets can be operationally insufficient if explicit revocation does not occur. That is the structural reason attackers use device code phishing: they are not trying to win one login event, they are trying to buy time inside a durable trust window. Identity teams need to think in terms of session blast radius, because that is where the compromise actually persists.

Correlated detection is now the minimum viable control for token-based takeover. A single suspicious login rarely proves compromise when the flow looks legitimate, the network location can be normalised through VPNs, and MFA has been completed. The meaningful indicator is the cluster of follow-on behaviours such as rogue MFA registration, mailbox rule creation, and security-setting changes. This is where email security, identity telemetry, and response playbooks have to operate as one detection fabric.

Microsoft 365 scale makes authentication-flow abuse a governance issue, not just a phishing issue. With 450 million paid commercial seats, the incentive for attackers is to target the mechanisms that keep users continuously connected to work. That pressure shifts the control conversation toward session governance, account containment, and revocation readiness across human identity and adjacent machine-driven workflows that consume the same cloud trust fabric.

From our research:

• 91.6% of secrets remain valid five days after the targeted organisation is notified, showing a critical gap in remediation procedures, according to Ultimate Guide to NHIs.
• Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them.
• That remediation gap is why readers should also review NHI Lifecycle Management Guide for offboarding, rotation, and revocation discipline.

What this signals

Session trust is becoming the new perimeter for identity teams. When a legitimate authentication flow can be weaponised into token theft, the practical question is no longer whether a login succeeded, but whether the resulting session can be terminated fast enough to matter. Teams that still separate identity, email, and response operations will miss the post-login behaviours that actually prove compromise.

Token persistence turns lifecycle governance into an incident-response requirement. The same offboarding and revocation discipline that applies to non-human identities now matters for human sessions that can survive credential changes. Identity programmes should align containment playbooks with NHI Lifecycle Management Guide principles and the NIST Cybersecurity Framework 2.0 response function.

Credential theft campaigns increasingly exploit legitimacy, not just weakness. Device code phishing shows why 450 million paid commercial seats also mean a much larger trust surface, and why detection must be behavioural rather than purely authentication-based. That same logic should shape review of OWASP Non-Human Identity Top 10 controls for token exposure and revocation gaps.

For practitioners

• Block device code flows where they are not required Restrict device code authentication to approved use cases and high-friction exception paths. If your environment does not need it, remove it from the default access path so attackers cannot rely on a legitimate Microsoft login flow for token theft.
• Treat token revocation as a first-class containment step When compromise is suspected, revoke refresh tokens and disable the account rather than relying on password reset alone. In Microsoft 365, explicit account disablement is critical because session artefacts can survive credential changes.
• Correlate identity and mailbox behaviour during triage Investigate suspicious sign-ins alongside mailbox rule creation, MFA method changes, security settings access, and related post-login activity. A login event without follow-on context is not enough to confirm or dismiss compromise.
• Use conditional access to narrow token abuse paths Require stronger policy checks for device code usage, unusual geolocation, and newly registered authentication methods. The goal is to force attacker behaviour into a smaller set of detectable conditions before persistence is established.

Key takeaways

• Device code phishing succeeds because it converts a legitimate login flow into durable session access, which makes authentication success a poor proxy for trust.
• The impact is amplified by refresh tokens, because password resets do not reliably end compromise unless sessions are explicitly revoked.
• Identity, email, and post-compromise telemetry must be correlated together, or the attacker’s behaviour will look like a series of ordinary events.

Key terms

• Device Code Phishing: A phishing technique that abuses a legitimate device login flow to obtain access and refresh tokens for the attacker’s session. The victim completes a real sign-in, but the session is anchored to attacker-controlled authentication, which makes the compromise harder to detect through login events alone.
• Refresh Token: A long-lived credential that allows a session to obtain new access tokens without repeated interactive sign-in. In compromise scenarios, refresh tokens matter because they can preserve access after a password change unless they are explicitly revoked or the account is disabled.
• Session Revocation: The act of invalidating active authentication sessions and their token chain so an attacker can no longer use previously issued credentials. It is a containment control, not just an administrative cleanup step, and it often determines whether a compromise truly ends.
• Account Containment: A response state in which the affected identity is isolated, its sessions are terminated, and its access paths are reduced until the organisation can validate and remediate the compromise. For cloud identity, containment usually combines disablement, token revocation, and behavioural review.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.

This post draws on content published by Abnormal AI: device code phishing and token theft through the VENOM attack flow. Read the original.