In September 2022, an eighteen-year-old sent an Uber employee a series of WhatsApp messages.
He claimed to be from Uber’s internal IT security team. He told the employee their account had been compromised. He explained that to fix the situation, the employee would need to approve an MFA notification that was about to arrive on their phone.
The notification arrived. The employee didn’t approve it.
Another notification arrived. They didn’t approve that one either.
This went on for a while — notification after notification, each one going unapproved, the employee presumably wondering why their phone kept buzzing at them. Then the attacker sent one more WhatsApp message. He said, essentially: I know this is annoying, but it’ll stop as soon as you approve one.
The employee approved the next notification.
That was it. That was the whole thing.
What Actually Happened
The technique has a name: MFA fatigue, or push bombing. The idea is straightforward — if an attacker has your username and password, they can trigger MFA push notifications on your phone repeatedly. Most people, if they receive enough notifications they didn’t initiate, will either approve one by accident or approve one just to make it stop. Add a social engineering layer — someone telling you it’s legitimate, that it’s coming from IT, that you just need to say yes — and the success rate goes up considerably.
Once inside Uber’s network, the attacker found something that made the situation significantly worse: PowerShell scripts stored on an internal network share with admin credentials hardcoded in plain text. It’s a shortcut that IT teams sometimes take — embedding credentials in scripts to avoid entering them manually — and it’s the kind of thing that seems fine until it very much isn’t.
With those credentials, he had access to a substantial portion of Uber’s infrastructure: AWS, Google Cloud, their internal Slack, their email systems. He also found his way into Uber’s HackerOne account — the platform where security researchers submit vulnerability reports — and left comments on open bug reports, just to make sure everyone knew he’d been there.
He then announced the breach in Uber’s own Slack channel. Because why not.
The attacker was reportedly affiliated with Lapsus$, a loosely organized group that had also hit Microsoft, NVIDIA, Samsung, and Rockstar Games around the same period using similar techniques.
The Two Problems Here
This breach is really two problems stacked on top of each other.
The first is MFA fatigue. Multi-factor authentication is genuinely good security — it stops the vast majority of credential-based attacks. But push notification MFA has a specific weakness: it relies on the person receiving the notification to make a judgment call in the moment. When attackers control the timing and volume of those notifications, and add a human voice (or message) reassuring the target it’s legitimate, that judgment call gets a lot harder.
The second is credential hygiene. Hardcoded credentials in scripts are the IT equivalent of writing your ATM PIN on the card. It happens. It happens more often than anyone would like to admit. But in this case, it turned a breach that might have been limited in scope into one that reached across Uber’s entire infrastructure.
What This Means for You
Switch to number-matching MFA if you can. Rather than a simple approve/deny push notification, number-matching requires the user to enter a number displayed on their screen into the MFA app. An attacker who triggers the notification without having access to the user’s screen can’t complete the challenge — so flooding the phone with notifications doesn’t work the same way. Microsoft Authenticator, Duo, and others support this. Enable it.
Teach your team what push bombing looks like. The rule is the same as vishing: if MFA requests arrive that you didn’t initiate, do not approve them. Full stop. Call IT on a known number and report it. One unexpected MFA notification might be a glitch. Two is suspicious. Five is an attack.
Audit your scripts and repositories for hardcoded credentials. This is unglamorous work, but it matters. Search your internal scripts, configuration files, and code repositories for passwords, API keys, and connection strings stored in plain text. There are tools that do this automatically — truffleHog, GitLeaks, and others — and most of them are free. Run one against your environment and see what comes up. You might be surprised.
Apply least privilege to service accounts. The admin credentials embedded in those Uber scripts had broad access. Even if hardcoded credentials are unavoidable in some context (they usually aren’t, but let’s say), they should have the minimum access needed for their specific job — not admin rights across the entire infrastructure.
An eighteen-year-old got into Uber’s infrastructure by asking someone to press a button. The rest was just walking through rooms that were left unlocked.
The scary part isn’t that it happened to Uber. The scary part is how reproducible it is.
