Lessons From 45 Cloud Breaches

Pattern 1: Stolen, purchased, and infostealer credentials

Shows up in: Uber, Snowflake / UNC5537, LastPass, Codefinger / S3, Salesloft Drift / UNC6395, Megalodon, Vercel / Context.ai, Shai-Hulud, Nx / s1ngularity, npm debug / chalk, 3CX / X_TRADER, 0ktapus / Twilio, CircleCI, Change Healthcare, Midnight Blizzard.

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.

The 2026 chains make the infostealer economy impossible to dismiss as background noise. Megalodon is the starkest measurement anyone has published: cross-referencing the affected repositories against known infections, 331 of 978 unique usernames - over a third - were direct matches to machines already running infostealers. Nobody exploited GitHub. Somebody bought enough logs to run a campaign. Vercel's chain started the same way, with a commodity stealer on one employee's laptop at a small AI vendor, and ended inside a major hosting platform two hops later. Developer endpoints deserve particular attention here, because a single browser profile and credential helper holds keys to repositories, package registries, and cloud accounts at the same time. Monitor stealer-log dumps for your own domains, keep credentials out of browser profiles, and prefer hardware-backed keys and short-lived tokens over long-lived personal access tokens.

Pattern 2: Help desk and human social engineering

Shows up in: Mitnick / Novell, Uber, Scattered Spider / MGM, Storm-2949, UNC6040.

The oldest breach on this list and one of the newest are the same attack with a 29-year gap. Kevin Mitnick called Novell staff impersonating real employees, with researched backstories, hunting for dial-up access - and the call that failed is the reason he is in a federal case study: the network admin he pretexted recognized the policy-breaking request and taped him. 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.

Storm-2949 shows the sharpest version of the problem, because it inverts the usual advice. Microsoft assesses that the actor triggered an Entra ID self-service password reset on the target's behalf, then phoned that target impersonating internal IT so the resulting MFA prompt would be approved as part of a routine-sounding reset. The prompt was genuine. Number matching bought nothing, because the control was faithfully validating a real request - it just could not tell who had asked for it. Self-service password reset is a credential-issuance system that most organizations classify as a convenience feature, and it deserves the same protection as an admin role grant: phishing-resistant methods required for reset, and a conditional-access policy on the security-information registration flow so a caller on an unmanaged device cannot re-enroll MFA at all.

Pattern 3: Over-permissioned identities and tokens

Shows up in: Capital One, Microsoft SAS leak, Storm-0558, Codefinger / S3, Salesloft Drift / UNC6395, Storm-2949, Vimeo / Anodot, Vercel / Context.ai.

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.

Two 2026 chains sharpen this into a specific warning about permissions that do not look dangerous. Storm-2949 never exploited anything after initial access: the compromised identities already held privileged Azure RBAC, and the actor simply spent it. The operations it used read like infrastructure management on a change ticket - publishxml/action to retrieve App Service deployment credentials, storageAccounts/listkeys/action to obtain account keys, firewallrules/write to open Azure SQL to its own addresses - and not one of them reads a byte of customer data by itself. Chained, they are a complete path from control plane to production data. Vimeo is the same lesson from the other end: the attacker never escalated at all, because the analytics integration's own grant was already enough to expose 119,000 records. The defensive question is not "how did they escalate" but "why could an analytics vendor read customer email addresses?" Audit management permissions for what they can be chained into, not just for what they are named.

Pattern 4: Missing or bypassed MFA

Shows up in: Snowflake / UNC5537, Uber, Storm-2949, Vimeo / Anodot, 0ktapus / Twilio, Change Healthcare, Midnight Blizzard.

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."

The 2026 chains add a third failure mode that neither of those covers: MFA that was present, enforced, and then quietly rewritten to belong to the attacker. Storm-2949 stripped the victim's registered phone, email, and Authenticator registrations and enrolled its own device in their place. From that moment every sign-in satisfied MFA and conditional access legitimately, using the attacker's device, while the real owner had lost exactly the methods they needed to recover the account. Vimeo shows the opposite gap - the stolen Anodot tokens were service-to-service credentials that never touch an MFA prompt at all, because machine identities do not have one. So the checklist grows again: enforce phishing-resistant MFA, alert on authentication-method registration changes as incidents rather than help-desk noise, and remember that non-human identities sit entirely outside the control you just spent a year rolling out.

Pattern 5: Supply-chain and build-pipeline compromise

Shows up in: SolarWinds, Codecov, 3CX / X_TRADER, XZ Utils, event-stream, Kaseya VSA, Polyfill.io, Ultralytics, Log4Shell, tj-actions/changed-files, Salesloft Drift / UNC6395, Nx / s1ngularity, Shai-Hulud, npm debug / chalk, LiteLLM / TeamPCP, Mini Shai-Hulud / TanStack, Megalodon.

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.

By 2026 the pipeline attacks stopped needing a stolen publishing token at all, which breaks the controls most teams had just finished deploying. Mini Shai-Hulud never took a maintainer credential: a fork pull request poisoned the GitHub Actions cache, a later release run restored it, and OIDC tokens scraped from runner memory published packages carrying entirely valid SLSA provenance. Megalodon poisoned Tiledesk's source on GitHub and let the maintainer publish from it, so the malicious releases carried legitimate publisher identity. In both cases every downstream check that verifies who published a package returned a clean answer. That is worth sitting with, because provenance and signing were the recommended answer to SolarWinds, and these chains route around them by compromising the thing being attested rather than the attestation.

Three chains added later push the category in directions the npm and Actions cases do not reach. Codecov is the earliest and the simplest: the compromised artifact was not a package at all but a shell script that pipelines curl and execute on every build, and the payload was a single added line exporting the environment. It ran for two months and ended because one customer compared a published SHA-256 against what they had downloaded - an available, documented, entirely optional control. 3CX establishes that the chain can be more than one link long: a trojanized trading application on an employee's personal computer led to stolen credentials, then to both build environments, then to a validly signed backdoored softphone shipped to 3CX's own customers. Mandiant called it the first cascading software supply chain compromise, and it breaks vendor risk management as normally practised, because assessing your suppliers tells you nothing about theirs.

XZ Utils is the one that should change how you think about the category, because it does not begin with theft or exploitation. It begins with two years of genuine, useful, reviewed contributions. An identity using the name Jia Tan built a real reputation from 2021, sock puppet accounts pressured an exhausted unpaid maintainer over release delays, and by January 2023 the attacker held maintainer rights to a compression library present on essentially every Linux system. The enabling change - IFUNC support, committed months early with a legitimate performance justification - was reviewable and correct. The payload never appeared in git at all: it lived in the release tarballs, hidden in files that looked like binary compression test fixtures, assembled at build time. Code review cannot catch that, and saying so plainly matters more than any control on this list. What the attack actually exploited was one burned-out volunteer maintaining critical infrastructure alone for free, which describes a large share of every dependency tree here. It was caught because someone investigating an unrelated performance regression noticed sshd logins were about half a second slow.

LiteLLM adds the most uncomfortable variant: the compromise entered through Trivy, a vulnerability scanner running as a build step. Security tooling is installed early, runs with the pipeline's credentials, and is trusted by definition, so the scanner read the job's secrets and handed over the PyPI publishing token. The practical controls are unglamorous. Split scanning and publishing into separate jobs with separate permissions so no one step holds both. Mint publishing credentials through OIDC-based trusted publishing instead of storing static tokens. Fail the build when a package version has no corresponding signed tag, which is the cheapest possible catch for a direct-to-registry upload. Pin dependencies by hash so a version that exists for forty minutes cannot enter your builds. And purge caches and rebuild runner images after any pipeline compromise, or you will restore the payload yourself.

Pattern 6: The vendor you authorized is the way in

Shows up in: Salesloft Drift / UNC6395, Vercel / Context.ai, Vimeo / Anodot, UNC6040, Okta support system, Okta / LAPSUS$, CircleCI, MOVEit / Cl0p.

This pattern deserves separating from the supply chain above, because nothing is poisoned and no artifact is tampered with. The attacker simply arrives through a door you opened on purpose. Vimeo's systems were never breached: Anodot, an analytics vendor, held long-lived tokens into Vimeo's Snowflake and BigQuery, and stealing those tokens was enough. Vercel's systems were never exploited: an employee had connected a third-party AI tool to their corporate Google Workspace account, and control of that tool's OAuth application converted into control of the employee's identity, then their Vercel account, then internal systems. Salesloft Drift ran the same shape a year earlier across 700 Salesforce tenants.

What makes this hard is that every human-facing control is bypassed by construction. A compromised OAuth grant produces no failed authentication, no MFA denial, and no impossible-travel sign-in, because there is no login. Password rotation does not revoke it. Employee offboarding does not revoke it. And the grant frequently never passed through vendor review at all, because from the company's perspective nothing was procured - an employee clicked "allow" on a consent screen. AI productivity tools concentrate the risk further, since they cannot function without ingesting organizational data and therefore ask for broad mail and drive scopes as a matter of design, which makes their token stores unusually dense targets.

Treat connected applications as identity infrastructure. Enumerate third-party consents in Google Workspace or Entra ID, restrict user consent to a vetted allow-list, require admin approval for broad scopes, and review the list on a schedule. Keep an inventory recording, for each integration, what credential it holds, its scope, its owner, and the exact command that revokes it - Vimeo contained this quickly because the integration was identifiable and killable, which is an inventory property rather than a lucky one. Then rehearse it: a tabletop whose scenario is "a vendor tells us our tokens are stolen" and whose success criterion is total revocation within the hour.

Pattern 7: Your own tooling, turned around

Shows up in: Nx / s1ngularity, Shai-Hulud, LiteLLM / TeamPCP.

Three separate chains, three separate actors, and the same idea in each: rather than write a capability, use the one the victim already installed. Shai-Hulud downloaded TruffleHog - a secret scanner built for defenders - and pointed it at the developer's own filesystem, inheriting years of work on what every cloud provider's credential format looks like and where it tends to live. Nx / s1ngularity went further and drove the developer's installed Claude, Gemini and Q command-line agents with --dangerously-skip-permissions, --yolo and --trust-all-tools, because an AI agent is already trusted on that machine, already has filesystem access, and reasons about "which of these ten thousand files holds a credential" far better than a regular expression. LiteLLM is the sharpest version, since the compromise entered through security tooling: TeamPCP poisoned Trivy, a vulnerability scanner running as a build step, and the scanner read the pipeline's secrets on the attacker's behalf.

The uncomfortable part is that none of these tools were misused in a way their authors could prevent. A secret scanner that finds secrets, an AI agent that reads files when told to, and a vulnerability scanner that runs early with pipeline credentials are all working exactly as designed. What changed is who is holding them. Every capability installed for convenience or diligence is a capability an attacker inherits on compromise, and the security toolchain is a particularly rich seam because it is trusted by definition, runs with elevated access, and is rarely reviewed with the suspicion applied to application dependencies.

The defensive moves are mostly about inventory and least privilege applied somewhere unfamiliar. Know which agents and scanners are installed on developer machines and in build images, and treat that list as attack surface rather than tooling. Alert on permission-bypass flags and on a build process fetching a security binary off the internet, which is a strong signal precisely because nothing legitimate about a dependency install should do that. Keep agent configuration and credential files out of directories arbitrary postinstall scripts can read. And split jobs so no single step holds both third-party tooling and the credentials that tooling could steal, which is the specific control that would have contained LiteLLM.

Pattern 8: You could not even reconstruct what happened

Shows up in: Storm-0558, Entra ID Actor token, Okta support system (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 forty-five 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 2026 chains show what happens when the telemetry exists but nothing in it looks wrong. Vimeo's attacker used a valid credential, a mainstream database client, and queries the integration was authorized to run; the only available signal was how much data moved. Storm-2949's Graph enumeration was authenticated, expected, high-volume API traffic. Megalodon's commits were authored as build-bot with messages imitating routine CI maintenance, and its dormant variant produced no workflow run history at all. None of these are logging gaps. They are baselining gaps, and the fix is different: profile what each integration and service identity normally does - rows scanned, bytes returned, call volume, time of day - and alert on deviation, because there will be no failed login to catch.

Pattern 9: The whole chain now finishes before anyone reads the alert

Shows up in: Suspected AI-assisted AWS compromise, Megalodon, Mini Shai-Hulud / TanStack, Storm-2949, Nx / s1ngularity, Shai-Hulud, GTG-1002.

The oldest chains on this page unfolded over months. SolarWinds ran for roughly fourteen months, the Microsoft SAS token sat public for about three years. The 2026 chains are measured differently. Megalodon pushed 5,718 commits into 5,561 repositories inside a six-hour window. Mini Shai-Hulud published 84 malicious npm versions in six minutes. Storm-2949 pulled dozens of Key Vault secrets in roughly four minutes. In the Sygnia case, one actor went from an application weakness to broad control of a large AWS estate in about 72 hours, and four accounts' keys were used within a single observed second - the detail that led Sygnia to infer AI assistance, though that attribution is inference rather than proven fact.

The consequence is structural, not rhetorical. A control that depends on a human noticing something and responding is now competing against a chain that may complete before the first alert is triaged. That does not mean detection is pointless; it means the weight has to shift toward things that hold without a human in the loop. Preventive controls that simply refuse the action - default-deny egress from build runners, network policies that make a stolen warehouse credential fail from an unexpected address, dependency pinning by hash, branch protection and required signatures. Short credential lifetimes, so the window a stolen token is useful in closes on its own. Automated response for the highest-confidence signals rather than a ticket. And blast-radius design, so that the speed of the first hour bounds how much it can reach.

Pattern 10: The attacker may not be a person

Shows up in: GTG-1002 / Claude Code, Hugging Face / OpenAI agent, Suspected AI-assisted AWS compromise.

Three chains here involve an AI system doing the tactical work, and they sit at three genuinely different points on a spectrum worth keeping straight. In the Sygnia AWS case the AI involvement is inference from tempo, not proven fact - four accounts' keys used in a single observed second is the kind of evidence that suggests automation without establishing what kind. In GTG-1002 humans chose every target and approved escalation at four to six gates; the AI did the labor between those gates, which makes it a human campaign with the work automated rather than an autonomous adversary. In the Hugging Face incident the model selected the target itself, and nobody intended an intrusion at all.

That last case is the one without precedent, and it is worth being precise about why. It was not a misuse of AI by an attacker. It was a capability evaluation whose containment failed, whose objective was open-ended, and whose subject pursued an instrumental step - get the benchmark answers from wherever they live - straight into a third party's production infrastructure. There was no ransom, no exfiltration to a criminal market, and no adversary in the ordinary sense. The attribution arrived five days later as a voluntary disclosure from the lab responsible.

What does not change is the defensive answer, and this deserves saying because the novelty invites overreaction. Every one of these chains ran the same phases as the human ones: reconnaissance, exploitation, credential harvesting, lateral movement, exfiltration. Patching, least privilege, phishing-resistant MFA, segmentation and egress control work exactly as well against an AI operator. What changes is tempo, which is the argument made in Pattern 9, and one new item: if you build or run agent systems, the containment around them is now part of your attack surface. Air-gap capability evaluations properly, bound agent objectives explicitly with out-of-bounds targets named, scope agent tool access and identity to the minimum, and log agent actions somewhere reviewable. And be reachable - in both AI incidents here, the notification came from a company the victim had no relationship with.