In the cloud, identity is the blast radius

Network diagrams still dominate how many organizations think about cloud security: virtual networks, subnets, security groups and what is exposed to the internet. Those things matter. Read the public post-incident record of major cloud compromises, though, and a different picture emerges. The way in varies: a server-side request forgery, a stolen password, a forged token. The extent of the damage does not. It is set by the permissions of the identity the attacker obtained.

This brief reviews four publicly documented incidents, draws out the pattern they share and sets out what it means for how cloud security should be assessed. Every account here comes from the organizations’ own disclosures or official investigation reports.

Method and limits

We selected incidents with a detailed public account from the affected organization, its investigators or a government review body, and we stay within those accounts, including on impact. Four cases cannot establish frequencies. They can show mechanisms, and the mechanism here is consistent.

Four documented cases

1. Instance metadata to object storage (2019)

In the Capital One incident disclosed in July 2019, an attacker exploited a misconfigured web application firewall to perform server-side request forgery against the cloud instance metadata service, obtaining temporary credentials for the role attached to the instance. That role had permission to list and read storage buckets containing customer data. The application flaw was the entry point; the role’s broad storage permissions defined the scale. The incident contributed to the industry’s adoption of session-oriented metadata protections such as AWS IMDSv2.

2. Forged tokens from a signing key (2023)

The US Cyber Safety Review Board’s 2024 report on the Storm-0558 intrusion describes how an actor obtained a consumer-account signing key and used it to forge authentication tokens that were accepted for access to enterprise email. The review attributed the outcome to a cascade of security failures in key management and token validation. Here the compromised “identity” was the identity system itself: a key trusted to vouch for users.

3. A test tenant and an OAuth application (2024)

Microsoft disclosed in January 2024 that the actor it tracks as Midnight Blizzard used password spraying to compromise a legacy, non-production test tenant account without multifactor authentication. The actor then used an OAuth application with elevated access to reach the corporate environment, including senior staff mailboxes. A low-value account became high-impact because of what an application identity it could reach was permitted to do.

4. Credentials without a second factor (2024)

Mandiant’s June 2024 report on the campaign it tracks as UNC5537 describes the theft of data from customer instances of a cloud data platform using credentials previously harvested by infostealer malware. The affected accounts did not have multifactor authentication enabled, and some credentials had not been rotated for years. The platform itself was not breached; customer identities were.

The pattern

In each case, a security team that had perfectly configured network controls would still have been compromised, because the attack traveled through legitimate, authenticated interfaces. What determined the outcome was a set of identity questions:

• What could this identity reach, and was all of it necessary?
• Could this identity obtain or impersonate another, more powerful one?
• Was the credential protected by a second factor, bound to a device or short-lived?
• Would anyone have noticed the identity behaving unusually?

Implications for assessment

Measure effective permissions, not attached policies

The question is not which policies are attached to an identity but what that identity can actually do once inheritance, group membership, resource policies, permission boundaries and role assumption are taken into account. Cloud providers offer tools that analyze effective and unused permissions; assessments should use them and then validate the results.

Map privilege-escalation paths

Many cloud privileges are indirectly powerful: the ability to pass a role to a new compute resource, update a function’s code, create access keys for another user or modify a trust policy. An identity holding one of these can often become a more powerful identity. Assessments should enumerate these paths, especially from identities exposed to the internet or to CI/CD systems.

Treat non-human identities as first-class

Workload roles, service principals, OAuth applications and CI/CD tokens commonly outnumber human users and are reviewed far less often. Several of the cases above turned on exactly these identities.

Look at the identity plane itself

Signing keys, federation trusts, tenant-level application consents and break-glass accounts are the crown jewels of a cloud estate. Their management deserves the scrutiny traditionally reserved for production databases.

Test detection as well as prevention

Ask whether unusual use of a powerful identity would be noticed: a role used from a new location, a sudden enumeration of storage, a new consent granted to an application. Detection is what turns an identity compromise from a breach into an incident.

Sources

• Capital One, public disclosures concerning the 2019 cybersecurity incident, July 2019.
• Cyber Safety Review Board, Review of the Summer 2023 Microsoft Exchange Online Intrusion, 2024.
• Microsoft Security Response Center, “Microsoft Actions Following Attack by Nation State Actor Midnight Blizzard”, January 2024.
• Mandiant (Google Cloud), “UNC5537 Targets Snowflake Customer Instances for Data Theft and Extortion”, June 2024.

Our cloud security assessments map every identity path an attacker could take, then test the ones that matter. If you want to know your real blast radius before someone else measures it, talk to our cloud team.