September 2022. A ride-share giant’s entire network compromised. Not through sophisticated malware or zero-day exploits—but because someone got tired of saying no.
It started with a stolen password.
An Uber contractor’s credentials—likely purchased from the dark web after an earlier breach—gave an attacker the first piece they needed. But Uber had multi-factor authentication protecting those credentials. Every login attempt triggered a push notification to the contractor’s phone: “Approve this sign-in?”
The contractor kept denying it.
So the attacker kept trying.
Again. And again. And again.
Push notification after push notification flooded the contractor’s phone. 10 notifications. 20 notifications. 40 notifications in 30 minutes. During work hours. During dinner. Late at night.
Eventually, exhausted and assuming it was some kind of system glitch, the contractor approved one.
The attacker was in.
What Happened Next
Once inside the network, the attacker moved laterally through Uber’s systems with alarming speed. They gained access to:
- Internal Slack channels where employees had shared credentials
- Cloud storage containing code repositories
- Administrative tools for Uber’s production environment
- Third-party systems including security platforms
The attacker even accessed Uber’s HackerOne account—the platform Uber uses to run its bug bounty program—and sent messages to security researchers announcing the breach.
“I announce I am a hacker and Uber has suffered a data breach,” one message read, accompanied by screenshots of internal systems.
The entire Uber engineering team had to be locked out of their own code repositories while the company investigated. Services went dark. The incident response scramble consumed hundreds of employee hours.
All because someone got tired of dismissing authentication requests.
How MFA Fatigue Attacks Work
Multi-factor authentication is supposed to stop exactly this scenario. You know the password? Great—but you still need to approve the login from your registered device.
Except attackers discovered the weakness: human psychology.
The attack pattern is simple:
Step 1: Obtain valid credentials (purchased, phished, or breached)
Step 2: Automate login attempts with those credentials
Step 3: Generate dozens or hundreds of MFA push notifications
Step 4: Wait for the victim to approve one out of frustration or confusion
The victim isn’t being tricked into revealing their password. They’re being exhausted into approving access they know is unauthorized.
Security professionals call it “MFA fatigue” or “push notification bombing.” Attackers call it effective.
The Social Engineering Layer
In Uber’s case, the attacker added one more element: they contacted the contractor directly.
Posing as Uber IT support, the attacker messaged the contractor claiming the notifications were part of a system fix. “Just approve the next one and they’ll stop,” the message suggested.
Tired of the constant alerts and believing they were talking to legitimate IT staff, the contractor approved the authentication request.
That combination—technical persistence plus social manipulation—is what makes MFA fatigue attacks so dangerous. The victim often knows something is wrong but approves anyway.
Why Traditional MFA Failed
Uber had implemented what many organizations consider best practice: multi-factor authentication requiring device approval.
But the implementation had a critical flaw—it allowed unlimited authentication attempts without throttling or alerts. An attacker could send 100 push notifications with no consequences beyond annoying the user.
The system treated each authentication request independently. No escalation after 5 denials. No automatic lockout after 10 attempts. No alert to security teams that something abnormal was happening.
The MFA provided security theater—visible protection that gave a false sense of safety—without addressing the human factor.
What Makes You Vulnerable
Your organization is vulnerable to MFA fatigue attacks if:
- MFA push notifications have no attempt limits
- Users can approve requests without context (what device, what location, what service)
- No alerts trigger after multiple denied attempts
- Contractors and vendors use the same MFA as internal employees
- Users receive MFA requests during off-hours with no additional verification
The Uber breach demonstrated that MFA alone—without proper implementation and monitoring—creates a false confidence. You believe you’re protected because you have two-factor authentication. You’re not wrong, but you’re not as safe as you think.
The Aftermath
Uber disclosed the breach publicly after the attacker announced it themselves. The company’s new chief security officer, hired just months earlier specifically to improve security culture, faced their first major crisis.
The Federal Trade Commission later included the Uber breach in enforcement actions, highlighting the company’s pattern of security failures. The incident cost Uber millions in investigation, remediation, and regulatory response.
But the broader damage was to trust. Uber riders, drivers, and employees all had to question whether their personal information was secure. The breach exposed sensitive data including:
- Driver license information
- Social Security numbers
- Background check details
- Internal communications
- Security vulnerability reports
For the contractor whose account was compromised? They likely faced internal review despite being the victim of a sophisticated social engineering attack.
What Actually Prevents This
Preventing MFA fatigue attacks requires layering defenses:
Number matching: Instead of “Approve yes/no,” the system displays a number that must be entered on the authenticating device. This eliminates mindless approval.
Attempt throttling: After 3 denied MFA requests, lock the account and alert security. After 5 denials, require in-person verification.
Context in requests: Show users what they’re approving—device type, location, IP address, time. “Someone in Russia is trying to log into your account at 3 AM” gets different treatment than generic requests.
Time-based restrictions: If your employees never log in from Asia at 2 AM, automatically deny those requests regardless of MFA approval.
Separate authentication for high-value access: Administrative accounts shouldn’t use the same MFA as standard users. Add hardware tokens or biometric requirements.
The goal isn’t making authentication harder—it’s making social engineering attacks impossible to execute at scale.
The Real Lesson
The Uber breach proves something security teams already knew: people will eventually do what’s convenient, even when they know it’s wrong.
The contractor who approved that authentication request wasn’t careless. They were human. Exhausted. Overwhelmed. Trusting that someone claiming to be IT support was telling them the truth.
Your security architecture has to account for that. Not with blame or punishment—with design that makes the secure choice the easy choice.
MFA fatigue attacks work because the secure action (denying every single request) creates friction. The attack exploits that friction.
The question isn’t whether your employees will eventually approve something they shouldn’t. The question is: what happens when they do?
Take Our 2-Minute Security Assessment
centrexIT has protected San Diego businesses since 2002. If MFA fatigue attacks concern you—or if you’re not sure whether your authentication system can withstand this kind of social engineering—let’s find out together.
Take the 2-Minute Cybersecurity Assessment:
https://centrexit.com/cyber-security-readiness-assessment/
Sources
- TechCrunch: “Uber Investigating Breach of Internal Computer Systems” (September 2022)
- BleepingComputer: “Uber Hacked, Internal Systems Breached” (September 2022)
- The New York Times: “Uber Investigating Breach of Its Computer Systems” (September 2022)
- KrebsOnSecurity: “MFA Fatigue Attacks” (2022)
- CISA: “Multi-Factor Authentication (MFA)” – Cybersecurity Best Practices
- Microsoft Security: “Number Matching in Microsoft Authenticator” (2022)