Implementing a multi-factor authentication (MFA) solution in your organization adds significant protection against user account compromise, but by no means is MFA hacker-proof. There are many tactics cybercriminals use to defeat MFA security, such as SIM swapping, transparent proxies, and brute-force attacks. As is true with many types of attacks, social engineering techniques that bypass MFA security are used frequently because they are low-cost, low-tech, and effective. One example of social engineering is “MFA fatigue” (sometimes referred to as “MFA nagging” or “MFA push spam”).
In this blog, LogRhythm Labs threat researchers provide an overview of MFA fatigue attacks and real-world examples, along with best practices to detect and respond to various attack techniques.
What are MFA fatigue attacks and how do they work?
MFA fatigue occurs when an attacker has obtained a valid username/password combination to a network that has push notifications as part of their MFA solution. Often via automation, an attacker sends large volumes of push notifications to the victim’s MFA device. Eventually the victim approves one of the push notifications, which allows the attacker to log in.
MFA fatigue is a technique used by both script kiddies and advanced persistent threats (APTs). It is easy and effective because once valid credentials are acquired, hackers do not need technical skills to spam a user with MFA requests.
Definition of MFA fatigue per MITRE T1621
The MFA fatigue technique has earned itself a MITRE mapping: T1621. MITRE defines the technique as “Adversaries may attempt to bypass multi-factor authentication (MFA) mechanisms and gain access to accounts by generating MFA requests sent to users.”
Examples of real-world cyberattacks using T1621
In September 2022, an Uber external contractor’s account was compromised when an attacker gained their credentials through social engineering and sent multiple two-factor authentication requests. One accepted request was all it took for the hacker to gain access to some of Uber’s internal applications like Slack. Allegedly, this attack was conducted by a teenager associated with the LAPSUS$ group.
Cisco was also breached in 2022 due to an MFA fatigue attack against an employee’s Google account, which was synced to their user credentials at work. APT 29, a prolific adversarial group attributed to the Russia’s Foreign Intelligence Service, is known to use the MFA fatigue technique.
MFA fatigue will likely remain a popular technique. The success or failure of an MFA fatigue attack depends on human error and training. Even employees that have been trained to identify this attack can accidentally press the wrong button when they are bombarded with requests.
Detecting MFA fatigue attacks: Log source familiarity
How are MFA fatigue attacks detected in a security information and event management (SIEM)? Per usual, collecting the appropriate logs and parsing them accurately are critical requirements. LogRhythm includes log collection and processing support for several MFA vendors, including Duo Security, RSA, and Okta. In this article, we will focus on detections using the API – Okta Log Source Type. Before moving on to detection analytics, spend a moment getting familiar with the pertinent logs.
*Disclaimer: The log artifacts and detections discussed in this blog are relevant to Okta Classic Engine deployments. The logs artifacts in Okta Identity Engine deployments will vary from logs shown here.
Okta log familiarization: AD authentication success and push verification success
Let’s dive into the sequence of logs produced when a user enters a good set of Active Directory (AD) credentials into their laptop and successfully verifies the push notification on their mobile device.
Using the Okta log Vendor Message IDs, along with selected information parsed into LogRhythm metadata fields, we can see the flow of events:
| Vendor Message ID | Result | Vendor Information |
| user.authentication.auth_via_AD_agent | Success | Authenticate user with AD agent |
| User.session.start | Success | Successful Okta login |
| policy.evaluate_sign_on | Challenge | Sign-on policy evaluation resulted in CHALLENGE |
| system.push.send_factor_verify_push | Success | A push was sent to a user for verification |
| user.authentication.auth_via_mfa | Success | Authentication of user via MFA |
| user.authentication.verify | Success | Verify user identity |
| user.authentication.sso | Success | User single sign on to app |
Table 1: Okta log sequence indicating AD authentication success and push verify success.
Okta log familiarization: AD authentication success and push verification deny
Next, review the logs produced when the user successfully authenticates to AD, and then is notified with a push verify to their mobile device, but the push verify is denied:
| Vendor Message ID | Result | Vendor Information |
| user.authentication.auth_via_AD_agent | Success | Authenticate user with AD agent |
| User.session.start | Success | Successful Okta login |
| policy.evaluate_sign_on | Challenge | Sign-on policy evaluation resulted in CHALLENGE |
| system.push.send_factor_verify_push | Success | A push was sent to a user for verification |
| user.mfa.okta_verify.deny_push | Failure | User rejected Okta push verify |
Table 2: Okta log sequence indicating AD authentication success and push verification deny.
Okta log familiarization: AD authentication failure
Finally, review the logs generated by unsuccessful authentication to AD:
| Vendor Message ID | Result | Vendor Information |
| user.authentication.auth_via_AD_agent | Failure | Authenticate user with ad agent |
| User.session.start | Failure | User login to Okta |
Table 3: Okta log sequence indicating AD authentication failure.
MFA fatigue detection theories and implementation in LogRhythm
Now that we have identified the logs generated during Okta authentication, both successful and unsuccessful, we have the building blocks required to build out the detection theories proposed in the Detection section of the MITRE technique page. The AI Engine rules that appear in this article will be included in an upcoming release of the MITRE ATT&CK Knowledge Base module.
Multiple Push Denies
According to MITRE ATT&CK, you should “monitor application logs for suspicious events including repeated MFA failures that may indicate user’s primary credentials have been compromised.”
This analytic is easily constructed in LogRhythm using the AI Engine Rule Builder and building a rule containing a Threshold Observed rule block:
The rule logic is easy to follow: if five or more push denies are observed in ten minutes for a given user, trigger the analytic. Push denies are detected by monitoring for the Vendor Message ID user.mfa.okta_verify.deny_push.
How can you determine whether five push denies in ten minutes is abnormal? Search for them in your own environment and use a Web Console Trend Widget to visualize push denies over time, per-user.
Variation: Multiple push denies followed by success
What can be worse than a user repeatedly denying push requests? A user repeatedly denying push requests, and then accepts one! This is the goal of the MFA fatigue attack: wear the user down until they finally accept a push request. How can you detect this sequence of events?
Fortunately, LogRhythm’s AI Engine allows for correlation of multiple observations, which are represented as “Rule Blocks.” With this functionality, we can construct an analytic such as the following:
Rapid login attempts with valid credentials
Per MITRE ATT&CK: “Monitor 2FA/MFA application logs for suspicious events such as rapid login attempts with valid credentials.” For the attacker to send rapid-fire push verifications, they need valid (AD) credentials: we observed in the section titled, “Okta log familiarization: AD authentication failure,” that bad credentials mean no Okta session is created, and there is no opportunity for push verification.
Once the attacker obtains valid credentials, they will continuously authenticate and generate an overwhelming volume of push requests. Often the authentications will take place automatically via a script.
How can you construct an analytic to detect the rapid authentications? In much the same way we detected rapid-fire push denies, with a threshold rule block.
First, you may want to understand what a normal volume of authentication successes are in a given environment:
You can see from the trend chart pictured in Figure 9, AD authentications are normally a low-volume event in this environment, with less than ten occurrences per hour. We will use the same threshold value as the Push Deny rule: >=5 logs per 10 minutes.
Variation: rapid push verifications
A similar detection to the rapid AD auth successes would be the observations of rapid push verifications being sent:
Location-based analytics
MITRE ATT&CK’s detection advice includes monitoring for “suspicious events such as unusual login attempt source location, mismatch in location of login attempt and smart device approving 2FA/MFA request prompts.”
Analytics based on location can be a tricky affair given that the location of a device is often determined by the public IP address of the device recorded in the Okta logs. The public IP address of a device can change quickly and dramatically: all a user needs to do is enable a VPN connection on their mobile device or laptop and, per their IP address, they’ve magically been transported to a faraway land.
Even in less-complicated network scenarios, such as a user working from home with their laptop connected to the home Wi-Fi but their mobile device connected over the local cellular network, the “location” of the two devices may be contextualized as coming from different cities.
Simple location-based detections include the initiation of a push request from a country that isn’t on your organization’s list of whitelisted regions. Figure 12 is an example rule which takes advantage of the CCF: Whitelisted Regions list included in the LogRhythm’s Consolidated Compliance Framework (CCF) Module.
Detections of anomalous behavior, such as push authentications originating from unusual locations, are best accomplished with machine learning products such as LogRhythm UEBA. Anomaly detections can both serve as the leading indicator of account compromise or as a qualifying observation for an Event raised by LogRhythm AI Engine.
Okta T1621 Mitigations
User training
Making users aware of MFA fatigue attacks is critical for any organization that utilizes MFA. Users should know what the attack looks like and that they should contact security immediately if they accidentally accept a push that they did not initiate.
Detection
Security operations centers (SOCs) should implement MFA detections based on thresholds and abnormal authentications regardless of the platform used. LogRhythm customers can enable the AI Engine rules discussed in this article in an upcoming release of the MITRE ATT&CK Knowledge Base module.
Okta ThreatInsight
Enabling Okta ThreatInsight is the first line of defense against MFA fatigue and other MFA attacks. Okta ThreatInsight “aggregates data about sign-in activity across the Okta customer base to analyze and detect potentially malicious IP addresses.” IPs flagged by ThreatInsight can be logged or logged and blocked. Okta logs from ThreatInsight are given the eventType “security.threat.detected.” Choosing to block ThreatInsight IPs can reduce the number of attacks against Okta and can reduce the number of Okta attack alarms a SOC has to handle. ThreatInsight logs contain interesting information like IP, user agent, and attack type. These logs can be used to build block lists or perform threat hunts.
Compromised account response and SOAR
There is still time to mitigate the damage done if a successful MFA fatigue attack is detected. Within the Okta console a user can be disabled, and all the user’s active sessions can be killed to contain further damage.
These user actions can run via the Okta API. The Okta API can be used to implement security orchestration, automation, and response (SOAR) within other security products. LogRhythm’s SOAR implementation utilizes LogRhythm SmartResponse™ automation plugins (SRPs) that allow for third-party integration with LogRhythm. Both LogRhythm-supported and customer written SRPs can be downloaded from the LogRhythm Community here.
LogRhythm SRPs are installed in the LogRhythm Console (Thick Client) and SRP actions can run automatically when linked to alarms like “Multiple push denies followed by success,” with or without user approval. SRP actions can also run on demand from the LogRhythm Web Console giving security analysts a single pane of glass to work from.
Be ready to defend against MFA fatigue attacks
MFA fatigue is a popular technique because its success or failure comes down to getting a user to press one button. This is not a challenging task and MFA fatigue is likely to remain a popular technique for the foreseeable future. MFA logs should always be collected and mitigations, including detection and user training, should be implemented.
To hear more from LogRhythm Labs about MFA attacks, listen to The Tech Talks Daily Podcast featuring LogRhythm Senior Threat Research Engineer, Sally Vincent, as she guides listeners through more tips and tricks!