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

At a glance

What this is: This is a defensive analysis of AI-powered device-code phishing kits that industrialise OAuth token theft, showing how EvilTokens and Kali365 automate lure creation, token capture, mailbox reconnaissance and BEC drafting.

Why it matters: It matters because OAuth grants, token issuance and post-grant behaviour now need to be governed as identity-layer attack surfaces, not just monitored as authentication events.

Context

Device-code phishing abuses the OAuth 2.0 device authorization flow, where a user signs in on one device to approve access for another. In this attack pattern, the victim completes a real Microsoft login and MFA prompt, but the attacker receives the resulting access and refresh tokens.

This article argues that the control problem is no longer just phishing detection. For NHI governance, the relevant question is how to monitor consent, device-code grants, token fan-out and persistence after the grant, because those are the stages where access becomes durable and abuse becomes operational.

The article uses two kits, EvilTokens and Kali365, to show that OAuth abuse has become productised. The practical issue for identity teams is that the attacker never needs the password or a fake login page once the token lifecycle is the real target.

Key questions

Q: What breaks when device-code phishing is allowed in a Microsoft tenant?

A: The control break is that a legitimate user login can still produce attacker-owned tokens. If device-code flow is broadly available, the phishing path bypasses password theft entirely and turns the approval step into the compromise point. Security teams should treat unrestricted device-code use as a governance exception, not a normal sign-in pattern.

Q: Why do OAuth tokens bypass MFA in real attacks?

A: OAuth tokens bypass MFA because the attacker reuses a valid authorization artifact after it has already been issued. Once the token exists, the identity provider may see the request as legitimate, so MFA is no longer part of the transaction.

Q: What are the signs that an OAuth phishing campaign has moved past the grant stage?

A: The clearest signs are rapid mailbox and Graph fan-out, especially reads of contacts, manager data, direct reports, sent items and inbox rules shortly after token issuance. That pattern shows the kit has shifted from capture to reconnaissance and persistence, which is the point where the incident becomes materially broader.

Q: How should teams respond when a device-code grant looks suspicious?

A: Contain the identity, revoke the grant, invalidate refresh tokens, kill active sessions and inspect for inbox rules or device-registration persistence before the attacker completes follow-on actions. If the tenant allows it, disable the affected app registration path as well. The response needs to be identity-led because the compromise lives in the token chain.

Technical breakdown

How device-code phishing turns a real login into attacker tokens

The Device Authorization Grant was designed for constrained devices, but attackers exploit the split between code display and user authentication. The victim signs in through the real Microsoft device-login flow and approves a code that the attacker is polling for, so the resulting access and refresh tokens are valid, legitimate tokens issued by the identity provider. The crucial point is that MFA does not stop this abuse because the attacker is not bypassing authentication, only redirecting the grant outcome.

Practical implication: treat device-code flow as a governed OAuth path, not just a user-experience convenience.

Why AI makes OAuth abuse scalable instead of merely faster

The new kits automate both sides of the phishing chain. Large language models write role-specific lures, summarise stolen mailbox contents, rank valuable threads and draft follow-on business email compromise messages in the victim's style. That changes the attacker economics: the hard work shifts from manual judgement to orchestration, while the human attacker supervises a repeatable workflow that can be rented as a service.

Practical implication: monitor for high-volume token use plus automated mailbox reconnaissance, not just suspicious messages.

Why token theft outlives password-centric response

OAuth access and refresh tokens are not passwords, and revoking a password does not necessarily invalidate the attacker's session path. Once a kit turns the grant into tokens, it can pivot into mailbox access, Graph queries, inbox-rule manipulation and even long-lived persistence mechanisms such as primary refresh token use. That is why password reset is a weak containment step when the breach path is token-based rather than credential-based.

Practical implication: build revocation and session-kill playbooks around grants, tokens and service principals, not passwords alone.

Threat narrative

Attacker objective: The attacker wants durable OAuth-backed access that can be monetised through mailbox reconnaissance, token persistence and business email compromise.

1. Entry occurs when the victim is lured into completing a real device-code or consent flow on Microsoft infrastructure, which hands the attacker a legitimate token grant.
2. Credential harvesting happens when the kit exchanges that grant for access and refresh tokens, then expands them into mailbox and Graph access.
3. Escalation follows when the kit fans out across mail, contacts, sent items, manager data and inbox rules to identify valuable conversations and persistence options.
4. Impact is achieved when the attacker uses the harvested tokens to support mailbox reconnaissance, business email compromise drafting and durable access that survives the initial phishing interaction.

Breaches seen in the wild

• CoPhish OAuth phishing via Copilot Studio: Datadog showed Copilot Studio agents on a Microsoft domain can front OAuth consent phishing and forward stolen tokens; no victims reported.
• Cyberhaven Chrome extension breach 2024: A phished OAuth consent gave attackers Chrome Web Store publishing rights and a malicious Cyberhaven extension update reached about 400,000 users.

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 login attack, it is a grant attack: The defensive error is to anchor controls at the sign-in screen when the real abuse begins after the user completes a legitimate approval step. That makes consent, token issuance and post-grant behaviour the identity security boundary that matters. Practitioners should therefore model OAuth grants as first-class attack surfaces, not secondary artefacts.

Ephemeral user interaction does not equal low risk: These kits collapse the distance between lure, approval and exploitation into one automated sequence. The result is a shorter attacker dwell time but a larger governance blind spot, because the useful evidence appears in token fan-out, Graph activity and inbox-rule creation rather than in password events. Identity programmes need to observe that sequence as a single chain.

Prompt engineering has become an offensive identity control plane: The article shows AI doing two jobs that previously constrained campaign scale, persuasive lure writing and post-compromise mailbox triage. That means the attacker no longer needs deep language skill or manual reconnaissance to abuse delegated access. The practitioner conclusion is that identity telemetry must be able to flag machine-paced abuse even when the user interaction was human and legitimate.

Token lifecycle governance is now a containment discipline: Refresh tokens, access tokens and persistence pivots can outlast the moment of initial compromise and survive routine password-centric remediation. This is why revocation, grant review and session termination sit at the centre of modern OAuth defence. The control question is no longer whether a user signed in, but whether the resulting grant should still exist.

Identity blast radius is the right concept for this threat: Once a stolen token can reach Graph, mail, files and inbox rules, the real security unit is not the account but the scope of delegated access. The more broadly a grant can move through the environment, the faster a phishing kit turns one approval into multi-service exposure. Practitioners should treat excessive OAuth scope as a blast-radius problem.

From our research library:

• Security researchers tracked consent phishing campaigns affecting 900 tenants and 3,000 user accounts in 2025.

What this signals

Identity teams need to move their detection boundary from sign-in to post-grant behaviour: The real signal in this attack class is not whether a user passed MFA, but whether a newly issued token immediately begins reading mail, contacts and directory data in bulk. That is where delegated access becomes operational abuse.

Token trust debt is now a governance problem: Once access and refresh tokens are issued, the environment has accumulated security debt that password resets do not repay. The faster kits can turn that debt into mailbox reconnaissance and inbox-rule persistence, the more important grant review becomes as a standing control.

Device-code phishing compresses user trust, OAuth scope and attacker automation into one path: That means a human approval step can still feed a machine-paced abuse chain. Practitioners should expect more incidents where the authentication looks clean while the identity telemetry shows abuse only after the grant.

For practitioners

• Block high-risk device-code flows Disable device-code grant use by default and allow it only for tightly justified devices and workflows. Where business use is required, pair it with explicit approvals and strong conditional access so a user code cannot be abused as a general-purpose phishing path.
• Review OAuth consent and app registration posture Set user consent to the most restrictive workable state, limit which scopes can be granted without admin review, and inventory app registrations that could be abused to receive delegated access. The goal is to remove easy paths from lure to usable token.
• Detect post-grant recon bursts Alert when a fresh token immediately triggers parallel reads of mail folders, contacts, manager data, direct reports or sent items. That burst pattern is a stronger signal than the phishing page itself because it reflects automated post-compromise reconnaissance.
• Revoke grants, tokens and sessions together Use a containment playbook that removes the service principal grant, revokes refresh tokens, kills active sessions and checks for inbox rules or device-registration persistence. Password reset alone is not sufficient once token issuance has already happened.
• Harden mailbox abuse monitoring Watch for new inbox rules, unusual mail send activity and sudden changes in token-derived access to Outlook and Graph. Those are the behaviours that turn an OAuth compromise into business email compromise and should be triaged as identity incidents.

Key takeaways

• AI-powered phishing kits have turned OAuth token theft into a rentable, automated service that starts with a real Microsoft sign-in and ends with attacker-held tokens.
• The strongest evidence of compromise is no longer the lure itself but the post-grant pattern, especially mailbox reconnaissance and rapid Graph fan-out.
• The control that matters most is identity-led revocation of grants, tokens and sessions, because password resets do not reliably stop token-based abuse.

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.
• Authentication Token Theft: Authentication token theft is the unauthorized capture and use of a credential that proves a user, service, or agent has already authenticated. Technically, it includes stealing session cookies, bearer tokens, refresh tokens, or API tokens, then replaying them to bypass login controls and impersonate the original identity until the token expires or is revoked.
• Grant review: The governance practice of examining which applications and devices have been approved to receive delegated access, and whether those approvals still make sense. For OAuth environments, this is often more important than reviewing passwords because the grant itself is the durable security object.
• Mailbox reconnaissance: The post-compromise reading and sorting of email, contacts and directory context to identify financial conversations, trusted relationships and fraud opportunities. In OAuth abuse cases, mailbox reconnaissance often follows token issuance and is a strong indicator that the compromise has become operational.

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 programme, it is worth exploring.