2022 · Ride-hailing

Uber, 2022: multi-factor authentication held, and then somebody sent a WhatsApp message

Case file · 5 min read · Published 15 September 2026

People affected: No evidence of access to customer accounts or trip data; internal tools, Slack, cloud consoles and vulnerability reports were reached
When it happened: 15 September 2022
Made public: 15 September 2022
How they got in: Stolen contractor credentials, multi-factor fatigue plus social engineering over WhatsApp, then hardcoded privileged credentials found in an internal PowerShell script
Attributed to: Attributed by Uber to Lapsus$; a UK teenager associated with the group was later convicted over a series of intrusions including this one
What it cost: No customer data loss established; internal tooling compromised, including access to the company's vulnerability disclosure programme

What was exposed: Internal collaboration and messaging systems · Cloud and identity administration consoles · Internal vulnerability reports

Uber had multi-factor authentication. It was enabled, it was enforced, and on the night of 15 September 2022 it worked precisely as specified: a login attempt from an unrecognised source generated an approval request to the account holder's phone. Then it generated another, and another, and then the account holder received a WhatsApp message explaining that the prompts would stop if they accepted one.

What happened

The starting point was a contractor's corporate credentials, which reporting indicates were purchased on a dark web marketplace after most likely being harvested by information-stealing malware on a personal device. On its own the password was useless, because the second factor stood in the way.

So the attacker attacked the second factor at the only point where it is soft: the human being approving it. Repeated login attempts generated a stream of push notifications. The contractor declined them. The prompts continued. The attacker then contacted the contractor over WhatsApp, presenting as Uber IT support, and said the notifications were the result of a problem that would be resolved once one was accepted. One was accepted.

What came next is the part with the broader lesson. Being inside the network as a contractor is not, by itself, very valuable, the account was not privileged. Looking around the internal file shares, the attacker found a PowerShell script containing hardcoded administrative credentials for the company's privileged access management system: the vault where administrative secrets are kept. One script, one plaintext credential, and the vault opened. From there came access to cloud consoles, the identity provider, internal dashboards, Slack, where the attacker posted a message announcing the breach to the workforce, and the company's account on its vulnerability disclosure platform.

MFA is not a boolean. "Do you have MFA?" is the wrong question, and it is the one on every security questionnaire. Push-approval and SMS codes stop credential stuffing and undirected phishing, and they fold against an attacker willing to spend twenty minutes on one person. Phishing-resistant factors, hardware security keys and passkeys bound to the origin, do not fold, because there is nothing for the user to approve that a fake site can use and no code that can be read out or relayed. The gap between those two is the gap this breach went through.

The secret in the script

The social engineering is what gets retold, and the hardcoded credential is what actually mattered. Everything beyond a single contractor's ordinary access followed from a secret written into a script and left on a share where any authenticated user could read it.

That file exists in most organisations. It is written during an outage or a migration by somebody who intends to remove the credential afterwards, and the credential stays because the script keeps working and nothing ever forces a review. Privileged access management exists exactly to stop long-lived administrative secrets from lying around, and the credential to the system that holds all the other secrets was lying around.

The defence is unglamorous: scan repositories and shared storage for secrets continuously rather than during audits, issue short-lived credentials so that a leaked one expires on its own, and treat any human-readable administrative password as an incident rather than a finding. The measure of success is not that no secret is ever written down. It is that a secret written down in March is dead by April.

The timeline

Before 15 September 2022: A contractor's corporate credentials are obtained, most likely via information-stealing malware, and sold.
15 September 2022, evening: Repeated login attempts flood the contractor's phone with approval prompts; a WhatsApp message posing as Uber IT asks them to accept one.
15 September 2022: The attacker reaches the internal network and finds a script containing hardcoded privileged access management credentials.
15 September 2022, later: Internal tools, cloud and identity consoles and the vulnerability disclosure account are accessed; a message is posted in the company Slack.
16 September 2022: Uber confirms the incident publicly and takes internal tools offline while it investigates.
Late September 2022: Uber attributes the intrusion to Lapsus$ and states it has found no evidence of access to customer accounts or trip data.
2023: A UK teenager associated with Lapsus$ is convicted over a series of intrusions, this one among them.

What it changed

This breach, alongside the 0ktapus campaign against Twilio and others in the same year, moved phishing-resistant authentication from a recommendation to an expectation at large technology companies. Push-based approval was not abandoned everywhere, but the assumption that it constituted adequate protection for administrative access did not survive 2022.

It also changed how MFA fatigue is treated operationally. Number matching, where the user must type a digit displayed on the login screen rather than simply tapping approve, was rolled out widely by identity providers, along with rate limiting on repeated prompts and alerting on the pattern itself. A flood of declined approvals is now, correctly, treated as an attack in progress rather than as a malfunction.

The quieter shift was cultural, and it is the one most organisations still get wrong. The contractor who accepted the prompt had been worn down and then lied to by someone who sounded like their own IT department. Organisations that responded by blaming users got less reporting and slower detection; the ones that responded by making it safe and quick to say "I think I just approved something I should not have" got the opposite.

If you use Uber

Uber stated that it found no evidence of access to customer accounts, trip histories or payment details, and no customer data exposure was subsequently established. On the current public record there is nothing for riders or drivers to remediate from this incident, and this archive is not going to manufacture an action item where none exists.

The applicable lesson is about your own accounts rather than about Uber. If your second factor is a push notification or an SMS code, it protects you against bulk attacks and not against someone who has decided to target you specifically. On the accounts that can reset everything else, your primary email above all, move to a passkey or a hardware security key. And treat any unexpected approval prompt as what it is: proof that somebody already has your password, and an instruction to change it rather than a decision about whether to tap approve.

Questions people ask

What is MFA fatigue?

Where the second factor is a push notification that the user approves with a tap, an attacker who already has the password can request approval over and over. The victim's phone fills with prompts, at any hour, with no way to make them stop. Eventually somebody taps approve, to end the noise, or because they assume a system is malfunctioning. The control is not bypassed technically. It is worn down.

How did the attacker get the password in the first place?

Reporting indicates the contractor's corporate credentials were obtained from a dark web marketplace, having most likely been captured by information-stealing malware on a personal device. This is the ordinary supply chain for initial access now: the credential is a commodity bought for a small sum, and the work begins after login.

What did the attacker actually reach?

After getting onto the internal network they found a PowerShell script on a shared drive containing hardcoded credentials for a privileged access management system, the vault holding administrative secrets. That unlocked access to a range of internal tools including cloud consoles, the identity provider, internal dashboards and Slack, where the attacker announced the breach. Uber stated it found no evidence of access to customer accounts or trip history.

Why does a vulnerability disclosure programme matter here?

Because the attacker reached Uber's account on its bug bounty platform, which holds reports of vulnerabilities that have been submitted but not yet fixed. That is a list of ways into the company, written by researchers, held in one place. Any organisation running a disclosure programme should treat that account as a crown-jewel system rather than a security team convenience.

Sources

Uber, security update and incident statements, September 2022
Contemporaneous technical reporting and screenshots published by the attacker, September 2022
UK prosecution and 2023 verdict concerning Lapsus$-associated intrusions
CISA guidance on phishing-resistant multi-factor authentication