Topic starter
22/07/2026 4:37 pm
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.
Editorial analysis by NHI Mgmt Group, based on content published by SlashID: “The Illicit Consent Grant Part 2: Device-Code Phishing and the AI PhaaS Wave”.
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.
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.
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.
Practitioner guidance
- Block high-risk device-code flows Disable device-code grant use by default and allow it only for tightly justified devices and workflows.
- 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.
- 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.
Bottom line: 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.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
This topic was modified 5 days ago by NHI Mgmt Group
22/07/2026 4:43 pm
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.
A few things that frame the scale:
- Security researchers tracked consent phishing campaigns affecting 900 tenants and 3,000 user accounts in 2025.
A question worth separating out:
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.
👉 Read our full editorial: AI-powered device-code phishing is industrialising OAuth token theft
This post was modified 5 days ago by NHI Mgmt Group