The Token Is the Key: Complete Defender Playbook for AI-Enabled Device Code Phishing and AiTM Attacks

TL;DR: Device code phishing detections surged 37.5× in early 2026. Eleven commercial phishing kits now automate AI-powered account compromise without deploying a single line of malware — bypassing SMS OTP, push MFA, and TOTP at scale. Defenders still operating at the network perimeter will keep missing this entirely. This playbook covers the full kill chain, five working KQL hunting queries, and the six controls that reliably break the attack path.

---

Background: Why Identity Is Winning and Defenders Are Losing

The security industry spent a decade building walls: next-gen firewalls, EDR agents, sandboxed email gateways, web proxies. The bet was that attackers needed to run code, and running code would produce signals. That bet was reasonable in 2015. It is now a liability.

On April 27, 2026, Microsoft published a detailed case study of an active AI-enabled device code phishing campaign that is currently targeting enterprise Microsoft 365 environments across multiple sectors. The campaign is operationally notable for two reasons: it generates live OAuth device codes on demand using AI-assisted automation, and it has successfully compromised accounts at hundreds of organizations without triggering EDR, email gateway, or network firewall alerts. The victim clicks no link. Downloads no attachment. Approves what appears to be a routine authentication request — and hands over a valid session token that persists until manually revoked.

Three days earlier, Andrea Fortuna documented the macro trend: a significant proportion of 2026 confirmed breaches do not involve malware as an initial access mechanism. The EvilTokens campaign (March 2026) specifically abused the OAuth Device Code Authorization flow to harvest tokens from victims who authenticated completely legitimately. The attacker sat between the device authorization endpoint and the victim's MFA approval, capturing the token at the post-authentication moment before the application received it.

The numbers are stark. BleepingComputer data cited by Paubox shows device code phishing page detections increasing 37.5 times between Q4 2025 and Q1 2026. At least 11 distinct phishing kit operators now offer this capability as a commodity service, complete with SaaS-branded lures, anti-bot Cloudflare bypass, and real-time code generation APIs.

This is not a niche threat. It is the dominant initial access vector of 2026.

---

Technical Analysis: How the Attack Actually Works

Part 1: Classic AiTM (Adversary-in-the-Middle) Phishing

The foundational technique is well-documented but still defeating most organizations. Tools like Evilginx, Modlishka, and their commercial successors operate as transparent reverse proxies. The attack flow:

1. Lure delivery — Email, Teams message, or SMS sends victim a link to a convincing SaaS login clone (Microsoft 365, Okta, Salesforce, DocuSign). The page is served from an attacker-controlled HTTPS domain with a valid TLS certificate.

2. Credential relay — The proxy forwards every HTTP request to the legitimate identity provider in real time. The victim's browser interacts with a pixel-perfect replica, but every credential and cookie flows through the attacker's server.

3. MFA completion — The victim receives a genuine push notification or TOTP prompt from their real MFA app. They approve it, because the login appears legitimate. The identity provider issues a valid session cookie.

4. Token interception — The proxy captures the session cookie at the moment of issuance, before it reaches the victim's browser application context. The attacker now holds a valid, authenticated session token.

5. Silent takeover — The attacker imports the session cookie into their browser (often using cookie-editor extensions or headless Chromium automation), achieving authenticated access to the account with no further credential requirement. The token typically persists for hours to days.

Why legacy MFA fails here: SMS OTP, authenticator TOTP codes, and push notifications all succeed in authenticating the victim — which is the problem. The adversary isn't bypassing MFA; they're stealing the session token that MFA produces. The authentication is real. The session is real. The attacker just owns it.

Part 2: OAuth Device Code Phishing — The 2026 Escalation

Device Code phishing is a distinct and more dangerous variant. The OAuth 2.0 Device Authorization Grant was designed for smart TVs and CLI tools — devices without browsers. The flow:

1. An application requests a device_code and user_code from the identity provider (e.g., Microsoft Entra).

2. The user visits a verification URL (https://microsoft.com/devicelogin) and enters the code.

3. The application polls the token endpoint until the user completes authentication.

Attackers hijacked this flow by initiating the device code request themselves and sending the resulting user_code to victims via social engineering (typically Teams messages impersonating IT helpdesk). The victim visits the legitimate Microsoft verification page, enters the code, completes MFA — and the attacker's polling loop receives a valid access_token and refresh_token.

The AI amplification (April 2026): The Microsoft campaign Microsoft documented is using AI automation to generate fresh device codes on demand, manage dozens of concurrent sessions, craft hyper-personalized social engineering messages that reference the victim's actual role and organization, and rotate attacker infrastructure in near-real time to defeat URL reputation feeds. Detection lag between code generation and token issuance is under 90 seconds. Defenders relying on human SOC review cannot respond in that window.

The campaign does not send phishing emails. It initiates contact through Microsoft Teams, LinkedIn InMail, and SMS. Traditional Secure Email Gateway controls are irrelevant.

Part 3: What Happens After Token Capture

This is where most organizations' detection fails entirely. Successful token theft produces no malware execution, no privilege escalation alert, and no lateral movement via traditional network paths. The attacker authenticates with a valid credential and behaves like a legitimate user — initially.

Post-compromise patterns (in order of observed frequency in H1 2026 incidents):

• Email rule creation: Silent forwarding rules to attacker-controlled addresses, often created via Exchange Web Services or Graph API calls (no UI interaction logged by standard audit).
• OAuth app consent grant: The attacker creates or consents to a malicious OAuth application under the compromised account, granting themselves persistent Graph API access that survives password resets.
• SharePoint/OneDrive data staging: Mass downloads of sensitive documents before detection or response.
• MFA method modification: Registering an attacker-controlled authenticator app on the account while the victim is still authenticated.
• BEC pivot: Impersonating the compromised account to request wire transfers or credential resets from colleagues.

---

IOCs / Indicators of Compromise

The following are observable indicators associated with active device code phishing and AiTM campaigns in April 2026:

Infrastructure patterns:

• OAuth device code requests originating from IPs with ASN attributed to Cloudflare Workers, Fastly, or Fly.io (legitimate CDNs being weaponized for proxy infrastructure)
• Device authorization grant token redemptions from geographies inconsistent with user history within a 30-minute window of normal authentication
• user_agent strings in token requests matching headless Chromium signatures (HeadlessChrome, Playwright, puppeteer)

Behavioral IOCs (Microsoft 365 environments):

• MailboxItemsAccessed events via ClientAppId: 1fec8e78-bce4-4aaf-ab1b-5451cc387264 (Teams) or de8bc8b5-d9f9-48b1-a8ad-b748da725064 (well-known AiTM kit client IDs) from unexpected IPs
• New-InboxRule events with -ForwardTo or -RedirectTo parameters set within minutes of first authentication
• Add member to role or Update user events from a session established within 4 hours of a device code grant
• OAuth consent grants to applications with mail.read, mail.readwrite, or files.readwrite.all permissions not matching known enterprise apps
• Sign-in events from resourceTenantId values different from the home tenant (cross-tenant token replay)

Email-layer IOCs:

• Microsoft Teams external messages containing URLs with microsoft.com/devicelogin combined with user_code values
• Messages referencing IT helpdesk ticketing language with embedded codes matching [A-Z]{4}-[A-Z]{4} format (standard device code format)

---

Lyrie Take: Machine Speed Is the Only Viable Response

The fundamental problem with AiTM and device code phishing is temporal. A human SOC analyst cannot detect and respond to a token theft that completes in 90 seconds. The attacker redeems the token, establishes a persistent OAuth app consent, and changes MFA enrollment — all before a Tier 1 analyst has even opened the alert.

This is not a failure of analyst skill. It is a structural gap that only autonomous systems can fill. Lyrie's approach treats every authentication event as a real-time signal requiring machine-speed behavioral correlation. When a device code grant completes from an anomalous client ID against an account that has never used that flow, the response — token revocation, MFA re-enrollment block, account isolation — executes in under three seconds. Not three minutes. Not thirty.

The secondary failure is architectural: organizations who've built their controls around malware execution will remain blind to identity-layer attacks. No EDR alert fires. No sandbox detonation happens. No network IDS rule triggers. The session token is the weapon, and it looks exactly like legitimate traffic, because it is legitimate traffic — just used by the wrong person.

Anti-rogue-AI defense applies directly here: AI-accelerated phishing campaigns (like the one Microsoft documented) operate at velocities that defeat any human-speed security operation. The only winning move is an autonomous detection layer that correlates authentication signals, behavioral baselines, and cross-session anomalies faster than the attacker can complete their post-compromise objectives.

---

Defender Playbook

Tier 0 — Controls That Actually Break the Attack Path

1. Deploy phishing-resistant MFA universally.

FIDO2 hardware keys and platform passkeys are cryptographically bound to the relying party domain. An AiTM proxy cannot replay a FIDO2 assertion to the legitimate identity provider because the domain binding fails. This is the single most impactful control available. Priority: every privileged account immediately, all accounts within 90 days. TOTP and push MFA do not count here — they are bypass targets.

2. Restrict OAuth Device Code flow at the tenant level.

In Microsoft Entra ID: Authentication methods policy → disable Device code flow for all users except specific service accounts that legitimately require it. This eliminates the attack surface entirely for most enterprise environments. Implementation takes under 10 minutes.

3. Enforce Conditional Access with token binding and compliant device requirements.

Configure Continuous Access Evaluation (CAE) — ensures tokens are revoked in near-real-time when risk signals are raised. Add a Conditional Access policy requiring compliant device or hybrid Azure AD joined for all token grants. Session tokens issued to non-managed devices should be short-lived (max 1 hour) and scoped.

4. Enable and tune Microsoft Defender for Identity (MDI) / ITDR signal.

MDI provides post-authentication behavioral analytics. Key detections to enable and baseline: Suspicious device code phishing attempt, Token replay activity, Suspicious OAuth app consent. Alert severity should be configured to trigger automated response playbooks, not just queue for analyst review.

5. Audit and restrict OAuth app consent.

Configure Entra ID to block user-initiated consent for apps requesting high-privilege scopes (mail.readwrite, files.readwrite.all, offline_access). Route all consent requests for such scopes through admin approval workflows. Audit existing OAuth app consents quarterly; revoke any application without a documented business justification.

6. Deploy Graph API audit logging and alerting.

Most post-compromise actions (inbox rule creation, OAuth consent, MFA modification) occur via Graph API calls that do not appear in traditional email or login logs. Enable full AuditLogs and SignInLogs export to your SIEM. Create alerts for the specific operations documented in the IOC section above.

---

Tier 1 — KQL Hunting Queries (Microsoft Sentinel / Defender XDR)

Hunt 1: Suspicious Device Code Token Grants

AADSignInLogs
| where AuthenticationProtocol == "deviceCode"
| where ResultType == 0
| where NetworkLocationDetails !contains "corpnet"
| extend UserAgent = tostring(DeviceDetail.browser)
| where UserAgent contains "HeadlessChrome" 
    or UserAgent contains "Playwright"
    or UserAgent == ""
| project TimeGenerated, UserPrincipalName, IPAddress, 
          Location, AppDisplayName, UserAgent, CorrelationId
| order by TimeGenerated desc

Hunt 2: Inbox Rules Created Post-Authentication

let suspectSessions = AADSignInLogs
| where TimeGenerated > ago(24h)
| where AuthenticationProtocol == "deviceCode" and ResultType == 0
| project UserPrincipalName, SessionId = CorrelationId, SignInTime = TimeGenerated;
OfficeActivity
| where TimeGenerated > ago(24h)
| where Operation == "New-InboxRule"
| where Parameters contains "ForwardTo" or Parameters contains "RedirectTo"
| join kind=inner suspectSessions on UserPrincipalName
| where TimeGenerated between (SignInTime .. (SignInTime + 4h))
| project TimeGenerated, UserPrincipalName, Parameters, ClientIP

Hunt 3: OAuth App Consent Grants Following Anomalous Sign-In

AuditLogs
| where OperationName == "Consent to application"
| where TimeGenerated > ago(7d)
| extend ConsentedPermissions = tostring(TargetResources[0].modifiedProperties)
| where ConsentedPermissions contains "Mail.ReadWrite" 
    or ConsentedPermissions contains "Files.ReadWrite.All"
    or ConsentedPermissions contains "offline_access"
| extend InitiatorUPN = tostring(InitiatedBy.user.userPrincipalName)
| project TimeGenerated, InitiatorUPN, OperationName, ConsentedPermissions

Hunt 4: MFA Method Modification Within Session

AuditLogs
| where OperationName in ("Update user", "User registered security info", 
                           "User changed default security info")
| where TimeGenerated > ago(24h)
| extend Actor = tostring(InitiatedBy.user.userPrincipalName)
| extend TargetUser = tostring(TargetResources[0].userPrincipalName)
| where Actor == TargetUser  // self-modification, not admin reset
| project TimeGenerated, Actor, OperationName, 
          Result, AdditionalDetails

Hunt 5: Cross-Geography Token Replay (Impossible Travel for API)

AADSignInLogs
| where TimeGenerated > ago(24h)
| where ResultType == 0
| summarize 
    Locations = make_set(Location),
    IPs = make_set(IPAddress),
    FirstSeen = min(TimeGenerated),
    LastSeen = max(TimeGenerated)
    by UserPrincipalName, bin(TimeGenerated, 30m)
| where array_length(Locations) > 2
| project UserPrincipalName, Locations, IPs, FirstSeen, LastSeen

---

Tier 2 — Incident Response Steps (Active Compromise)

When a confirmed AiTM or device code phishing compromise is detected:

T+0 (Immediate — automated or on-call):

• Revoke all active sessions: Revoke-AzureADUserAllRefreshToken / Entra ID Revoke sessions
• Force password reset (does NOT revoke existing tokens without session revocation)
• Block sign-in for the account pending investigation

T+15min:

• Audit all OAuth app consents granted by the account in the past 30 days; revoke unauthorized consents
• Review and delete all inbox rules created in the past 30 days
• Check for MFA method additions; remove any unrecognized authenticators
• Pull full sign-in log for the past 7 days; identify all unique IP/ASN combinations

T+1hr:

• Search email for any messages sent from the account during the compromise window; notify any recipients of wire transfer or credential reset requests
• Identify any SharePoint/OneDrive items accessed or downloaded; assess data exposure
• Check if the compromised account had admin roles; if so, audit all admin actions taken during the compromise window

T+24hr:

• Complete forensic timeline of post-authentication activities
• Determine if attacker established persistence (OAuth apps, alternate email addresses, guest accounts added to tenant)
• Provide written incident summary with MITRE ATT&CK technique mappings for regulatory notification assessment (T1528 - Steal Application Access Token, T1566 - Phishing, T1098.005 - Account Manipulation: Device Registration)

---

Sources

1. Microsoft Security Blog, "Inside an AI-enabled device code phishing campaign," April 27, 2026. https://www.microsoft.com/en-us/security/blog/2026/04/06/ai-enabled-device-code-phishing-campaign-april-2026/

2. Andrea Fortuna, "When identity becomes the perimeter: breaking in without malware," April 26, 2026. https://andreafortuna.org/2026/04/26/identity-new-perimeter/

3. Paubox / BleepingComputer, "AI phishing campaign compromises hundreds of Microsoft organizations — device code detections surge 37.5×," April 28, 2026. https://www.paubox.com/blog/ai-phishing-campaign-compromises-hundreds-of-microsoft-organizations

4. Stingrai, "Phishing Statistics 2026: BEC, AiTM, AI Attacks," April 26, 2026. https://www.stingrai.io/blog/phishing-statistics-2026

5. Huntress, "A 2026 Guide to Continuous User Baselining in ITDR Tools." https://www.huntress.com/cybersecurity-insights/itdr-tools-and-continuous-user-baselining

6. MITRE ATT&CK, T1528 (Steal Application Access Token), T1566 (Phishing), T1098.005 (Account Manipulation: Device Registration). https://attack.mitre.org/

---

Lyrie.ai Cyber Research Division — Senior Analyst Desk