AI-powered device-code phishing is industrialising OAuth token theft

At a glance

What this is: This is a defensive analysis of how device-code phishing and AI-powered Phishing-as-a-Service kits industrialise OAuth token theft and post-compromise mailbox abuse.

Why it matters: It matters because IAM and NHI teams have to govern token grants, consent flows, and delegated app access as first-class identity risks, not just passwords and MFA.

By the numbers:

• When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes, and as quickly as 9 minutes in some cases.

👉 Read SlashID's analysis of AI-powered device-code phishing and OAuth token theft

Context

Device-code phishing turns the OAuth device authorization flow into a token theft path. The user signs in on a real Microsoft page, often with MFA, but the attacker receives the resulting access and refresh tokens and can keep acting as the delegated identity.

That matters for identity programmes because the control point is no longer just authentication. Consent, token issuance, app grants, inbox rules, and post-grant activity all become part of the identity attack surface, which is why OAuth abuse has to be managed alongside NHI governance and identity lifecycle controls.

Key questions

Q: How should security teams handle OAuth token theft in phishing campaigns?

A: Security teams should treat OAuth token theft as account compromise, not just phishing. Focus on revocation, token lifetime, delegated scope review, and anomalous token use across mail and SaaS. Password resets alone will not stop a bearer token that remains valid until it is explicitly revoked.

Q: Why do device code phishing attacks bypass many standard phishing controls?

A: They use the real Microsoft login page, so there is no fake domain, no malicious payload, and no obvious infrastructure to block. The victim completes MFA willingly, which makes the sign-in look legitimate to many tools. Detection has to move to token issuance, unusual device-code use, and post-authentication behaviour instead of URL reputation alone.

Q: What do teams get wrong about OAuth consent for agents?

A: They assume consent to access a service is the same as consent to perform a specific action. In practice, OAuth proves capability, not intent. For agents, a send permission should still be followed by a separate approval step whenever the action can disclose sensitive content or create irreversible change.

Q: Who is accountable when a stolen token is reused for business email compromise?

A: Accountability usually spans identity, email security, and SaaS owners because the compromise sits at the boundary between authentication and delegated access. Organisations should assign explicit ownership for token revocation, consent monitoring, and session invalidation so a valid token cannot become an indefinite trust grant.

Technical breakdown

OAuth device-code phishing turns user approval into token theft

The Device Authorization Grant was designed for constrained devices, not adversarial consent flows. In the attack chain described here, the victim enters a user code on a legitimate Microsoft page, the backend polls until authorization completes, and the attacker receives valid tokens without ever handling the user’s password. That means the attacker is not bypassing the identity provider, but abusing its legitimate delegation mechanics. Once the refresh token is captured, access can extend beyond the original session and into downstream resources that trust the token chain.

Practical implication: treat device-code grant paths as high-risk identity flows and review whether they should be allowed at all in your environment.

AI changes the economics of phishing-as-a-service

The important change is not just that the kit steals tokens, but that generative AI compresses the work around the theft. The article shows AI being used to tailor lures, triage stolen mailboxes, rank financially valuable conversations, and draft business email compromise messages that match a victim’s tone. That shifts phishing from a one-shot credential capture problem into a repeatable service pipeline with reconnaissance, exploitation, and monetisation built in. The operational result is more convincing lures and faster post-compromise abuse with less attacker labour.

Practical implication: detection and response need to look for the full abuse workflow, not only the initial lure or token exchange.

Post-grant mailbox abuse is the real payload

Once the attacker has a valid token, the compromise quickly moves into Microsoft Graph activity such as inbox rules, contacts, sent items, manager data, direct reports, and message history. That fan-out gives the attacker enough context to identify payment threads, impersonate trusted senders, and write credible BEC follow-up messages. In other words, the mailbox is not just a target. It becomes the source of intelligence for the next stage of fraud, and that stage is often what produces the business loss.

Practical implication: monitor for high-volume Graph reads, suspicious inbox rules, and unusual token-backed mail access immediately after first token use.

Threat narrative

Attacker objective: The attacker wants durable delegated access to mail and adjacent Microsoft 365 resources so they can reconnoitre conversations, impersonate the victim, and execute business email compromise.

1. Entry occurs when the victim is lured into entering a device code or approving a delegated OAuth grant on a legitimate Microsoft flow.
2. Escalation happens when the attacker receives access and refresh tokens, then uses them to fan out across mailbox and Graph resources with the victim's delegated authority.
3. Impact is achieved through mailbox reconnaissance, inbox-rule persistence, and AI-drafted business email compromise that turns delegated access into financial fraud.

Breaches seen in the wild

• Salesloft OAuth token breach — hackers stole OAuth tokens to access Salesforce data via Salesloft.
• CoPhish OAuth Token Theft via Copilot Studio — CoPhish campaign exploits Microsoft Copilot Studio agents to steal OAuth tokens via AI-assisted phishing.

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 not a weaker form of login abuse, it is a delegated-access abuse pattern. The attacker never needs to defeat the primary authentication ceremony if the victim can be induced to authorise the attacker’s waiting device. That changes the security question from password strength to delegated authority, consent scope, and token lifecycle. Practitioners should therefore treat OAuth grants as identity assets, not just application settings.

AI-powered PhaaS creates a mailbox-to-fraud pipeline, not just a phishing kit. The article shows the kit using large language models to sort mail, find payment exposure, and draft follow-on BEC messages. That matters because the value of the compromise is no longer limited to the initial token capture. It includes automated intelligence extraction from the mailbox itself, which means detection has to cover post-authentication abuse as well as the lure.

Standing trust in refresh tokens is the governance assumption this attack exploits. Refresh tokens were designed for continuity across sessions, but this chain uses that continuity to outlive the original user interaction and extend access into other Microsoft services. The implication is that token persistence has become an identity control problem, not merely an authentication convenience.

Ephemeral session thinking is too narrow for OAuth abuse. Teams often focus on MFA completion as the finish line, but in this pattern MFA is just the point where the attacker receives usable delegated access. The real governance boundary is the grant, the scope, and the downstream token fan-out. Practitioners should reframe identity risk around what the token can do after the user has finished signing in.

Mailbox reconnaissance is the new precursor to fraud, and it is visible if you look for it. The article’s recon burst across contacts, managers, direct reports, sent items, and message rules is a strong behavioural signal. That sequence is structurally different from normal user behaviour and gives defenders a useful detection opportunity. Teams should build detections around abnormal Graph fan-out, not only malicious URLs or suspicious domains.

From our research:

• Only 1.5 out of 10 organisations are highly confident in their ability to secure NHIs, compared to nearly 1 in 4 for securing human identities, according to The State of Non-Human Identity Security.
• Lack of credential rotation is cited as the top cause of NHI-related attacks by 45% of organisations, followed by inadequate monitoring and logging at 37%, according to the same study.
• For a broader breach pattern view, see The 52 NHI breaches Report for recurring identity abuse patterns across real incidents.

What this signals

Token governance is now part of identity governance. As OAuth abuse moves from manual phishing to productised device-code kits, the control plane has shifted from password resets to consent policy, token revocation, and behavioural monitoring. Teams that still treat these as app-owner issues will miss the sequence that matters: grant, fan-out, persistence, and fraud.

The named concept here is delegated access drift: the point at which a legitimate token starts being used for purposes that no longer match the original user intent. In practice, that drift is visible in mailbox reconnaissance, inbox-rule creation, and message-hijack activity. Identity teams should be preparing detection content for that post-grant behaviour rather than waiting for a user to report a suspicious login.

For practitioners

• Restrict device-code and user-consent flows Disable end-user consent where possible, and block or tightly scope device-code grant paths for environments that do not need them. If business requirements demand exceptions, route them through explicit approval and logging so delegated access cannot be created casually.
• Monitor token-backed Graph fan-out Alert on bursts of reads across /contacts, /manager, /directReports, /mailFolders/sentitems, and message rules shortly after first token use. That sequence is a better indicator of compromise than a simple login event because it shows what the token is being used to learn.
• Treat suspicious refresh tokens as live access Revoke the service principal grant, refresh tokens, and active sessions when token theft is suspected, then verify that inbox rules and device registrations have not been used to re-establish persistence. Password resets alone do not address delegated OAuth abuse.
• Separate consent risk from authentication risk Build policy around the grant itself. Review which apps can request high-risk scopes, which users can self-authorise, and which identities are allowed to approve access to mail or directory data without admin review.

Key takeaways

• Device-code phishing works because it abuses legitimate delegation, not because it defeats MFA.
• The scale problem is now operational as well as technical, with AI reducing the effort needed to turn stolen tokens into financial fraud.
• Practitioners should govern consent, token lifecycle, and post-grant behaviour as a single identity risk chain.

Key terms

• Device code phishing: An identity attack that abuses the device authorization flow by tricking a user into entering a code on a legitimate login page while the attacker completes the flow elsewhere. It is effective because it relies on a real authentication protocol and can bypass password theft and familiar MFA prompts.
• Delegated access drift: The point at which a valid token or OAuth grant begins being used in ways that no longer match the original user intent. In practice, this shows up as mailbox reconnaissance, inbox-rule changes, or data access that follows the sign-in event but does not fit normal user behaviour.
• Phishing-as-a-service: A criminal service model that packages phishing infrastructure, templates, delivery tools, and sometimes evasion features for reuse by multiple attackers. It lowers the skill threshold for advanced campaigns and makes targeted identity abuse more repeatable across victims and sectors.

What's in the full report

SlashID's full research covers the operational detail this post intentionally leaves for the source:

• The full token-capture and polling sequence used by device-code phishing kits, including where the attacker waits for approval
• The AI mailbox-analysis pipeline that ranks payment risk and drafts business email compromise messages
• The defensive control mapping for Entra consent settings, token revocation, and post-grant detection
• The reconstruction details that show how the kit behaves in a sandboxed test tenant

👉 SlashID's full post covers the EvilTokens chain, Kali365 comparison, and detection guidance in more detail.

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 building or maturing an IAM or identity security programme, it is worth exploring.