Why Is the Majority of Our MFA So Phishable?

The huge push to multifactor authentication (MFA) is ostensibly to help people avoid getting so easily phished. But are we making the same mistake with MFA and making too much of it too easily phishable? Will we be pushing our organizations and end-users to MFA only to repeat many of the same mistakes? The US government is worried about it. You should be worried as well.

The U.S. government has been pushing people to avoid SMS- and voice call-based multifactor authentication (MFA) for years, but their most recent warning is to avoid any MFA that is overly susceptible to phishing. That is only commonsense (since most data breaches involve social engineering), but what MFA types do they mean and what does that mean for you? Read on.

The U.S. Government Has Discouraged SMS- and Voice Call-Based MFA Since At Least 2017

The U.S. has been pushing people to avoid SMS- and voice call-based MFA ever since it pushed out drafts of its new Digital Identity Guidelines, NIST Special Publication 800-63 (https://www.nist.gov/itl/applied-cybersecurity/tig/projects/special-publication-800-63), which was finalized in 2017.

They declared it in SP 800-63-3, Part B (https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-63b.pdf) by stating the “Use of the PSTN [Public Switched Telephone Network or a phoneline connection in human-speak] for out-of-band [authentication] verification is RESTRICTED”. This means any authentication, including MFA that relies on your phone or phone number as part of its authentication, is “restricted”. This includes all SMS- and voice call-based MFA.

Note: This does not mean all MFA-based phone apps are restricted. Most phone apps require an additional authentication that is not reliant on or tied to a phone number. If the user’s phone number gets re-routed, the installed phone app does not go along with it and any thief installing the same phone app on their phone using your phone number will not be able to automatically use the app, logging in as you, without additional authentication.

What does “restricted” mean? It is defined in the same document at section 5.2.10. In short, it includes language that states that restricted authentication is very risky. Perhaps too risky. They require that any governed organization using a restricted authentication method should understand it, accept the risks, let any user who is using a restricted authentication method know that the solution is extra risky, and let the user choose at least one other non-restricted authentication solution.

While the requirement of letting the user proactively know they are using an extra risk authentication method may happen at some government sites and services, SMS-based MFA is probably the most used and forced MFA method used on the Internet by tens of thousands of companies…companies you and I use…and never have they ever warned me that the SMS-based (or voice call-based) MFA method they are forcing me to use is extra risky. Perhaps it’s buried in some of their end-user license agreements, but I read them all the time and I’ve never seen that language. To be fair, it’s only a requisite for sites and services which are obligated to follow NIST requirements.

The Digital Identity Guidelines finished its section on RESTRICTED MFA solutions by stating that vendors using restricted MFA solutions must “Develop a migration plan for the possibility that the RESTRICTED authenticator is no longer acceptable at some point in the future [emphasis added] and include this migration plan in its digital identity acceptance statement.”

Now a Bunch of Other MFA Solutions Have Been Declared Persons Non Grata

Well, some future point in time has arrived and it, rightly, includes more types of MFA solutions which the government says vendors and people should not use because they are overly susceptible to phishing.

President Biden’s recent executive order (EO 14028), among many things, asked all agencies to develop zero trust architectures, which most security experts welcomed. In a related clarifying follow up memo (https://zerotrust.cyber.gov/federal-zero-trust-strategy/#identity) it states, “For routine self-service access by agency staff, contractors and partners, agency systems must discontinue support [emphasis added] for authentication methods that fail to resist phishing, such as protocols that register phone numbers for SMS or voice calls, supply one-time codes, or receive push notifications. [emphasis added]”

So, there you go. The U.S. government is telling its agencies, and really, the whole world, “Stop using any MFA solution that is overly susceptible to phishing, including SMS-based, voice calls, one-time passwords (OTP) and push notifications!” This describes the vast majority of MFA used today. There are no published figures on this, but I bet that over 90% of all MFA is susceptible to easy phishing. To be clear there are MFA solutions that are less susceptible to easy phishing, such as FIDO (Fast Identity Online), but they are not as widely deployed as the solutions that are more susceptible.

Note: Most broadly used MFA is susceptible to phishing and social engineering, but some types are far more susceptible to it and have been widely compromised by phishing attacks in the real world. It is the MFA solutions that have proven to be overly susceptible to phishing that we need to be most concerned about.

Some MFA Phishing Examples

Unfortunately, most MFA users can be tricked into revealing their MFA codes or into letting an attacker steal their access control token by simply clicking on the wrong link sent in a phishing email. The link sends the victim to a “proxy” server that then links the victim to the legitimate destination server the victim thought they were going to in the first place. But the proxy server is now capturing everything sent from the legitimate destination server to the victim; and vice-versa. This includes any login information: login name, password and any provided MFA codes. The attacker can even capture the resulting access control token cookie, which allows the attacker to take over the victim’s session.

Hacking OTP MFA Demo

Here is a demonstration great video on it: https://www.youtube.com/watch?v=xaOX8DS-Cto by KnowBe4’s Chief Hacking Office, Kevin Mitnick. Screenshot of the video is below.

I think anyone who has not seen the video before is shocked at how easy it is to phish around someone’s supposedly super secure MFA solution. This attack type does not work against all MFA solutions, but probably 80% to 90% of them. Essentially, any MFA solution that cannot tell the difference between a logon coming from the legitimate user (and their device and browser) and another in-between device and browser, can be tricked using this method. MFA that has required pre-registration of specific, identified, devices, and will only “activate” when it is directly communicating with those devices, is less susceptible.

SMS Bogus Tech Support Scams

Any login method protected by SMS can be tricked as easily using text messages. Here is an example where the attacker is spoofing that they are Google tech support to the victim. The attacker would have to know the victim’s Gmail address and phone number to pull this off, but those are pretty easy to learn in today’s world. In this fake attack example, the attacker is pretending to be Gmail or Google tech support. They send this SMS message.

Then the attacker goes to the victim’s Gmail account and types in the user’s email address to start the login process.

The attacker clicks on the Forgot password link provided by Gmail (and they really do not know the user’s password). This takes them to another screen which asks if they want to try the password before the current one. The attacker instead chooses Try another way.

Then Gmail offers the attacker (thinking it is the legitimate user) a handful of different ways to recover the account, one of which is to send an SMS message with the recovery code.

The victim gets the recovery code.

And then types it back in response to the attacker’s initial message.

It is game over! The attacker uses the recovery code to take over the account.?

SMS Spoofed Recoveries

But here are even easier SMS recovery hacks. In these instances, the attacker determines ahead of time which of the victim’s targeted accounts allow SMS recovery which sends a recovery PIN without a lot of identifying information. This would describe probably half of all SMS recovery messages.

Then the attackers send any social engineering message they like in order to trick the user into accepting the recovery code, except the victim does not know it is a recovery code to some other service. They just think the person contacting them currently is sending them a PIN verification code for the current transaction. The attacker can use any social engineering scheme that motivates the victim to re-post the code back to the scammer. Here are some examples:

Asking the victim to type in YES to approve “being added to a service” just adds to the fraudulent validity of the message. I mean, why would a hacker ever ask permission? Here are two other social engineering schemes I just thought up off the top of my head. They are both going to trick a lot of users.

Let’s say that the PIN recovery message is branded (meaning contains the legitimate service’s name). All the attacker has to do is say that they use Gmail or Microsoft 0365, or whatever brand they are impersonating, as part of their authentication scheme. It is really not that hard to do. All SMS-based MFA can be stolen, hijacked, MitM’d and impersonated, far too easily. This type of attack works against other non-SMS-based MFA methods as well. ?

Google recently published a report (https://blog.google/threat-analysis-group/countering-threats-iran/) revealing this sort of scam as used by sophisticated advanced persistent threat (APT) attackers for years. In this real-world example, the attackers first established contact with the victims using fake social media identities, established trust, and then invited the researchers to attend a (fake) conference. Some related text and the fake registration web site shown below.

During “registration” for the fake conference, the victim could choose which social media identity they wanted to use for registration. Many of us are familiar with this for OAuth-participating web sites, where they will allow you to use your Facebook, Twitter, Apple, etc. ID as your logon for convenience instead of needing to create an entirely new identity and password. When the user “activated” their registration, they would be sent what they thought was an activation code needed to register for the conference. Instead, the attackers sent them a reset code which would allow the attackers to take over the victim’s identity account.

Note: For more information on OAuth phishing, see https://blog.knowbe4.com/watch-out-for-oauth-phishing-attacks-and-how-you-can-stay-safe.

Phishing Pushed-Based MFA

With push-based MFA, when you are logging onto a website, a related authentication service “pushes” a login approval message to you. You click on “Approve”, “Yes” or something like that to get logged in. Or choose the other option to prevent the login. It is pretty easy to use and fairly secure. See an example push-based approval notice below.

Push-based authentication is used by all sorts of popular vendors, like Google (shown above), Amazon and Microsoft. And it would seem a fairly foolproof method for authentication.

Turns out end users frequently approve logins that they are not initiating. It is a very common problem in an environment where pushed-based authentication has been implemented. Users are approving malicious logins…many times when the user is not anywhere near their computer. They are home, watching a TV program, eating dinner or whatever, when a push-based approval notice comes in – and they approve it.

The first time I heard of this issue was from a Midwest CEO. His organization had been hit by ransomware to the tune of $10M. Operationally, they were still recovering nearly a year later. And, embarrassingly, it was his most trusted VP who let the attackers in. It turns out that the VP had approved over 10 different push-based messages for logins that he was not involved in. When the VP was asked why he approved logins for logins he was not actually doing, his response was, “They (IT) told me that I needed to click on Approve when the message appeared!”

And there you have it in a nutshell. The VP did not understand the importance (“the WHY”) of why it was so important to ONLY approve logins that they were participating in. Perhaps they were told this. But there is a good chance that IT, when implementing the new push-based MFA, instructed them as to what they needed to do to successfully log in, but failed to mention what they needed to do when they were not logging in if the same message arrived. Most likely, IT assumed that anyone would naturally understand that it also meant not approving unexpected, unexplained logins. Did the end user get trained as to what to do when an unexpected login arrived? Were they told to click on “Deny” and to contact IT Help Desk to report the active intrusion?

Or was the person told the correct instructions for both approving and denying and it just did not take? We all have busy lives. We all have too much to do. Perhaps the importance of the last part of the instructions just did not sink in. We can think we hear and not really hear. We can hear and still not care. This is one of the core points of Perry Carpenter’s book, Transformational Security Awareness: What Neuroscientists, Storytellers, and Marketers Can Teach Us About Driving Secure Behaviors (https://www.amazon.com/Transformational-Security-Awareness-Neuroscientists-Storytellers/dp/1119566347/).

Many professional pen testers tell the same story. They all state how often users in environments with push-based MFA are approving their “malicious” login attempts. One pen testing team leader told me, “When we hear that a client has push-based notification, we literally start laughing. You cannot help it. We know what we are going to do and how we are going to get in. I would say three out of five people we test just approve our logins. It is like hitting all the buttons on an apartment building buzzer console to see which random people will buzz you through the locked security door because someone’s always waiting for someone. There are always people who will just click “Yes” because they have been trained to click on “Yes” and the whole reason of when they should click on “Yes” and “No” has become a forgotten distraction. It makes our jobs easy.” Most of the penetration teams say that it is so easy to break in using push-based MFA that they would not recommend it to anyone. The U.S. government agrees. And that is a problem when our largest vendors, including Google and Microsoft, are recommending to everyone as the way to solve the world’s hacking problems.

The whole reason the world is being recommended to use MFA instead of passwords is to prevent phishing attacks against login credentials. But it appears that the vast majority of MFA solutions are overly susceptible to phishing. Are we pushing organizations and users to what is being touted as the salvation to our phishing problems and setting them up for failure? The US government and many other computer security experts think so.

Government Does Define Acceptable MFA

The U.S. government does not hate or think all MFA is easily phishable. In the same zero trust executive order (https://zerotrust.cyber.gov/federal-zero-trust-strategy/#identity), it states, “This requirement for phishing-resistant protocols is necessitated by the reality that enterprise users are among the most valuable targets for phishing, but can be given phishing-resistant tokens, such as Personal Identity Verification (PIV) cards, and be trained in their use. For many agency systems, PIV or derived PIV will be the simplest way to support this requirement. However, agencies’ highest priority should be to rapidly implement a requirement for phishing-resistant verifiers, whether this is PIV or an alternative method, such as WebAuthn.”

The U.S. government has strongly supported the use of PIV cards for decades. Learn more about PIV cards here: https://www.osp.va.gov/PIV_Information.asp and here: https://www.nist.gov/topics/identity-access-management/personal-identity-verification-piv. I worked with a very common U.S. government PIV implementation known as CAC cards (https://www.cac.mil/common-access-card/). Most government employees must insert one in their smartcard reader on their government issued computer and input a PIN to log into their government device, use the network or run any CAC-protected application. The U.S. government is also big on biometrics (although they have plenty of their own issues including ability to be phished). WebAuthn is a passwordless authentication standard that any MFA solution can support. It is already very closely affiliated with FIDO (https://fidoalliance.org/) solutions.

Phishable MFA Must Evolve

So, what does the government’s stance on overly phishable MFA mean for the rest of us? For one, most MFA is overly susceptible to phishing. It is so overly phishable that it really does not provide as much protection as most organizations and users think. We need to change that.

There are many different ways to take existing phishable MFA solutions and make them less phishable. Sometimes it means adding more information and context to a user’s logon so they can be assured as to what they are really logging into. Other times it means updating the solution so that simple phishing attacks simply don’t work. Many times it means better end-user education about the types of phishing attacks that their particular MFA method may be susceptible to and then periodically doing simulated phishing tests to make sure they “heard” and understood the education. And sometimes, an overly phishable MFA solution just needs to disappear.

Every MFA solution needs to be security reviewed and the common ways that attackers can bypass and phish around them need to be identified and remediated. We should not accept or use any MFA solution that can be easily bypassed by a phishing email containing a rogue link. MFA was supposed to stop easy phishing from working in the first place. But it is not true for most MFA solutions.

Phishing-susceptible MFA solutions need to be redesigned to prevent easy phishing. It can be done. How it can be done is dependent on the type of solution. Most of the phishing can be defeated by doing something like FIDO-compliant MFA devices do by requiring pre-registration to the involved legitimate websites by the device to the site and the site to the device. That way, if a user gets tricked into visiting a fake website, their MFA solution will simply not work and not provide any authentication information or codes.

Educate Everyone

But it is going to take a long time for most MFA methods to be modified to prevent phishing. Every stakeholder in any MFA solution should be educated about the hacker methods that could be used to hack and bypass their particular MFA solution. Vendors should provide threat modeling to potential customers. Everyone – buyers, senior management, sysadmins, users – should understand how their MFA solution can be hacked and bypassed, and instructed how to prevent it. When you have push-based MFA users approving logins they are not involved in, you know there is a lack of education. We do not let our end users use passwords on our systems without giving them warnings and education (e.g., “Do not share your password with anyone else”, “We will never ask for your password in an email”, “Your password should be long and contain some complexity, and never be shared with any other website or service”, and so on). We just need to do the same with MFA users, especially until our MFA solutions become less phishable.

Last Point

I have recently heard an executive from one of the largest companies currently pushing MFA as THE solution to 99% of our computer security problems say publicly at a large MFA conference, "Use MFA. Any MFA. We don't care if it is weak MFA. Just get on MFA!"

Ignoring the fact that MFA doesn't even come close to solving 99% of our problems, I have to question if going to MFA...any MFA...is the right messaging? The whole reason the world is trying to get to MFA is supposedly to prevent easy phishing. But if the MFA method they are pushing you to is easily phishable, are we really gaining much? I'm worried that much of the world is being sold a bill of goods that will be already spoiled on delivery. Is over promising and undelivering going to restore people's faith in the computer security industry or are they going to see it as just another way vendors used to sell more product that doesn't work as advertised? We can do better. We need to do better.

Other Relevant MFA Links

Hacking Multifactor Authentication book (Wiley)

Book discussing over 50 ways to hack various MFA solutions. Starts with pointing out the strengths and weaknesses of passwords, details how authentication works, covers all the various MFA methods and how to hack and protect them, and ends with telling the reader how to pick the best MFA solution for them and their organization.

https://www.amazon.com/Hacking-Multifactor-Authentication-Roger-Grimes/dp/1119650798

Free KnowBe4 Hacking MFA e-book

41-page Hacking MFA ebook, covers 20 ways that MFA can be hacked, was the beginning source material for the larger Hacking Multifactor Authentication book

https://info.knowbe4.com/12-way-to-hack-two-factor-authentication

KnowBe4 Webinar

Ways to Hack MFA webinar

One-hour webinar on how to hack various MFA solutions

https://info.knowbe4.com/webinar-12-ways-to-defeat-mfa

KnowBe4 MFA Assessment Tool

Free, Multifactor Authentication Security Assessment tool

Answer a dozen or so answers to correctly describe your current MFA solution (or one you are considering) and get back a report detailing all the ways it could be hacked

https://www.knowbe4.com/multi-factor-authentication-security-assessment

KnowBe4’s Multifactor Authentication web portal

All of KnowBe4’s free MFA content

https://www.knowbe4.com/how-to-hack-multi-factor-authentication