Lessons From 13 Cloud Breaches

The thirteen breaches

The chains synthesized here span 1994 to the present. Old and new belong on the same page on purpose: the tooling changed, the root causes did not. A phone call to a Novell help desk in 1994 and a vishing call to an MGM help desk in 2023 are the same attack.

• Mitnick / Novell (1994) - OSINT, pretexting, and a phone call talked an employee out of dial-up access and NetWare source code.
• Capital One (2019) - an SSRF bug reached IMDSv1, borrowed an over-privileged IAM role, and exfiltrated 106 million records from S3.
• SolarWinds (2020) - the build system itself was compromised, shipping the SUNBURST backdoor to thousands of customers, then a Golden SAML pivot into the cloud.
• Uber (2022) - dark-web credentials plus MFA push fatigue got a contractor's account, then a hardcoded PAM secret unlocked full AWS and GCP admin.
• LastPass (2022-23) - a dev environment breach led to source-code recon, a keylogger on a DevOps engineer's home PC, and exfiltration of encrypted vault backups from S3.
• Storm-0558 (2023) - a stolen Microsoft signing key found in a crash dump was used to forge authentication tokens and read government email.
• Microsoft SAS leak (2023) - an over-permissioned SAS token pushed to public GitHub exposed 38TB of internal data for roughly three years.
• Scattered Spider / MGM (2023) - LinkedIn OSINT fed a vishing call to the help desk, yielding Okta super-admin, Azure AD, and encrypted ESXi servers.
• Snowflake / UNC5537 (2024) - infostealer credentials logged into accounts with no MFA, then bulk-exfiltrated data from 165+ organizations.
• Promptware kill chain (2024-26) - indirect prompt injection poisoned an AI agent's context, establishing persistence and covert command and control.
• Codefinger / S3 (2025) - stolen AWS keys encrypted victims' S3 buckets with AWS's own SSE-C, holding the only copy of the key and setting 7-day delete timers as ransom pressure.
• tj-actions/changed-files (2025) - a compromised GitHub Action (CVE-2025-30066) was retagged to a malicious commit that dumped CI runner memory and printed secrets into public build logs across 23,000+ repositories.
• Salesloft Drift / UNC6395 (2025) - stolen OAuth tokens from a third-party Salesforce integration drove bulk SOQL exfiltration across 700+ tenants, then the exports were mined for embedded cloud secrets.

Now the patterns. Most breaches belong to more than one, because real kill chains stack failures.

Pattern 1: Stolen, purchased, and infostealer credentials

Shows up in: Uber, Snowflake / UNC5537, LastPass, Codefinger / S3, Salesloft Drift / UNC6395.

The most boring initial-access vector is also the most common: the attacker already has a valid password. Nobody exploited a zero-day to get in. In Uber, the attacker bought a contractor's credentials off a dark-web marketplace. In Snowflake, an infostealer running on employee and contractor machines - some of them personal, unmanaged devices - harvested Snowflake logins that had been valid for years. In LastPass, the second-stage intrusion planted a keylogger on a DevOps engineer's home computer to capture the master password for a privileged vault.

The lesson is that your identity perimeter includes machines you do not manage. A credential is only as trustworthy as the endpoint it was typed on, and infostealer malware has turned every unmanaged laptop into a credential faucet. The controls that matter here are phishing-resistant MFA (so a stolen password alone is useless), short-lived credentials instead of long-lived static logins, and killing standing access to sensitive systems from unmanaged devices. This is the core argument for zero trust: never assume a valid credential means a trusted session.

The 2025 chains extend "credential" past the password. Codefinger never touched a login screen - it authenticated with a leaked long-lived AWS access key and used it to encrypt S3 buckets. Salesloft Drift was breached with stolen OAuth tokens for a third-party integration, no password or MFA prompt involved. API keys, access keys, and OAuth tokens are credentials too, and they leak from git history, CI logs, and integration vendors just as readily as passwords leak from infostealers. Rotate them, scope them, expire them, and monitor for their use from unfamiliar sources.

Pattern 2: Help desk and human social engineering

Shows up in: Mitnick / Novell, Uber, Scattered Spider / MGM.

The oldest breach on this list and one of the newest are the same attack with a 29-year gap. Kevin Mitnick called Novell, pretexted his way into an employee's trust, and was handed access. Scattered Spider scraped LinkedIn to learn who worked at MGM, called the IT help desk impersonating one of them, and talked the agent into resetting MFA and handing over Okta super-admin. Uber's attacker, after buying credentials, still had to defeat MFA, and did it partly through a barrage of push prompts and a message pretending to be from Uber IT.

Humans are a control surface, and the help desk is the softest part of it. The identity-recovery flow - the process for when a legitimate user loses their phone - is the exact process an attacker abuses. Hardening this means treating account recovery as a high-assurance operation: identity-proofing that cannot be satisfied by information from a LinkedIn profile, manager or in-person verification for privileged accounts, and phishing-resistant factors that a help desk agent cannot simply reset over the phone. Threat modeling your own help desk is one of the highest-leverage exercises most teams never do.

Pattern 3: Over-permissioned identities and tokens

Shows up in: Capital One, Microsoft SAS leak, Storm-0558, Codefinger / S3, Salesloft Drift / UNC6395.

This is the pattern that turns a foothold into a catastrophe. In Capital One, an SSRF bug was the way in, but the reason it mattered was the IAM role reachable from the instance metadata service had far more permission than the web application needed, including broad S3 read access. In the Microsoft SAS leak, the exposed token was not just leaked, it was scoped to an entire storage account with write access and a multi-decade expiry, so a single accidental commit exposed 38TB. In Storm-0558, a single consumer signing key turned out to be usable, through a validation flaw, to forge tokens for enterprise and government accounts far beyond its intended scope.

The connective tissue is blast radius. Every one of these was survivable if the compromised identity or token had been scoped to only what it needed. Least privilege is not a compliance checkbox, it is the difference between an incident and a disaster. Practically: scope tokens narrowly and give them short lifetimes, prefer IAM roles with tightly bound policies over broad ones, enforce IMDSv2 so SSRF cannot trivially steal instance credentials, and continuously audit for identities whose granted permissions vastly exceed their used permissions. This is exactly the gap a CNAPP or CIEM tool is built to surface (disclosure: the site's author works at Wiz).

The 2025 chains are pure blast-radius stories. The Codefinger keys carried enough S3 permission to both read and overwrite objects, so a single leaked key could encrypt an entire bucket. The Salesloft Drift OAuth tokens were scoped to broad Salesforce API access, so one compromised integration exposed every object in hundreds of tenants. Third-party integration tokens deserve the same least-privilege scrutiny as your own IAM roles - grant them the minimum objects and API scopes they need, and revoke the ones you no longer use.

Pattern 4: Missing or bypassed MFA

Shows up in: Snowflake / UNC5537, Uber.

Snowflake is the cleanest case study in the cost of not enforcing MFA. The attacker had valid credentials from infostealers, and the accounts they targeted simply had no second factor required. There was no clever bypass because none was needed. The platform supported MFA, but it was not enforced organization-wide, so a stolen password was a full login. The blast radius reached 165+ downstream organizations.

Uber shows the next level: MFA was present but defeated. Push-based MFA that just asks the user to tap "approve" is vulnerable to fatigue attacks, where the attacker spams prompts until someone taps yes to make it stop, sometimes helped along by a social-engineering message. The lesson is a two-parter. First, enforce MFA everywhere, with no exceptions for service accounts, contractors, or legacy integrations, because attackers find the one door without a lock. Second, not all MFA is equal: push-approve and SMS are phishable and fatigue-able, while phishing-resistant factors like FIDO2 or passkeys defeat both the replay and the fatigue attack. When you read these two chains next to each other, "turn on MFA" quietly becomes "enforce phishing-resistant MFA with no gaps."

Pattern 5: Supply-chain and build-pipeline compromise

Shows up in: SolarWinds, tj-actions/changed-files, Salesloft Drift / UNC6395.

SolarWinds was once the outlier that did not follow the identity playbook; by 2025 the supply chain is a well-worn attack surface. The attackers did not phish a user or steal a password to start. They compromised the build system and inserted the SUNBURST backdoor into the software itself, so that SolarWinds cryptographically signed and shipped the malware to thousands of customers as a trusted update. The victims did nothing wrong at install time; they trusted a signed update from a vendor they had every reason to trust.

This is a different threat model, and it is why software supply chain security is its own discipline. The controls live in your CI/CD pipeline: hardened and isolated build environments, verified reproducible builds, artifact signing and provenance (the SLSA framework and tools like Sigstore), and a software bill of materials so you know what is actually in what you ship and consume. It also reframes vendor risk: you inherit the security of everyone whose code runs in your environment. The later Golden SAML pivot in the same intrusion also ties back to Pattern 3, forging trusted authentication material to move from on-prem into the cloud.

The 2025 chains show the supply chain moving up-stack. In tj-actions/changed-files, the compromised dependency was a single popular GitHub Action: attackers stole a bot's token, retagged every version to a malicious commit, and turned tens of thousands of CI pipelines into secret-leaking machines - a build-pipeline attack that needed no vendor of SolarWinds' size. In Salesloft Drift, the compromised link in the chain was a SaaS integration vendor whose OAuth tokens unlocked hundreds of downstream Salesforce tenants. Pin third-party actions to full commit SHAs rather than mutable tags, treat every integration you authorize as part of your attack surface, and remember that your build pipeline and your SaaS OAuth grants are supply chains too.

Pattern 6: You could not even reconstruct what happened

Shows up in: Storm-0558 (and it made every other breach worse).

Storm-0558 exposed a second, quieter failure: many affected organizations could not tell whether they had been accessed, because the relevant sign-in and mailbox-access logs were only available in higher-priced licensing tiers. When forged tokens are indistinguishable from legitimate ones, logs are the only way to find them, and if you do not have the logs, the honest answer to "were we breached" is "we cannot say." That is not an incident-response posture, it is a coin flip.

Logging is not a detection nicety, it is the substrate that detection engineering and incident response are built on. Across all thirteen breaches, the ones that were caught early were caught because someone had the telemetry and was looking at it; the ones that ran for months or years (the Microsoft SAS token sat public for about three years) ran that long partly because nobody was watching the right signal. Turn on cloud audit logging (CloudTrail, Azure sign-in and audit logs, GCP audit logs), retain it long enough to matter, ship it somewhere an attacker who owns the account cannot delete it, and actually build detections on it. Storing logs you never query is a compliance artifact, not a control.

The mapping table: vector to control

Each row is one breach, its initial-access vector, and the single control that would most likely have broken the chain earliest. "Single control" is a deliberate oversimplification - real defense is layered - but forcing the choice makes the priorities obvious.

Read the right-hand column top to bottom. Identity controls dominate: MFA, least privilege, scoped tokens, hardened recovery. That is not a coincidence, it is the headline finding of this whole page.

MITRE ATT&CK techniques across these chains

Mapping the breaches to ATT&CK turns thirteen stories into a short, deduplicated list of behaviors you can build detections and controls around. A handful of techniques recur constantly - which tells you exactly where to point your detection engineering first.

• T1078 Valid Accounts - the connective thread of almost the entire list. Logging in with legitimate credentials or session material appears in Uber, Snowflake, LastPass, Scattered Spider / MGM, and Mitnick / Novell. If you detect one thing well, detect anomalous use of valid accounts.
• T1552 Unsecured Credentials - credentials or tokens left somewhere reachable: the IMDS role in Capital One, the SAS token in public GitHub in the Microsoft SAS leak, the hardcoded PAM secret in Uber, and the CI secrets printed into public logs in tj-actions/changed-files.
• T1621 Multi-Factor Authentication Request Generation - the push-fatigue technique that helped defeat MFA in Uber.
• T1195 Supply Chain Compromise - the defining technique of SolarWinds, where the trusted software update was itself the weapon, and of tj-actions/changed-files, where a retagged CI dependency (T1195.001) leaked secrets from tens of thousands of pipelines.
• T1606 Forge Web Credentials - forging trusted authentication material: the stolen signing key forging tokens in Storm-0558 and the Golden SAML pivot in SolarWinds. Closely related to the broader T1550 Use of Alternate Authentication Material pattern of abusing tokens instead of passwords.
• T1589 Gather Victim Identity Information and T1656 Impersonation - the OSINT-then-pretext opening of Scattered Spider / MGM and Mitnick / Novell.
• T1566 Phishing - social-engineering delivery, present in the Scattered Spider / MGM and Mitnick / Novell chains.
• T1530 Data from Cloud Storage and T1486 Data Encrypted for Impact - the impact end of the chains: bulk cloud-storage exfiltration in Snowflake, LastPass, and the Microsoft SAS leak, ESXi ransomware in MGM, and SSE-C bucket encryption in Codefinger / S3.
• T1528 Steal Application Access Token - abusing OAuth tokens instead of passwords, the entire basis of Salesloft Drift / UNC6395, where stolen third-party integration tokens drove bulk data theft across hundreds of SaaS tenants.

The pattern in the ATT&CK view matches the pattern in the table: the recurring techniques cluster around identity (T1078, T1552, T1621, T1606) and social engineering (T1589, T1656, T1566), not around exotic exploitation. Build your detection library outward from there.

What to actually do about it

If you compress all thirteen breaches into a to-do list, it is short and unglamorous:

1. Enforce phishing-resistant MFA everywhere, with zero exceptions. No carve-outs for contractors, service accounts, or legacy integrations. Attackers find the one door without a lock (Snowflake, Uber).
2. Practice ruthless least privilege on identities and tokens. Scope narrowly, expire quickly, prefer roles over long-lived keys, and continuously audit granted-versus-used permission gaps (Capital One, Microsoft SAS leak, Storm-0558). See IAM.
3. Harden your recovery and help-desk flows as high-assurance operations. The account-recovery process is the attack surface (Mitnick, MGM, Uber).
4. Assume unmanaged endpoints are compromised. Keep privileged access off devices you do not control (LastPass, Snowflake).
5. Secure the build pipeline and know your dependencies. Provenance, signing, an SBOM, and third-party actions pinned to commit SHAs in your CI/CD flow (SolarWinds, tj-actions/changed-files). Treat SaaS OAuth integrations as part of that supply chain too (Salesloft Drift).
6. Turn on complete, tamper-resistant audit logging and actually build detections on it. You cannot respond to what you cannot see (Storm-0558, and every long-dwell breach here). See detection engineering and incident response.

None of this is exotic. That is the point. These breaches did not fall to novel research; they fell to fundamentals that were skipped, scoped too broadly, or turned off for convenience. If you want a worked example of these same controls applied to a real (small) production system, this site documents its own setup in how CSOH.org is secured.