Uber's own account of its September 2022 incident describes a contractor account, repeated two factor prompts and access to internal tools. You can test your org against that path with ten concrete checks. They are about controls, not blame. Any company with contractors and push based MFA has the same exposure.
What did Uber say happened?
According to Uber's published updates, an attacker likely bought a contractor's corporate password on the dark web after the contractor's personal device was infected with malware. The attacker repeatedly tried to log in, which triggered two factor approval requests. The contractor initially rejected them, and eventually accepted one. From there the attacker reached other employee accounts and gained elevated permissions on tools including G Suite and Slack.
Uber reported that the attacker posted to a company Slack channel, changed OpenDNS settings, downloaded some internal Slack messages, accessed an internal finance tool and the HackerOne dashboard, and that it had no evidence of access to production systems or sensitive user databases. Uber said it believed the attacker was likely affiliated with Lapsus$, and that is its belief, not a confirmed finding. Its response included blocking accounts, rotating keys, locking the codebase to stop new changes and strengthening MFA.
What are the ten checks?
Identity
- Do your MFA prompts allow one tap approval? Test whether number matching or a phishing resistant method is available.
- Would ten failed prompts in a row alert anyone, or just annoy the user?
- Are contractor accounts held to the same MFA and device rules as employees?
- Can you detect a corporate password in a breach corpus or a stealer log?
Access
- After a first login, how far can one account move? List what a standard employee account can reach.
- Who can grant elevated rights, and is that logged and reviewed?
- Does a login from a new device or place trigger step up checks on admin tools?
Response
- Can you disable many internal tools quickly, as Uber did, without breaking customer service?
- Can you rotate service keys on demand, and do you know which ones exist?
- Can you freeze code changes during an incident, and who decides?
How do you run the exercise?
Pick two people, one from IT and one from engineering, and give them 90 minutes. Ask them to walk the path above on paper using your real systems. Where the answer is "I think so," treat it as "no" until you test it.
Then run a small live test with consent: a test account, a prompt storm, and a timer on how long until someone notices.
Where does software supply chain come in?
Once inside, an attacker looks for credentials in internal tools and for access to code and pipelines. Locking the codebase was a response step in this case. Make sure your pipeline secrets are short lived and that build systems log who changed what. Our secrets and dependency checks work at that layer, though no scanner replaces strong identity controls.
What to do
- Move admins and contractors to phishing resistant or number matching MFA first.
- Alert on repeated prompt failures and on a successful prompt that follows them.
- Review contractor access quarterly.
- Subscribe to credential exposure monitoring for your domains.
- Map what one stolen employee account can reach and cut it.
- Write and rehearse a key rotation runbook.
- Define who may freeze code merges.
Quick check
Is this a software vulnerability?
Not in Uber's account. It describes stolen credentials and MFA approval. The lessons are identity and access controls.
Does number matching solve it?
It raises the bar but is not the whole answer. Combine it with device checks, alerts and limited reach after login.
Sources
Last reviewed: 18 October 2026.
