Uber 2022: MFA Fatigue, a PowerShell Script, and Full Cloud Admin

, s3:, ec2:, rds: on all resources — create backdoor roles, exfiltrate all data, terminate productionGCP: project owner — all APIs, all storage, all service accountsGoogle Workspace: read all email, impersonate any user, export directory — complete business intelligence compromise

In September 2022, an 18-year-old attacker compromised Uber’s internal systems so thoroughly that they were able to post screenshots of the company’s AWS console, GCP dashboard, HackerOne vulnerability reports, internal Slack workspace, and code repositories — all in the same evening. The attacker later told journalists it had taken them about an hour.

The technical chain that produced this outcome involved four steps, each individually preventable. Together they collapsed Uber’s security posture from the outside in, using nothing more exotic than a bought credential list, a messaging app, and a PowerShell script on an internal file share.

Step 1: A contractor’s credentials, purchased

The attacker obtained the username and password for an Uber contractor’s corporate account from a dark web credential market — likely the product of an earlier phishing campaign or infostealer infection unrelated to Uber. Credential stuffing and purchased credential lists are the entry point for a significant fraction of enterprise breaches because corporate email addresses and the passwords associated with them are reused across services, and previous breaches make them available in bulk.

The contractor account had VPN access to Uber’s internal network, which was the attacker’s primary goal.

Step 2: MFA fatigue

The contractor’s account was protected by push-based MFA. The attacker could not satisfy this factor through stolen credentials alone, so they used MFA fatigue — also called push bombing. They attempted to authenticate repeatedly, triggering a stream of push notifications to the contractor’s phone. After receiving approximately 20 notifications in quick succession, the contractor accepted one — either to make the notifications stop, or after the attacker sent a WhatsApp message claiming to be Uber IT and asking the contractor to approve the sign-in.

Push-based MFA is vulnerable to this technique because the approval request carries no context about the authenticating session. The contractor sees “Approve sign-in?” on their phone screen, not the IP address or geographic origin of the request. There is no binding between the push and the specific session the attacker controls.

Step 3: Hardcoded credentials in a PowerShell script

With VPN access established using the contractor’s session, the attacker gained access to Uber’s internal network. Scanning internal file shares — a routine reconnaissance step — they found a PowerShell script containing hardcoded administrative credentials for Uber’s Thycotic Privileged Access Management (PAM) system.

This was the pivotal failure. A PAM system is designed to be the vault where privileged credentials are stored and access is controlled, audited, and time-limited. Hardcoding administrative access to the PAM system itself in a script on an accessible internal share inverted this model entirely: the safe was locked, but the combination was written on a sticky note next to it.

With admin access to Thycotic, the attacker could retrieve the credentials stored inside — service account keys, API tokens, and administrative passwords for Uber’s cloud environments.

Step 4: Full admin across the cloud estate

The credentials extracted from Thycotic included administrative access to Uber’s AWS and GCP environments and Google Workspace tenant. In AWS terms, this meant access equivalent to AdministratorAccess — the ability to call any IAM, S3, EC2, RDS, or other API on any resource in the account. In practice: read any data store, create backdoor IAM roles that would persist after the attacker’s session ended, terminate production infrastructure, or exfiltrate the entire environment.

The attacker used this access to take screenshots across systems and posted them publicly to demonstrate the extent of the compromise. They did not appear to exfiltrate large data volumes, but the access they held would have permitted it.

The controls that were missing

Phishing-resistant MFA. FIDO2 hardware keys (YubiKey, Google Titan) and passkeys are cryptographically bound to the relying party’s origin. They cannot be satisfied by a push notification sent to a phone — the hardware key must be physically present and the browser must be communicating with the legitimate domain. Push-based MFA and TOTP are susceptible to real-time phishing and fatigue attacks; FIDO2 is not. Microsoft and Google both now offer number-matching and additional context in push notifications as a partial mitigation, but hardware keys remain the only fully phishing-resistant option.

No hardcoded credentials anywhere in internal systems. Scripts, configuration files, and internal tools should never contain credentials — including credentials to credential management systems. In AWS, scripts running on EC2 or Lambda use IAM roles; no credential is written anywhere. For PAM systems specifically, access should require a just-in-time request flow, MFA re-authentication at the PAM layer itself, and session recording — not a static admin password stored in a script.

Contractor account hygiene. Contractor and vendor accounts are chronically over-permissioned and under-monitored. They frequently retain access beyond the engagement period, carry broader permissions than the work requires, and are not subject to the same anomaly detection thresholds as employee accounts. Contractor accounts should be time-limited, scoped to the minimum necessary access, and reviewed on each renewal — not left active indefinitely.

Anomaly detection on authentication. Twenty consecutive failed MFA attempts from an unrecognized IP, followed by a successful authentication, is a high-confidence signal of credential compromise. This pattern should trigger an automatic account suspension and security alert, not simply log a successful sign-in.

Takeaway

Uber’s breach illustrates a compounding failure pattern that is more common than the headline numbers suggest: a single weak link in the authentication chain gave access to an internal environment where a single script undermined an entire privileged access architecture. Neither failure required sophisticated tooling to prevent. Phishing-resistant MFA and the elimination of hardcoded credentials are well-understood baselines — and the cost of not meeting them, as Uber demonstrated, is total.