top of page
Search

Uber Breach 2022: MFA Fatigue and the Human Cost of One Approved Request

Writer: Rebecca Guy
Rebecca Guy
Nov 7, 2022
4 min read

Updated: Aug 31


A contractor's credentials, a flood of push notifications, and one approved request were enough to put an attacker inside Uber's internal systems. Attackers do not always need to exploit a software vulnerability to gain access. Sometimes the more effective path is through stolen credentials, authentication workflows, and the people who interact with them.


Case type: Social engineering / credential compromise

Identified: Sept 15, 2022 Disclosed: Sept 15, 2022

Attribution: Lapsus$-affiliated actor



When organizations think about cybersecurity threats, they often focus on technical vulnerabilities: unpatched systems, misconfigured cloud environments, sophisticated malware. Attackers think differently. Attackers look for whatever combination of technical weaknesses, stolen credentials, trusted processes, and human decisions gives them a workable path to access.


The 2022 Uber breach is a powerful example of why human risk deserves the same level of attention as technical risk, and why organizations need to think beyond the idea of "human error."





On September 15, 2022, an attacker posted screenshots in Uber's internal Slack channels and left comments on Uber's HackerOne bug-bounty reports, making the breach impossible to ignore internally or publicly. Uber confirmed it was "responding to a cybersecurity incident" that same evening, and the New York Times was first to report it publicly. The next day, Uber said there was no evidence the attacker had reached sensitive user data, and that internal tools taken offline as a precaution were coming back online.


The fuller picture came on September 19, when Uber published a detailed security update explaining how the attacker got in. It's likely the attacker purchased a contractor's Uber corporate password on the dark web after the contractor's personal device had been infected with malware. With that password in hand, the attacker repeatedly tried to log into the contractor's account. Each attempt triggered an MFA push notification, which initially blocked access. Eventually, the contractor approved one, and the attacker logged in.




From there, the attacker accessed several other employee accounts, gaining elevated permissions to internal tools including G-Suite and Slack. From a technical perspective, Uber had real security controls in place. MFA was enabled. Authentication mechanisms existed. Security tools were present. The attacker still succeeded because the authentication process could be pressured from another direction: repeated MFA requests combined with social engineering and a legitimate user's eventual approval.





Predictable behavior, not a lapse in judgment


Most post-breach discussions settle on a simple explanation: an employee clicked, a contractor approved a request, someone made a mistake. That's simple. It's also incomplete. The attacker was counting on something more reliable than a lapse in judgment: predictable behavior under pressure.


The attacker did not need to break the MFA technology itself. They needed to create conditions in which a legitimate user might eventually approve the request.

Repeated authentication prompts can create confusion, frustration, or habituation, particularly when an attacker pairs them with social engineering. The security problem is therefore larger than whether one person recognizes one suspicious prompt. That's social engineering in its purest form.





Not one decision. A set of conditions.


The question organizations should ask isn't "why did the employee approve the request?" A more useful question is: what conditions made that decision possible?

Human risk is rarely the result of a single action. It emerges when multiple controls, processes, and cultural factors fail to work together.






Attackers follow opportunity, not company size


Many small and midsize businesses assume attackers only target large enterprises. The reality is that attackers follow opportunity, not company size. The techniques used against Uber are not limited to large enterprises. Attackers look for whatever combination of technical weaknesses, stolen credentials, trusted processes, and human decisions gives them a workable path to access.




In many cases, smaller organizations face additional challenges:



A small accounting firm, law office, healthcare practice, or professional services organization may hold highly valuable information while maintaining far fewer layers of protection.





Training Completion Is Not a Risk Measure


One of the most common security metrics is training completion: did employees finish the course, did they pass the quiz. Completion and quiz scores can show whether required training occurred and whether information was recalled, but they do not by themselves demonstrate how employees will respond to realistic security decisions. A more important question is how employees behave when confronted with a realistic security decision.


Organizations should focus on measuring:



That's where the real risk lives.









"Human Risk Is Organizational Risk"


The Uber breach is often described as a story about social engineering. It's also a story about human risk. The real lesson is that people operate within systems, and security outcomes are shaped by technology, policies, communication, culture, leadership, training, and organizational design. When a breach occurs, focusing exclusively on the individual involved often misses the larger opportunity to improve the system itself.


Organizations that reduce human risk don't simply tell employees to be more careful. They build environments where secure decisions are easier to make, easier to recognize, and easier to reinforce.


BECAUSE ATTACKERS DO NOT NEED TO BREAK EVERY SECURITY CONTROL IF THEY CAN MANIPULATE THE TRUSTED PROCESSES AROUND IT.



SOURCES


Comments

bottom of page