Barracuda counted 7 million device‑code phishing attacks in four weeks — a data point that underlines how quickly a once‑niche technique has become industrialized.
How device code phishing actually works
Device code phishing abuses the OAuth 2.0 device authorization grant to steal access tokens rather than user credentials. The victim is typically already authenticated to the provider; they copy a short code from a phishing page, navigate to the provider’s legitimate device login URL, select their account from a dropdown, and click “allow.” The attack therefore targets the authorization layer that runs after authentication — in short, it captures the token the user grants, not the password they used to log in.
Why it defeats MFA, including passkeys
Because the attack operates at the authorization step, standard authentication protections do not stop it. The source is explicit: “Passkeys, hardware security keys, enforced phishing‑resistant MFA — none of it makes a difference, because the device code flow is separate from the authentication mechanism.” The structural distinction between proving identity and granting access is the vulnerability attackers are exploiting; controls that focus on authentication alone leave the authorization grant exposed.
The PhaaS ecosystem: EvilTokens, Kali365, Tycoon2FA, ARToken
Device code phishing moved from curiosity to commodity in months. Researchers first described the vector in 2020; nation‑state use appeared in 2024 (the source names Storm‑2372), ShinyHunters ran large campaigns against Salesforce in 2025, and criminal adoption exploded after the arrival of the EvilTokens kit in February 2026. By April, Microsoft reported “10 to 15 entirely new campaigns every 24 hours.”
Phishing‑as‑a‑service platforms incorporated the technique as a product feature: Tycoon2FA added device code phishing in May, Kali365 offers both AiTM and device code phishing in a single platform, and ARToken ships with packaged features such as PRT persistence, mailbox access, BEC automation, and SharePoint exfiltration. The FBI issued a standalone advisory on Kali365 — the first U.S. federal agency public service announcement about a specific phishing‑as‑a‑service kit.
Scale, speed, and tool proliferation
Push Security now tracks more than 25 distinct device code phishing kits in the wild. That figure signals a sharp acceleration: a new AiTM kit used to be notable on a months‑long cadence; here, kits are appearing weekly. Push attributes part of the proliferation to AI‑assisted development — similar LLM prompts produce structural similarities across independently built kits — and notes that attackers are “vibe‑coding” new kits faster than defenders can catalog them. The ShinyHunters Salesforce campaign, cited in the source, compromised over 1,000 organizations and produced 1.5 billion stolen records, an example of what scaled abuse of the device flow can enable.
Targets beyond Microsoft: Salesforce, GitHub, AWS
While 99% of the device‑code phishing Push detects today targets Microsoft, the underlying OAuth 2.0 device authorization grant is cross‑platform. The source notes nation‑state actors used device code phishing against Salesforce, and that apps such as GitHub and AWS support device code flows — for GitHub, the flow is core to authenticating CLI tools and VS Code tunnels. As kit developers look beyond Microsoft, those platforms present obvious next targets.
Detection and mitigation: browsers, conditional access, and behavioral signatures
Defensive options in the source are practical and narrow. The most common mitigation advice for Microsoft environments is to restrict device code authentication flows via conditional access policies — a useful step where feasible, but one the source warns can break legitimate developer tooling, CLI workflows, and constrained‑device use cases. Locking down Microsoft does nothing to protect against equivalent flows in GitHub, AWS, or other providers.
Push argues the only vantage point that sees both the phishing lure and the device code approval — across any provider — is the browser. Its approach is to deploy browser‑layer telemetry and behavioral detection rules that target the technique class (the approval flow and kit behavior) rather than chasing kit‑specific fingerprints or domains. That distinction matters, the source says, when new kits are appearing weekly and infrastructure is being rotated faster than IOC‑based defenses can keep up.
What this means for security teams, policymakers, and end users
- Security teams: Expect rapid tool proliferation — Push tracks 25+ kits — and plan for detections that observe behavior across the browser’s view of both lure and approval; conditional access can help but may break legitimate workflows.
- Policymakers and regulators: Federal action has already begun — the FBI issued a standalone advisory on Kali365 — signaling that specific phishing‑as‑a‑service kits have drawn government attention and may shape guidance or enforcement.
- End users and developers: Authentication hardening alone will not be enough; device code flows are legitimately used by CLI and constrained‑device scenarios, and those legitimate uses are precisely what attackers are abusing.
The record in the source is unambiguous: a technique originally described in 2020 has been weaponized and commercialized with extraordinary speed. With kits like EvilTokens and Kali365 on the market, 10–15 new campaigns reported daily, and millions of attacks observed in weeks, defenders face a narrow window to shift detection from authentication controls to the authorization flows attackers now exploit.
