What Is MFA Fatigue (Push Bombing)? Attack Steps, Real Breaches & Prevention Guide

Multi-factor authentication has long been the strongest cheap defense against credential theft, but attackers stopped trying to break it. They started exploiting the human sitting behind it. That technique is MFA fatigue, also called push bombing or MFA bombing, and it has become one of the most reliable initial-access techniques in enterprise intrusions.

This guide explains the attack mechanics down to the protocol level, walks through real breaches beyond the one most people already know, and covers where the threat is heading next.

Defining MFA Fatigue (Push Bombing)

MFA fatigue is a social engineering attack in which an adversary who already holds a valid username and password triggers repeated authentication requests against a victim’s registered device, betting that irritation or confusion will eventually produce a tap on “Approve.” No cryptography is broken. No exploit code is written. The attacker automates the login attempt and waits for the human factor to fail.

It matters because push bombing doesn’t target a flaw in TOTP, WebAuthn, or any authentication standard. It targets the interaction layer sitting on top of them: the single button that turns a cryptographic decision into a reflex.

For organizations weighing where this fits into broader defenses, treating identity as the primary security perimeter rather than an afterthought is the starting point.

Why Push-Based MFA Is the Weak Link, Protocol by Protocol

Not all MFA is built the same way, and the differences are not cosmetic. Here is what’s happening under the hood with each method, and why some resist push bombing while others don’t.

Simple push approval (Approve/Deny) : The authentication server sends a payload to the user’s device; the app renders two buttons. There is no cryptographic binding between the tap and the specific login attempt beyond a session token the user never inspects. The user is authenticating “a request,” not “this request from this device at this location.” That ambiguity is the entire attack surface.

SMS and voice OTP : A shared secret (the OTP) is transmitted out-of-band over the carrier network, which was never designed with authentication security in mind. It isn’t bombable in the push sense, but it’s vulnerable to SIM swapping and to real-time phishing proxies that ask the victim to type the code into a lookalike page.

TOTP (Time-based One-Time Password, RFC 6238) : The app and the server share a secret seed established at enrollment; both sides independently derive a 6-to-8-digit code from that seed and the current time window, typically 30 seconds. It resists push bombing because there’s no prompt to spam, but the code itself is just a string, and an adversary-in-the-middle (AiTM) phishing kit can relay it to the real login page in real time, defeating it the same way it defeats a password. This is precisely what happened during the 0ktapus phishing campaign against Twilio and over 130 other organizations, where entered TOTP codes were relayed to attackers via Telegram in real time.

Push with number matching : The login screen displays a number; the user must key that same number into the approval prompt. This forces a moment of active attention and kills blind-tap approvals, but a well-built AiTM proxy can still show the victim the correct number to relay, so CISA classifies it as a mitigation, not a phishing-resistant control.

FIDO2 / WebAuthn : This is the only category that removes the vulnerability structurally rather than procedurally. At registration, the authenticator generates a public and private key pair; the private key never leaves the device (or a hardware security key), and the public key is stored server-side. Every login is a challenge-response “ceremony”: the server sends a random challenge, and the authenticator signs it, but only after cryptographically verifying that the requesting origin matches the Relying Party ID it was registered against. There is no code, number, or approval button to steal, guess, relay, or fatigue. If an attacker’s proxy domain doesn’t match the legitimate one, the authenticator refuses to sign. This is why security teams describe FIDO2 as phishing-resistant rather than phishing-resistant-ish.

Passkeys use the same WebAuthn cryptography, generally synced across a user’s devices via a platform account (Apple, Google, Microsoft) rather than bound to a single physical key. Under NIST SP 800-63B, phishing-resistant authenticators of this kind are what’s required to reach Authenticator Assurance Level 3 (AAL3), the highest tier, while push and OTP methods typically cap out at AAL2.

How the Attack Plays Out

• Credential theft : Usually an infostealer log, a phishing kit, or a dark-web credential dump.
• Repeated login attempts : The attacker scripts logins against the stolen credentials; each attempt fires a legitimate MFA challenge to the real user’s device.
• Prompt flooding : Sometimes dozens of pushes within minutes; sometimes spaced out over hours to stay under the radar of rate-based detection.
• Vishing reinforcemen : In most documented breaches, the attacker also calls or messages the victim posing as internal IT, asking them to approve “one more” to make the noise stop.
• Fatigue-driven approval : The tap happens, often at night or mid-task, and the attacker inherits a fully authenticated session.
• Post-access consolidation : The attacker frequently enrolls a new MFA device or resets recovery settings immediately after gaining access, locking the real user out and cementing persistence.

Real Breaches: Beyond Uber

For context, Uber’s own security update confirmed a contractor’s two-factor approval request was eventually accepted after repeated push prompts, giving the attacker an initial foothold that expanded into internal Slack, VPN, cloud storage, and source code repositories.

Cisco, May 2022 : The intrusion started with an employee’s personal Google account, which had Chrome-synced corporate credentials sitting in it. Once the attacker had valid login details, they launched a sustained push-bombing campaign against the employee’s phone while placing vishing calls impersonating Cisco’s own support desk. The victim eventually approved a request, and the attacker rode that approval straight into a VPN session. Cisco Talos published a detailed technical writeup attributing the intrusion to an initial access broker with ties to Lapsus$ and the Yanluowang ransomware operation, turning what could have been a quiet incident into an industry-wide warning.

The Lapsus$ campaign, early 2022 : Uber and Cisco were two data points in a broader pattern. Microsoft’s own writeup on the group it tracks as DEV-0537 describes push-bombing paired with help desk impersonation calls used against Microsoft (exfiltrating source code), Okta (compromising a third-party support engineer’s session, which cascaded into hundreds of downstream Okta customers), Nvidia, and Samsung, all within a matter of months. The reuse of the same simple playbook across wildly different companies is the clearest evidence that this is a systemic weakness in one authentication pattern, not a one-off failure at any single company.

MGM Resorts and Caesars Entertainment, September 2023 : This pair of breaches, both attributed to Scattered Spider (also tracked as UNC3944, 0ktapus, and Muddled Libra), is documented in detail in CISA’s joint advisory AA23-320A, and it’s the natural next chapter after push bombing, and a preview of where the trend is heading. Instead of flooding an existing MFA method, the attackers built a pretext from employee details scraped off LinkedIn and called the IT help desk directly, convincing staff to reset MFA enrollment on a target account. From there they configured a rogue identity provider inside MGM’s Okta tenant using the “inbound federation” feature and pivoted into the Azure environment, eventually encrypting hundreds of ESXi servers. MGM refused to pay and absorbed a reported $100 million operating impact; Caesars paid a reported $15 million ransom. Neither company was beaten by a flooded push notification. They were beaten by a help desk agent who had no reliable way to verify a caller’s identity.

Cloudflare, the same campaign as Twilio, a different outcome : Cloudflare’s employees received the identical SMS phishing lure pointing to a fake Okta login page in the same 0ktapus wave that hit Twilio. Some staff entered credentials and TOTP codes into the fake page. The attack still failed, because Cloudflare’s own postmortem confirmed the company had already rolled out FIDO2 hardware security keys organization wide. The keys are cryptographically bound to Cloudflare’s actual domain, so they refused to authenticate against the attacker’s lookalike page. This is the cleanest natural experiment available: identical attacker, identical lure, identical initial employee mistake, and phishing-resistant MFA was the only variable that changed the outcome.

Change Healthcare, February 2024 : Worth including because it complicates the “just add MFA” narrative. UnitedHealth Group CEO Andrew Witty’s congressional testimony confirmed the breach, the largest healthcare data exposure in US history, traced back to a Citrix remote access portal with no MFA enabled at all. Not a bypassed method, an absent one. It sits alongside the push-bombing cases as a reminder that the identity attack surface has two distinct failure modes: MFA that’s weak, and MFA that was never turned on.

The Trend the Industry Keeps Missing

Verizon’s Data Breach Investigations Report has tracked prompt bombing as a recurring share of social-engineering incidents in recent editions, and the human element (social engineering plus stolen credentials) continues to sit behind a large share of all confirmed breaches. That data lines up with what the breaches above show: this isn’t shrinking, and it’s mutating.

The real gap isn’t push bombing anymore. It’s the help desk : MGM, Caesars, and the wider Scattered Spider campaign show attackers routing around push-based MFA entirely by targeting the reset process instead of the approval process. A help desk agent with weak identity verification can undo months of MFA hardening in a single ten-minute phone call, and no comparison table of push versus number matching versus FIDO2 protects against that, because the attacker never has to face the authentication prompt at all. Any MFA strategy that hardens the login flow but leaves account recovery and help desk reset procedures on the honor system is solving half the problem.

The second gap sits at the opposite end : organizations that treat “MFA enabled” as a finished project. Change Healthcare shows that a single unprotected legacy portal can undo an otherwise sound MFA policy. Coverage needs to be complete, not just strong where it exists.

Indicators of Compromise

• Multiple push requests, OTP prompts, or failed logins against a single account inside a short window.
• Authentication attempts from unfamiliar IPs, ASNs, or geolocations relative to the user’s normal pattern.
• Any login prompts the user did not initiate, the strongest single signal available.
• A dense run of denials followed immediately by one approval.
• A new MFA device enrolled, or recovery contact info changed, shortly after a successful authentication, especially following a help desk interaction.

How to Close the Gap

• Move privileged and high-risk accounts to FIDO2/WebAuthn or passkeys : This is the only control category that removes the human decision point structurally rather than adding friction to it.
• Enable number matching everywhere push is still in use, as an interim step, understanding it raises the bar against blind taps but does not stop a live AiTM relay.
• Rate-limit and auto-lock after a small number of denied or failed requests, rather than allowing indefinite retries.
• Harden the help desk identity-verification process, not just the login flow. Require verified callback numbers, manager attestation, or in-person or video verification before any MFA reset or device re-enrollment. This is now the more exploited seam.
• Add context to every push request, device, location, IP, and time, so a 3 a.m. login from an unrecognized country is visibly wrong, not just statistically wrong.
• Monitor authentication and help desk ticketing logs together. A spike in denied MFA requests followed by a help desk reset ticket for the same account, within a short window, is close to a smoking gun and should alert automatically. This is the kind of correlation a well-run security operations function is built to catch.
• Have a tested incident response plan ready before the alert fires. Response speed determines blast radius; organizations that can revoke sessions and roll back MFA changes within minutes contain incidents that would otherwise spread for days, an area covered in more depth in a guide to building an incident response plan.

Where This Leaves You

Push bombing proved that MFA’s weakest point was never the cryptography. It was the tap. The Scattered Spider wave since 2023 proves the next weakest point is the reset button, not the login button. Closing one gap without the other just moves the attacker down the hall to the help desk.

If your organization is still relying on basic push approval, or on a help desk that verifies identity with a name and a date of birth, that’s a gap worth closing before it becomes the next headline.

Enjoyed reading this blog? Stay updated with our latest exclusive content by following us on Twitter and LinkedIn.