TL;DR: Device-code phishing kits now package OAuth token theft, mailbox reconnaissance, and AI-generated BEC drafting into Phishing-as-a-Service, with EvilTokens and Kali365 showing how attackers can scale token abuse without handling passwords or fake login pages, according to SlashID. The key failure is that access review and password-centric controls assume the real risk sits at sign-in, when the compromise actually begins at token grant and persists after the session ends.
NHIMG editorial — based on content published by SlashID: LLMjacking and AI-powered device-code phishing research
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.
Questions worth separating out
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.
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.
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.
Practitioner guidance
- 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.
- 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.
- 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.
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
👉 Read SlashID's analysis of AI-powered device-code phishing and OAuth token theft →
Device-code phishing kits and OAuth tokens: are your controls keeping up?
Explore further
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: AI-powered device-code phishing is industrialising OAuth token theft