CASE-11 · Case Study — Uber: MFA Fatigue
What happened
In September 2022, Uber disclosed that an attacker had gained access to its internal systems. The way in was not a zero-day and not a clever exploit chain — it was a person. The attacker obtained the login credentials of an external contractor, most likely purchased after they were harvested by malware. Those credentials alone were not enough, because the account was protected by multi-factor authentication. So the attacker attacked the second factor directly: they logged in over and over, and each attempt fired a push notification to the real contractor's phone asking them to approve the sign-in.
This is called MFA fatigue, or push bombing. The idea is simple and ugly: bury the target in approval prompts until they cave. When the flood of notifications alone did not work, the attacker changed channels. Posing as Uber IT support, they contacted the contractor on WhatsApp and told them the prompts would stop if they just approved one. The contractor approved. That single tap turned a stolen password into a live, authenticated session inside Uber's network.
See it — the incident, entry to impact
timeline
title Uber 2022 — MFA Fatigue to Broad Access
Credentials : Contractor password stolen via malware
Push bombing : Attacker spams repeated MFA prompts
Social pull : Poses as IT on WhatsApp to get one approval
Inside VPN : Reaches the internal network
Secret found : PowerShell script with hard-coded admin creds
Broad access : Unlocks the privileged-access system
The root cause
There are two failures here, stacked, and the breach needed both. The first is the authentication design. The MFA in use was push-approval MFA — a simple "Approve / Deny" prompt. That kind of prompt carries no proof that the person tapping it is the person actually trying to log in, and it carries no binding to where the login is coming from. It reduces the whole security decision to one exhausted human being nagged into compliance. Push-approval MFA is real MFA, but it is phishable MFA: it can be defeated by pressure rather than by breaking any cryptography.
The second failure is what waited on the other side of the door. Once inside the VPN, the attacker did not stop at the contractor's limited access. They found a PowerShell script sitting on a network share, and that script contained hard-coded administrator credentials for Uber's privileged access management (PAM) system — the vault that brokers access to the most sensitive internal systems. A secret written in plaintext into a script is a secret with no expiry, no rotation, and no owner watching it. The stolen contractor login opened the front door; the hard-coded secret handed over the master keys. Neither alone would have been catastrophic. Together they turned one approved push into broad internal access.
The control that would have stopped it
The clean fix targets both failures. For the authentication layer, the answer is phishing-resistant MFA. FIDO2 and WebAuthn security keys bind the login to the specific site and to the physical key in the user's possession, so there is no prompt to spam and nothing a fake IT rep on WhatsApp can talk a victim into approving. Where hardware keys are not yet everywhere, number matching is the interim control: instead of a bare "Approve," the app shows a number that the user must read off the login screen and type in — which makes a blind, fatigued approval impossible, because approving requires seeing the attacker's actual session. CISA specifically recommends moving to phishing-resistant MFA and, short of that, enabling number matching to defeat push bombing.
For the second failure, the control is straightforward and old: no hard-coded credentials, ever. Secrets belong in a managed secrets store or vault, issued short-lived, rotated automatically, and scoped to the least privilege the job requires. A PowerShell script on a share should be able to request access through the PAM system under its own audited identity — not carry the PAM system's admin password in plaintext. Get either control right and the chain breaks: phishing-resistant MFA stops the login, and a vaulted, rotated secret means the foothold never escalates to the keys of the kingdom.
The blast radius
Uber stated that the attacker accessed internal systems and internal tooling, including its internal communications and some engineering and finance-related tools, and posted a message to an internal Slack channel. In its own disclosure, Uber said it found no evidence that the attacker accessed the production systems that run its user-facing apps, or that they accessed sensitive user data such as trip history. There was, in short, no confirmed customer-data theft — but the attacker had a broad, humiliating run of the internal environment, and the incident became one of the most cited examples of MFA fatigue in the industry.
It is worth setting this beside Uber's earlier, separate 2016 breach, which was notable for a very different reason: Uber concealed that incident and paid the attackers a one-hundred-thousand-dollar payment framed to look like a bug bounty. Different root cause, but the same organization learning, twice, how expensive a mishandled intrusion becomes.
The lesson
If your second factor can be approved by an exhausted human, it can be defeated by an impatient attacker — bind the login to a key, not to a tap.
Where it rhymes
This is textbook OWASP A07:2021 — Identification and Authentication Failures: weak or phishable authentication defeated at the human layer. On the MITRE ATT&CK map it lines up with Multi-Factor Authentication Request Generation (T1621) — the push-bombing technique — paired with Valid Accounts for the stolen contractor credentials and Unsecured Credentials for the hard-coded secret in the script. The defensive pattern to carry away is phishing-resistant MFA plus centralized secrets management: the login must be un-phishable, and the foothold must never find a plaintext master key waiting on the other side.
Named concepts: MFA fatigue, phishing-resistant MFA, hard-coded credentials, privileged access management
