MFA fatigue attacks: how push bombing works and how to stop it

Multi-factor authentication was supposed to make a stolen password worthless. For most attacks it still does. But one technique turns MFA's convenience against the people it protects: instead of breaking the second factor, the attacker simply asks for it again and again, until the user gives in.

The technique is called MFA fatigue, push bombing or MFA spamming. MITRE ATT&CK tracks it as T1621, Multi-Factor Authentication Request Generation. It needs no malware and no exploit, only a valid password and patience.

How the attack works

Push notifications are designed to be easy: a prompt appears on the phone and one tap approves it. That ease is the weakness. The attack usually unfolds in four stages.

1. The attacker gets a valid password

   Through phishing, password spraying, an infostealer on a personal device, or a password reused from an old breach. Without the password there is no attack.

2. Prompts start arriving, often at a bad time

   The attacker signs in repeatedly, and each attempt sends a push notification. Late at night is a favorite: a tired user who wants the phone to stop buzzing is more likely to tap "Approve".

3. Social engineering closes the gap

   Many attackers add a message or a call pretending to be the IT help desk: "We are fixing an issue with your account, please accept the prompt so it stops."

4. One approval, then persistence

   Once a prompt is approved, the attacker is in. The first move is often to register their own MFA method, so they no longer depend on the victim.

Two breaches that made it famous

In September 2022, an attacker linked to the Lapsus$ group got into Uber's internal systems. According to Uber, the attacker had a contractor's password and tried to log in repeatedly, sending MFA prompts until the contractor accepted one. The attacker later claimed to have messaged the contractor on WhatsApp, posing as Uber IT support.

Earlier that year, Cisco suffered a similar intrusion, disclosed in August 2022. The attacker had taken over an employee's personal Google account, where work credentials were saved in the browser, and then combined voice phishing with a flood of MFA pushes until one was accepted.

Neither company lacked MFA. Both had MFA that a human could be talked into approving.

Why simple push approval is the problem

A plain "Approve / Deny" prompt asks the user to answer a question they cannot really answer: is this sign-in mine? The prompt shows little context, it arrives at a moment the attacker chose, and the cost of tapping the wrong button is invisible until later.

Every effective defense against MFA fatigue does one of two things: it gives the user enough information to say no, or it removes the decision from the user entirely.

Defenses that work

Number matching and additional context

With number matching, the sign-in screen shows a number and the user must type it into the authenticator app. Someone who did not start the sign-in has no number to type, so blind approval stops working. Microsoft has enforced number matching for all Microsoft Authenticator push notifications since May 2023.

Additional context goes one step further and shows which application is asking and the approximate location of the sign-in. A prompt claiming to come from another country at 3 a.m. becomes much easier to refuse.

Phishing-resistant MFA

Passkeys, FIDO2 security keys, Windows Hello for Business and certificate-based authentication are bound to the real website and to a device the user holds. There is no prompt to approve from a distance and nothing to read aloud to a fake help desk. For administrators and other high-value accounts, this is the standard to aim for.

Conditional Access and sign-in risk

Conditional Access policies can require a compliant device, block legacy authentication, and demand stronger authentication methods for risky sign-ins. Combined with Entra ID Protection, a burst of sign-ins from an unfamiliar location can be blocked before the user ever sees a prompt.

Let users report, and train them to

Entra ID lets users report an MFA prompt they did not expect as suspicious activity. The report raises the user's risk and can trigger your policies automatically. A short message in security awareness training, "if you didn't start it, deny it and report it", turns every target into a sensor.

How to spot it in your logs

Repeated MFA denials for the same user in a short window are the clearest signal. This query looks for users with many failed strong-authentication attempts within an hour:

SigninLogs
| where TimeGenerated > ago(1d)
| where ResultType == "500121"  // authentication failed during strong authentication
| summarize Denied = count(), IPs = make_set(IPAddress), Apps = make_set(AppDisplayName)
    by UserPrincipalName, bin(TimeGenerated, 1h)
| where Denied >= 5
| order by Denied desc

Tune the threshold to your environment: a user with a broken phone can generate a handful of failures too. What matters is the combination of many denials, an IP address the user has never used and, above all, a successful sign-in right after the burst.

Why it matters for a SOC analyst

MFA fatigue is a reminder that "MFA enabled" is not the end of the identity story. When you investigate a compromised account, check how MFA was satisfied, not only whether it was. And when you write recommendations after an incident, number matching, phishing-resistant methods for privileged users and an easy way to report suspicious prompts are the three changes that make this attack fail.