The Illicit Consent Grant Part 2: Device-Code Phishing and the AI PhaaS Wave

Summary

This post follows on from Part 1: Understanding Modern OAuth Consent Phishing. Part 1 showed the attack done by hand. This part shows how its close cousin — device-code phishing — works, and how that same attack is now sold as a ready-made kit, with AI doing most of the work. This research also includes a reconstruction of an AI PhaaS to help defenders understand what they’re up against.

Part 1 explained illicit consent as a manual OAuth abuse chain: the attacker registers an app, requests high-value scopes, sends a lure to the real /authorize endpoint, and waits for the victim to click Accept. The victim authenticates through the real Microsoft flow, including MFA, but access is delegated to the attacker’s application. That same flow is now being industrialized.

In 2026, Phishing-as-a-Service kits began packaging OAuth and device-code token theft into ready-made products. Instead of manually building each campaign, attackers can rent kits that generate lures, capture consent or device-code tokens, perform mailbox reconnaissance, and even draft follow-on BEC fraud using AI.

The same OAuth abuse Part 1 described by hand is now run start to finish by software. Large language models fill the two jobs that used to need a skilled person: writing convincing lures, and reading a stolen mailbox to decide what is worth stealing.

This report focuses on two examples: EvilTokens, a device-code phishing kit with an LLM pipeline for mailbox analysis and BEC drafting, and Kali365, the kit the FBI warned about in May 2026. We analyze EvilTokens through the same three phases from Part 1 — lure, consent prompt, grant — compare it with Kali365, and close with detection and mitigation guidance mapped to the SlashID identity layer.

Scope and intent. This is defensive research. The test build in the “AI PhaaS reconstruction” section is a safe, sandboxed tool we ran only against our own test tenant, to study these kits. We do not include any phishing pages, lure templates, working attack code, or attacker prompt text that someone could reuse.

A technical deep-dive into AI-powered PhaaS

Phishing-as-a-Service is not new. Kits like Tycoon 2FA, Sneaky 2FA, and the broader Adversary-in-the-Middle (AiTM) family have sold credential-and-cookie theft for years, reverse-proxying the real login page to capture session cookies after MFA. Two things changed in 2026.

1. Technique: from cookie theft to token theft. The newest kits drop the fake login page and instead abuse OAuth by either consent phishing (Part 1) or its close relative, device-code phishing. Both end with the attacker holding Entra-issued access and refresh tokens instead of a copied cookie. Tokens are harder to cancel and keep working even after a password reset.
2. Capability: from delivery to full lifecycle. Earlier kits stopped at capture. The damaging 2026 variants integrate generative AI on both ends — from manufacturing personalized lures before the click, to sorting through the mailbox and writing the scam after it.

EvilTokens

EvilTokens is a ready-made Microsoft device-code phishing kit sold as PhaaS. The pricing is plain: an Office 365 capture link for a one-time $1,500, plus $500 a month for the live backend key. For that, a buyer gets a control panel, token-harvesting automation, a built-in fake-Outlook webmail client that runs straight off stolen tokens, and the part that matters most — an AI pipeline that turns a raw mailbox into a ranked list of scam targets, identifying valuable conversations and preparing follow-up scams faster.

Figure 1: EvilTokens pricing, advertised through its Telegram channel and shop.

The device-code flow

Part 1’s attack abused the /authorize consent screen. Device-code phishing abuses a different but related OAuth 2.0 method — the Device Authorization Grant, built for devices that are hard to type on, like smart TVs and printers. The method lets one device ask for access while the user signs in on a second device. That split is the whole weakness.

Figure 2: the device-code flow. Credit: Microsoft Security research.

The victim does a real, MFA-backed login on real Microsoft pages. They are not handing over a password or a cookie — instead they are approving the attacker’s waiting device.

The phishing site in EvilTokens is where the threat actor displays the device code to the victim (step 3) — the fake page that tricks the victim into thinking they need to verify something. Illicit consent (Part 1) doesn’t need a phishing site because the victim goes directly to Microsoft’s real consent screen without any intermediary page.

Figure 3: EvilTokens phishing lures. Credit: Sekoia.

EvilTokens PhaaS impersonates Adobe Acrobat Sign and Viewer, DocuSign, email quarantine notices, calendar invites, SharePoint, and OneDrive, with the intent of giving the victim a believable reason to enter the device code. The device-code steps are not where EvilTokens is clever. The clever part is everything built around them.

The three steps

Step 1 — The lure (now built by AI). Where Part 1’s attacker wrote an email by hand pointing at /authorize, an EvilTokens buyer picks from ready-made templates that pretend to be Adobe Acrobat Sign, DocuSign, SharePoint, OneDrive, voicemail, e-fax, payroll, and calendar invites. The phishing page is served from trusted cloud hosts such as Cloudflare Workers, Vercel, and AWS Lambda, and often backed by Railway.com servers, so the traffic blends in with normal business cloud use. AI tailors the lure to the person’s job (finance, HR, logistics, accounts payable), which Microsoft points to as a direct reason the campaign worked so well.

Step 2 — The prompt (device login, not consent). In Part 1 the victim reached the real Entra consent screen. Here they reach the real microsoft.com/devicelogin page, type in the code, and sign in as normal. The moment they confirm, the attacker’s backend (which has been checking over and over) flips from authorization_pending to a real token. Behind the scenes, the phishing page polls the attacker’s /state endpoint every 3–5 seconds with a secret session ID, asking whether the victim has signed in yet, while the attacker’s backend separately polls Microsoft’s token endpoint. Both return pending until the victim finishes the MFA-backed login, at which point Microsoft issues a live access token to the attacker, and the victim is redirected to a harmless placeholder page so nothing looks off.

Step 3 — The grant (and what runs after). Part 1 ended at the grant: the attacker holds what they need to exchange the authorization code for access and refresh tokens. EvilTokens treats the grant as the start of an automatic chain. The backend right away trades the stolen refresh token for tokens to other services (Outlook, Graph, Azure, Substrate, SharePoint) and turns it into a Primary Refresh Token (PRT) for long-term use. Then the AI pipeline runs.

The AI pipeline

This is the part worth slowing down on, because it is the clearest known case of an AI doing the analyst’s job in a scam, not just the writer’s. The pipeline has a fact-gathering/recon step that feeds two AI steps, plus a third model used as a simple translator.

Step 0 — Graph fact-gathering (no AI). The backend executes eight parallel Microsoft Graph API calls to perform reconnaissance and gather information in the mailbox, so that when AI is used later it has a summary of exploitable financial exposure to work from.

async def parallel_recon(token_mgr: TokenManager) -> Dict[str, Any]:
    """Run all reconnaissance calls in parallel."""
    endpoints = {
        "inbox_rules": "/me/mailFolders/inbox/messageRules",
        "contacts": "/me/contacts",
        "events": "/me/events",
        "sent_items": "/me/mailFolders/sentitems/messages?$top=50&$orderby=receivedDateTime desc",
        "mail_folders": "/me/mailFolders",
        "manager": "/me/manager",
        "direct_reports": "/me/directReports",
        "organization": "/organization",
    }

Figure 4: the Graph API calls used in Step 0 — the same fan-out that becomes a detection signal for defenders.

Steps 1 & 2 — the two AI models. Both run on Meta’s Llama models through the Groq API (likely chosen for Groq’s very fast responses on the high-volume reading job). A separate OpenAI model handles translation.

The two analysis prompts each open with a jailbreak framing — the model as an “authorized red team security analyst” running a “sanctioned penetration test” — then instruct it to extract only operationally useful detail like real amounts, real names, real thread context, and to rank findings by financial impact. The AI is instructed to impersonate the victim’s voice by first learning their writing pattern from real sent emails, then composing BEC messages that match their natural greeting, sentence rhythm, tone, and signature block.

Kali365 vs EvilTokens

EvilTokens was not the only one. On 21 May 2026 the FBI put out a public warning about Kali365, a PhaaS platform first seen in April 2026 and, like EvilTokens, sold mostly through Telegram. The fact that Kali365 received a dedicated FBI warning shows how quickly device-code phishing had moved from a niche technique into a productized threat. Reports put Kali365’s price around $250 a month or $2,000 a year.

The FBI’s four steps for Kali365 — lure, authorization, token theft, and persistence — are, step for step, the EvilTokens chain. Both abuse the same OAuth 2.0 device-code method, both copy the same cloud-app brands, both grab access and refresh tokens to get past MFA without touching passwords, and both lean on AI-made lures and buyer dashboards. They are best seen as two products in the same young market, not as two different tricks.

AI PhaaS reconstruction

To understand the mechanics of AI-powered PhaaS platforms, we built a working prototype that recreates the core attack chain — from OSINT reconnaissance to AI-generated phishing emails, token capture, mailbox analysis, and automated BEC drafting. The only difference is that our reconstruction uses the standard OAuth consent-phishing model (Part 1), not the device-code flow of EvilTokens or Kali365.

Attack chain

1. OSINT — given a company name, the tool discovers email addresses (Hunter.io), fetches recent news (Google RSS), and uses an LLM to rank high-value targets by role.
2. AI-generated personalized phishing emails — for each target, an LLM writes a personalized email that references real company news, creates urgency, and embeds a shortened malicious OAuth link.
3. Token capture — a listener captures the authorization code from the victim’s redirect, exchanges it for access + refresh tokens (using the client secret), and saves them.
4. Post-compromise mailbox analysis — using the access token, the tool fetches recent emails and groups them into conversation threads. A llama-4-scout-17b-16e-instruct model analyses each thread, extracts financial entities (amounts, account numbers, invoice IDs), assigns a vulnerability score (0–100), and ranks high-risk threads for BEC targeting.
5. BEC email crafting & sending — a llama-3.3-70b-versatile model generates a convincing BEC email that matches the victim’s writing style (inferred from sent items), references the real conversation, and requests a wire transfer to an attacker-controlled account. The email is sent directly from the compromised account via Microsoft Graph (Mail.Send).

All AI calls use the Groq API with Meta’s Llama models — the same provider and model family as EvilTokens.

Our sandboxed reconstruction running as a CLI against a test tenant — from OSINT reconnaissance through the full AI-driven chain.

To help defenders understand the threat, we reconstructed EvilTokens (with some exceptions mentioned above) for research purposes. Because EvilTokens itself sells a GUI web panel, we used the same core functions and moved our prototype from CLI to a web dashboard to portray the platform as realistically as possible.

The same reconstruction moved to a web dashboard — campaigns, captured tokens, AI analysis, and BEC drafts — to mirror how real PhaaS kits present to a buyer.

Why this matters

Our prototype proves that a fully automated, AI-driven OAuth consent-phishing platform can be built with off-the-shelf LLMs and public APIs. Attackers can scale the attack with minimal effort, and AI eliminates manual email writing and financial reconnaissance.

Defenders should treat OAuth grants as identity-layer attack surfaces: continuously monitor new consent grants, high-risk scopes, unusual app activity, and token usage patterns, then revoke suspicious grants before they become persistent access. Concrete recommendations:

Before the grant — close the doors

• User consent → off. Set Entra user consent to “Do not allow” (or verified-publisher + low-risk scopes only); route the rest through admin consent. Removes the Accept button for unverified apps.
• Block device-code flow. Conditional Access → block the device code grant, allow only for specific input-constrained devices, exclude break-glass accounts. Direct counter to EvilTokens/Kali365.
• App registration → No. Stops attackers registering the malicious multi-tenant app in the first place.
• Phishing-resistant MFA. Deploy FIDO2 security keys, passkeys, or mutual TOTPs.

During the grant — minimize blast radius

• Least privilege. Treat Mail.Send, Mail.ReadWrite, full_access_as_user, Application.ReadWrite.All, Directory.ReadWrite.All, … as high-risk and never default-grantable.
• Short token lifetimes + sign-in frequency on high-value roles — cuts the refresh token’s window.

After the grant — detect the sequence, auto-revoke

• Recon-burst detection. Fresh token reading /contacts, /manager, /directReports, /mailFolders/sentitems in parallel within seconds of issuance is the loudest single signal. Alert on Graph read fan-out shortly after first token use.
• New/unknown client_id requesting high-risk scopes, or a known first-party client_id requesting an unusual resource. Allowlist legitimate device clients to keep this high-signal.
• Persistence pivot — device registration or PRT issuance immediately following the grant. High severity.
• Automated revocation. Password reset is useless here. Revoke the service principal grant, refresh tokens, and PRT, and kill sessions; a standard revoke can leave an access token valid ~1h, so disable the account for active intrusions.

Detection and Mitigation with SlashID

Device-code phishing leaves defenders nothing conventional to catch: no fake domain, no malicious app registration, and no credential theft. SlashID links identity → token → grant/scope → resource/action on one graph and turns that context into automated containment.

This is where treating identity as the control plane pays off: the device-code grant, the recon burst, and the persistence pivot are invisible to a perimeter- or endpoint-centric stack, but they are exactly the sequence SlashID is built to catch and stop.

For the manual version of this attack — how an illicit consent grant works by hand, and why it bypasses MFA — start with Part 1: Understanding Modern OAuth Consent Phishing.