09.04 · Foundations

Cloud-Native Threats

Read enough cloud breach reports and the same five patterns appear over and over. Each year, in every provider, with every customer.

Cloud breaches do not usually feature novel zero-days. They feature the same small set of failure modes, repeated across organizations, with names attached to the customer column. The Cloud Security Alliance publishes a "Top Threats to Cloud Computing" report every two years; the entries change slowly because the failure patterns are stable — only the affected company names rotate.

This page walks the five patterns you will see most often. If you can recognize each one in a post-mortem, you can recognize it in your own architecture before the post-mortem gets written.

01

Misconfiguration — the default footgun

Highest frequency

The pattern. A service is provisioned with permissive defaults. Nobody reads the documentation closely enough to find the warning. The bucket is public, the security group is 0.0.0.0/0, the database is exposed on a routable IP, the API key is committed to a public repo.

Why it keeps happening

Cloud services are configurable. Most controls have a knob with three states: secure, less secure, and "wait, that was a knob?" Defaults vary by provider, by service, and by year. A team that learned S3 in 2014 (public by default) does the same thing in 2026 (private by default) and gets a different outcome.

What stops it

Infrastructure as Code with policy-as-code on top. Don't ask "is the bucket public?"; ask "does our linter let us deploy a public bucket?" Tools: tfsec, checkov, AWS Config, Azure Policy, GCP Organization Policy.

Real-worldCapital One (2019): WAF misconfiguration plus an over-permissive EC2 role lets an attacker exfiltrate ~100 million records from S3. Verizon/Nice (2017): public S3 bucket with 14 million customer records, no exploit required.
02

IAM sprawl — too much access, accumulating

Highest blast radius

The pattern. Permissions are granted because a user or service "needs to do X right now," and nobody comes back to remove them. After three years, the application's runtime role has 80 permissions, of which it uses 12 on a normal day. When the role is compromised, the attacker inherits the full 80.

Why it keeps happening

Adding a permission unblocks someone today. Removing one might break something tomorrow. The asymmetry of consequences quietly grows the policy. Multiply across thousands of roles and you get an audit nightmare and a breach surface in the same place.

What stops it

Least privilege as a discipline. Periodic access reviews. Access analyzers that surface unused permissions (AWS IAM Access Analyzer, GCP IAM Recommender, Azure Entra Permissions Management). Time-bound elevation rather than standing access (JIT).

Real-worldCodecov supply chain breach (2021): a compromised CI script's overly-broad permissions let attackers exfiltrate customer credentials. Uber breach (2022): contractor account compromise led to MFA fatigue, then sprawling internal access let the attacker reach privileged consoles.
03

Public storage exposure

Easiest to find

The pattern. An S3 bucket, Cloud Storage bucket, or Azure Blob container is marked publicly readable. A researcher (or attacker) enumerates buckets, finds yours, and copies the contents. There is no exploit; the access control was the door, and it was open.

Why it keeps happening

"Public" is a single setting. Engineers who needed the bucket reachable from a CDN, or temporarily-public for testing, leave it that way. Bucket names are sometimes guessable (acme-prod-backups) and are enumerable for the patient.

What stops it

Account-level controls that override per-bucket settings. AWS S3 Block Public Access at the account level. Azure storage account public access disabled by default since 2023. GCP Public Access Prevention org policy. Default-deny at the highest level you can set it.

Real-worldThe "leaky S3 bucket" genre is so common that Wiz, UpGuard, vpnMentor, and Comparitech publish reports about new ones monthly. Notable: Accenture (2017), Pegasus Airlines (2022, 6.5 TB), MoveIt-related disclosures (2023).
04

SSRF to the metadata service

Cloud-specific

The pattern. A web application has a server-side request forgery (SSRF) vulnerability. An attacker tricks it into fetching http://169.254.169.254/ — the Instance Metadata Service (IMDS) URL inside every major cloud provider. IMDS returns temporary credentials for the instance's IAM role. The attacker now has those credentials.

Why it keeps happening

SSRF is a common web-app bug, especially in image-fetchers, URL preview generators, and SSRF-adjacent features like server-side analytics. The IMDS URL is well-known and the same across every region of every provider. The credentials it returns work with full network access.

What stops it

Use the hardened metadata endpoint: AWS IMDSv2 (requires a session token; SSRF-blind requests fail), GCP V1 metadata header requirement, Azure IMDS metadata header. Combine with: tight roles (Topic 02), allow-listing egress, network policies.

Real-worldCapital One (2019) again — the attacker used SSRF in a WAF to reach IMDS, stole the EC2 role's credentials, and used them to read S3. The IMDSv2 hardening that prevents the SSRF path was released by AWS shortly after this breach.
05

Supply chain & shared identity

Hardest to detect

The pattern. An attacker compromises something upstream of your cloud account — a software dependency, a CI/CD pipeline secret, a connected SaaS app's OAuth token, or your identity provider itself. From that vantage point, they don't need to break your cloud's authentication; they already have a trusted credential.

Why it keeps happening

Cloud environments increasingly depend on dozens of upstream trust relationships: GitHub Actions running in your account, Datadog with read-only IAM, Okta as your federated IdP, a third-party vendor with a cross-account role. Each one is a potential entry that doesn't look like an attacker because they have a valid token.

What stops it

Short-lived tokens everywhere (OIDC federation rather than long-lived keys). Tight scopes on third-party integrations. Anomaly detection on identity actions (GuardDuty, Defender, Chronicle). Monitor for impossible travel, unusual API call patterns, new region usage.

Real-worldSolarWinds (2020): trojaned vendor update reached cloud-administered environments. Okta (2022, 2023): support tooling and HAR-file exposure led to downstream tenant breaches. Storm-0558 (2023): stolen Microsoft signing key let attackers forge tokens into M365 tenants.

A pattern across the five

Notice what these have in common: none of them are exploits of provider-side code. They are failures of the customer-side configuration, customer-side identity hygiene, customer-side application code, or customer-side trust decisions. The provider's infrastructure performed exactly as specified in every case — the shared responsibility line was misread.

This is also why "cloud security" is largely a vocabulary translation of pre-cloud security. Least privilege matters in IAM. Default deny matters at network boundaries. Input validation matters in web apps that read external URLs. Trust no input matters in identity federation. The fundamentals never changed; the surfaces did.

The point

Cloud-native threats are not new categories of attack. They are old categories of attack against new surfaces, and they show up in real breaches in roughly the same five flavors year after year.

If you build a habit of asking three questions on every new cloud workload — what does the default give an attacker?, what permissions does this thing have that it doesn't need?, what upstream trust am I relying on? — you've eliminated the leading edge of most cloud breach categories.

References

Formatted in APA 7. Alphabetized by first author's last name.

  1. Amazon Web Services. (n.d.). Configure the Instance Metadata Service (IMDSv2). AWS Documentation. https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/configuring-instance-metadata-service.html
  2. Cloud Security Alliance. (2024). Top threats to cloud computing 2024. https://cloudsecurityalliance.org/artifacts/top-threats-to-cloud-computing-2024
  3. CrowdStrike. (2024). 2024 global threat report. https://www.crowdstrike.com/global-threat-report/
  4. Microsoft Security Response Center. (2023, September 6). Results of major technical investigations for Storm-0558 key acquisition. https://msrc.microsoft.com/blog/2023/09/results-of-major-technical-investigations-for-storm-0558-key-acquisition/
  5. OWASP Foundation. (2021). OWASP top 10: A10:2021 Server-side request forgery. https://owasp.org/Top10/A10_2021-Server-Side_Request_Forgery_%28SSRF%29/
  6. U.S. Cybersecurity and Infrastructure Security Agency. (2021, April 15). Alert AA21-105A: Russian foreign intelligence service (SVR) cyber operations. https://www.cisa.gov/news-events/cybersecurity-advisories/aa21-105a
  7. U.S. Department of Justice. (2019, July 29). Seattle tech worker arrested for data theft involving large financial services company [Press release]. https://www.justice.gov/usao-wdwa/pr/seattle-tech-worker-arrested-data-theft-involving-large-financial-services-company