In this section, we explore a cyberattack experienced by the company Uber. As in the previous case study, we will analyze the methods attackers used to penetrate the organization’s network, escalate their privileges, and possibly exfiltrate valuable information.
Overview
On September 15, 2022, Uber — a well-known rideshare and food delivery company — officially confirmed an organization-wide security breach [244]. According to public reports [243] [245] [246], the attacker infiltrated the organization’s systems and moved laterally to access critical resources. The discovery of the intrusion became evident when a 17-year-old individual, claiming to have compromised Uber’s systems, shared evidence of the intrusion. This included snapshots of vital assets such as an email dashboard and privileged server access, as well as vulnerability reports, thereby validating the successful breach of the internal network [244]. Following the attack, the attacker announced his success to the entire company through the organization-wide utilized messaging application [247].
Our Approach
The following describes the phases of our case study.
1. Action Tracing: We reconstruct the actions taken by the attacker using the chain of events method [217]. This involves examining a series of actions and their effects that are linked together, resulting in the particular outcome.
2. Missing Security Control Measures Assessment: We identify and highlight the security measures expected under a ZTA that were missing during the breach.
3. Discussion: Finally, we discuss the incident from our perspective, theorizing to what extent a deployed Zero Trust Architecture could have influenced the impact of the attack in terms of containing the incident.
The information about the attack, the sequence of events, and the missing security measures at the time of the breach rely on public sources such as articles [243] [244] [245], security bulletins [248] [249], official statements from involved parties [250], press releases [251] [254], and social media posts [252] [253].
1. Action Tracing & 2. Missing Security Control Measures Assessment
In this part, we systematically follow the likely path that the attacker took, examining the chain of events in sequence. The events are illustrated in Figure 69.
Source: https://www.cyberark.com/resources/blog/unpacking-the-uber-breach
→ Phase 1: Reconnaissance
We assume the attacker browsed dark web markets to buy stolen credentials that would grant access to Uber’s internal network. Before the incident, logs gathered from infostealers were put up for sale on the dark web on September 12 and 14 [248]. Since the attack utilizing these credentials was revealed from September 15 to 16, we are confident that the compromised credentials were fresh.
** Missing Security Control Measures **
Threat Intelligence: The failure to monitor dark web forums and marketplaces meant that they disregarded the chance to identify and address the compromised employee information.
→ Phase 2: Weaponization
This step typically refers to pairing a cyber weapon (like malware) with a delivery method. In this attack, credentials purchased from the dark web market were weaponized for unauthorized access to Uber’s system.
** Missing Security Control Measures **
No specific missing security measures at this phase.
→ Phase 3: Delivery
Having obtained the credentials, the attacker’s initial attempt to connect to Uber’s network failed due to MFA protection [244]. The threat actor initiated a multifactor authentication fatigue attack, repeatedly attempting to log in and flooding the contractor’s Uber account with MFA notifications [245]. Then, by posing as a member of Uber’s security team and contacting the Uber employee via a messaging app, the hacker pressured the employee to approve an MFA request [248]. Succumbing to the flood of notifications, the employee was granted network access, giving the attacker a foothold inside Uber’s internal network.
** Missing Security Control Measures **
Authentication and Access Control Measures: Uber failed to monitor login attempts properly. Uber didn’t receive notifications if a third party tried to log into a business account but failed to enter the network [255]. These failed entry attempts did not trigger Uber’s security system networks. This is most probably due to the absence of endpoint host checks, risk-based or attribute-based authentication mechanisms, or conditional access measures (e.g., device fingerprinting, domain connections, geo-IP tracking, location data, device X.509 certificate authentication), and it left gaps in the company’s security posture evaluation and alerting.
Security Awareness Training: Without regular training and simulated phishing tests, employees were left vulnerable and unprepared to recognize and fend off such attacks.
Note on MFA: It’s a common misconception that MFA completely prevents unauthorized access. While often reliable, MFA can be vulnerable to Man-in-the-middle attacks (MiTM), briefly mentioned on page 83. For instance, an attacker could bypass MFA by creating a fake login page that closely resembles the original and using it for phishing victims’ credentials.
→ Phase 4: Exploitation
From the public reports, we hypothesize that the hacked contractor’s account didn’t have unique access rights but was allowed read access to a broad range of network file shares, either due to providing accessibility or a misconfiguration. The attacker located a PowerShell script containing hard-coded privileged credentials for Uber’s Privileged Access Management (PAM) solution within this network share [252]. PAM refers to a process that helps organizations maintain strict control over privileged accounts, which have elevated permissions to access sensitive systems and data. This gave the attacker admin-level access to various systems. [244][257].
** Missing Security Control Measures **
Credential Management: Storing credentials in clear text, without segmentation into secure containers, created exposure. Implementing encryption and storing sensitive digital assets in isolated, secure containers/vaults would have restricted the level of unauthorized access.
MFA Protocols: Incorporating physical security authentication keys, such as FIDO2 [256], to necessitate physical interaction during authentication would have reinforced an additional layer of protection, especially during privileged account authorization.
Network Segmentation and Single Sign-on (SSO): Critical resources lacked strategic segmentation. There were no policy enforcement measures in place, such as whitelisting specific IPs, to control which addresses could communicate with certain resources. While SSO provided ease of access, its configuration settings didn’t have sufficient access control mechanisms enforced. This made the system vulnerable, especially if the credentials were found. We observed no strategic approach or operational measures that set distinct access levels or reduced data exposure risks across different platforms and among privileged accounts.
→ Phases 5 and 6: Installation and Command and Control (C&C)
With the obtained high-privileged user in the PAM solution, the attacker used the credentials to further establish persistent presence and control into Uber’s sensitive services, including Amazon Web Services (AWS), an Endpoint Detection & Response (EDR) software, Google Workspace, Slack, VMware vSphere — cloud computing virtualization platform [247][254]. The hacker also allegedly accessed Uber’s bug bounty reports, which often contained unremediated security vulnerability reports [252].
** Missing Security Control Measures **
Granular Monitoring: The privileged account within the PAM system was not adequately monitored. According to published reports, there were no measures in place to recognize typical administrative actions and anomalies, making detection difficult. Without user-specific monitoring and/or application-specific monitoring, the organization was unable to identify the compromised admin account and respond to the attacker’s lateral movement across its infrastructure.
→ Phase 7: Actions on Objective
Despite the extensive compromise of systems, the attacker chose not to inflict damage on Uber’s systems. No actions, such as the deployment of ransomware or data theft, seem to have been reported [248] [254].
** Missing Security Control Measures **
No specific missing security measures at this phase.
Impact
Although the attacker gained administrative access to several of Uber’s sensitive internal resources, including AWS Identity Access Management (IAM), and the Endpoint Detection and Response (EDR) portals, the damage of the attack is minimal, as the attack did not result in any significant harm to the systems or operations like deployment of ransomware or company sensitive data theft. There are suggestions that the attacker was driven more by the thrill of success and recognition within the hacking community rather than malicious intent or financial gain [247] [254]. The only confirmed exfiltration includes some internal messages and limited information from financial software used for managing invoices [243]. No publicly announced evidence has shown proof of access to sensitive information, such as Personally Identifiable Information (PII), trip history, or payment preferences [250].
After the attacker revealed their actions, the company responded by taking several reactive measures to mitigate the damage and further secure their systems [250]:
- The company’s codebase was locked down for a while, preventing any new code changes.
- Compromised and suspectedly compromised accounts were identified, blocked, and remediated.
- Many internal tools like Powershell usage and system configuration settings modifications were further limited for all personnel.
- Access control enforcements were reset on many of Uber’s internal services.
3. Discussion
This recent cyberattack on Uber, along with similar incidents against major companies such as Cloudflare [257] and Cisco [258], highlights the continuous threat of social engineering that organizations face today. What stands out in the Uber incident is the hacker’s choice to walk away after gaining complete control over the company’s systems. Without any security barriers, the attacker could have easily launched ransomware or sold vulnerabilities and privileged account credentials on the dark web if driven by financial interests. The specifics of certain security measures employed by Uber, such as Data Loss Prevention (DLP), remain ambiguous. Nevertheless, considering the level of access achieved by the attacker, the hacker could have easily evaded detection by altering configurations and exfiltrated information.
Like the Equifax breach, the breach at Uber was also more than just a failure of a single entity; it consisted of a chain of events that included social engineering, insider manipulation, compromised credentials, undetected privilege escalation, and a lack of proper application segmentation. The attacker gained access to the internal network using the VPN credentials of an external consultant, who was inherently supposed to have limited access to Uber’s internal resources. The truly damaging aspect of the breach occurred when the attacker discovered plain-text credentials in a network file share exposed to this compromised employee.
After defining the attack steps and highlighting the missing security measures, we acknowledge the potential of the Zero Trust model and the dynamics it enforces on security. We firmly believe that if Uber’s security architecture had encompassed multilayered control systems and employed a defense-in-depth approach integrated with Zero Trust strategies, the compromise’s impact could have been contained and mitigated at the initial access stage. The attacker might have gained the initial entry but would have been substantially restricted in their ability to navigate further or access more sensitive systems.
References
[217] K. Singh, J. Maiti, and K. Dhalmahapatra, “Chain of Events Model for Safety management: Data Analytics Approach,” Safety Science, vol. 118, pp. 568–582, Oct. 2019, doi: https://doi.org/10.1016/j.ssci.2019.05.044
[243] CyberArk Blog Team, “Unpacking the Uber Breach,” www.cyberark.com, Sep. 20, 2022. Available: https://www.cyberark.com/resources/blog/unpacking-the-uber-breach
[244] Masarrati, “Recent Uber Breach and Lessons Learnt ,” HAWKEYE, Sep. 29, 2022. Available: https://www.hawk-eye.io/2022/09/recent-uber-breach-and-lessons-learnt/
[245] R. Turner, “Meaningful Learnings from the Uber Breach,” Infosecurity Magazine, Sep. 27, 2022. Available: https://www.infosecurity-magazine.com/opinions/learnings-uber-breach.
[246] M. Jackson, “Uber Breach 2022 — Everything You Need to Know,” GitGuardian Blog , Sep. 16, 2022. Available: https://blog.gitguardian.com/uber-breach-2022/
[247] E. Kost, “What Caused the Uber Data Breach? | UpGuard,” www.upguard.com, Dec. 11, 2022. Available: https://www.upguard.com/blog/what-caused-the-uber-data-breach
[248] R. Lakshmanan, “Uber Claims No Sensitive Data Exposed in Latest Breach,” The Hacker News, Sep. 17, 2022. Available: https://thehackernews.com/2022/09/uber-claims-no-sensitive-data-exposed.html
[249] M. Kapko, “Uber Details How It Got hacked, Claims Limited Damage,” Cybersecurity Dive, Sep. 19, 2022. Available: https://www.cybersecuritydive.com/news/uber-attack-details/632193/
[250] Uber Team, “Security Update,” Uber Newsroom, Sep. 16, 2022. Available: https://www.uber.com/newsroom/security-update/
[251] S. Nichols, “Uber Says Lapsus$ Hackers behind Network Breach,” Security, Sep. 19, 2022. Available: https://www.techtarget.com/searchsecurity/news/252525111/Uber-says-Lapsus-hackers-behind-network-breach
[252] A. Yevdokimova, “Uber Breach 2022: Detect the Destructive Cyber-Attack Causing the Complete Organization’s System Takeover,” SOC Prime, Sep. 19, 2022. Available: https://socprime.com/blog/uber-breach-2022-detect-the-destructive-cyber-attack-causing-the-complete-organizations-system-takeover/
[253] “Uber Blames Hack on Lapsus$ Group,” Le Monde.fr, Sep. 20, 2022. Available: https://www.lemonde.fr/en/international/article/2022/09/20/uber-blames-hack-on-lapsus-group_5997648_4.html.
[254] A. Uberoi, “Uber Cyber-Attack: a Live Timeline,” www.cm-alliance.com, Sep. 18, 2022. Available: https://www.cm-alliance.com/cybersecurity-blog/uber-cyber-attack-crowdsourced-timeline
[255] T. Jethwani, “Uber Data Breach 2022: What You Need to Know,” www.appknox.com, Sep. 22, 2022. Available: https://www.appknox.com/blog/uber-data-breach-2022
[256] R. Campillo, “What Is FIDO2? What Is It for and How Does It work?,” Mobbeel, Apr. 19, 2022. Available: https://www.mobbeel.com/en/blog/what-is-fido2-what-is-it-for-and-how-does-it-work/.
