Understanding MFA Bypass

While Multi-Factor Authentication (MFA) was introduced with promises of near-invincible security, hackers continue to find ways to exploit it. So, how is this still happening? And how do people stop these attacks from happening?

Understanding Multi-Factor Authentication (MFA)

To fully understand Multi-Factor Authentication, we first need to understand the different types of authentication. The three primary factors of authentication are "something you know," "Something you have, "and "Something you are". MFA is just using more than one of those factors.  Examples of 'Something you know' could encompass security questions and PINs "Something you have" could be Radiofrequency Identification (RFID) or Near Field Communication (NFC) badges, phones, and USB tokens. Lastly, "Something you are" includes fingerprints, facial features, iris or retina scans and other biometrics.

Bypassing Multi-Factor Authentication (MFA)

Bypassing security questions and pin numbers.

• People can bypass Security questions and pins using social engineering or guessing/brute-forcing. The ThreatLocker Ops team has done research to figure out what the worst security questions are; check out that research here, Are Security Questions Secure?

Bypassing biometrics.

• While fingerprint scanners and facial recognition seem foolproof, reality is different. Fingerprint replicas can be crafted with putty, akin to movie scenes. Although retina and facial recognition are generally robust, some scanners can be tricked with images or 3D-printed faces. Apple's initial Face ID struggled with distinguishing between twins or look-alikes, highlighting the challenges of biometric precision.

Bypassing phones, authentication apps, RIFD/NFC.

Push MFA alerts

• During the early MFA days, users received authentication notifications on their phones or emails with just a single button to authenticate. Exploiting this, attackers flooded users with continuous MFA alerts until the legitimate user became fatigued, eventually pressing the MFA email or phone button. This phenomenon became known as MFA fatigue.

Example of a push MFA:

Pin MFA alerts

• As MFA transitioned to PINs to address MFA fatigue, another loophole emerged—SIM swapping. This method allows individuals to bypass SMS/RCS (Text Message) MFA by socially engineering the cell provider into providing the attacker with the user's SIM card. Subsequently, the attacker gains access to any SMS/RCS messages that the MFA system would typically send.

Example of Pin MFA:

Authentication apps

• There are various methods to bypass MFA using an authentication app. One approach involves stealing the token of an already authenticated user. Did you ever notice that on some sites, they only ask once in a while for your MFA? That is because they used stored tokens. So that is what the attacker is trying to steal so they don't have to go through the MFA process.  Another approach is the Machine-In-The-Middle Attacks (MITM), or Man-In-The-Middle (MITM), or Adversary-in-the-middle (AITM). In this scenario, someone or a computer sits between the user's computer and the desired service. When the user logs in and performs the MFA process, their computer first communicates with the attacker's machine, which then relays the data to the intended site, tricking it into recognizing the attacker's machine as a legitimate user.

RIFD / NFC

• Using specialized tools, an attacker can replicate a user ID card, obtaining identical access privileges. For instance, by cloning an IT manager's ID card, the attacker gains unauthorized access to the server.

How can people prevent MFA bypass?

The main thing to help stop these attacks is to do the following:

• Train users to be aware of these attacks.  
• Do not use the security questions mentioned above.
• Enable alerts for account changes for cellular providers.  
• Train users to be mindful about what they are posting on social media.  
• Don’t use PIN numbers that can be easily guessed. Examples of easy pins to guess are birthdays, phone numbers, etc.  
• Use HTTPS and not HTTP.  
• Verify Certificates.