Hackers are more frequently using social engineering attacks to gain access to corporate credentials and breach large networks. One component of these attacks that is becoming more popular with the rise of multi-factor authentication is a technique called MFA Fatigue.
When breaching corporate networks, hackers commonly use stolen employee login credentials to access VPNs and the internal network.
The reality is that obtaining corporate credentials is far from difficult for threat actors, who can use various methods, including phishing attacks, malware, leaked credentials from data breaches, or purchasing them on dark web marketplaces.
To counter this, enterprises have increasingly adopted multi-factor authentication to prevent users from logging into a network without first entering an additional form of verification. This additional information can be a one-time passcode, a prompt asking you to verify the login attempt, or the use of hardware security keys.
While threat actors can use numerous methods to bypass multi-factor authentication, most revolve around stealing cookies through malware or man-in-the-middle phishing attack frameworks, such as evilginx2.
However, a social engineering technique called ‘MFA Fatigue’, aka ‘MFA push spam’, is growing more popular with threat actors as it does not require malware or phishing infrastructure and has proven to be successful in attacks.
What is MFA Fatigue?
When an organization’s multi-factor authentication is configured to use ‘push’ notifications, the employee sees a prompt on their mobile device when someone tries to log in with their credentials. These MFA push notifications ask the user to verify the login attempt and will show where the login is being attempted.
An MFA Fatigue attack is when a threat actor runs a script that attempts to log in with stolen credentials over and over, causing what feels like an endless stream of MFA push requests to be sent to the account’s owner’s mobile device.
The goal is to keep this up, day and night, to break down the target’s cybersecurity posture and inflict a sense of “fatigue” regarding these MFA prompts.
In many cases, the threat actors will push out repeated MFA notifications and then contact the target through email, messaging platforms, or over the phone, pretending to be IT support to convince the user to accept the MFA prompt.
Ultimately, the targets get so overwhelmed that they accidentally click on the ‘Approve’ button or simply accept the MFA request to stop the deluge of notifications they were receiving on their phone.
This type of social engineer technique has proven to be very successful by the Lapsus$ and Yanluowang threat actors when breaching large and well-known organizations, such as Microsoft, Cisco, and now Uber.
Therefore, if you are an employee who is the target of an MFA Fatigue/Spam attack, and you receive a barrage of MFA push notifications, do not panic, do not approve the MFA request, and do not talk to unknown people claiming to be from your organization.
Instead, contact the known IT admins for your company, your IT department, or your supervisors and explain that you believe your account has been compromised and is under attack. You should also change the password for your account if possible to prevent the hacker from continuing to log in and generate further MFA push notifications.
Once your password has been changed, the threat actor will no longer be able to issue MFA spam, giving you and your admins room to breathe while the compromise is investigated.
Tips from the Pros
We don’t pretend to be multi-factor authentication or identity management experts, but others who are, were gracious enough to share their thoughts with BleepingComputer or on Twitter.
Security professionals have recommended disabling MFA Push notifications, and if that’s not possible, enabling number matching for increased security.
Microsoft’s MFA number matching, also known as Verified Push in Duo, is a feature that displays a series of numbers to a user attempting to log in with their credentials. These numbers must then be entered into the account owner’s authenticator app on their mobile device to verify they are logging into the account.
As only the person logging into the account will see these numbers, any attempts to convince a user to enter them into their authentication app should be immediately seen as suspicious, especially if that login attempt is from another country.
Microsoft plans on enabling it by default for all Azure Active Directory tenants soon after the feature becomes generally available.
Another suggestion is to limit the number of MFA authentication requests per user [Microsoft, DUO, Okta], and when those thresholds are exceeded, lock the accounts or raise alerts to the domain admin.
Some suggest the enterprise move to FIDO hardware security keys to secure logins, but other researchers and security professionals are concerned it is still too early to require adoption and may not be compatible with some online services.
If your organization can overcome the complexities of requiring only security keys for logins, then this may be a direction you can take to increase your login security.
Finally, BleepingComputer has received recommendations from Microsoft, Okta, Duo, and CyberArk on mitigating these attacks, which we have shared below.
Microsoft:
In response to our questions on the best way to mitigate MFA Fatigue attacks, Microsoft’s Alex Weinert, Director of Identity Security, shared the following tips:
- Microsoft strongly suggests removing any factors which rely on simple approvals. Approvals should require that the user has provable context on the login request. For example, instead of “press 1 to approve” users should be required to round-trip information presented in the login request, e.g. “enter the number you see on the screen.” Classic “OTP” approvals in which the user has to enter information provided in the authentication request are great, as are requirements to enter screen information on that authenticating device. The Microsoft Authenticator supports push notifications with screen context (as well as information about login location, application etc.) and which require the user enter data provided on screen. This is our recommended approach and our tests have proven it is highly effective at disrupting MFA Fatigue attacks.
- We would reiterate that the most effective mechanism is to avoid methods which allow simple approvals which are subject to fatigue. In the Microsoft Authenticator, in addition to the mechanisms above we are suppressing notifications which originate with features unfamiliar to the good user, instead asking the user to check the app. This prevents any bad experiences triggered by the adversary by pushing unexpected notifications. Additionally, a bad actor cannot send multiple Authenticator passwordless notifications to a given user per time window if the previous ones were denied or not responded. Access rules (in our products, Azure AD Conditional Access) can be configured to prevent authentication from proceeding if the device, location, or risk levels are unacceptable.
- Azure AD provides risk levels on every login, and login attempts which show risk in conjunction with simple-approval MFA methods should be investigated to ensure that an MFA fatigue attack wasn’t indicated.
- Broadly, many organizations have deployed “layered on” MFA which added a phone call or text message to password based authentication. While this is provably effective at deterring attacks, attackers are using techniques like MFA fatigue to penetrate these defenses. Today, passwordless solutions effectively defend against both this and more advanced adversary-in-the-middle attacks. We strongly recommend that as organizations look at changing their authentication policies, they move towards modern authentication methods such as such as the Microsoft Authenticator, Windows Hello, or the industry standard FIDO standards.
Okta:
Okta’s Sumit Bahl, Security Product Director, also shared some general advice for BleepingComputer readers on mitigating MFA spam:
- Advocating for user education and user preparedness, as those can scale across vendors and technologies.
- Setting thresholds and triggering alarms to your soc if events exceed specific thresholds (regardless of technology, most or all orgs have a SOC that monitors events and logs for the systems they use).
- Moving to higher assurance factors such as WebAuthn.
For those using Okta’s services, Bahl also recommended the following tips:
Okta’s Adaptive Multi-Factor Authentication (Adaptive MFA) analyzes the user’s context at login time in enforcing security. This approach considers device posture, user behavior, and location context to allow or deny access, through an adaptive, risk-based approach. If the risk is high then the user should be prompted for strong authentication factors like Okta Verify, WebAuthn etc. Additionally, organizations should consider the option of passwordless authentication to reduce the risk of MFA Fatigue attack. Pairing it with Okta ThreatInsight gives you an even stronger risk assessment tool, as ThreatInsight analyzes data from a wealth of sources to uncover risks that could otherwise have caused trouble.
Okta ThreatInsight acts as the first layer of defense to block high-volume credential-based attacks that are directed at Okta endpoints. ThreatInsight is evaluated pre-authentication before all logon events, therefore addressing the issue of account lockout. So When ThreatInsight is blocking suspicious IP addresses, login attempts from suspicious IPs do not count towards a user’s login attempts. This means that legitimate users accessing Okta from a known device will still be able to access their account.
Risk based Authentication identifies the context in which users attempt to login and enables organizations to automate security by implementing significantly stronger authentication techniques and remediation when the scenario calls for it. As the user tries to sign in, Risk-based Authentication, a feature of Adaptive MFA, assigns a risk score to the attempt based on contextual cues, such as their location, device, and IP address. Based on the risk level, the solution can deny access or prompt the user to submit stronger authentication factor to guard against potential breaches.
Cyberark:
Cyberark’s Shay Nahari, CyberArk VP of Red Team Services, also provided tips on strengthening MFA and prevent MFA Fatigue.
“MFA Fatigue is only one specific type of MFA attack. As attackers continue to innovate, they’re finding new ways to target MFA and circumvent critical security controls. One method to mitigate MFA Fatigue is switching your organization’s MFA setting or configuration to require a one-time password (OTP), versus a push notification. When faced with repeated authentication messages and touchpoints, users can often become careless and unwittingly create openings for attackers. While OTP requires more involvement from the user, it can mitigate the risk associated with MFA Fatigue. Additionally, an endpoint privilege management solution [like CyberArk Endpoint Privilege Manager] can help prevent the theft of cookies that can allow an attacker to bypass MFA controls. In the grand scheme of defense strategies, endpoint privilege management that can protect client-side credentials is an important layer.
In addition, the SOC can set anomaly-based triggers that notify it if certain thresholds are exceeded, or block user authentication from suspicious IP addresses.
As part of my team’s adversary simulation exercises, we look at different types of detections including hard indicators of compromise (IOCs). Hard IOCs are fundamental to a specific attack. In the case of MFA Fatigue, the attacker already has access to credentials and needs to solicit the user to approve the MFA notification in order to gain access. If an organization is successful in blocking MFA Fatigue, the attacker will be forced to choose another attack path. The OTP configuration can make the user less susceptible to this type of attack and significantly reduce risk.”
Duo:
When we asked Duo for their suggestions on blocking the attacks (dubbed by Duo “push phishing”), they recommended this article.
Source: www.bleepingcomputer.com