What happened?
The first information about the incident was issued yesterday, September 15th, 2022. We know that a hacker called “Tea Pot” successfully accessed Uber infrastructure and critical cloud services such as AWS, Slack, Google Workspace, and others.
Most likely, Uber understood what had happened after this message was posted to their corporate Slack from the hacker itself:
Source: https://www.theverge.com/2022/9/16/23356213/uber-hack-teen-slack-google-cloud-credentials-powershell
The community became aware of this incident from a public message posted by a hacker on a bug bounty platform HackerOne, on behalf of the Uber account for bug hunters:
Source: https://twitter.com/vxunderground/status/1570597582417821703/photo/1
How it happened:
After the incident, one of the community members found the hackers’ contacts, such as a Telegram account, and messaged him to understand the details. As a result, we have the following piece of the dialogue:
Source: https://twitter.com/hacker_/status/1570582547415068672/photo/1
As we can see here, this attack started with social engineering on one of the Uber employees and caused unbelievable damage by hacking the Thycotic PAM system.
Thycotic is a PAM system, a Gartner MQ leader, used by Uber to store cloud credentials and API keys, such as AWS, GSuite (Google Workspace), DUA, Onelogin, and others.
Credentials for the Thycotic PAM were found by a hacker on one of the network shares inside Uber infrastructure in a PowerShell script. That’s the scariest part of this incident. Any Uber employee could have found the same share and used the hardcoded credentials to do the same.
Who was socially engineered from Uber?
UPDATE: the Group-IB company has another explanation of the initial penetration. In the post on LinkedIn https://www.linkedin.com/feed/update/urn:li:activity:6976588511638347777/ they rely on screenshots of the hackers' browser download dock. According to their analysis, it was malware-driven access, not social engineering.
UPDATE: Mike Wilkes / Chief Information Security Officer and risk evangelist | Advisor
The AWS console screenshot shared with those other screenshots also shows a username FWIW. If legitimate, it leads me to believe there was an AWS admin account created by Tea Pot on 9/15 at 19:22 eastern called “vc” by credentials taken from the password vault for a login with the name phil.lee@uber.com
The community doesn’t know this for sure, and most likely, this part of the incident will not be uncovered. However, the initial compromised Uber employee’s account was not privileged; that’s why the hacker spent time discovering a network share with a PowerShell script to get admin access for PAM.
However, one of the screenshots on Twitter refers to Chris Duarte, https://www.linkedin.com/in/csduarte/ Leading Enterprise Apps @ Uber, based in San Francisco.
There is no other evidence that his account was initially compromised by the social engineering attack.
What’s unclear?
The only missing part for the community of cybersecurity experts is how the hacker could bypass 2FA/MFA while running the initial social engineering attacks. And there is an answer between three options:
- The initial victim of the social engineering attack shared a one-time password/code with a hacker during the attack. In this case, we all waited for the message sequence used.
- The attacker compromised VPN credentials like private keys that don't require 2FA. In this case, the use case for the DUO security product mentioned by the hacker is unclear.
- Uber doesn’t have 2FA for VPN employee authentication. That’s hard to believe in.
UPDATE: a few readers mentioned the following message from the hacker that explains 2FA bypass as the following (source https://twitter.com/GossiTheDog/status/1570717994397073410/photo/1):
Lessons learned:
- No hardcoded credentials and temperate keys, such as SSH, VPN, cloud credentials, etc. Scan your shares and assets for hardcoded credentials before hackers do that. That’s an easy task.
- Always require 2FA/MFA for VPN. Split intranet by zones even inside VPN; segmentation required.
- No AWS keys. Use AWS IAM Instance Profile (https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_use_switch-role-ec2_instance-profiles.html) or GCP Application Default Credentials (https://cloud.google.com/docs/authentication/client-libraries#adc) or the same approach of granting access (part of every cloud's CIS Benchmark) instead of provisioning secrets.
- Use API security solutions, such as Wallarm, to protect internal services and systems, such as PAM, corporate portals, and management systems. It also helps with leaked API token blocking and investigations.
- The Wallarm Research Group routinely records data breaches (add company locations, sizes and industries). Use our "Data breaches" service for evaluation purposes, get a free report.
