MFA fatigue and push bombing

How it works

Push-based MFA sends a notification to the user's phone asking them to approve or deny a sign-in. It was designed to be faster and friendlier than typing a code. An attacker who already holds a valid password, usually from a breach dump, a phishing kit, or an infostealer, signs in repeatedly, which fires a push prompt each time. The victim's phone buzzes, once, then again, then again, often late at night or during a meeting. Some campaigns pair the barrage with a message or a call posing as IT, telling the user to approve the prompt to make it stop, or claiming a legitimate system issue caused it. Eventually a tired, annoyed, or trusting user taps approve, and the attacker is authenticated.

Why it works

Approve or deny push MFA outsources a security decision to a person under manufactured pressure, with almost no context to make it well. The default prompt on many systems shows nothing more than an app name and a timestamp, no location, no device, no reason. A user has no way to tell a legitimate re-authentication from an attacker's replay, and the interface offers a one-tap escape from an annoying, repeating interruption. This is not a cryptographic weakness in MFA; the factor itself works exactly as designed. The control assumption that fails is that a human under repeated pressure will reliably make a correct security judgment with no supporting information, which is not a safe assumption at any scale.

How to detect it

• A burst of MFA push requests to the same user within a short window, especially several denied or ignored prompts followed by one approval.
• MFA approvals immediately following failed password attempts against the same account.
• Approvals occurring at unusual hours relative to the user's normal activity pattern.

Be honest about the limits: users legitimately mistype passwords and re-trigger prompts, and a genuine device switch or app reinstall can also generate a burst of pushes. Volume and timing alone are suggestive, not conclusive, so pair this with an interview step or automated context (location, device) before treating a burst as confirmed compromise.

How to stop it

• Turn on number matching so the user must enter a code shown on the login screen into the phone app, which removes blind, one-tap approval.
• Show context in the prompt: application name, approximate location, and device, so a user has real information to judge against.
• Rate-limit and alert on repeated prompts to the same user in a short window, and consider automatically locking the account after a threshold rather than leaving it to the user.
• Move high-value and privileged accounts to phishing-resistant MFA: FIDO2 security keys and passkeys have no approve-or-deny prompt to wear a user down with.
• Train help desks and users on the specific social-engineering script ("this is IT, please approve") rather than generic phishing awareness, since this attack has no fake login page to spot.

Seen in the wild

• MFA fatigue and push bombing: defeating MFA without breaking it, covering the 2022 Uber breach and the pattern's evolution

Sources

• MITRE ATT&CK T1621: Multi-Factor Authentication Request Generation
• CISA: Implementing Phishing-Resistant MFA