How did the Uber 2022 breach start?

With the credentials of an external contractor. Uber's own update stated the attacker likely purchased the contractor's corporate password on the dark web after the contractor's personal device had been infected with malware that steals credentials. The password alone was not enough, because the account required multi-factor approval.

What is an MFA fatigue attack?

The attacker has a valid password and repeatedly triggers the login, so the victim receives push approval prompts continuously. The intent is that the victim eventually approves one to stop the interruption, whether from irritation, confusion or the assumption that IT is doing something. In this case the attacker added a message on WhatsApp claiming to be Uber IT support and saying the prompts would stop once one was approved.

The activity was widely associated with the Lapsus$ group, and Uber's update stated the attacker was affiliated with it. A UK teenager was subsequently convicted in connection with Lapsus$ activity including the Uber intrusion. Attribution is a claim made by investigators rather than a technical fact, and it is stated here as they stated it.

What would have stopped it?

Several controls independently. Phishing-resistant authentication, meaning a hardware key or a passkey, which cannot be approved by a person under pressure. Throttling and alerting on repeated push denials. And most importantly, no plaintext administrator credential in a script on a share, which is what turned a foothold into total access.

Why does this incident get cited so often?

Because every step is ordinary and reproducible in most organisations. A reused or stolen contractor credential, push-approval MFA, a helpful-sounding message, and a script containing a password. None of it required an exploit, and the last step reached the system that holds every other secret.

The Uber 2022 Breach: MFA Fatigue to a Hardcoded PAM Password

Q: How did the attacker gain administrator access?

After connecting to the internal network, the attacker found a PowerShell script on a network share that contained hardcoded administrator credentials for Uber's privileged access management system. Those credentials opened the vault, and the vault held secrets for other internal systems and cloud services.

On 15 September 2022, a message appeared in Uber's internal Slack announcing that the company had been breached. It was the attacker.

The path they took is worth studying precisely because none of it was clever. A stolen contractor password. Enough push notifications to wear someone down. A message claiming to be IT. And then a file on a network share with an administrator password written into it, which happened to be the administrator password for the system that holds every other password.

That last step is the reason this case gets cited more than larger breaches. Everything up to it is a story about social engineering that most organisations have thought about. The finish is a story about a secret in a script, which most organisations still have.

Facts here come from Uber's own security update, Microsoft's analysis of the group's tradecraft, and the US Cyber Safety Review Board's review of Lapsus$ activity.

Timeline

Date	Event
Before September 2022	A contractor's personal device is infected with credential-stealing malware. Uber reported the corporate password was likely then purchased on the dark web
15 September 2022	Repeated login attempts generate a stream of two-factor approval requests to the contractor
15 September 2022	The attacker contacts the contractor on WhatsApp posing as Uber IT, saying the prompts will stop if one is accepted. One is accepted
15 September 2022	Access to the internal network. A PowerShell script on a share yields hardcoded admin credentials for the privileged access management system
15 September 2022	Access to internal tooling, including the vault's stored secrets and several internal systems
15 September 2022	The attacker posts in the company's internal Slack, announcing the compromise
16 September 2022	Uber confirms the incident publicly and begins response

The entire chain, from first push notification to administrative access, ran inside a single day.

Step one: a credential that was already gone

The contractor's password had been taken from a personal device by malware that harvests stored credentials, browser sessions and password manager data. Uber's statement described the attacker as likely having purchased it.

This is now the ordinary way intrusions begin, and it is covered in What Is an Infostealer. Credential-stealing malware runs on a personal machine, the harvest is sold in bulk, and buyers search it for corporate domains. The organisation whose credential is being sold has no visibility into any of it: nothing on their network was compromised, no alert fired, and the first sign is a valid login.

The structural point is that the corporate password existed on a device the company did not manage. Contractors, personal devices and unmanaged endpoints are consistently the softest edge of an otherwise well-run estate.

Step two: MFA that a person can be talked out of

The password alone did not work, because the account required a second factor delivered as a push notification.

The attacker did two things. First, repeated authentication attempts, generating a continuous stream of approval prompts. Second, a WhatsApp message claiming to be Uber IT support, saying the notifications were part of a fix and would stop once one was approved.

That combination is what makes the technique work, catalogued by MITRE as T1621. Push spam alone is annoying and suspicious. Push spam plus an explanation from someone claiming to be IT converts a suspicious event into a plausible one. The victim is not careless; they have been given a story that fits what they are seeing.

The configuration details that enabled it are worth naming, because they are settings rather than human factors:

No limit on authentication attempts. The prompts could continue indefinitely.
No alert on repeated denials. A user denying twenty approvals in ten minutes is one of the highest-signal events an identity provider can produce, and it was not treated as an incident.
A factor that a human can approve under pressure. This is the fundamental weakness.

The fix for the last one is phishing-resistant authentication: a hardware security key or a passkey, where the credential is bound to the origin and there is no prompt for a tired person to accept. Passkeys Explained and Two-Factor Authentication Guide cover the options, and number matching is the useful interim step where push cannot be replaced.

Inside the network, the attacker found a PowerShell script on a network share. The script contained hardcoded administrator credentials for Uber's privileged access management system.

Consider what that means. The PAM system exists to solve this exact problem. It holds credentials so they are not scattered in files, releases them under control, records their use, and rotates them afterwards. It is the control that limits what a foothold becomes.

Its own administrator password was in a script on a file share.

Once those credentials were used, the attacker had the vault, and the vault had the secrets for other systems and services. A single contractor account with no special privileges became administrative access across the environment through one file.

Two general lessons come out of this, both covered in Privileged Access Management Explained:

Secrets in scripts are secrets with no access control. A file on a share is readable by everyone who can reach the share, it is copied into backups, it appears in version control history, and it is never rotated because rotating it means finding every copy. A secrets manager exists so that the script fetches the credential at runtime under an identity that can be authorised, logged and revoked.

The vault is the highest-value target in the estate. Anything that holds every other credential deserves the strictest controls: its own administrators, phishing-resistant authentication, no standing access, alerting on every administrative authentication. Compromising it is a shortcut to everything it protects.

Step four: the announcement

The attacker posted in Uber's internal Slack, told employees the company had been breached, and listed systems reached. Screenshots circulated publicly.

This is characteristic of the group and it is operationally strange. Access this deep is normally kept quiet for as long as possible: an intruder with the credential vault could have persisted for months. Announcing it forced immediate response and ended the access.

There is a defensive point in that. Discovery in this case was instant because the attacker chose to be found. A quieter operator with the same access, using valid credentials for legitimate-looking actions, would have produced very little that a monitoring programme would flag. It is worth asking what would have detected this intrusion if nobody had posted in Slack, and for most organisations the honest answer is the vault authentication from an unusual source, if anyone was watching it.

What generalises

Corporate credentials live on devices you do not manage. Assume some are already for sale, and design so that a password alone achieves nothing.
Push approval is a factor a person can be persuaded to give. Phishing-resistant authentication removes the persuasion surface. Where push must stay, use number matching, throttle attempts, and alert on repeated denials.
Contractors sit inside the same systems and outside the strongest controls. They need the same authentication standard, particularly for anything reaching internal networks.
A secret in a script is the single most common escalation path in real intrusions. Not an exploit chain. A file.
The privileged access system is the crown jewel. Protect it accordingly, and monitor authentications to it as the highest-severity signal you have.

The verdict

An attacker with a purchased password, patience, and one convincing message reached the system that holds every other credential, in a day, without exploiting a single vulnerability.

The whole chain is defended by two changes that most organisations can make: phishing-resistant authentication so that no prompt can be approved under social pressure, and no plaintext credentials in scripts so that a foothold has nowhere to go. Neither requires a new product category, and both would have broken this intrusion at a different point.

Timeline

Step one: a credential that was already gone

Step two: MFA that a person can be talked out of

Step three: the script on the share

Step four: the announcement

What generalises

The verdict

Related guides

Sources & further reading