Three unrelated-looking stories broke in the same five-month window. A phishing-as-a-service kit called EvilTokens compromised 340+ organizations by having victims complete a login flow originally designed for smart TVs. Google’s Threat Intelligence Group caught three separate Russia-nexus clusters walking diplomats and defense researchers through generating an “app password” to join a fake conference call. And a market-intelligence vendor called Klue got breached, and the attacker didn’t need a single password from a single Klue customer — they replayed OAuth tokens Klue already held on their behalf.

Read those as three incidents and you learn three sets of IOCs. Read them together and the pattern is unmistakable: nobody in any of these campaigns stole a credential. They collected an authorization. That distinction is the whole story of identity attacks in 2026, and most enterprise detection stacks still aren’t built to see it.

The Property That Makes This Work

Every technique below shares one trait: the victim authenticates through the real identity provider’s real infrastructure, using their real credentials and their real MFA. login.microsoftonline.com. accounts.google.com. web.whatsapp.com. No spoofed domain, no cloned login page, no TLS warning, no “this certificate is invalid” prompt — because there isn’t a fake page. The attacker isn’t intercepting the authentication. They’re a bystander who gets handed the output of it.

This is a different failure mode than adversary-in-the-middle phishing (Evilginx, Tycoon2FA, the reverse-proxy kits that relay a real login session and steal the resulting cookie). AiTM at least has to sit between the victim and the IdP, which gives you a detection surface: TLS fingerprint mismatches, a proxy hop, a session cookie replayed from a new ASN seconds after issuance. The techniques below don’t need a proxy at all. The victim goes to the legitimate site directly. What the attacker phishes isn’t the login — it’s the authorization the login produces, and they get it because they talked the victim into generating or granting it on the attacker’s behalf.

Three flows are getting weaponized industrially right now: OAuth’s Device Authorization Grant, application-specific passwords, and OAuth consent screens. A fourth — device-linking in messaging apps — shows the same logic has spread past enterprise identity providers entirely.

Device Code Phishing: A Smart-TV Login Flow as a Skeleton Key

RFC 8628’s Device Authorization Grant exists so a device with no browser — a smart TV, a CLI tool, a conference room panel — can still authenticate a user. The device displays a short alphanumeric code and a URL. The user opens that URL on their phone or laptop, types the code, logs in normally (MFA included), and the device — not the browser the user is looking at — receives the access and refresh tokens.

Attackers now play the role of the device. The phishing email says “your paycheck report is ready” or “IT needs you to re-verify your account,” with a link or QR code pointing at the actual microsoft.com/devicelogin page and a pre-filled or attacker-supplied code. The victim types the code, authenticates for real, satisfies MFA for real, and the token lands in the attacker’s session instead of a legitimate device. Access tokens are short-lived, but the refresh token that comes with them is typically valid up to 90 days and requires nothing from the victim to keep using — no re-login, no re-MFA, just silent token refresh against Microsoft Graph.

EvilTokens, the PhaaS platform Sekoia disclosed in March 2026, industrialized this: automated lure generation (including LLM-written phishing copy), automated device-code polling, and Microsoft Graph harvesting, sold as a subscription on Telegram. It hit 340+ organizations in five weeks. SquarePhish2 does the same thing via QR code with a 15-minute race against the code’s expiry window. Graphish skips subtlety and requests the broadest Graph API scopes it can get approved, going straight for mail, files, and Teams. Attribution spans crimeware (TA2723) and state-nexus actors (a Russia-aligned cluster tracked as UNK_AcademicFlare, hitting government and transportation targets using compromised .gov and .mil accounts to build rapport before delivering the link).

Why this evades detection: there’s no failed login, no foreign-IP anomaly if the attacker proxies carefully, no password spray signature. Most SOCs have no baseline for device-code sign-in volume at all, because almost nobody in a modern office uses a device that legitimately needs it.

Detect it. Device Code Flow sign-ins are the exception, not the rule, in a normal knowledge-worker tenant. Pull them directly:

1
2

Get-MgBetaAuditLogSignin -Filter "authenticationProtocol eq 'deviceCode'" `
  -All | Select-Object UserPrincipalName, CreatedDateTime, IPAddress, AppDisplayName

Or in Sentinel/Log Analytics against SigninLogs:

1
2
3
4
5

SigninLogs
| where AuthenticationProtocol == "deviceCode"
| where ResultType == 0
| project TimeGenerated, UserPrincipalName, AppDisplayName, IPAddress, Location
| order by TimeGenerated desc

Any hit from a role that isn’t running a CLI tool, kiosk, or headless IoT enrollment is worth an immediate look.

Block it. Entra ID’s Conditional Access now has an “Authentication flows” condition (currently in preview) that targets device code grants specifically. Scope a policy to block it for everyone except an explicit allowlist of the accounts and service principals that legitimately need it — that allowlist should be small and named, not “all users.”

App Passwords: The Bypass Nobody Turned Off

Application-specific passwords predate modern OAuth and MFA. They exist so legacy clients — an old mail client, a scripting tool — that can’t do interactive MFA can still authenticate. By design, an app password satisfies authentication without triggering a second factor, and it survives a normal password rotation because it’s a separate credential entirely.

GTIG’s August 2026 report on three Russia-nexus clusters (UNC6293, UNC7005, UNC5976 — the first two assessed as tied to Ice Relic / APT29 / Midnight Blizzard) documents UNC6293 running this as its primary technique against diplomats, academics, and aerospace/defense researchers. The lure impersonates a State Department official inviting the target to a “secure call” or shared document, and walks them — step by step, screenshots included — through generating a Google application-specific password and handing it over “to join.” No malware, no exploit, no MFA prompt to defeat, because app passwords don’t ask for one. The resulting access is durable and invisible to any detection tuned to catch anomalous password logins, because the app password is a valid credential the moment it’s minted.

Detect it. In Google Workspace, app password generation events are logged in the Admin console audit log (Login Audit → filter for 2SV Enrolled/app password creation events) and via the Reports API. In Microsoft 365 tenants, app passwords are a legacy per-mailbox MFA feature — if you still allow them anywhere, audit who has one and why.

Kill it. For the overwhelming majority of knowledge-worker tenants, application-specific passwords have no legitimate use case in 2026. Disable app password generation at the org level in Google Workspace admin (Security > Authentication > 2-Step Verification > App passwords) and in Entra ID via the legacy per-user MFA settings. If a legacy integration genuinely needs one, scope it to a service account with narrow permissions, not a human user’s mailbox.

OAuth Consent: The Fake Login Page That Isn’t Fake

Consent phishing skips credential theft entirely. The victim clicks “Continue with Google” or “Sign in with Microsoft” on what looks like a normal file-share or productivity app. The button opens a real OAuth consent screen on Google’s or Microsoft’s actual domain, with a valid certificate, asking the victim to grant a registered application permission to read mail, files, or calendar. The victim clicks Allow. The malicious app — not the identity provider — receives a token scoped to whatever the victim just approved, and that token keeps working until someone finds and revokes it.

GTIG’s UNC7005 runs exactly this against high-value individual targets, relaying the resulting token through an attacker-controlled Google Cloud project. At industrial scale, the same technique has hit nearly 3,000 accounts across 900+ Microsoft 365 tenants via apps impersonating 50+ legitimate brands, succeeding in over half of attempts according to Microsoft’s own tracking. And the Klue/Icarus breach shows the enterprise variant: rather than phishing individual users for consent, the attacker compromises the SaaS vendor that already holds hundreds of customers’ consent grants, then replays those tokens directly against Salesforce, HubSpot, and SharePoint APIs — no phishing step required at all, because the consent was already granted months or years earlier.

Detect it. Alert on new OAuth app registrations and new consent grants from applications outside your admin-approved allowlist, especially ones requesting Mail.Read, Files.ReadWrite.All, or equivalent broad scopes shortly after creation. In Entra ID, Enterprise Applications > Consent and permissions surfaces this; in Google Workspace, Security > API controls > App access control.

Constrain it. Restrict user consent to admin-approved apps only — this single setting change closes the individual-user consent-phishing vector outright. For the vendor-compromise variant, there is no config toggle: it requires actually inventorying every connected app with production data access and asking whether you’d notice if that vendor got popped tomorrow. Most organizations can’t answer that question about more than a handful of their integrations.

WhatsApp Linking: The Same Logic, Off the Enterprise IdP Entirely

UNC7005 also runs a variant against WhatsApp’s multi-device linking feature — a legitimate feature that lets a user link a second device (a laptop, a tablet) to their account by scanning a QR code. Victims are lured into linking their account to an attacker-controlled “device” during what looks like a normal voice call setup, and from that point the attacker-linked session can silently trigger audio/video capture during subsequent calls and upload it to attacker infrastructure. No malware touches the victim’s phone. There’s nothing for an EDR agent to catch, because the phone was never compromised — only the account’s device list was.

The lesson here generalizes past WhatsApp: any product with a “link a new device” or “authorize this session” flow is a candidate for the same attack, and most of those products were not designed with an adversarial linking scenario in mind. Check Settings > Linked Devices on corporate and high-risk personal devices, and treat any unrecognized entry as an active compromise, not a stale session to shrug off.

Why This Keeps Working

Every mitigation vendor ships for phishing assumes the attacker is trying to obtain a credential or defeat MFA. Anti-phishing filters look for spoofed domains. Conditional Access risk scoring looks for anomalous sign-in patterns. Security awareness training tells users to check the URL bar and watch for a fake login page. None of that fires here, because the domain is real, the sign-in pattern looks like a legitimate but unfamiliar auth flow, and there is no fake login page to spot — the victim is looking at the genuine one.

Phishing-resistant MFA (FIDO2 hardware keys, platform passkeys) is necessary but not sufficient. It closes the door on credential-phishing and AiTM cookie theft, which is real progress. It does nothing for device code phishing, app-password generation, or OAuth consent grants, because none of those techniques ask the victim to authenticate to a fake relying party — they ask the victim to authorize a real one on the attacker’s behalf. Passkeys don’t have an opinion about that.

Takeaways

  • Treat “authentication flow abuse” as its own detection category, distinct from credential phishing and AiTM. Device code sign-ins, app-password creation events, and new OAuth consent grants each need their own alert, because none of them trip your existing failed-login or impossible-travel logic.
  • Block device code flow by default. Use Entra ID’s Authentication flows Conditional Access condition (or an equivalent block for other IdPs) and allowlist only the specific service principals that need it. If you don’t know whether anything in your tenant needs it, that’s your answer — block first, then handle exceptions as they surface.
  • Kill application-specific passwords tenant-wide unless a specific legacy integration requires one, in which case scope it to a locked-down service account, never a human mailbox.
  • Restrict user consent to admin-approved apps only. This is the single highest-leverage setting against consent phishing and costs you nothing but a short queue of app-approval requests.
  • Inventory every OAuth grant your org has handed to a third-party SaaS, and ask specifically what that vendor’s compromise would hand an attacker. The Klue and Salesloft/Drift incidents both prove that your OAuth security posture is only as strong as the worst-secured vendor you’ve ever clicked Allow for.
  • Extend the same suspicion to non-enterprise identity surfaces — WhatsApp, Signal, any product with a device-linking or session-authorization flow that a targeted user might be walked through on a call. If your threat model only covers the corporate IdP, you’re missing where sophisticated actors are already operating.

None of these attacks has a CVE. None of them will show up in a vulnerability scan. They exploit the fact that “the user completed a legitimate authentication flow” has quietly stopped being sufficient evidence that the user should be trusted — and most identity infrastructure hasn’t caught up to that yet.

Sources: