Phishing Resistant MFA Does Not Mean Un-Phishable

Human societies have a bad habit of taking a specific, limited-in-scope fact and turning it into an overly broad generalization that gets incorrectly believed and perpetuated as if it were as comprehensively accurate as the original, more-limited fact it was based on.

Anything can be hacked. Do not confuse “phishing-resistant” with being impossible to phish or socially engineer.

You would be hard-pressed to find an organization that has provided more free content over the last few years about many of the common attacks against multi-factor authentication (MFA) and how everyone needs to use “phishing-resistant” MFA, including here:

In fact, we built a whole webpage around it.

With the publishing of the CISA’s most recent memo touting phishing-resistant MFA, it seems that the message has now gone mainstream. That is a good thing. And everyone should implement phishing-resistant MFA where they can in order to protect valuable data and systems.

But it is important to know that phishing-resistant does not mean not phishable.

Everything is subject to social engineering and phishing. Even the strongest phishing-resistant MFA solutions can still be socially engineered around or hacked. Just as many people believed any MFA would prevent social engineering attacks, just as many people are probably going to see the phrase, phishing-resistant, and unfairly think that it means un-phishable. In fact, I talk to MFA admins who tell me that all the time. I see vendors for phishing-resistant MFA touting their products as being utterly un-phishable!

It is not true. And they should stop saying it. It undermines the industry and will hurt customers who rely on those statements who still end up getting hacked because of that overreliance.

It should be enough to say that their products are phishing-resistant and far less susceptible to some common forms of social engineering than other, more phishable products.

What has happened in the industry is that MFA products that significantly mitigate the most common type of social engineering attack against MFA, Man-in-the-Middle (MitM) attacks (called Adversary-in-the-Middle by some), have somehow been mistakenly labeled as un-phishable.

Note: If you want to see a good demonstration of the most common type of MitM attack against MFA see.

And let me say that we are huge fans of MFA products that prevent MitM attacks. Preventing your MFA solution from being hacked or bypassed by the most common type of phishing attack is the first step to being phishing-resistant. It just is not the only step. There are still plenty of ways MFA solutions that mitigate MitM attacks can be socially engineered and hacked around. How?

Some Other Types of Social Engineering Attacks Against MFA

Here are some real-world social engineering attacks which do not rely on MitM attacks:

Compromised Endpoint

If an attacker can convince a victim to download malware, that malware can take control over their desktop or device, and no MFA solution can stop that malicious software from doing whatever it wants to do. It is game over! Since a large percentage of phishing emails, text messages and compromised websites try to trick users into downloading malware, it means this type of popular attack will work even against phishing-resistant MFA. It involves social engineering and phishing, and it works against any MFA solution.

Compromised Infrastructure

If an attacker can socially engineer an admin or an employee of any component in the path of the MFA authentication (e.g., server, database, etc.), they can compromise the MFA solution. The client victim did not do anything wrong, but someone in the pathway of the client and the server providing the authentication was socially engineered (they often are not running the same phishing-resistant MFA) and the result is the same, if not worse.

A great example of this sort of attack was the 2020 Twitter breach, where a Twitter employee, likely protected by some form of MFA, was socially engineered. Once the attackers gained access to the employee’s admin credentials and tools, they took over dozens of other high-profile Twitter accounts, like those belonging to Bill Gates and Elon Musk. And even if any of those accounts were protected by really good, phishing-resistant MFA, those accounts would still be compromised.

Fraudulent Recovery Action

Most popular MFA options have self-help portals to allow users to “recover” their accounts if their MFA solution stops working for some reason. Almost always, the method used to authenticate the user to initiate the recovery option is less secure than the MFA solution they were using. It is often simply a link sent to someone’s previously registered email address or a link or code sent to the user’s cell phone using SMS. All of those options are less secure than the MFA option being used and can be easily socially engineered.

One of the easiest hacks is when the recovery action involves a code sent via SMS. All the attacker has to do is pose as someone from the vendor (i.e., tech support) calling or texting you saying that some event is happening that requires that they send you a code that you then repeat back to them. For example, your account is being hacked and they need to send a code to you to “confirm” you are the real account holder. Then they put your account in recovery mode, the vendor sends you an SMS code, which you are tricked into sharing with the attacker. The attacker is told the recovery code by the victim and uses it to recover the account. The hacker then takes over the account and changes the user’s authentication and personal information. This happens thousands of times a day.

Trick Tech Support

Many sites protected by MFA allow users to call in to recover their accounts. An attacker, using information they have previously socially engineered from the victim (like login name and password or PIN), can call the vendor’s technical support number and start a fraudulent account recovery. This is a very common social engineering attack method. Vendor tech support representatives are even warned about these types of fraudulent recovery events and if they follow the “scripts” they are supposed to follow, it makes using social engineering very hard to accomplish. But human beings want to help, and a good social engineering attacker can get a tech support agent to “go off script”. A great example of that type of attack is here.

Fake Successful Login

This type of attack is not super common, but it is a valid type of attack and has happened in the real world. It is very difficult to impossible to prevent. In this attack, the hacker socially engineers the victim into going to a fraudulent URL with a look-alike website. The victim thinks they are on the real website. The attack then prompts the user to log in.

Now, many MFA solutions, like FIDO, will not work if a fake website tries to “activate” them. They will simply fail, not work or even possibly state that you are being hacked. But with this type of attack, the entire authentication sequence is faked. The user comes up on the fake website, the fake website asks the user to authenticate, and then the fake website fakes the entire experience.

For example, the victim is tricked into going to a fake FIDO-protected website…say it is protected by a FIDO-enabled Yubico Yubikey. The fake website can create a fake popup (“browser within a browser”) that pretends to be the FIDO authentication client asking the user to type in their PIN, followed by another prompt to touch the sensor on their FIDO key. A fake website can fake the entire experience.

The user thinks they have successfully logged into a real website and now relaxes and begins doing what they would normally do on the real website. But instead of showing the user the entire real website, which would be a lot of work, the attacker just asks the user for their credit card or other personal identification information (e.g., “We need to re-verify your credit card to ensure it is valid”, etc.), which the user responds to. Then the fake website creates a fake error message and drops the user to the login screen of the real website. The user is none the wiser. They log into the real website and think everything is hunky dory.

Send Me Your MFA

An attacker could pretend to be technical support and ask you to send them your MFA solution along with your PIN. Maybe they claim that the MFA was compromised. Either way, the user is tricked into sending the MFA solution to the attacker along with whatever knowledge information is normally needed, and the attacker uses the sent information and device to take over the MFA logins as the user.

Receive New MFA

Alternately, an attacker pretending to be tech support can send you a new, but previously compromised device, and tell you it is important that you use the new device because the old one is no longer good. Here is a really good and sophisticated example of that type of attack. This one is so good that I still wonder if I would have detected it.

I could go on and on with tons of additional, creative social engineering attacks, but you get the idea. And I did not even include all of the phishing attacks around SMS-based and push-based MFA that are going around these days. If I included those MFA solution types, I could easily make up another one to two dozen different social engineering and phishing attacks. None of those would involve MitM attacks.

Your MFA should be phishing-resistant, but no MFA solution is entirely resistant to all social engineering and phishing attacks. Most MFA solutions…even the ones you have been told are phishing-resistant, would fall victim to most of the attacks listed above.

But perfect security is not the point. Anything can be hacked. Anything can be socially engineered. The key is to pick an MFA solution that is somewhat phishing-resistant to the most common types of attacks, of which MitM attacks are one. And it is a big, popular one.

Just make sure you do not say or think that any particular MFA solution cannot be phished. Because it is not true.

Defenses

If all MFA solutions can be hacked and socially engineered, what are you supposed to do?

Well, start by educating yourself and anyone around you on the fact that any MFA solution can be hacked and socially engineered, and there is no unhackable, un-phishable MFA solution. But also, share that some forms of MFA (here is a good list) are less phishable than others. It is good to use phishing-resistant forms of MFA.

Second, whenever you have a chance (you often do not have authority to decide what to use) to pick or use an MFA solution, try to pick a phishing-resistant MFA solution. We need to world to buy and use less easily-phishable MFA and more phishing-resistant MFA.

Last, no matter what MFA solution(s) you use or support, educate everyone involved about what the particular type of MFA solution does and does not prevent. Teach about the common types of attacks against that type of authentication, how to recognize them, how to mitigate them and the appropriate way to report them so they can be further addressed and mitigated.

A little education goes a long way.