How do attackers get through passkey domian specificity?
This is a good thing. The most commonly used MFA factors (like SMS codes, push notifications, and app-based OTP) are routinely bypassed, with modern reverse-proxy “Attacker-in-the-Middle” phishing kits the most common method (and the standard choice for phishing attacks today).
These work by intercepting the authenticated session created when a victim enters their password and completes an MFA check. To do this, the phishing website simply passes messages between the user and the real website — hence “Attacker-in-the-Middle”.
In contrast, passkey-based logins can’t be phished. Because passkey-based logins are domain-bound, trying to use a passkey for microsoft.com on phishing.com simply won’t generate the correct value to pass the authentication check, even when proxied using an AitM kit.
But attackers haven’t given up that easily. As passkeys become more popular, we’re seeing a number of techniques designed to downgrade or otherwise circumvent the authentication process to make it vulnerable to phishing attacks.
So, here’s all the techniques that attackers have used to get around passkeys (so far).
Downgrade attacks
Downgrade attacks are the go-to method used by attackers to get around phishing-resistant MFA. MFA downgrade functionality has been observed in a number of criminal AitM kits and is even possible using commodity kits like Evilginx.
When conducting an Attacker-in-the-Middle phishing attack, the attacker doesn’t need to relay 100% of the messages accurately. Instead, they can alter some of them. The app might ask the user “You need to MFA — do you want to use your passkey, or your backup authenticator code?”, but the phishing website might modify this page to say “You need to MFA — use your backup authenticator code” not giving you the option to use your secure passkey. This is called a downgrade attack.
Device code phishing
To get around phishing-resistant authentication methods, attackers are also using device code phishing attacks that take advantage of alternative authentication flows for devices which do not support passkey-based logins, e.g. because they don’t have web browsers, or have limited input capabilities.
This alternative login flow operates by supplying a user with a unique code and instructing them to visit a webpage in a browser on a different device to enter the code in order to authorize the device.
This can be used by an adversary to conduct a phishing attack against a target by convincing them to visit their authentication provider website and enter a code supplied by the adversary, thereby granting access to their account.
Consent phishing
Consent phishing was one of the first techniques added to the SaaS attacks matrix and has been around for some time, but with a recent uptick in malicious activity.
OAuth allows users to grant third-party apps permissions to access their data. Adversaries can abuse this functionality by tricking users into authorizing access for malicious OAuth apps.
In a consent phishing attack, an adversary sends a phishing link to a target that requests permissions to access sensitive data or permissions to perform dangerous actions. If the target grants consent for the permissions, the adversary gains that level of access over the target’s account. This level of access will bypass MFA and persist through password changes.
Verification phishing
Email verification is sometimes used as a control, such as when registering new accounts. This is typically implemented by emailing the target user with either a clickable link for them to verify or a verification code that they need to enter.
Verification phishing is when an adversary uses phishing, or some other type of social engineering, to convince a user to click a verification link or pass them the verification code in order to defeat this control.
An example of this technique being used to bypass MFA is with cross-IdP impersonation. This is where an attacker simply registers a new IdP account to the victim’s corporate email domain. In many cases, this allows you to log in via SSO using the new IdP without any further checks — in fact, 3 in 5 apps were found to allow this behavior.
App-specific password phishing
App-Specific password phishing is a social engineering technique where an adversary tricks a user into generating an "app-specific password" for their account and then sharing it with the attacker. These legacy passwords are a feature in some major SaaS providers (like Google and Apple) designed to allow older applications that do not support modern authentication (like OAuth 2.0) to access account data.
The attack flow typically involves a pretext where the attacker, posing as a trusted entity (e.g., tech support, a service provider), directs the user to their account's security settings. The user is then guided through the process of creating a new app-specific password and is instructed to paste this password into a form or chat window controlled by the attacker.
Because app-specific passwords are designed for use in environments that do not support MFA, once the attacker possesses this password, they can gain persistent, programmatic access to the user's account data (e.g., emails, contacts, files) via APIs, often without triggering the same level of security alerts as a traditional interactive login from an unrecognized device.
Targeting local accounts not using passkeys
Possibly the easiest way to get around passkeys, though, is to target apps that don’t support passkeys natively. Passkeys are typically used in combination with SSO, where you log into your primary IdP provider with a secure, passkey-protected login, and then on to connected apps via SSO. Many apps do not allow passkey logins directly.
As a result, apps like Slack, Mailchimp, Postman, GitHub, and other commonly-used business apps are being increasingly targeted directly — bypassing IdPs (MS, Google, Okta, etc.) that typically have more robust authentication controls in place.
Just like backup MFA methods are often registered alongside passkeys, local “ghost login” methods are often registered alongside SSO, meaning that accounts have multiple possible entry points.
