Lessons from the 2022 Uber Breach: One Hardcoded Token, Total Access

In September 2022, Uber suffered one of the most widely discussed security incidents in recent years. What makes it worth revisiting isn't just how the attacker got in, but what they found once inside: a script with hardcoded admin credentials that handed them access to nearly all of the company's internal infrastructure.

It's a near-perfect case study because it separates two problems we tend to lump together: the entry vector (social engineering) and the root cause that amplified the damage (a secret sitting in plaintext). That second part is almost never fixed.

What happened, briefly

Based on public reporting about the incident, the rough sequence was:

1. An attacker obtained a contractor's credentials, likely purchased from underground forums.
2. The account had MFA, so the attacker used push bombing — flooding the contractor with authentication requests — and, posing as IT support, convinced them to approve one.
3. That approval got the attacker onto the corporate VPN and from there onto the internal network.
4. Once inside, they found a network share containing a PowerShell script. That script had hardcoded credentials for a privileged access management (PAM) tool.
5. With those PAM credentials, the attacker accessed secrets for critical systems: cloud providers, internal tools, Slack, and more.

Phishing opened the front door. A hardcoded token handed over the keys to the entire building.

The real root cause: a plaintext secret, not just phishing

It's tempting to read this as "just another social engineering attack" and focus the response entirely on employee training and phishing-resistant MFA (hardware security keys, for instance). That's necessary — but incomplete.

The part that actually amplified the damage was an infrastructure design choice: a script that needed to authenticate against a PAM system did so with a credential written directly into the file, unencrypted, readable by anyone with read access to that network share. The attacker didn't need to break into the PAM system directly — finding the script was enough.

This pattern shows up constantly in security incidents. Attackers rarely need to break encryption or find a zero-day. They just need to find a secret someone left where it shouldn't be — in a script, in a repo, in a Slack channel, in a README's environment variables.

Why this pattern is getting worse in the AI-coding era

In 2022, finding that script required manually crawling the network. Today, with AI assistants generating configs, deployment scripts, and integrations at high speed, the habit of writing const token = "sk-..." straight into code is more common, not less. An AI assistant has no context on internal security policy — it suggests the simplest thing that "works," and that's almost always hardcoding the value.

We've written about this in detail at /ai-security: the sheer volume of AI-generated code has multiplied the number of places a secret can leak by carelessness, not attacker sophistication.

What would have limited the damage

If the PAM credential had been managed as an encrypted secret instead of plaintext in a script, the incident would have had a much lower ceiling:

• No secrets in plaintext on disk. The script should only ever reference the secret's name, never its value.
• Verification of who can decrypt. "Has access to the network" shouldn't be enough — the device or process requesting the secret should have to prove it's what it claims to be.
• Fast rotation and revocation. If a credential is suspected of being compromised, it should be invalidated in seconds, not days.
• Traceability. Knowing which device or service accessed which secret, and when.

None of this would have stopped the initial phishing. But it would have stopped that phishing from turning into a full infrastructure compromise.

How Koove addresses this specific failure mode

Koove isn't an MFA product and doesn't replace social engineering training. It's a zero-knowledge secrets manager: the server only ever stores ciphertext, and secrets are end-to-end encrypted using X25519 and AES-256-GCM in an envelope encryption scheme.

For a workflow like the one in the Uber case, this changes the picture in practice:

# Instead of writing the credential into a script
koove set PAM_ADMIN_TOKEN "xxxxx" --env prod

The script or automation code only ever references PAM_ADMIN_TOKEN by name. The actual value never gets written in plaintext to disk, never sits on a network share, and never ends up in a repo.

On mobile consumers, decryption only happens on devices verified with native attestation — Apple App Attest or Google Play Integrity — combined with biometrics, verified end-to-end on real physical hardware with no developer bypass. If an attacker steals a session or an app access token but doesn't control an attested, biometrically-verified device, they can't decrypt the secret.

If a credential is suspected of being compromised, you can revoke a device's access and force a rewrap of the affected secrets from the CLI — documented in /docs/sdk.

The limits worth saying out loud

Koove drastically reduces the surface of secrets sitting around in plaintext, but it's not magic:

• It doesn't replace a solid phishing-resistant MFA policy for employee access to internal systems.
• Revoking a device blocks future access, but it can't "un-deliver" a secret that was already downloaded and decrypted before revocation happened.
• The scheme doesn't provide ratchet-style forward secrecy — it's robust envelope encryption, not a messaging protocol.
• Koove doesn't remove the need for internal network segmentation or least-privilege enforcement on PAM systems themselves.

You can see the full architecture and trust model at /security, and check common questions at /faq.

The lesson that sticks

The 2022 Uber breach isn't remembered for how clever the initial attack was — it's remembered for how short the distance was between "one employee approved a push notification" and "access to nearly everything." That distance is set by secrets management, not by the perimeter.

If your team still has tokens sitting in scripts, .env files shared over Slack, or hardcoded variables in code your AI assistant just wrote, that's your real point of highest risk — not the next zero-day.

Check out /plans and take the first step today at /register: move your secrets into an encrypted store before a forgotten script becomes your own case study.