How MFA Fatigue Attack Works and How to Fight Back

In September 2022, a member of the Lapsus$ group sent an Uber contractor a steady stream of push notifications over several hours. The attacker already had the contractor's password, stolen through an earlier compromise, but multi-factor authentication still stood in the way. So they kept triggering prompts until the contractor, worn down and assuming the company's IT team was behind it, approved one. That single tap handed over access to Uber's internal network.

That technique is an MFA fatigue attack: an adversary who already holds valid credentials floods a user with repeated MFA prompts until one gets approved, turning a second factor that was meant to stop them into the thing that lets them in. MITRE ATT&CK tracks it as Multi-Factor Authentication Request Generation (T1621), and you will also see it called MFA bombing or push bombing. It works by exploiting a predictable human reaction under pressure rather than any weakness in the cryptography.

Push bombing drove some of the most disruptive intrusions of the past few years, and it remains a common route to initial access wherever push-based MFA is in use. Vendors responded: Microsoft enforced number matching in the Authenticator app by default in May 2023, and Okta, Duo, and others added similar challenges. Those controls raise the bar, but plenty of environments still run permissive push approval, and attackers have folded fatigue into broader social-engineering playbooks. For security teams, the practical question is how to catch the pattern early and shut it down before an approval lands.

{{ebook-cta}}

What is an MFA fatigue attack?

An MFA fatigue attack, also called MFA bombing, push bombing, or push fatigue, is a social-engineering attack in which an adversary who already has a user's password repeatedly triggers MFA prompts until the user approves one out of confusion, annoyance, or habit. The second factor itself stays intact. The attacker only needs the user to approve a single prompt to gain access to the account.

The tactic sits at the intersection of credential theft and human psychology. The attacker supplies a valid username and password, so every prompt the victim sees looks like a real login. All that is missing is the approval, and persistence usually gets it.

How do MFA fatigue attacks work?

Initial credential compromise. The attacker starts with a working username and password, harvested through phishing, credential stuffing, password reuse from an earlier breach, or infostealer logs sold on criminal markets. These credentials clear the first authentication step but cannot satisfy the MFA challenge on their own.

Prompt flooding. Using the stolen credentials, the attacker attempts to log in over and over. Each attempt fires an MFA push notification, SMS code, or phone call at the legitimate user, generating a burst of prompts in a short window.

Pressure and habituation. As the prompts pile up, the user grows confused or frustrated. Three human factors do the attacker's work: cognitive load, which makes people error-prone under stress; habituation, the reflex to clear a notification without reading it; and training gaps, where the user cannot tell a malicious prompt from a legitimate one.

The approval. Eventually the user accepts a prompt, either to stop the barrage or in the mistaken belief that it is necessary. That approval grants the attacker the full session that MFA was supposed to protect.

Persistence. A foothold won this way is fragile, so attackers move fast to keep it. Expect to see a new MFA method registered, a password reset, recovery details changed, or fresh tokens minted within minutes of the approval. Those follow-on actions are often the clearest sign that a fatigue attack succeeded.

Why MFA fatigue attacks still work

The appeal for attackers is that the technique scales human error. Push-based MFA was built for one-tap convenience, the exact behavior an MFA fatigue attack abuses, and many users were never taught to treat an unexpected prompt as something to question.

Number matching and phishing-resistant factors close much of this gap, but adoption is uneven. Plenty of tenants still allow simple approve or deny push, legacy applications fall back to weaker methods, and help-desk reset flows can be socially engineered around even strong controls. Until permissive push is gone everywhere, detection still matters.

How to detect an MFA fatigue attack: best practices

Detecting MFA fatigue takes a mix of monitoring, correlation, and the kind of disciplined alert investigation that separates signal from noise. The raw indicators are noisy on their own, so the goal is to combine them into a picture that warrants action.

Monitor MFA prompt frequency. Fatigue attacks depend on a high volume of prompts, so track how many each user receives in a given window and alert on spikes. As a starting heuristic, more than two failed MFA attempts followed by a successful authentication inside a four-hour period is worth a closer look.

Analyze authentication patterns. Logins from new IP addresses, unfamiliar devices, or geo-impossible travel are useful, if noisy, early indicators of account takeover. Okta behavioral detections and most enterprise SIEMs surface these by default. Reduce the noise by paying special attention to logins from anonymous proxies or VPN providers, a common favorite for threat actors.

Correlate with persistence signals. Tie the prompt burst to what happens next. A successful login followed by a new MFA enrollment, a password change on an unrelated account, or modified recovery settings points to an attacker establishing a foothold rather than a user fumbling a login.

Use behavioral analytics. Tools that baseline normal user behavior can flag deviations, such as a sudden volume of prompts for someone who almost never triggers them, that static thresholds miss.

Give users a reporting channel. Encourage people to report unusual MFA activity through an email alias, Slack channel, or web form that makes escalation easy. A user saying "my phone will not stop buzzing" is often the first and fastest detection you get.

Each of these signals maps to MITRE ATT&CK T1621, and none of them is conclusive alone. Turning them into a verdict is a question of alert triage and investigation: pulling the login telemetry, the device and location context, and the follow-on activity together to decide whether a push storm was a tired user or a live intrusion.

How to prevent MFA fatigue attacks: best practices

Prevention works best in layers, addressing both the technical opening and the human one.

• Deploy phishing-resistant MFA for high-value access. FIDO2 security keys and passkeys require a physical device or bound authenticator, which removes the simple approve or deny prompt an MFA fatigue attack relies on. CISA recommends phishing-resistant MFA as the strongest available option, and it is the single most effective control here.
• Turn on number matching. Instead of a one-tap approval, require the user to enter a number shown on the login screen. Microsoft Authenticator enforces number matching by default as of May 2023, and Okta, Duo, and others offer equivalent number challenges. Confirm it is enabled rather than assuming it.
• Use passwordless and biometric methods where you can. Options like Okta FastPass and Windows Hello combine strong authentication with convenience, which reduces both risk and prompt volume.
• Rate-limit and lock out. Cap how many prompts a user can receive in a set window, and temporarily suspend prompts or lock the account after repeated failures. This alone can halt an in-progress fatigue attack.
• Tighten conditional access. Block or step up authentication for logins from anonymous proxies, Tor, and non-compliant devices, so stolen credentials cannot even reach the prompt stage from suspect infrastructure.
• Train for the specific behavior. Build MFA fatigue attack prevention into security awareness training. Make the rule simple: never approve a prompt you did not personally start, and report the ones you did not.

Turning MFA fatigue signals into investigations

The hard part is rarely defining the detections. It is having the capacity to run down every suspicious push burst, because most are benign and the dangerous few look identical until someone investigates. A prompt flood could be a user behind a captive portal, a misconfigured app retrying in a loop, or an attacker one tap from your network. Most SOCs cannot investigate that volume by hand.

At Prophet Security, we are building an AI SOC Analyst that investigates every identity alert, including MFA fatigue and impossible-travel signals, with the depth, reasoning, and evidence trail of a senior analyst. Request a demo to see how Prophet AI triages and investigates security alerts in minutes.