I have spent a lot of time thinking about how to hack multifactor authentication (MFA) solutions. I have done so my whole career, deploying dozens, if not hundreds, of MFA projects. Also, I have been hired to hack different types of MFA solutions. I have hacked various biometric solutions so much that it is become boring. I have written dozens of articles about hacking MFA over the years, presented two webinars on 12 Ways to Defeat MFA and Hacking Multi Factor Authentication, wrote a free e-book and wrote a nearly 600-page book on the subject.
This article is going to summarize many of the ways I know of for MFA to be hacked in one place.
MFA Is Good
One quick note first. I want to start by saying that using MFA is usually a good thing. Almost any, although not all, MFA solutions significantly reduce some kind of hacking risk. And for that alone, MFA should be used when strong authentication is needed, where it can be used.
But there is a common, mistaken impression that using MFA means you are much less likely to be hacked and that simply is not true. For one, MFA only stops some kinds of authentication attacks. It does not even stop all authentication attacks. And it does not stop anything that is not an authentication attack, like attacks that are against unpatched software (which is the number two reason why people are successfully hacked). And there are instances where the MFA solution itself, or the user using it, is hacked and the MFA solution is bypassed like it was not even there. With 90% of MFA solutions, I can send a regular-looking phishing email and bypass the MFA solution just as easily as if the victim were using a password. I will cover this method and many others below.
General MFA Hacking
Here are some hacking techniques that work against the vast majority of MFA solutions.
The vast majority of hacking techniques against MFA have to do with social engineering the end user. The easiest MFA bypass method is to trick the victim into connecting with a fake, man-in-the-middle (MitM), proxy website before they get connected to the legitimate website they intended to go to. It is not hard to trick a person into connecting to a malicious website. All it takes is an email that looks legitimate enough that is asking them to click on a button or to verify some sort of normal-sounding information.
When the victim connects to the fake website, everything the victim does is proxied to the real website and everything the real website wants to send to the victim goes through the MitM site as well. The proxy site knows all and sees all. The malicious website can steal the user’s login credentials, whether they are using login name and password or putting in some MFA code. The attack can then use those credentials to log in to the real website as the victim. Or the attacker can capture the resulting access control session cookie, which allows them to take control of the victim’s session. If you want to see an excellent video demonstration of this technique, called cookie network session hijacking, watch this one.
Anyone seeing an attack like this done for the first time is usually quite surprised how easy it is to do. Perhaps 90% of MFA solution are susceptible to various MitM attacks of some type. Some MFA methods, like FIDO2, are not. But most are.
If your computer or device is exploited by malware or a hacker, anything it and you can do, the hacker or malware can do as well. That includes piggybacking on legitimate logins, stealing session cookies, and instituting new transactions and permissions. The most common form of these types of attacks is what is known as bancos or banking trojans. They get onto your computer just like any other piece of malware (usually social engineering or unpatched software) and then they monitor your browser activity. When you go to a bank, stock trading site or some other location, they wait for you to successfully log in, no matter how you log in, and then start a second, hidden browser session and steal all your money. Now in our mobile world, mobile-focused malware threats are now routinely doing these sorts of attacks. The EventBot malware program is a good example.
Here’s one of the hardest types of attacks to stop for 80% of MFA solutions. An attacker can trick a person into visiting a fake website that looks like a legitimate website where the user would normally use their MFA login. But instead, the website simply fakes the whole MFA routine, from asking the user to input their MFA login, to acting as if the MFA login was successfully accepted. The website can then post additional, fake actions and requests, such as, “You must update your credit card information” and then prompt the user to re-enter their credit card details. It can be hard for an MFA provider to prevent a faked authentication event from occurring.
Almost every major MFA login method allows that login to be recovered using a method that is less secure than using MFA. It is a fact of life. People lose their MFA. They lose tokens. They accidentally break things. They get new cell phones. Re-activating new MFA instances and/or logging in while the current MFA solution is not available is the number one request of any vendor using an MFA solution. Because of this, almost every vendor that uses MFA allows users to temporarily bypass their MFA solution to get logged in or to request a new MFA solution.
The most common recovery method is to have the user send a confirmation URL link to a secondary, alternate email account or to a link send via SMS to the user’s phone. Phishing criminals often take over a user’s second email account and then initiate a recovery event, which sends the link to that compromised email address.
Other common recovery methods include “password reset questions, which are officially known as personal knowledge questions.” Those are questions like, “What’s your mother’s maiden name?”, “What’s your favorite car?”, and “Who was your favorite third-grade teacher?”. Whoever thought that our mother’s maiden name couldn’t be looked up on the Internet by anyone? No matter what the questions are, they are easier to guess at than a person’s password. Google did a great paper on this a few years ago. In it, they conclude that 20% of recovery questions could be guessed on the first try by a hacker and one-sixth of the answers could be found in a person’s social media profile. Wow!
All MFA involves programming, and all programming has bugs. Every MFA solution has buggy code, and most of it can be exploited by someone who finds the vulnerability. Almost every MFA solution I investigated had one or more vulnerabilities, which eventually became publicly known, that have been used to bypass the MFA solution. Some of the more popular MFA solutions that have been around a decade or longer have a handful to dozens of published exploits. Even if your favorite MFA solution doesn’t have any known, published, bugs, it likely has them. No one has learned how to make bug-free code yet. It is the nature of software and firmware code.
Here are some example bug reports to give this exploit type some color:
Any physical device involved with MFA can be physically attacked. By that I mean, there are physical and wireless emanation connections, signals and storage devices which can be examined to reveal authentication secrets. Electron microscopes have been used to find secret encryption keys on MFA solutions and cryptographically-protected hard drives. Here’s one such example. Cans of air have been used to freeze memory chips of involved cryptographic devices in order to allow them to be transferred to a forensic computer where the secrets they contained could be revealed. The latter type of attack is known as a “cold boot” attack. Here is a good video showing how the attack works.
Specific Techniques Against Specific Types of MFA
Many different MFA attacks are specific to a particular type of MFA.
Short Message Service (SMS)-based text messages make the world go around, and SMS-based MFA is probably the most popular type of MFA solution used on the Internet. You go to some website, it sends you an SMS code that you then type back into that website, and it lets you in. The problem is that SMS (and voice calling) have very poor authentication. SMS (and voice calling) relies on an underlying protocol called SS7 (Signaling System No. 7). SS7 is weakly authenticated. It allows phone numbers to be spoofed and calls and messages to be eavesdropped on.
One of the most common SMS hacking methods is for a hacker to send an SMS message to a potential victim claiming to be someone in authority that the victim might otherwise trust. For example, an SMS message might show up claiming to be from your bank and that the bank’s “tech support” has noticed that the victim’s account was “hacked”. They then claim they are going to help you, and all you need to do to get help is to respond with a code that will be sent via SMS, “so they can authenticate” the victim and provide them with “help”. The hacker then puts the victim’s bank login account in recovery mode and chooses for that recovery code to be sent to the victim via SMS. The victim gets the recovery reset code and types it in reply to the first SMS message. The hackers than take the sent recovery code and take over the victim’s account. The problem is that anyone receiving an SMS message has no way of recognizing who is contacting them unless they already have the sender’s phone number in their contact list. So, anyone can claim to be anyone else, and hackers often do. Here is an example of an SMS-based attack.
A similar attack can be done using voice calling. Here’s an example.
Another common attack against SMS-based MFA solutions is known as a SIM swap attack. SIM stands for Subscriber Identity Module. Every cell phone has a memory chip or part of its memory storage area that contains the information that essentially identifies your phone and your phone number to the global cell phone network. Turns out that hackers can use various tricks to move your SIM and its information to their phone. When this happens, your phone stops working, but it is not always very apparent. It could take you hours to notice that no one has called you or text messaged you. In the intervening time, a hacker could have put your MFA account into account recovery mode and have the reset PIN texted to your phone number or simply log in to a site of yours that uses SMS-based MFA. In any case, the authentication information headed for your legitimate phone gets re-routed to their phone and they use that SMS-provided information to take over your account.
Here are some related news stories about SIM swap attacks:
All-in-all, SMS-based MFA methods are considered among the easiest types of MFA to compromise.
One-Time-Password (OTP) tokens and phone apps (like Google Authenticator) send 4- to 6-digit codes which are updated at some set period of time (say every minute) or after some event (like you logging in successfully or you pushing a button to get the next code). The OTP codes are generated using a one-time selected random value, and other information, which is stored in a database and on the MFA OTP device or instance. If attackers can access the database where the OTP “seed” secret is stored, they can create additional, unauthorized instances of the OTP device or instance.
This has happened at the corporate level (example here) and at the individual level (see this example here). OTP codes can also be MitM’d, meaning that the codes that you type in at an MFA prompt can be stolen as you type them, if typed into a look-alike, fake, proxy website. This type of hacking happens every day, and here is a real-world example of that here.
Smartcards are the original MFA device. These credit card-sized MFA tokens contain a cryptographically secure microchip, which protects the stored secrets. Except, there is a whole subculture of hackers which, if they can physically access your smartcard, can remove the chip, chemically remove physical protective layers and then steal your secret encryption keys using an oscilloscope device. There are many great white papers on these types of smartcard attacks, including these: https://www.cs.uic.edu/~sloan//my-papers/ieee-messerges-proof.pdf and www.infosecwriters.com/text_resources/pdf/Known_Attacks_Against_Smartcards.pdf. This is just to say that there are likely hundreds to thousands of people who know how to compromise your smartcard if they can get physical access.
But it doesn’t always take physical access. In this video, I show how changing a single email address lets an unprivileged insider take over a super administrator’s account. In this example, I know that Microsoft Active Directory links users’ smartcards to their logon accounts using a value in the User Principle Name (UPN) field. Most people’s UPN is the same as their email address, although it does not have to be. But, I show that temporarily changing a target victim’s email address allows another person to log in as that person even if that account is protected by a smart card. The attacker logs in as themselves, but because the victim’s UPN field has been changed to the hacker’s UPN value, the hacker will be given the other user’s login access control. Not only that, but everything the hacker does will be tracked in Windows and to the Event Log as the victim. It is a difficult attack to detect and stop, and leaves almost no evidence of the attack. This is not to say smartcards are bad. They are not. They are a great MFA solution and have worked for decades to protect some of the top security networks. But just like all MFA solutions, they can be hacked.
Passwords Are Here to Stay for at Least Another Decade
One of the most frequently asked questions I receive is regarding passwords and how long I think people will be using them. It seems every year there are at least a few articles predicting the end of passwords. I have been reading those articles since 1990.
I think most people will be using a combination of many passwords and multiple MFA solutions, for various logins, for at least the next ten years. I do not see a passwordless society (too many sites and services only accept passwords) and none of the things that would replace them work on even 2% of the world’s websites and services. And the things that replace passwords can all be hacked. I think we will see less and less passwords over time, but it will be quite some time, if ever, before no one is using a password.
Best MFA Advice I Can Give
The biggest lesson I have learned and want to pass along is that whenever you use or administrate MFA, make sure that the involved users understand the common ways they can be hacked and educate them to recognize, avoid and report those types of attacks. A little knowledge is a beautiful thing. You would not ask your end users to use passwords without a few hints on how they can be hacked and abused. You should do the same with your MFA solutions.