Beyond the Hype: How Attackers Exploit Flaws in 'Phishing-Resistant' Passkeys
3 min read
Share this article
For years, SMS codes, push notifications, and OTPs have proven vulnerable to Attacker-in-the-Middle (AitM) phishing kits, which intercept credentials by relaying traffic between victims and legitimate sites. In response, FIDO2-based passkeys (like YubiKeys, Windows Hello, or Okta FastPass) emerged as a gold standard. They bind authentication to a specific domain—attempting to use a Microsoft passkey on phishing.com fails cryptographically, foiling AitM proxies. Yet, as adoption grows, attackers are pivoting to ingenious workarounds that exploit gaps in implementation and human behavior.
The Downgrade Attack: Forcing a Weaker Path
Most criminal AitM kits, including Evilginx, now incorporate MFA downgrade functionality. When a service offers multiple authentication options (e.g., "Use passkey or backup code"), attackers manipulate the phishing page to remove the passkey choice, coercing victims into using phishable methods like OTP. This preys on a critical weakness: the presence of less secure backup MFA or password fallbacks. As one security engineer notes, "An account with a passkey and a backup SMS is only as secure as SMS."
alt="Article illustration 3"
loading="lazy">
> *Managed vs. unmanaged identity providers (IdPs) create complexity. Attackers target unmanaged 'social' IdPs to bypass corporate controls.*
### Beyond Downgrades: Four Emerging Bypass Techniques
1. **Device Code Phishing**: Attackers exploit OAuth flows for limited-input devices (e.g., smart TVs), tricking users into entering a rogue code on a legitimate site like Microsoft’s login portal. This grants attackers access without triggering MFA. Russian state groups have weaponized this in campaigns against M365, leveraging the legitimacy of the domain to evade suspicion.
2. **Consent Phishing**: Malicious OAuth apps request excessive permissions (e.g., full email access). Victims granting consent hand attackers persistent, MFA-bypassed access. Recent campaigns target GitHub, where a compromised OAuth app can poison repositories or exfiltrate code:
Verification Phishing: Attackers socially engineer users to click verification links or share codes, enabling tactics like cross-IdP impersonation. By registering a victim’s email with a new IdP, attackers can bypass SSO controls—a flaw affecting 60% of apps.
App-Specific Password (ASP) Phishing: Legacy apps that don’t support modern auth rely on ASPs. Attackers, posing as trusted entities (e.g., "IT Support"), guide users to generate and share these passwords. One high-profile case involved a forged U.S. State Department lure granting mailbox access:
The Ghost Login Problem: Targeting the Unprotected Perimeter
Passkeys often guard primary IdPs (e.g., Microsoft Entra), but countless SaaS apps (Slack, GitHub, Jira) rely on weaker local logins or SSO fallbacks. Attackers skip the fortified IdP entirely, aiming for these vulnerable endpoints. In a typical 1,000-user organization, over 15,000 accounts exist across apps—many without MFA. This identity sprawl creates a massive attack surface, as seen in the Snowflake and recent Jira breaches.
Why 'Set and Forget' Security Fails
Truly phishing-resistant accounts require eliminating backup methods and enforcing strict conditional access policies. Yet, complexity hinders this: Microsoft’s own templates sometimes mislabel risky sign-ins as false positives. Auditing every app for MFA gaps, SSO misconfigurations, and rogue OAuth grants is daunting, especially with shadow IT. As passkeys scale, security teams must prioritize holistic identity threat detection—monitoring for AitM patterns, anomalous consent grants, and ASP usage—over isolated solutions. The irony is stark: the tools designed to end phishing are only as strong as their weakest configured dependency.
Source: Adapted from BleepingComputer analysis sponsored by Push Security. Original URL: https://www.bleepingcomputer.com/news/security/how-attackers-are-still-phishing-phishing-resistant-authentication/