MFA Fatigue and Push Bombing: How Attackers Wear Down Your Users

TL;DR: What Is MFA Fatigue and How Do You Stop It?

MFA fatigue—also called push bombing—is an attack where an adversary who already holds a user’s valid credentials floods them with multi-factor authentication push notifications until the user, out of confusion, annoyance, or fear, approves one. Attackers don’t break MFA; they weaponize your users’ patience. Defeat it with number matching, MFA denial rate limits and lockout policies, and—ultimately—phishing-resistant authentication like FIDO2, passkeys, and certificate-based authentication, backed by Conditional Access and log-based detection.

Multi-factor authentication has a well-established reputation as the single highest-leverage control against credential theft. CISA, Microsoft, and NIST have spent a decade telling organizations to “turn on MFA,” and most have. But since roughly 2021, attackers—Lapsus$ and Scattered Spider chief among them—stopped trying to bypass MFA and started trying to exhaust it. This guide breaks down how MFA fatigue attacks actually unfold, why users approve, how to detect them in your logs, and the four defensive layers that shut them down.

How MFA Push Fatigue Attacks Work: Attack Mechanics

An MFA fatigue attack is beautifully simple, which is exactly what makes it dangerous. The attack chain looks like this:

1. Obtain valid credentials. The attacker gets a real username and password via phishing, AiTM proxy kits (Evilginx-style), infostealer malware logs sold on criminal markets, or credential stuffing from third-party breaches. This is critical: every subsequent push notification is a legitimate authentication attempt against a legitimate account. There’s no failed-login noise to alert on.
2. Initiate repeated sign-ins. The attacker triggers authentication over and over—often a script loops the login—generating a continuous stream of push notifications to the victim’s authenticator app.
3. Time it for maximum effect. Campaigns typically run between midnight and 5 a.m., when the user is asleep, disoriented, or half-awake. The rational response—”that’s weird, I’ll deal with it in the morning”—competes with the irrational one: “just make it stop.”
4. Apply psychological pressure. The notifications keep coming. Some attackers pair the pushes with a phone call or text posing as IT support: “We’re rolling out a security update, please approve the prompt.” Some users approve simply to silence their phone.
5. Cash in. One accidental approval and the attacker is inside the account—sessions, email, VPN, whatever the identity provider grants.

Traditional detection struggles here because the brute-force playbooks—failed sign-in thresholds, IP reputation, password spray alerts—don’t fire. Every prompt was a successful credential validation. You’re not attacking the authentication system; you’re attacking the human confirmation step at the end of it.

Push Bombing vs. MFA Bombing vs. Prompt Bombing: Terminology

Practitioners use these terms interchangeably, and mostly that’s fine—but precision helps when writing detection rules and policies:

• MFA fatigue — the umbrella term, emphasizing the psychological exhaustion of the victim. This is the term used by Microsoft, CISA, and most vendor guidance.
• Push bombing / MFA bombing — the same technique described mechanically: bombing the user with push-based MFA requests. “OTP bombing” when the target is SMS or TOTP-based flows.
• Prompt bombing — broader term, sometimes encompassing repeated consent prompts or repeated MFA challenges across multiple channels (push, phone call, SMS).
• MFA spam — informal synonym, common in social media incident chatter.

One related-but-distinct term: MFA request forwarding, where a help desk or attacker relays a prompt to a victim. Number matching addresses bombing; it only partially addresses forwarding—more on that below.

Real-World Campaigns: Uber 2022, Cisco 2022, Twilio Supply Chain

Uber, August 2022

The canonical case. The attacker—affiliated with Lapsus$—obtained the password of an Uber contractor, likely purchased from an infostealer log marketplace after the contractor’s device was compromised with RedLine infostealer malware. The contractor’s credentials repeatedly triggered MFA push requests. The attacker then WhatsApp-messaged the contractor posing as Uber IT, claiming the push notifications were part of legitimate activity and asking them to approve. The contractor accepted one prompt, granting access to Uber’s VPN. From there, the attacker moved laterally to a network share containing PowerShell scripts with hardcoded credentials for a privileged admin account, eventually reaching Uber’s AWS, GSuite, Slack, and even the company’s HackerOne bug bounty program, where they posted a message to triagers. Uber’s official security update and its subsequent root-cause analysis confirmed the MFA fatigue mechanism.

Cisco, May 2022

The Yanluowang ransomware group compromised a Cisco employee’s Google account via MFA fatigue: repeated push notifications, voice calls posing as trust organizations, and eventually the employee accepting one of the prompts. Cisco disclosed the incident in its Talos Intelligence analysis, noting the attacker attempted to escalate to the corporate VPN environment. The account was secured, but the intrusion demonstrated MFA fatigue works against technical staff too.

Twilio and the Okta Supply Chain, August 2022

Twilio’s incident disclosure described a sophisticated phishing campaign using AiTM pages that harvested both credentials and one-time passcodes—technically adjacent to push bombing but part of the same strategic shift: MFA is now an obstacle to be socially engineered, not bypassed. The fallout spilled into Okta’s own systems via contractor 0ktapus compromises, reminding the industry that identity chains break at the weakest vendor.

CISA catalogued these techniques in the MITRE ATT&CK framework as T1621: Multi-Factor Authentication Request Generation.

Why Users Approve: The Psychology Behind the Attack

The attack succeeds because it exploits well-documented human factors, not exotic exploits:

• Alarm fatigue and habituation. Security professionals know this from SOC alert queues; end users know it from years of notifications. The tenth push notification at 2 a.m. carries almost no signal. Habituation is the predictable result of high-frequency, low-consequence stimuli.
• Fear of consequences. Many users believe denying a prompt might lock them out of their account, delay their morning login, or flag them for a security investigation. Approval feels like the path of least resistance.
• Authority bias. Attackers posing as IT support—via call, WhatsApp, or SMS—exploit deference to authority. In the Uber case, the “IT is doing this” framing did the heavy lifting.
• Ambiguity about what approval means. Most users have never been told what a push notification actually confirms. The default mental model is “approve = accept connection,” not “approve = authorize this specific login attempt from this device in this location.”

Any defense that ignores this psychology—one that merely documents “don’t approve unknown prompts”—will fail under pressure at 3 a.m. Good defenses change the interaction itself so that blind approval is impossible.

Detecting MFA Fatigue in Your Logs

If you’re on Microsoft Entra ID (formerly Azure AD), sign-in logs contain everything you need. MFA fatigue leaves a distinctive signature: clusters of successful credential validations followed by repeated MFA interruptions and denials, typically outside business hours, concentrated on a single user.

Key Entra ID sign-in error codes to hunt:

• 500121 — Authentication failed during strong authentication request (user denied or timed out)
• 50074 — Strong authentication is required (challenge issued)
• 50076 — Strong auth required, proof-up interrupted

Here’s a KQL query for Microsoft Sentinel that flags users with high MFA-denial counts in a 30-minute window:

SigninLogs
| where TimeGenerated > ago(1d)
| where Result == "Failure"
| where ResultDescription in ("500121", "50076")
| summarize MfaDenials = count(), Apps = make_set(AppDisplayName),
    DistinctIPs = dcount(IPAddress), LastEvent = max(TimeGenerated)
    by UserPrincipalName, bin(TimeGenerated, 30m)
| where MfaDenials >= 5
| project TimeGenerated, UserPrincipalName, MfaDenials, DistinctIPs, Apps
| order by MfaDenials desc

Complement it with a rule that alerts on any MFA denial followed by a successful MFA approval within the same window for the same user—this is the exact signature of a fatigue attack that just succeeded. Okta’s System Log exposes equivalent events (user.mfa.challenge, user.mfa.push.accept), and Google Workspace admin logs expose 2SV challenge events for equivalent alerting.

Defense 1: Number Matching

Number matching changes the approval interaction fundamentally. Instead of “tap Approve,” the user sees a two-digit number on the sign-in screen and must type that number into Microsoft Authenticator. An attacker spamming prompts at 2 a.m. can’t be silenced by a blind tap—the user must actively read the number displayed on the sign-in screen they didn’t initiate, which makes the mismatch obvious.

Microsoft enforced number matching for Microsoft Authenticator push notifications organization-wide in May 2023, making it the default. Verify it’s on (or lock it in) via Entra ID → Protection → Authentication methods → Microsoft Authenticator → Configure, and set it in your Authentication Methods Policy. Note what it breaks or degrades:

• Authenticator versions older than 6.5.28 (Android) / 6.5.62 (iOS) can’t complete number-matched approvals—block or update them.
• Third-party authenticators using OATH tokens are unaffected (they never used push).
• Approval via Apple Watch requires number matching support on the paired phone.

Number matching is a mitigation, not a cure: AiTM phishing proxies like Evilginx relay the number to the victim in real time, so a phished user can still complete a number-matched login on an attacker-controlled proxy. That’s why it’s defense one, not the end state.

Defense 2: Rate Limiting and Lockout Policies

Number matching changes the user experience; rate limiting caps the attack’s ammunition. In Entra ID:

1. Navigate to Entra ID → Protection → Authentication methods → Account lockout.
2. Enable Smart Lockout and configure number of MFA denial attempts that trigger lockout and the lockout duration in seconds.
3. Common practice: lock the account’s MFA after roughly 10 denials within a 60–120 second window, with a lockout duration of 60+ seconds that doubles on repeat offenses.

Okta offers an equivalent in Security → Authenticators and sign-on policy rate-based rules; Google Workspace enforces 2SV challenge limits via Security → Authentication → 2-Step Verification and Context-Aware Access rate signals. Pair technical lockouts with an operational rule: never allow a help desk to “reset MFA” purely at a user’s telephoned request—verify identity first, or fatigue attacks become MFA reset attacks.

Defense 3: Phishing-Resistant MFA (FIDO2, Passkeys, CBA)

Push-based MFA shares a fatal design property: the approval decision is transferable—anyone holding the user’s unlocked phone can approve, and any social-engineered user can approve on behalf of an attacker. Phishing-resistant authentication closes this by binding the credential to the origin and the device:

• FIDO2 security keys and passkeys use public-key cryptography where the private key never leaves the device and is bound to the relying party’s origin. An AiTM proxy at evil-portal.com cannot replay a FIDO2 assertion minted for login.microsoft.com. WebAuthn, the protocol underneath, is the W3C Web Authentication Level 3 standard.
• Certificate-based authentication (CBA) binds authentication to an X.509 certificate provisioned to a managed device—strong for enterprise-managed fleets.
• Windows Hello for Business delivers FIDO2-equivalent phishing resistance for the Windows estate without extra hardware.

NIST SP 800-63B explicitly classifies push-based multi-factor as vulnerable to social engineering relative to hardware-bound authenticators at AAL3. The practical migration path: pilot FIDO2 passkeys with your most-targeted users—executives, IT admins, finance—then expand. Treat push MFA as a transitional control, not a destination.

Defense 4: Conditional Access, Risk-Based Sign-Ins, and Device Trust

Even with strong MFA, Conditional Access shrinks the attack surface the credentials can reach:

• Require compliant or hybrid-joined devices for access to sensitive apps. An attacker with stolen credentials but no enrolled device fails at the device check, not the MFA check.
• Use sign-in risk policies. Entra ID Protection scores risk signals—impossible travel, anonymizing IPs, unfamiliar properties—and can block or force strong authentication on high-risk sign-ins before a push prompt is ever generated.
• Block legacy authentication. Protocols like IMAP, POP, and SMTP AUTH don’t support MFA at all and are a favorite landing pad for credential stuffing. If you haven’t blocked legacy auth in Conditional Access yet, that’s a same-week fix.
• Restrict by location where feasible. Named locations won’t stop a determined attacker with residential proxies, but they raise the bar and improve risk scoring fidelity.

User Training and Reporting: The Human Layer

Technology reduces the attack’s success rate; people reporting it kills the campaign early. Build the human layer deliberately:

• Teach the specific behavior: “If you receive an MFA prompt you didn’t trigger, deny it, then report it immediately. Do not wait. Do not approve ‘to make it stop.'”
• Provide a low-friction reporting channel. A one-click “report suspicious MFA prompt” button, a dedicated security hotline, or a chat shortcut. If reporting takes five minutes, it won’t happen at 2 a.m.
• Train help desks as a first-class defense. Attackers pivot to MFA reset social engineering when prompts fail. Require callback verification to a known number, manager approval for MFA resets, and treat reset requests from recently reported-fatigue accounts as high-risk.
• Reinforce after every alert. When your monitoring catches an attempt, tell the targeted user what happened and that their report (or the system) stopped it. Positive feedback loops sustain reporting behavior.

OWASP’s Top 10 and its Authentication Cheat Sheet frame credential abuse as a people-plus-process problem—MFA fatigue is the clearest current example.

Blue-Team Checklist: Hardening MFA in 30 Days

Prioritized, sequenced, and scoped to a single month:

1. Week 1 — Contain the attack vector. Verify number matching is enforced in Entra ID Authenticator policy; block outdated authenticator versions. Block legacy authentication protocols via Conditional Access.
2. Week 1 — Cap the ammunition. Configure Smart Lockout: ~10 MFA denials, escalating lockout duration. Confirm equivalent policies on Okta/Google if multi-IdP.
3. Week 2 — See the attacks. Deploy the Sentinel KQL detection above (or equivalent), plus an alert for MFA-denial-followed-by-approval. Route alerts to the SOC with a documented triage playbook.
4. Week 2–3 — Shrink blast radius. Require compliant devices for VPN, email, and admin portals. Enable sign-in risk policies in report mode, review, then enforce.
5. Week 3 — Harden the human layer. Push targeted comms on unexpected-prompt reporting; verify help desk identity-verification procedures for MFA resets.
6. Week 4 — Start the endgame. Pilot FIDO2 passkeys or Windows Hello for Business with admins and high-risk users; set a target date to require phishing-resistant methods for privileged accounts.

MFA fatigue works because it attacks the gap between authentication systems and human attention. Number matching and lockouts close the gap for today; phishing-resistant authentication closes it for good.

Frequently Asked Questions

What is MFA fatigue?

An attack where an adversary with valid credentials floods a user with MFA push notifications until they approve one out of confusion or annoyance. The technique, tracked as MITRE ATT&CK T1621, exploits habituation rather than any cryptographic weakness.

How did the 2022 Uber breach relate to MFA fatigue?

The attacker obtained a contractor’s password from an infostealer log, sent repeated push prompts, and posed as Uber IT via WhatsApp. Believing the prompts were legitimate, the contractor approved the MFA request, giving the attacker VPN access that led to a full compromise of Uber’s cloud and internal systems.

Does number matching stop push bombing?

It largely mitigates it. Number matching requires the user to type a number shown on the sign-in screen into the authenticator app, preventing blind approvals—a 2 a.m. prompt with no visible number context can no longer be dismissed with a tap.

Can attackers bypass number matching?

Yes. AiTM phishing proxies relay the number in real time to a phished user, and MFA prompt forwarding tricks users into completing approvals. This is why phishing-resistant MFA—FIDO2, passkeys, certificate-based authentication—is the stronger end state.

How many push notifications before lockout should I allow?

Common practice is to lock out after roughly 10 MFA denials within a short window (60–120 seconds). In Entra ID, this is configured under Authentication methods → Account lockout, with a lockout duration of 60 seconds or more.

Related reading

• Shodan and Censys for Attack Surface Recon: A Hands-On OSINT Lab with Ethics Guardrails
• Weekly Threat Intel: 27 September 2026 — Agentic Supply Chain Abuse and CVE Trades

Published by Hmmnm

Hands-on cybersecurity tutorials, CVE breakdowns, and guided learning paths — written and lab-tested by the Hmmnm team.

Learning Paths · About Hmmnm · Editorial policy