Uber 2022 Breach and MFA Fatigue to Internal Tool Escalation

The 2022 Uber breach deserves study for its architecture, not its scale. Every stage of the attack was made possible by design choices, not by exceptional attacker skill, which is precisely what makes it the clearest teaching case available for modern enterprise access failure. The attacker was reportedly 18 years old, affiliated with the Lapsus$ group, the same gang that struck Microsoft, Cisco, Samsung, and Okta using comparable methods in 2022 alone. There was no zero-day, no custom malware, no cryptographic trick. There was a contractor, a flood of push notifications, and a corporate network with almost nothing standing between the front door and the crown jewels.

What makes Uber instructive is not that an attacker got in. Attackers get in constantly, at companies with far less sophisticated security programs than Uber's. What makes Uber instructive is the distance covered after entry and the speed at which it was covered. Within hours of a single approved MFA push, the attacker had reached Slack, AWS, and Google Workspace. That is a story about an access model that had no mechanism to notice, question, or stop an authenticated session doing things no legitimate session would ever do.

Push-bombing and social engineering: how the attacker got past MFA

MFA fatigue, also called push-bombing, works on a simple premise: send enough authentication prompts to a device and eventually the person holding it will tap "approve" just to make the noise stop. The attacker had obtained the contractor's credentials, likely purchased on the dark web after the contractor's personal device had been infected with malware, though some accounts describe the initial vector as smishing, with the attacker posing as Uber IT support to extract a VPN password directly. The two explanations have not been definitively reconciled in public disclosures, but both agree that social engineering got the attacker past the front gate.

Credentials alone were not enough. The account was protected by multi-factor authentication, so the first login attempts triggered push notifications that the attacker could not approve. So the attacker switched channels, contacting the contractor directly over WhatsApp, posing as a member of Uber's IT support team, and asking them to approve the MFA prompts that were about to arrive. What followed was less a hack than a war of attrition: a barrage of push notifications sent to the contractor's phone, one after another, until the contractor, worn down, approved one.

The approval was enabled by a design failure. Uber's push-based MFA had no rate limiting, no automatic lockout after repeated denials, and no alert routed to the security team when an account was being hit with a flood of requests. An attacker could send prompts indefinitely at no cost beyond annoying the target. MFA was built to require a second factor, not to confirm that the person holding that factor was acting under their own free will and sound judgment, which is a distinction security teams often gloss over and attackers exploit constantly. The contractor approved a single notification. The attacker was in.

Hardcoded credentials and an open PAM vault

The approved push notification was not the breach. It was the door to the breach, and what the attacker found on the other side of that door turned a single compromised VPN session into total internal access. Once authenticated, the attacker began moving laterally across internal network shares, and any attacker with legitimate-looking credentials can perform this kind of routine reconnaissance without raising suspicion.

On one of those shares sat a PowerShell script, and inside it, in plain text, were hardcoded administrative credentials for Uber's privileged access management tool. A PAM system exists to control and audit access to sensitive systems; it is supposed to be the vault, not something a script casually references in cleartext. Those credentials functioned as a master key to Uber's corporate network. With PAM admin access in hand, the attacker no longer needed to exploit anything. The systems confirmed as accessed included Slack, Google Workspace, Amazon Web Services, VMware vSphere, an internal finance tool used to manage company invoices, and HackerOne, Uber's bug bounty platform, which held detailed reports of vulnerabilities, some of them unpatched.

The attacker's conduct inside the network reads less like an extended campaign and more like a victory lap. On September 15, 2022, Uber employees saw a message posted to the company's internal Slack: "Hi @here I announce i am a hacker and uber has suffered a data breach." The attacker also reconfigured Uber's OpenDNS system to display a graphic image to employees on some internal pages. Uber's investigation later found no evidence that the attacker reached production systems storing sensitive user data, but confidential material, including internal invoices and the HackerOne vulnerability reports, was exposed. The attacker's choice to announce rather than persist produced what restraint there was. Lapsus$ runs on notoriety and data extortion rather than quiet, sustained infiltration, which bounded the damage in this case. Nothing about Uber's internal environment would have stopped a more patient attacker from doing considerably worse.

Contractor accounts, inherited permissions, and the absence of runtime controls

Speed is the detail that separates this case from a routine phishing story, and the speed came from the environment, not from the attacker's talent. The compromised contractor account was not some low-privilege guest login. It carried access broad enough for the attacker to locate internal network shares holding PAM credentials, so the account itself was already a meaningful liability before any credentials were stolen.

Traditional access models draw a hard line at authentication. Once a session passes MFA, it is trusted, and almost nothing checks whether that session continues behaving the way the account's legitimate owner would behave. No alert flagged a contractor account pulling PowerShell scripts off a network share. Nothing flagged that same account querying a PAM vault. Nothing flagged the pivot to AWS and Google Workspace, all inside a single session, all within hours of the original login. Push-bombing explains how the attacker got past the gate. Overpermissioned accounts and the absence of runtime controls explain why, once past the gate, there was no second gate, no third gate, nothing but open hallways.

That same failure mode applies to AI agents operating inside enterprise environments, and it applies with less friction, not more. Agents inherit the permissions of the accounts or roles under which they run, they act at machine speed, and they are less likely than a human contractor to face behavioral scrutiny once authenticated. An agent running under a broadly provisioned service account can traverse the same internal tool surface the Uber attacker traversed, without even the hour of push-bombing that, however poorly handled, at least produced a visible signal that something was wrong. Uber's human attacker needed a lucky break and sustained pressure to get in. A misconfigured agent needs nothing but the permissions it was handed at setup.

The operational cost Uber paid

Reconstructing what happened cost Uber far more than the data exposed during the breach itself. The HackerOne compromise alone created a serious operational burden: the platform held detailed reports of vulnerabilities, some unpatched at the time of the breach, and Uber had to review and remediate every referenced vulnerability before resuming normal operations. A list of known weaknesses in the hands of an outside party is a liability that does not disappear once the attacker is locked out.

The deeper cost appeared in the aftermath. Uber's subsequent SEC filings note that its data security and privacy practices have been the subject of inquiries from government agencies and regulators, not all of which are finally resolved. Regulatory scrutiny of that kind runs on a timeline measured in years, not news cycles.

What the investigation revealed about Uber's access model is more instructive than the dollar figure of any single consequence. Uber could not surgically contain the attacker's reach because it could not quickly determine which systems the compromised account had actually touched. Breadth of access was invisible until investigators forensically reconstructed it after the fact. That is the real cost of an access model built without runtime visibility: the organization does not know the size of its own exposure until the exposure is already over.

What the attack chain required at each stage

The Uber attack ran through four distinct stages, and each stage depended on a different control failing. That matters because it means no single fix, applied in isolation, would have stopped the breach. Patching stage two without touching stages three and four leaves an attacker with a slightly harder front door and an identical empty house behind it.

Stage one was credential theft, achieved through a malware-infected personal device or smishing, depending on which account is accurate. Credential hygiene and endpoint protection are the standard answers here, and both failed quietly before the attack ever became visible to Uber's security team. Stage two was the MFA bypass itself, push-bombing with no rate limit and no alert. Two mitigations close this stage. Number matching requires the user to enter a code shown in the authentication prompt rather than tapping approve on a generic notification, which removes the "approve anything" failure mode that doomed Uber's contractor. Phishing-resistant MFA, built on FIDO2 and passkeys, goes further by removing the push-approval flow entirely: authentication is cryptographically bound to the legitimate origin, so there is no prompt to bomb and no approval a social engineer can talk anyone into giving. CISA designates FIDO and WebAuthn, alongside other hardware-backed authentication methods, as the only approved phishing-resistant methods, a distinction that matters because number matching reduces risk without eliminating the underlying vulnerability. A lower-cost interim step, rate limiting paired with automatic security team alerts on repeated denials, would have flagged the bombing in real time even without a full authentication overhaul.

Stage three was lateral movement to the PAM credentials, and hardcoded administrative credentials sitting in a PowerShell script on an accessible network share made it possible. The fix is secrets management: credentials belong in a vault, retrieved dynamically at runtime, never written into a script in plain text. This failure operated independently of the MFA failure and would have been just as catastrophic even if Uber had deployed phishing-resistant authentication at the perimeter. Stage four was the traversal of internal tools without detection, and this is where the human access model failed completely. No runtime monitoring watched the session. No policy enforcement governed what an authenticated account was permitted to do. This same structural weakness will make the model fail for AI agents by default.

Complete audit logs of every action an authenticated session takes are necessary, but logging only provides forensics after the fact. What actually stops lateral movement before it reaches a PAM vault is the capacity to act on anomalies while they are happening. The lesson across all four stages is sequential: each fix closes one stage but leaves the next one open. Phishing-resistant MFA closes stage two, but it leaves stages three and four wide open. Secrets management closes stage three and leaves stage four wide open. Only runtime behavioral monitoring paired with enforceable policy controls closes stage four, and most post-breach commentary skips past stage four.

Why the "human error" framing understates the structural problem

Blaming the contractor forecloses the questions that actually reveal whether an organization is sitting on Uber's exact conditions right now. The contractor's decision to approve a notification after being bombarded for an extended period was predictable behavior under engineered pressure, not a personal failing, and most organizations in the world could be breached the same way Uber was. What conditions made that approval possible, and what would have stopped the attacker even if the approval had been given anyway, matter more than why the employee approved the request.

That reframing changes what an audit should look like. Security teams should ask whether their push-based MFA has rate limiting and automatic alerts tied to repeated denials, because Uber's did not, and that absence is what let the bombing continue uninterrupted for as long as it did. They should ask whether privileged accounts have moved to phishing-resistant authentication built on FIDO2 and passkeys, not just standard MFA, since standard MFA is exactly the layer that failed at Uber. They should ask whether administrative credentials live in a secrets vault and get retrieved dynamically, rather than sitting hardcoded in scripts the way Uber's PAM credentials did. They should ask whether there is runtime visibility into what authenticated sessions, human or otherwise, are actually doing after login, since Uber had none. They should ask whether policy violations by an authenticated account can be detected and stopped as they happen rather than reconstructed afterward through forensics. And they should ask whether a complete, real-time audit log exists for every account in the environment, including service accounts and AI agents, not just the human logins that tend to get the most attention.

Agent deployments deserve specific weight here, because the Uber logic maps onto them almost without modification. Agents running under broadly provisioned accounts replicate every stage-three and stage-four condition that made Uber's post-authentication environment indefensible. They inherit human-scale access, they act on it at machine speed, and there is no MFA ceremony in most agent deployments that even creates a moment where anomalous behavior might be noticed. Discovering every agent running inside an organization, monitoring the traffic those agents generate, and detecting anomalous behavior before it reaches sensitive systems is the runtime control layer that Uber lacked in 2022 and that most enterprise AI deployments still lack by default.

The pattern of MFA-protected breaches between 2022 and 2025 settled a question that should no longer be open: number matching is a mitigation, not a solution. The structural fix is removing the approval prompt from the authentication flow entirely for privileged access, and building runtime controls on the assumption that the perimeter will eventually be crossed regardless of how well the front door is guarded. Uber's breach was not a story about one tired contractor tapping the wrong button. It was a story about a network with no mechanism to notice what happened after that button got tapped, and every organization running authenticated humans and authenticated agents should close that gap now, before its own version of the Uber Slack message appears.