MFA Bypass Attacks: Why MFA is Not a CYA

The volume and sophistication of phishing attacks is at an all-time high. One of the most highly recommended security controls for preventing unauthorized access is multi-factor authentication (MFA), which can add an important layer of security beyond a traditional password. It comes in many different forms, including:

• Push notifications
• SMS
• Authenticator apps/Soft tokens
• Voice
• Email
• Hardware token

Is MFA a fail-safe? Several recent high-profile MFA bypass attacks would suggest it still has weaknesses that can be circumvented. Despite having MFA enabled, these incidents involved threat actors successfully bypassing traditional MFA methods mentioned above. 

Read on to explore ways threat actors are targeting and circumventing common MFA implementations, and get recommendations for reducing the risk of one of these attacks affecting your organization.

MFA Improves Security—But Still Has Weaknesses

Poorly worded phishing emails have evolved significantly. Modern tactics include “smishing,” or SMS phishing messages, QR code links that bypass many modern security email filtering tools, and convincing calls to IT help desks to replace “lost” MFA devices. Advancements in artificial intelligence (AI) and automation have made it easier for threat actors to carry out attacks on target organizations and individuals at scale. 

Here’s an example of a phishing email with a QR code redirecting a user to a malicious site: 

Users with MFA enabled are significantly less likely to get hacked. In addition, MFA is being used by an estimated 64% of users, according to a 2023 Secure Sign-in Trend report from Okta. 

There are, however, many forms of multi-factor authorization, and some forms are more secure than others. Increased adoption of MFA has led threat actors to evolve their techniques. Threat actors, such as Scattered Spider, have gained a reputation for being “social engineering experts” after executing a number of several high-profile attacks. These have included tricking IT help desks into enrolling replacement MFA devices, impersonating IT help desk employees, tricking colleagues into installing remote monitoring and management (RMM) tools, and stealing web session cookies to single sign-on tools, such as Okta . 

Enrolling New MFA Devices

Help desks (also referred to as service desks) are designed to assist users with issues, such as connectivity and access. An increasing number of attacks have involved threat actors calling help desks, sometimes with voice altering AI or native western English speakers, with conceivable stories involving an urgent deadline and access being required immediately. 

The target organization may not have strong employee authorization controls, or they may have authentication control weaknesses, such as asking for publicly available information or personal information that’s attainable on the surface, deep, or dark web (e.g., mother’s maiden name, past street address, high school mascot, etc.). Once the threat actor is enrolled with a replacement MFA device, the threat actor gains access to the victim’s accounts and systems, which can lead to data exfiltration, privilege escalation, and further reaching attacks. 

Remote Monitoring and Management Tools

RMM tools, such as AnyDesk, ScreenConnect, Team Viewer, and LogMein, are legitimate technical support programs that are being widely abused by threat actors, especially since they provide similar capabilities as other attacker tools but don’t always trigger alerts by antivirus and EDR security tools . Threat actors have also used phone calls and text messages to impersonate IT personnel and direct victims to download and run commercial RMM tools . Once installed, the RMM tool runs on the host system and provides significant capabilities to manage and modify the host system remotely without requiring MFA. RMM tools also allow remote users the ability to move laterally to other systems on the network.  

Stealing Web Session Cookies

Web session cookies are becoming increasingly favored by threat actors through in-the-middle phish kits and botnet information stealing malware. Depending on how accounts are secured, a stolen cookie of an authenticated session can be enough in some cases to login as the user from another device without any MFA prompts. 

How to Reduce the Risk of MFA Bypass Attacks at Your Organization

• Organizations should implement MFA for access using the strongest available method. Prioritize accounts with the highest risk, such as privileged administrative accounts for key systems. Here are the most secure MFA methods sorted by high to low strength:
• Hardware-based, phishing-resistant MFA (e.g., FIDO/WebAuthn)
• If hardware-based MFA is not available, then mobile app-based soft tokens (preferably push notification with number matching) or emerging technology, such as FIDO passkeys, are sufficient
• MFA via SMS or voice should only be used when no other options are possible
• MFA enrollment requests should be properly vetted and void of information that may be identified through surface, deep, and dark web searches. MFA enrollment requests involving privileged accounts should be scrutinized and follow increased vetting procedures. 
• Audit remote access software and implement application controls to manage and control execution of software, including allowlisting for only approved remote access programs.
• Perform on-going scans of deep and dark web data sources to help detect stolen credentials and sensitive data. Organization-owned data and credentials identified during deep and dark web scans should be reviewed for further evidence of threat actor use on the dark web.
• If a web cookie session is identified as stolen, perform the following actions:
  • Invalidate the user’s sessions to limit stolen cookies from being used to access the affected application. If single sign-on (SSO) is involved, all SSO sessions for the user should be invalidated and reviewed individually for signs of unauthorized activity.
  • Require the user to reset their password and implement MFA, if it wasn’t already required.
  • Identify how the information stealer came to be on the system. Review the login history for the affected user and identify any unauthorized access.

Experiencing an incident or need help implementing these recommendations? Contact ZeroFox today. 

Tags: Incident Response