TL;DR: MFA push bombing is not a cryptographic attack. The attacker already has your password. They then flood the target's phone with approval requests until the user taps "Approve" to make it stop. Uber, MGM Resorts, and Microsoft have all been hit by variants of this technique. Standard push MFA is vulnerable. Number matching, FIDO2 hardware keys, and rate limiting are the defenses that actually work. Social engineering penetration tests are how you find out whether your people and processes hold up before an attacker does.
Multi-factor authentication was supposed to be the end of credential-only attacks. The theory is sound: even if an attacker obtains your password through phishing, credential stuffing, or a data breach, they still cannot log in without the second factor. For most implementations, that second factor is a push notification sent to the user's registered smartphone. Approve it and you are in. Deny it and you are not.
The problem is that this architecture puts a human being in the critical path of access control. And humans can be pressured, confused, and worn down. MFA fatigue attacks - also called push bombing - do exactly that. They do not crack the cryptography. They crack the person.
How the Attack Works, Step by Step
The setup requires one piece of information: the target's password. Attackers acquire this through phishing, purchasing it from a credential broker who aggregated it from a past breach, or simply guessing it via password spraying. Once the credential is in hand, the mechanics are straightforward.
- The attacker attempts authentication against the target service - Microsoft 365, Okta, Cisco VPN, a corporate SaaS application.
- The service validates the password and issues a push notification to the user's enrolled device.
- The attacker denies or ignores the outcome, then immediately attempts authentication again, triggering another push.
- This loop runs dozens or hundreds of times over minutes or hours.
- The user's phone lights up repeatedly with "Did you try to sign in?" prompts. At 2 a.m., after the tenth notification, at the end of a long workday - eventually many users tap "Approve" to make the interruptions stop.
- The attacker's authentication succeeds. The second factor has been bypassed without touching it technically.
The core insight: This attack does not break MFA. It exploits the gap between what a push notification tells the user ("Someone is trying to sign in - is this you?") and what the user does with that information under sustained pressure. The notification is honest. The human response is the vulnerability.
The attack is particularly effective at off-hours - late evening, early morning, weekends - when users are distracted, groggy, and less likely to think critically about an unexpected authentication request. Security teams are also thinner on the ground to notice the burst of failed authentications that precede the eventual successful one.
Real Incidents: What This Looks Like in Practice
Uber, 2022
The Uber breach is the canonical push bombing case study. The attacker - reportedly an 18-year-old - purchased an Uber contractor's credentials on the dark web and then began triggering push notifications against the employee's account. When the notifications alone did not produce an approval after several minutes, the attacker escalated: they contacted the employee directly on WhatsApp, claimed to be from Uber's internal IT security team, and explained that the authentication prompts were "a known system issue" the employee needed to approve to resolve.
The employee approved. The attacker moved laterally through the internal network, eventually reaching Uber's privileged access management system, internal Slack, AWS environment, Google Workspace admin panel, and HackerOne vulnerability disclosure program - where they accessed reports for open, unpatched vulnerabilities.
The technical entry point was not a zero-day. It was a push notification approved under social pressure.
MGM Resorts, 2023
The Scattered Spider threat group - also known as UNC3944 - breached MGM Resorts in September 2023 using a combination of help desk social engineering and MFA manipulation. The group is notable for their proficiency in English-language vishing (voice phishing) and their ability to impersonate employees convincingly enough to defeat identity verification procedures over the phone.
After convincing an MGM IT help desk agent to reset an employee's credentials by finding their LinkedIn profile and impersonating them, attackers leveraged access to MGM's Okta environment. The breach extended into MGM's VMware ESXi infrastructure, resulting in ransomware deployment across hotel operations, casino floor systems, and guest-facing platforms. Estimated losses exceeded $100 million.
Caesars Entertainment was hit by the same group weeks earlier. Caesars reportedly paid approximately $15 million of a $30 million ransom demand to avoid the same public disruption.
Microsoft Midnight Blizzard, Early 2024
Microsoft disclosed in January 2024 that Midnight Blizzard - the Russian SVR threat actor responsible for the SolarWinds supply chain attack in 2020 - had accessed the email accounts of senior Microsoft executives, including members of the security and legal teams. The initial access vector involved password spraying against a legacy, non-production test tenant that lacked modern MFA enforcement, followed by lateral movement into production accounts.
The incident illustrates a related but distinct failure mode: uneven MFA deployment. Organizations that enforce strong MFA on production systems but leave legacy tenants, staging environments, or service accounts outside the policy create a flanking route. Attackers find the gap.
Attack Variants Beyond Simple Bombing
Pure push flooding - repeated notifications without any additional contact - has a moderate success rate that depends on how worn down the user becomes. Sophisticated actors layer additional techniques on top.
Bombing Combined with Pretext Calling
The Uber pattern: the attacker calls or texts the target while the push notifications are firing, impersonating internal IT support. The script typically claims the notifications are a known technical issue, a security test, a system migration, or that the employee's account is about to be locked and approving will fix it. The social engineering pretext lowers the user's guard and provides a plausible reason to approve a notification they might otherwise deny or report.
This hybrid approach is significantly more effective than bombing alone and is now the standard technique for sophisticated groups like Scattered Spider.
SIM Swap and MFA Bypass
When the MFA factor is SMS-based (a one-time code delivered by text message), attackers have a separate path: SIM swapping. The attacker contacts the target's mobile carrier, impersonates the account holder, and convinces the carrier to transfer the phone number to a new SIM card the attacker controls. Incoming SMS messages - including OTP codes - then route to the attacker's device.
SIM swap does not require the target to do anything. It is entirely invisible until the victim's phone loses service. High-value individuals - executives, cryptocurrency holders, politicians - have been targeted this way repeatedly. The defense is to switch away from SMS-based MFA entirely.
Adversary-in-the-Middle (AiTM) Phishing Proxies
Tools like Evilginx, Modlishka, and Muraena operate as transparent proxies between the victim and a legitimate authentication service. The attacker stands up a convincing lookalike domain and sends a phishing link. When the victim enters their credentials and approves their MFA push on the real authenticator, the proxy relays the request to the legitimate service in real time - capturing the resulting session cookie before it is delivered to the user's browser.
The victim sees a successful login. The attacker now holds a valid, authenticated session cookie that does not require MFA again until the session expires. Microsoft reports this technique is now commonplace in large-scale phishing campaigns targeting Microsoft 365 tenants, with individual campaigns reaching hundreds of thousands of targeted mailboxes.
AiTM attacks succeed against every form of MFA except phishing-resistant credentials. TOTP codes, push notifications, and SMS OTPs are all captured in transit. Only FIDO2/WebAuthn keys are immune, because the credential is cryptographically bound to the origin - the proxy's lookalike domain is not the same origin, and the key will not sign the authentication challenge for it.
MFA Methods Ranked by Phishing Resistance
Not all MFA is created equal. The security community has moved toward clearer language around phishing-resistant MFA as a distinct category after years of treating any second factor as roughly equivalent. Here is the realistic ranking:
SMS One-Time Passwords (OTP) — Lowest
SMS codes are the weakest second factor in production use. They are vulnerable to SIM swapping, SS7 protocol attacks, real-time phishing proxies that forward the code before it expires, and malware on the device that intercepts incoming messages. NIST deprecated SMS as an authenticator in draft guidance as far back as 2016. It remains widely deployed because of its low enrollment friction, but it should not be considered meaningful MFA for privileged accounts or high-value systems.
Push Notifications (Standard) — Vulnerable to Fatigue
Standard push notifications - approve/deny prompts with no additional verification - are better than SMS but remain vulnerable to push bombing and AiTM proxies. They are the MFA method most organizations deployed en masse during the remote-work transition because they are convenient. Convenience and security tension is familiar here. The fix is configuration, not replacement.
TOTP Authenticator Apps — Better
Time-based one-time passwords (Google Authenticator, Authy, similar apps) generate codes locally on the device using a shared secret. They are not vulnerable to push bombing because there is no push to approve. They are still vulnerable to AiTM proxies that can forward the 30-second code in real time during an active phishing session, and to malware that reads the device clipboard or screen. But they represent a meaningful step up from push for many environments.
FIDO2 / WebAuthn Hardware Keys — Gold Standard
FIDO2 security keys (YubiKey, Google Titan, similar devices) and platform passkeys implemented via FIDO2 protocols are the only MFA methods that are fully phishing-resistant. The authentication challenge is cryptographically bound to the relying party's origin. A proxy cannot relay the handshake because the attacker's domain is not the same origin as the legitimate service. Push bombing is irrelevant because there is no push. SIM swapping does not apply. The user must physically possess the key and interact with it.
The tradeoff is enrollment complexity, hardware cost at scale, and handling lost keys. For privileged users, executives, IT administrators, and remote access paths, the tradeoff is straightforward. CISA and NSA both recommend FIDO2 as the minimum bar for high-value accounts.
Defenses That Actually Work
Number Matching
Number matching is the single highest-impact configuration change available to organizations running Microsoft Authenticator or Duo Security. When enabled, the login screen displays a two- or three-digit code that the user must type into their authenticator app before approving. The approval is no longer a blind tap - it requires active reading and entry of a value the attacker cannot see.
This breaks push bombing because blind approval is no longer possible. A user who has not initiated a login will not have a number to type. An attacker flooding the account will trigger prompts that simply time out. Microsoft enabled number matching by default for Authenticator in May 2023. Duo supports it as an optional policy. If your organization has not enabled it, do so now - it is a configuration toggle, not an infrastructure change.
Additional Context in Push Notifications
Alongside number matching, showing the user the geographic location of the authentication attempt and the application being accessed in the push notification dramatically improves their ability to make an informed decision. A notification that reads "Sign-in to Microsoft 365 from Lagos, Nigeria" is far easier to correctly deny than one that reads "Is this you signing in?" Users need information to make good decisions. Removing ambiguity from the prompt removes a significant attacker advantage.
Rate Limiting Push Requests
Authentication systems should detect and block repeated authentication attempts that generate push notifications within a short window. Microsoft Entra ID includes configurable sign-in risk policies. Okta has adaptive MFA policies with anomaly detection. Duo offers lockout after repeated denials. None of these are enabled by default in every configuration - they require explicit policy decisions. A legitimate user does not generate twenty push notifications in five minutes. Flag or block the burst.
FIDO2 and Passkeys for Privileged Accounts
For accounts that represent the highest risk if compromised - domain administrators, cloud infrastructure access, privileged identity management systems, executive accounts - the correct answer is to move off push MFA entirely and onto FIDO2. Modern identity providers (Entra ID, Okta, Ping) all support FIDO2 authenticators. Passkeys backed by FIDO2 are now available as a consumer-familiar form factor through platform authenticators on iOS and Android.
A tiered approach is practical: require FIDO2 for Tier 0 accounts (domain controllers, privileged identity systems, cloud admin roles), enforce number matching for all other accounts, and block SMS OTP as a fallback option for any account in scope.
Geographic and Behavioral Anomaly Detection
Impossible travel detection - flagging authentication from a location inconsistent with the user's recent history - catches many push bombing scenarios automatically. An employee who logged in from Chicago this morning generating an authentication attempt from Eastern Europe six hours later is a strong signal. Coupled with conditional access policies that can step up authentication requirements or block access outright for anomalous sessions, this reduces attacker dwell time before the account is actually compromised.
The limitation is that sophisticated attackers use residential proxy networks to source traffic from the same country as the target, defeating basic IP geolocation checks. Behavioral signals - typing patterns, session duration, application access sequences - are harder to spoof. User and Entity Behavior Analytics (UEBA) tooling in your SIEM or identity platform can apply these heuristics continuously.
Security Awareness Training with Explicit MFA Coverage
Users who understand the attack model make better decisions. Training that explains push bombing in plain terms - "if you receive a push notification you did not initiate, deny it and report it immediately, even if someone calls you claiming to be IT" - removes the social engineering leverage. Uber's employee approved because they did not have a frame for what was happening. That is a training gap as much as a technology gap.
Operational reminder: No legitimate IT support function will call you to ask you to approve an MFA push. If you receive an unsolicited push notification followed by a call from someone claiming to be from IT, hang up and call your help desk on a number you look up yourself. This is the pattern for virtually every hybrid push bombing attack documented in the wild.
How Social Engineering Penetration Testing Reveals Your Exposure
Organizations often believe their MFA policies are solid until they test them. Policy documents and configuration screenshots do not tell you how users actually respond when a convincing caller tells them that approving a push notification will prevent their account from being locked.
A social engineering penetration test exercises exactly these scenarios in a controlled, authorized way. The scope typically includes:
- Vishing campaigns — testers call employees impersonating IT support, vendors, or executive assistants, attempting to obtain credentials or MFA approvals through pretextual scenarios tailored to the organization's environment.
- Push bombing simulation — with appropriate authorization, testers trigger repeated authentication requests against test accounts with enrolled staff to measure approval rates and time-to-approval under sustained pressure.
- Help desk bypass testing — testers attempt to social-engineer the IT help desk into resetting credentials or enrolling new MFA devices without completing identity verification, the technique Scattered Spider used against MGM.
- Phishing with AiTM proxies — realistic phishing campaigns using proxy infrastructure that captures session cookies even from MFA-protected accounts, to determine whether FIDO2 enforcement is actually in place where it needs to be.
- Pretext scenario development — building organization-specific lures using publicly available information from LinkedIn, company websites, and social media, to demonstrate the plausibility of an attack built on open-source intelligence.
The output is not a checkbox. It is a measured approval rate, a list of accounts where help desk verification failed, a set of session cookies that bypassed MFA, and a clear picture of which user populations are most susceptible. These findings drive concrete remediations: policy changes, training targeting specific departments or roles, MFA reconfiguration, and help desk verification procedure updates.
The MGM breach postmortem made clear that the help desk agent who reset the attacker's credentials was following normal procedure - the procedure itself was the failure. Finding that before an attacker does requires actively testing it.
What to look for in a social engineering assessment: A well-scoped engagement should produce clear, reproducible evidence of what succeeded and why - not just a pass/fail verdict. If a tester was able to obtain an MFA approval through a pretext call, the report should include the exact script, the organizational knowledge used to build the pretext, the time elapsed, and which controls were absent or ineffective. That specificity is what makes the finding actionable.
The Bottom Line on MFA Fatigue
Push bombing is not a sophisticated attack. It does not require a nation-state budget, a zero-day exploit, or significant technical skill. The tools are freely available, the credential inventory is purchasable on criminal markets for a few dollars per record, and the human psychology is predictable. What makes it dangerous is that organizations have collectively communicated to users that MFA makes them safe, without also communicating what to do when the MFA system itself is being weaponized against them.
The technology fixes are available and, in most identity platforms, are a configuration change rather than an infrastructure project. Number matching should be treated as a baseline, not an advanced feature. FIDO2 should be mandatory for privileged accounts. Rate limiting should be active on every authentication path. And the human layer - the one that gets bombed - needs training that is specific enough to actually change behavior when the phone starts ringing at midnight.
MFA is still worth having. It does raise the cost of attacks compared to passwords alone. But it is not a perimeter. Testing it like a perimeter - from the outside only, with technical tools - misses where it is actually breaking.
Find Out How Your People Respond Under Pressure
Lorikeet Security's social engineering assessments test your MFA policies, help desk procedures, and user awareness against realistic attack scenarios — before an adversary does. We deliver findings specific enough to drive real remediation, not just awareness.
