Uber, 2022: a bought password and an accepted login prompt

The attack path, step by step

What the published record says happened at each stage, then our reading of it: what would have stopped the step, what would have caught it in progress, and what a test would have shown first.

1. 1

   Step 1. Before first access

   Step 1: A contractor's password was already out there

   Uber said an external contractor's account was compromised by an attacker.[1]

   Uber said it was likely the attacker bought the contractor's Uber corporate password on the dark web, after malware on the contractor's personal device exposed those credentials.[1]

   Would have stopped it

   • Phishing-resistant MFA (security keys or passkeys) on every workforce account, contractors included, so a password on its own opens nothing
   • Corporate sign-in only from managed devices, or a device check before a session is granted, so credentials harvested from a personal machine are not enough

   Would have caught it

   • Watching infostealer and credential-leak sources for your own domains and contractor accounts, and forcing a reset when one appears

   What a test would have shown

   An assumed-breach test starts from exactly this position: a valid contractor credential, handed over at the outset. It shows what that one account reaches, without spending the budget on how it was stolen.

2. 2

   Step 2. First access

   Step 2: Two-factor prompts until one was accepted

   The attacker repeatedly tried to log in to the contractor's account. Each attempt sent the contractor a two-factor approval request, which initially blocked access, until the contractor accepted one and the attacker got in.[1]

   The US Cyber Safety Review Board, reviewing attacks associated with the Lapsus$ group, described attackers spamming employees with MFA prompts until they said yes, sometimes late at night.[3]

   The same review reports CISA's recommendation of one-time codes or number matching over simple push approval, and found that hardware-backed FIDO2 MFA proved most resilient.[3]

   Would have stopped it

   • Number matching at minimum, and phishing-resistant MFA for anyone with access to internal tools
   • A limit on MFA prompts per account, with lock-out and a support call after repeated denials

   Would have caught it

   • An alert on a burst of denied or unanswered prompts followed by an approval
   • A one-step way for staff and contractors to report a prompt they did not start

   What a test would have shown

   A prompt-fatigue exercise, agreed in advance with the people running it, shows whether a flood of approval requests is noticed by anyone other than the person receiving it, and whether it is stopped before one is accepted.

3. 3

   Step 3. Moving inside

   Step 3: From one account to several, and to admin tools

   From there, Uber said, the attacker accessed several other employee accounts, which ultimately gave elevated permissions to a number of tools, including G-Suite and Slack.[1]

   The review board lists privileged credentials embedded in a PowerShell script on a misconfigured network share among the ways these attackers escalated privilege across the organisations involved. That passage does not name the organisation.[3]

   Would have stopped it

   • No credentials in scripts, shares or repositories: a secrets manager, and privileged access granted just in time rather than held permanently
   • Separate administrative accounts, each with its own phishing-resistant MFA

   Would have caught it

   • An alert when one session starts using accounts or admin consoles it has never touched before
   • Scheduled scans of file shares and code for embedded credentials

   What a test would have shown

   Credential hunting on internal shares is among the first things an assumed-breach test does from a foothold. A password found in a script during a test becomes a report finding; the same password found during an intrusion becomes the attacker's route to administrative access.

4. 4

   Step 4. Acting on objectives

   Step 4: Visible changes, data taken, and the bug bounty queue

   The attacker posted a message to a company-wide Slack channel and reconfigured Uber's OpenDNS to show a graphic image to employees on some internal sites.[1]

   Uber said the attacker appeared to download some internal Slack messages and accessed or downloaded information from an internal tool its finance team uses to manage some invoices.[1]

   The attacker reached Uber's dashboard at HackerOne, where researchers report vulnerabilities. Uber said any bug reports the attacker could access had been remediated.[1]

   Uber said it had not seen the attacker access the production systems that power its apps, any user accounts, or the databases holding sensitive user information such as card numbers, bank details or trip history.[1]

   Would have stopped it

   • Least privilege on collaboration and security tooling: very few accounts should be able to change DNS filtering or read the vulnerability report queue

   Would have caught it

   • Alerts on configuration changes to DNS and other security tooling, and on bulk export from collaboration platforms

   What a test would have shown

   A red team exercise measures how far someone holding administrative tooling gets, and how quickly a change to a security control such as DNS filtering is spotted and challenged.