How is AI phishing different from regular phishing in 2026?

AI-powered phishing-as-a-service kits automate the parts of an attack that used to require a skilled operator: they tailor lures to a target's language and industry, read a compromised mailbox to find who approves payments and which vendor threads are live, map the organization through directory APIs, and draft follow-on impersonation messages. The result is business email compromise at scale from affiliates with no social-engineering skill. Microsoft's September 2026 takedown of EvilTokens, which compromised more than 12,000 inboxes across more than 10,000 organizations from a $1,500 kit, is the reference case.

What is the single most effective defense against device code phishing?

Block the OAuth device code authentication flow in your identity provider unless you have a documented need for it. In Microsoft Entra, use a Conditional Access policy that blocks the device code flow for all users, and if you run Teams devices, scope an exception to those specific resource accounts and exclude the Device Registration Service. Device code phishing works because the victim authorizes the attacker's session on the real login page with real MFA, so no detection catches it; removing the flow removes the attack.

Does MFA stop AI phishing?

Not the kind most organizations run. Push notifications, SMS codes and TOTP apps are all defeated by adversary-in-the-middle proxies and device code phishing, because the victim completes MFA legitimately while the attacker captures the resulting session token. Only phishing-resistant methods, FIDO2 security keys and passkeys, bind the credential to the real origin so a proxy or a code entered on a look-alike flow cannot succeed. Microsoft's post-EvilTokens guidance is to move to FIDO2 or passkeys and to avoid telephony-based MFA entirely.

What should I do if an account has been compromised by token theft?

Temporarily disable the account, then revoke sessions, then investigate. Revoking sign-in sessions invalidates refresh tokens but leaves existing access tokens valid for up to an hour, and operators of AI phishing kits work inside that window. Disabling the account ends access immediately. Next, remove any inbox rules the attacker created (forwarding, move-to-folder, delete rules that hide replies), check for newly registered devices and consented OAuth apps, force re-authentication for the user, and search the mailbox for outbound messages the attacker sent to finance contacts or vendors.

Quick Answer

How to Defend Against AI Phishing in 2026: A Guide

Published: September 24, 2026

The short answer

AI phishing is a subscription product now, and the defenses that work are identity controls, not better spam filters. Kits like EvilTokens, which Microsoft disrupted on September 22, 2026 after it compromised more than 12,000 inboxes, sell for $1,500 plus $500 a month and use AI to write lures, choose targets inside a compromised mailbox and draft the next fraud email. Their primary technique, device code phishing, defeats push, SMS and TOTP MFA because the victim authenticates for real. Five controls stop it: block device code flow, move to FIDO2 or passkeys, kill legacy authentication, alert on inbox rules, and disable rather than merely revoke compromised accounts. This guide covers each with the specific settings.

Step 1: Understand what you are defending against

The 2026 attack chain, drawn from Microsoft’s analysis of EvilTokens:

Stage	What the AI kit does	What you see
Lure	Picks from dozens of themes (invoice, RFP, shared file), writes target-specific copy in the target’s language	A plausible email with a link, PDF or HTML attachment
Evasion	Fake CAPTCHA gates; redirect chains through compromised sites and serverless hosts (Vercel, Cloudflare Workers, AWS Lambda)	URL scanners see a clean landing page; users see a “verify you are human” step
Token theft	Device code flow: attacker starts a sign-in, gives the victim the code inside the lure, victim enters it on the real login page	A legitimate sign-in event in your logs, MFA satisfied
Post-compromise	AI reads the mailbox, maps org structure via Graph, identifies payment authority, drafts BEC messages; hidden inbox rules; new device registration	Vendor “bank detail changes,” hijacked threads, replies the victim never sees

Two things follow. First, the phishing email is the least important part of the chain; a user who clicks is the expected case. Second, the sign-in itself looks legitimate, so detection has to key on what happens after: unusual flows, inbox rules, device registrations, Graph queries.

Step 2: Block device code flow

This is the highest-value change and it takes ten minutes.

Microsoft Entra: Create a Conditional Access policy → Users: all users → Target resources: all cloud apps → Conditions: Authentication flows → Device code flow → Access controls: Block. If you have Teams Rooms or shared devices that need it, exclude those specific resource accounts and exclude the Device Registration Service resource, not entire user groups. Test in report-only mode for a few days to catch any legitimate use you did not know about.

Google Workspace, Okta and others: the equivalent is disabling OAuth 2.0 device authorization grant for client applications that do not need it, and restricting which apps may use it. Check your IdP’s documentation for “device authorization” or “device flow.”

Verify: attempt a device code sign-in from a test account (for Microsoft, az login --use-device-code works as a probe). It should fail with a Conditional Access block.

Step 3: Move to phishing-resistant MFA

Push, SMS and TOTP are all replayable through an adversary-in-the-middle proxy and all irrelevant to device code phishing. FIDO2 security keys and passkeys are not: the credential is bound to the origin, so a proxy on a look-alike domain gets nothing, and there is no code to type into an attacker’s flow.

Rollout order that works in practice:

Administrators and finance first. They are the targets that turn a compromised inbox into a wire transfer.
Passkeys via the platform authenticator (Windows Hello, Touch ID, Android) for the general population; hardware keys for admins and anyone with payment authority.
Then enforce it with an authentication-strength Conditional Access policy requiring phishing-resistant MFA for privileged roles, and disable SMS and voice as methods entirely.

Avoid telephony MFA everywhere; SIM swapping is a separate, cheaper attack.

Step 4: Close the legacy and risk gaps

Block legacy authentication (IMAP, POP, SMTP AUTH, older Office clients). These protocols cannot enforce MFA at all, and per-user MFA prompts are trivially abused.
Enable sign-in risk policies that block or step up on medium and high risk, and turn on continuous access evaluation so a session is revoked when risk changes rather than at the next token refresh.
Restrict user consent to OAuth apps. Token-theft kits often persist by consenting a malicious app; require admin consent for anything requesting mail or directory scopes.
Centralize identity. Hybrid environments should sync all standard user accounts to the cloud directory (keeping on-prem admin accounts separate) so risk models see all sign-ins in one place.

Step 5: Detect the post-compromise signals

Because the sign-in is legitimate, detection lives in what the attacker does next. Alert on:

New inbox rules, especially ones that forward externally, move mail to RSS/Archive folders, or delete messages containing keywords like “invoice,” “payment,” “wire” or the names of finance staff.
New device registrations shortly after a sign-in from a new location.
Microsoft Graph or directory API queries from a user who does not normally run them: enumeration of users, groups and roles is the AI kit mapping the organization.
Sign-ins via device code flow at all, if you have not yet blocked it; these should be rare and explainable.
Outbound mail volume spikes or new external correspondents from a single mailbox.

Microsoft publishes Defender XDR hunting queries and an inbox-manipulation alert-grading playbook for exactly this; if you are on another stack, replicate the logic against your audit logs.

Step 6: Respond correctly

When you suspect token theft:

Disable the account. Session revocation alone invalidates refresh tokens but leaves access tokens live for up to an hour, and kit operators exploit that window. Accept the brief business disruption.
Revoke sign-in sessions and force re-authentication via Conditional Access.
Remove inbox rules, consented apps and registered devices the attacker added.
Search sent mail for messages to finance contacts, vendors and customers; the AI will already have drafted and possibly sent BEC emails. Warn recipients.
Reset the credential to a phishing-resistant method before re-enabling.
Check for lateral movement: other accounts signed in from the same IPs, shared mailboxes the user could access, SharePoint or Drive content downloaded.

Step 7: Train for the 2026 lure, not the 2016 one

Awareness training still helps, but only if it reflects what the lures look like now: correct grammar, the target’s real vendor names, and a request to “enter this code to view the document.” The one behaviour to drill is: never enter a code from an email into a login page. Legitimate device code prompts come from a device you are holding, not from a message.

Why this matters more each quarter

The same week Microsoft dismantled EvilTokens, Cisco Talos disclosed CLOSEDQUORUM, malware that lets LLMs vote on its next move, and Palo Alto Networks launched a multi-model defensive harness. Offensive tooling is being productized with subscriptions and support desks. The controls above are cheap, mostly free, and remove entire techniques rather than detecting individual campaigns. Start with Step 2 today. For the specific kit that prompted this guide, see What is EvilTokens?

Last verified: September 24, 2026.