Skip to main content
  1. Blog/

The Uber Breach — When MFA Isn't Enough

·931 words·5 mins
Osmond van Hemert
Author
Osmond van Hemert
Breaches & Zero-Days - This article is part of a series.
Part : This Article

Today, Uber disclosed that an attacker gained broad access to their internal systems — Slack, Google Workspace, AWS consoles, HackerOne vulnerability reports, and more. The initial reports suggest it was an 18-year-old who got in through social engineering. Not a sophisticated zero-day exploit. Not a state-sponsored attack chain. A teenager with patience and a messaging app.

This should scare every engineering leader reading this. Not because Uber is uniquely bad at security — they’ve invested heavily since their 2016 breach — but because the attack vector exploits assumptions that most of us are making right now.

How It Happened
#

Based on what’s been reported so far, the attack chain went roughly like this:

  1. The attacker obtained credentials for an Uber contractor, possibly through a dark web marketplace or prior phishing campaign
  2. The contractor had multi-factor authentication (MFA) enabled
  3. The attacker repeatedly triggered MFA push notifications — a technique known as “MFA fatigue” or “MFA bombing”
  4. After being bombarded with authentication prompts, the contractor eventually approved one (the attacker also reportedly contacted them on WhatsApp, posing as Uber IT)
  5. Once inside the VPN, the attacker found a PowerShell script on a network share containing hardcoded admin credentials for Uber’s Privileged Access Management (PAM) system
  6. Game over. Those PAM credentials unlocked access to virtually everything

The screenshots the attacker posted to Uber’s internal Slack channels are almost comical in their breadth of access. AWS console, vSphere admin, Google Workspace admin, SentinelOne security dashboard — the attacker had the keys to the kingdom.

MFA Fatigue Is a Real Problem
#

Let’s talk about step 3, because this is where most security architectures are failing. Push-based MFA — where you tap “Approve” on your phone — was supposed to be the reasonable middle ground between security and usability. And for years, it worked well enough.

But MFA fatigue attacks exploit a fundamental UX problem: if you send someone enough push notifications at 3 AM, eventually they’ll tap “Approve” just to make it stop. It’s the authentication equivalent of alarm fatigue in hospitals, and it’s just as dangerous.

The mitigations exist but aren’t widely deployed:

  • Number matching: the authentication prompt shows a number that the user must enter, rather than just tapping “Approve”
  • Rate limiting: blocking excessive MFA requests and alerting security teams
  • FIDO2/WebAuthn: phishing-resistant hardware tokens that can’t be socially engineered
  • Contextual signals: denying authentication attempts from unusual locations or devices

Microsoft has been pushing number matching for Azure AD, and Duo has added similar features. But how many organisations have actually enabled these? In my experience consulting across the industry, the answer is “not nearly enough.”

The Hardcoded Credentials Problem
#

Step 5 is the one that really makes me wince. Hardcoded credentials in a PowerShell script on a network share. In 2022. At a company that employs thousands of engineers and has a dedicated security team.

Before anyone gets smug about this, I’d ask: have you audited every script, configuration file, and internal wiki in your organisation? I’ve been in this industry for thirty years, and I guarantee that virtually every company of sufficient size has credentials hiding in places they shouldn’t be. It’s not a matter of policy — every company has policies against this. It’s a matter of enforcement and tooling.

This is where secrets management platforms like HashiCorp Vault, AWS Secrets Manager, or Azure Key Vault earn their keep. But deploying them is only half the battle. You also need:

  • Automated scanning for secrets in code repositories (tools like truffleHog or GitLeaks)
  • Regular audits of shared drives and internal resources
  • Just-in-time privilege escalation rather than standing admin credentials
  • Network segmentation that limits lateral movement even after initial compromise

Zero Trust Isn’t Just a Buzzword
#

The Uber breach is a textbook argument for zero trust architecture — and I say that as someone who’s usually sceptical of security marketing terms. The core principle is straightforward: don’t trust anything inside your network perimeter any more than you trust things outside it.

In Uber’s case, once the attacker was past the VPN, they had remarkably free lateral movement. A zero trust approach would have required continuous verification at each system boundary, limited the blast radius of compromised credentials, and made it much harder to pivot from a contractor VPN session to AWS admin access.

The practical implementation looks like:

  • Microsegmentation of network resources
  • Per-application authentication rather than VPN-grants-everything
  • Continuous device health verification
  • Least-privilege access with time-limited elevation
  • Comprehensive logging and anomaly detection at every layer

My Take
#

Every security incident teaches us something, and the lesson from Uber’s breach isn’t new — but it’s one we keep failing to learn. Defence in depth isn’t optional. MFA is necessary but not sufficient. And the biggest vulnerabilities in most organisations aren’t technical — they’re the gap between security policy and actual implementation.

I’ll be watching closely as more details emerge about this breach. But if you’re an engineering leader reading this today, here’s what I’d do right now:

  1. Audit your MFA implementation. If you’re using simple push notifications without number matching, you’re vulnerable to fatigue attacks. Upgrade or add compensating controls.
  2. Run a secrets scan. Today. Not next quarter. Use automated tools to sweep your repositories, shared drives, and internal wikis.
  3. Review your PAM configuration. Standing admin credentials accessible from general network shares is an unacceptable risk.
  4. Test your lateral movement controls. Red team your own network — can a compromised VPN session reach your crown jewels?

Security isn’t a product you buy. It’s a practice you maintain. And days like today are uncomfortable reminders of what happens when the practice slips.

Breaches & Zero-Days - This article is part of a series.
Part : This Article