What the 18-Year-Old Who Hacked Uber Knew About Your Employees
What the 18-Year-Old Who Hacked Uber Knew About Your Employees
What the 18-Year-Old Who Hacked Uber Knew About Your Employees

Author

Harley Sugarman

Published on

In September 2022, an Uber contractor received a WhatsApp message from someone claiming to be from Uber's internal IT security team.

The attacker, who claimed to be 18 years old, already had the contractor's email and password but still couldn't get in to their work account because Uber used multi-factor authentication. Every login attempt triggered a push notification to the contractor's phone for their approval.

So the attacker kept triggering them.

Notification after notification, for over an hour. But alongside the flood of pings, he sent a WhatsApp message: he was from IT security, and the contractor needed to approve the request to stop the activity.

He didn’t rely on notification fatigue alone. He added a story that made approval feel like the way to make the problem stop.

The contractor, simply wanting the deluge to stop, approved one.

And the attacker was in.

This technique has a name: MFA fatigue. Multi-factor authentication is a meaningful security layer, but it relies on the human on the other end making the right call, potentially under sustained pressure. Attackers who already have valid credentials can trigger those notifications at will, until the target approves one.

Once inside, the attacker found PowerShell scripts on an internal drive, one which reportedly contained hardcoded credentials for a privileged admin account.

That single exposed credential turned an account compromise into broad access across Uber’s internal systems. The attacker now had access to Uber's Slack, AWS, GCP, financial dashboards, and HackerOne account, which contained confidential reports from their bug bounty program.

He then announced the breach in Uber's own Slack channels and contacted the New York Times directly, sharing screenshots as proof.

The attacker exploited no zero-day vulnerabilities and wrote no malicious code. He had stolen some credentials, sent a WhatsApp message, and waited.

The framing that gets this story wrong

After the breach, a lot of the commentary focused on the person whose credentials were stolen. Who approved the notification. In the framing that dominates security right now, that contractor represents what the industry calls "human risk": the unpredictable, irrational, vulnerable employee who sits between your security stack and a breach.

That framing gets the lesson backward.

The contractor was a person put in an impossible situation by an attacker who understood human psychology better than their training program did. The attacker knew that authority + urgency + pressure = compliance.

This is teachable. They were never taught it.

When the industry frames employees as risks to be managed, it designs training programs that reflect that framing: compliance-driven modules, annual videos nobody watches, phishing simulations built to trick people rather than teach them. The implicit message is that the employee is the problem, and the security team's job is to document that they were warned.

Two failures. Two different responses.

There were two failures in this breach. The first was the social engineering failure. The contractor didn't know that a string of unsolicited MFA notifications is an indicator that someone already holding their credentials is attempting to break into their account. The second was a developer security failure. Hardcoded credentials in a PowerShell script is a basic secure coding error that can lie undetected for months. That requires a different intervention entirely: developer security education that builds secure coding as an engineering discipline, and internal practices that surface exposed credentials before an attacker does.

Why we built Anagram to address this

When I started building Anagram, I wasn't looking at enterprise security training at all. We built a capture-the-flag platform for security professionals, hands-on and adversarial, built around the premise that you learn security by trying to break things. CISOs kept asking if we could adapt it for their general workforce. That question eventually led us here.

The first thing I did was ignore almost everything the legacy security awareness vendors were building because none of it was designed around how people actually learn. It was designed around compliance documentation.

I looked at Duolingo and TikTok instead. Duolingo understood repetition. TikTok understood attention. Legacy awareness training mostly understood proof of completion.

The Uber contractor needed thirty seconds of specific knowledge: what MFA fatigue is, what an unsolicited push notification means, and what to do. If that knowledge was real and practiced rather than clicked through on a January compliance module and forgotten by March, the story ends differently.

That’s our job: training people for the moments attackers actually create, across every channel they use.

The wrong starting point is treating employees as a risk to be mitigated. Preparing them as the last line of defense, and actually equipping them for that role, is a different task entirely.

Anagram builds security awareness and developer training designed around behavior change.

If you want to see what that looks like, book a demo here.

Keep
Learning

A short blurb about our resources for learning.

Keep
Learning

A short blurb about our resources for learning.

Your Finance Team and Engineering Team Should Not Get the Same Security Training

Most security awareness platforms were built with compliance in mind, not learning. The goal was to get everyone through the content and generate a completion report. Role-specific delivery was an afterthought, if it was a thought at all. That made sense when attacks were more uniform and when the tooling didn't exist to do anything more sophisticated. It doesn't make sense now.

Your Finance Team and Engineering Team Should Not Get the Same Security Training
What Most Security Training Still Fails to Measure

You start the module. You realize it’s going to take a while. You half-pay attention for a minute, move it to the second monitor, click through the quiz, and get back to work. Whether any of it changed anything is a different question. That disconnect is why we need to start thinking about security awareness metrics differently -- because so much of this category is built around proving the training happened, not proving it did anything.

What Most Security Training Still Fails to Measure
Keep
Learning

A short blurb about our resources for learning.

Your Finance Team and Engineering Team Should Not Get the Same Security Training

Most security awareness platforms were built with compliance in mind, not learning. The goal was to get everyone through the content and generate a completion report. Role-specific delivery was an afterthought, if it was a thought at all. That made sense when attacks were more uniform and when the tooling didn't exist to do anything more sophisticated. It doesn't make sense now.

Your Finance Team and Engineering Team Should Not Get the Same Security Training
What Most Security Training Still Fails to Measure

You start the module. You realize it’s going to take a while. You half-pay attention for a minute, move it to the second monitor, click through the quiz, and get back to work. Whether any of it changed anything is a different question. That disconnect is why we need to start thinking about security awareness metrics differently -- because so much of this category is built around proving the training happened, not proving it did anything.

What Most Security Training Still Fails to Measure

Security training that actually sticks.

Security training that actually sticks.

Security training that actually sticks.